# Product sales: from a stranger's question to a signed renewal A sales person on this platform sells one thing: **provable control of AI spend and AI risk, one request at a time**. Every claim has a page or an endpoint behind it, and the buyer can check it while you speak. Read `osr-customer-success` for what happens after the deal (activation, retention, the funnel) and `osr-financial-control-plane` for how money moves inside the platform; this skill is the seller's playbook and the buyer's-eye validation of the product. Voice: `docs/BRAND.md` - precise, calm, evidence-led. Never a number you cannot link. ## The pipeline and the artefact at each stage ```text lead ──> discover ──> demo ──> routing audit ──> pilot ──> business case ──> security review ──> proposal ──> won ──> hand-off ──> QBR / renewal ``` | Stage | What the seller does | Product artefact / page | Kit | |---|---|---|---| | Lead | Reads the inquiry, checks the workspace's signals, replies within the plan's response time | `GET /api/v1/admin/sales/inquiries` (`/platform/admin/leads`, `OSR-S-nnnnn`, new -> contacted -> qualified -> won -> lost), `GET /api/v1/admin/pql` (`_pql_signals`: volume, multi-tenant, EU region, private boundary, agentic, multi-team, enterprise e-mail; `qualified` at 3 signals or volume) | - | | Discover | Names the buyer's traffic, models, quality bar, spend, constraints and authority | The catalogue worksheet; `POST /api/v1/estimate` gives an anonymous quote for any prompt shape | `docs/sales/DISCOVERY_GUIDE.md` | | Demo | Ten minutes, real commands, real output; shows the trace, the alternatives and the price before the call | `/platform/playground` (no account: estimate only), `GET /api/v1/trace/{request_id}`, `/compare`, `/rankings`, `/status` | `docs/sales/DEMO_SCRIPT.md` | | Routing audit | Replays the prospect's logged traffic against the router; reports what routing would have cost and where quality holds | `osr audit traffic.jsonl --baseline --monthly N --markdown` (`eval/audit.py`) | `docs/sales/ROUTING_AUDIT.md` | | Pilot | Scope, baseline, data handling, fees, roles, acceptance criteria, exit terms - in writing before the first request | Team plan or a custom plan (`PATCH /api/v1/admin/accounts/{id}` `limits`), `coupons` for a launch trial, `GET /api/v1/savings?baseline=` on **their** model, `/platform/dashboard/impact` | `docs/sales/PILOT_CHARTER.md` | | Business case | Cost saved against the buyer's own baseline, requests handled, success rate, data protected | `GET /api/v1/savings`, `/roi` (same formula), `GET /api/v1/governance/report?format=markdown` | `docs/sales/ROI_CALCULATOR.md` | | Security review | Threat model, data flow, questionnaire answers, DPA outline; edition and BYOK make the answers concrete | `/security`, `/docs/SECURITY`, `/docs/SECURITY_REVIEW`, `/docs/ENTERPRISE`, `GET /api/v1/governance`, `GET /api/v1/audit`, `/.well-known/security.txt` | `docs/sales/SECURITY_PACK.md` | | Proposal | Plan, quota, overage, support tier, SLA, term, price - from the live plan table, never from memory | `GET /api/v1/info` -> `plans` (price, requests, keys, seats, `support_response_hours`, `sla_uptime_pct`, `contact_sales`, `billing_mode`), `GET /api/v1/offers` (per-model prices, `priced_by`), `/pricing` | `docs/sales/PRICING_AND_PROPOSAL.md` | | Won | Checkout or invoice; the workspace is on its plan the same minute | `POST /api/v1/billing/checkout` (Stripe, automatic tax), `billing_mode` `subscription` / `wallet` / `invoice`, `GET /api/v1/billing/invoices`, `/platform/admin/finance` | - | | Hand-off | The customer-success owner gets the pilot charter, the baseline and the promised outcomes | `/platform/admin/accounts/{id}` (*Getting started* card, `nudge`), the activation funnel | `osr-customer-success` | | QBR / renewal | Value delivered against the charter, expansion (tenants, seats, plan), the next pilot | `GET /api/v1/sla` (availability and support against the tier), `/platform/dashboard/impact`, `reports.py` digests | `docs/sales/CASE_STUDY_AND_QBR.md` | The kit lives in `docs/sales/` (index: `docs/sales/README.md`); everything in it is runnable against the repository. Battlecards and the objection sheet: `docs/sales/BATTLECARDS.md` next to the public `/compare/*` pages (`platform/web/src/lib/config/comparisons.ts` - every row names a capability that exists; the pages are walked by `platform/web/e2e/page-quality.spec.ts`). ## What the buyer can verify while you talk Lead with links, not adjectives: - **Price before the call** - `POST /api/v1/estimate {text}` (no key) returns the recommended, cheapest, best-quality and fastest target with tokens, cost, quality estimate and the per-strategy rationale; the playground shows the same. `GET /api/v1/offers` lists every model on offer with list and customer prices per million tokens (`priced_by`: catalogue, rules, contract) and the `pin_syntax` to call one. - **Explainability** - every decision has a trace; the alternatives and rejections are on it. - **Savings** - `GET /api/v1/savings` (`baseline`, `routed_cost_usd`, `baseline_cost_usd`, `savings_pct`, `projected_monthly_savings_usd`, per target and per day). **Always pass `?baseline=`** - the default baseline is the dearest LLM in the catalogue and a buyer who sees "97 % saved" against a model they never used stops believing the rest. - **Status and SLA** - `/status` (components, 90-day uptime, incidents, the monitor's heartbeat), `GET /api/v1/sla` (this month's availability and first-response times against the plan's commitment). - **Governance** - `GET /api/v1/governance` (controls, keys, policy, budgets, posture score with findings) and the evidence pack `GET /api/v1/governance/report?format=markdown`; the hash-chained audit at `GET /api/v1/audit`. - **Honesty markers** - `/changelog` with dates, `docs/ROADMAP.md` readiness table, `ADOPTERS.md` (real production users only), the developer-preview banner when the deployment runs `main`. - **Real client parity** - `/v1/chat/completions` with an OpenAI or Anthropic client, `pip install opensmartroute`, `@opensmartroute/sdk` on npm, the MCP server at `/mcp`, the browser extension and desktop app. ## Plans, quotas and what to sell to whom Read the live table (`GET /api/v1/info` -> `plans`; `platform/api/osr_platform/plans.py` is the source) before every quote; prices and quotas change by release and by operator override. The shape to remember: | Plan | Sell it to | The feature that closes | Watch out | |---|---|---|---| | Free | Developers testing the API | Decisions with the full trace, the `/v1` proxy on the platform's own providers, BYOK | `execute: true` on `/route` and plans (persona -> skill -> model) are Pro and up; the error names the *feature* `plan`, not the tariff | | Pay as you go (`wallet`) | Teams that want every model by the token, no seat | Prepaid credits, price shown before the call is the price on the row after it, auto top-up | No quota wall but also no SLA or support tier | | Pro | A team with steady traffic | Plans, 300k requests a month with overage instead of a wall, a trial, e-mail support | Trial days are on the plan row; a coupon can extend or replace it | | Team | Several teams or customers behind one workspace | Tenants with their own constraints and budgets, hash-chained audit, health and learner statistics, deployment alerts, priority support | `stats` is a deployment-wide feature: on a shared deployment it shows the whole deployment's health | | Enterprise | Regulated or business-critical production | Organization SSO, region pinning, custom quotas and retention, the availability target with service credits in the agreement, dedicated support | `contact_sales`: annual agreement, quoted; never sold from the checkout button | Custom quotas: `PATCH /api/v1/admin/accounts/{id} {"limits": {...}}` marks the plan `custom` and the customer's billing page says so. Trials and discounts: `/platform/admin/coupons` (`coupons.py`; `promotion` in `GET /api/v1/info` is the one quoted on the site). Reseller pricing (buy from providers below list, sell below market): the price books and rules in `osr-financial-control-plane` - a quote for a named model comes from `Pricing.customer_rates`, and `POST /api/v1/admin/finance/quote` prices a request shape with the margin shown. ## Objections and the honest answer | Objection | Answer with | Never say | |---|---|---| | "Routing will hurt quality" | The trace with the quality estimate per candidate, the rankings (Wilson lower bound on reported outcomes), a pilot with *their* quality bar as the acceptance criterion, `osr eval --frontier --min-accuracy` | "Quality is guaranteed" | | "Your savings number is inflated" | `?baseline=`; the routing audit on their own traffic; the by-target table | The default 90 %+ figure | | "We already have a gateway" | `/compare/`; the difference is the decision (learned, explained, governed), not the proxy | Anything about a competitor's roadmap | | "Our data cannot leave the region / the building" | Region pinning, `data_boundary: private`, BYOK to their endpoints, the on-prem `osr serve` image and Helm chart, the enterprise edition's audit chain | "We never see your prompts" (the platform sees what it routes; say what it stores and for how long) | | "Is this real / who else uses it?" | `/status`, the changelog, `ADOPTERS.md` as it stands, a live request in the playground | A customer name that is not in `ADOPTERS.md` | | "What if you go down?" | `GET /api/v1/sla`, the 90-day uptime strip, the incident history, the self-hosted fallback (same image) | An uptime figure the status page does not show | | "Prove the security posture" | `docs/sales/SECURITY_PACK.md`, `/docs/SECURITY_REVIEW`, `GET /api/v1/governance/report`, `/.well-known/security.txt` | "SOC 2 certified" or any certification not held | | "Too expensive" | The plan row against their volume: overage instead of a wall on Pro, pay as you go by the token, the price shown before each call | A discount that is not a coupon on the record | ## Validating the platform as a buyer Do this walk before a launch, a release or a pricing change, and whenever a prospect reports a rough edge. Production is read-only except a throw-away workspace that is deleted at the end; the buying journeys run on the dev stack. ```powershell # 1. Prospect on production (read-only): facts, pages, pricing claims, procurement artefacts # GET /api/v1/info (plans, promotion, billing), /status, /status/board, /legal, /services, /offers, POST /estimate # every page a prospect opens (/, /pricing, /compare/*, /roi, /security, /status, /enterprise, /solutions, # /docs, /contact, /support, /terms, /privacy, /changelog, /platform/signup, /platform/playground) # /pricing must show every plan price the API returns; /.well-known/security.txt, /sitemap.xml, /llms.txt answer # 2. Customer on the dev stack (writes): signup -> verify -> first route -> execute on free (403 with the feature # named and X-Upgrade) -> /v1/chat -> quota -> savings -> billing/subscription -> checkout -> coupon -> # wallet -> invoices -> support ticket -> sales inquiry (reference back, operator notified, in /admin/leads) # -> governance report -> billing cancel -> the activation funnel shows the workspace # 3. Fresh free customer on production: admin creates a workspace, verifies the owner (stand-in for the mail # link), mints a key, three /v1/chat prompts (model chosen, latency, an answer a person would accept), # /route decision and execute, /sla, /quota, /savings, /governance; DELETE the workspace in a finally python -X utf8 platform/api/scripts/smoke.py --api https://api. --web https:// # the platform's own smoke ``` What to write down for every step: status, time, the exact text the customer saw, and whether a buyer would accept it without opening the docs. The register of what this walk found and what was changed: `SALES_AND_CUSTOMER_GAP_AUDIT.md` (dated; add a section per walk, never rewrite history). Tests that keep the seller's claims honest: `tests/test_use_cases.py` (every use case runs), `platform/api/tests/test_platform_docs_claims.py` (every documented endpoint and page exists; the changelog reads for customers), `test_admin_extras.py` (activation funnel, PQL), `test_sales_inquiries.py` (inquiries, notices, the operator queue), `test_plan_entitlements.py` (what each plan unlocks), `test_billing.py` (checkout, coupons, invoices, wallet), `platform/web/e2e/sales.spec.ts`, `billing.spec.ts`, `customer-journey.spec.ts`, `page-quality.spec.ts` (every public page incl. `/compare/*`). ## Handing a deal to the product A sales gap is only real when a buyer said it or the walk showed it. File it with: who (segment), the exact words or screenshot, the page or endpoint, what a buyer expected, the stage it blocked. Product changes go through the owning skill (`osr-product-experience` for screens, `osr-financial-control-plane` for prices and credits, `osr-customer-success` for onboarding and trust, `osr-platform` for the API) and land in `CHANGELOG.md` under `[Unreleased]` in customer words. A closed gap gets its evidence (test, screenshot, endpoint answer) in the register. ## Do not - Do not quote a price, quota, SLA or support time from memory; read `GET /api/v1/info` or `/pricing` and paste. - Do not promise a saving; show the ledger against the buyer's own baseline and let the pilot prove it. - Do not name a customer, a certification, an integration or a roadmap date that the repository cannot show. - Do not give a discount, a trial or a custom quota outside the platform (a coupon, a plan override or a contract row on the record) - finance reconciles against those, not against an e-mail. - Do not e-mail anyone who did not ask (see the consent rules in `osr-customer-success`); the inbound inquiry and the workspace's own signals are the pipeline. - Do not run the production probe without the `finally` that deletes the throw-away workspace.