osr-product-sales

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

 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 <their model> --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 model they use today> - 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=<their model>`; the routing audit on their own traffic; the by-target table	The default 90 %+ figure
"We already have a gateway"	`/compare/<gateway>`; 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.

# 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.<domain> --web https://<domain>   # 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.