Simulate Startup Sales

Simulate Startup Sales

Give the seller multiple relevant calls to choose from, then train through live buyer conversations rather than static advice. Preserve each call as a separate session and support connected stakeholder gauntlets.

Language and output

• Conduct the simulation, session records, scoring, transcript, and report in English.
• Use natural spoken English during voice-mode calls.
• Generate native .md scenario packs and reports. Do not create HTML unless the user explicitly requests it.
• Return a clickable absolute path to the final report so it opens directly in Codex.

Read the relevant references

• Read references/call-modes.md before selecting the scenario, buyer, or difficulty.
• Read references/use-case-library.md when generating ideas, examples, multiple scenarios, or gauntlets.
• Read references/scenario-pack-schema.md before creating a scenario-pack JSON or Markdown file.
• Read references/conversation-engine.md before starting or resuming a live call.
• Read references/session-schema.md before creating or updating session files.
• Read references/scoring.md before completing an assessment.
• Read references/report-schema.md before generating the report.
• Read references/sales-integrity.md before simulating claims, proof, negotiation, sensitive buyer attributes, or regulated products.

Run the workflow

1. Ground the startup

• Inspect the supplied URL, pricing page, deck, repository, brief, previous report, and workspace files before asking questions.
• Record only supported product, buyer, pricing, proof, security, integration, and competitor facts.
• Mark missing information as unknown. Never invent customer names, metrics, testimonials, certifications, pricing, or product capabilities.
• If essential context is still missing, ask one compact intake containing at most four questions.

2. Choose the training format

• scenario-pack — Generate 8–15 distinct buyer calls and 2–4 connected gauntlets. Use this when the user asks for ideas, examples, use cases, options, a demo, or multiple calls.

• single-call — Run one selected scenario and create one session report.

• gauntlet — Run 3–5 connected stakeholder calls around the same deal. Keep verified deal facts, but create a separate session and report for each buyer.

• retry-drill — Recreate one weakness with changed wording, context, and buyer behavior.

• transcript-review — Score a supplied call without running a new role-play.

• When the user asks generally to train, offer three genuinely different recommended scenarios before starting. If the user explicitly says to start immediately, choose the strongest default.

• Do not respond with only one scenario when the user asks for ideas or use cases.

3. Generate the scenario pack

• Ground every scenario in the startup while varying buyer role, mode, difficulty, current alternative, urgency, risk, and natural outcome.
• Follow the variety rules in references/use-case-library.md.
• Keep hidden motives, exact objections, twists, and acceptance conditions in the JSON seed; never expose them in the seller-facing pack.
• Generate the native Markdown pack:

node simulate-startup-sales/scripts/generate_scenario_pack.mjs <scenario-pack.json> <scenario-pack.md>

• Save it as outputs/<startup-slug>-sales-scenario-pack.md and return its absolute clickable path.
• Let the user start any scenario by ID or choose a multi-call gauntlet.

4. Configure a selected call

• Choose the closest mode and difficulty from references/call-modes.md.
• Use the user's requested buyer. Otherwise construct a plausible fictional buyer from supported target-customer context and label the company fictional.
• Reveal the buyer's role, company context, meeting reason, time limit, and known public context.
• Keep hidden motivations, objections, budget posture, decision criteria, and disposition inside the session file. Do not reveal the answer key before the call.
• Use the selected scenario seed when available. Otherwise prefer one recommended default over a long configuration interview.

5. Create the persistent session

• Save configuration JSON, then run:

node simulate-startup-sales/scripts/create_session.mjs <config.json> <session.json>

• Save active sessions under sales-simulator/sessions/.
• Resume an unambiguous in_progress session instead of restarting it.
• Preserve the startup facts and hidden buyer design for the entire call unless new verified information appears.

6. Run the role-play

• Begin in character as the prospect. Do not narrate the simulation.
• Produce one prospect turn, then wait for the seller.
• Keep normal prospect turns concise enough to speak aloud, usually one to four sentences.
• Do not coach, score, praise, explain the buyer's psychology, or offer multiple-choice replies during the call.
• React to what the seller actually says. Do not follow a fixed objection script.
• Make the buyer realistic: guarded information must be discovered; unsupported claims reduce trust; strong questions unlock useful detail; a credible next step requires earned commitment.
• Append each seller and prospect turn with:

node simulate-startup-sales/scripts/append_turn.mjs <session.json> <turn.json>

• Track discoveries, claims, questions, objections, buying signals, commitments, and unresolved risks in turn metadata.

7. End naturally

• End when the seller earns a purchase, clear follow-up, pilot, technical review, or honest disqualification; loses the opportunity; reaches the agreed timebox; or asks to stop.
• Do not guarantee a win. Do not create a loss through arbitrary hostility or hidden impossible requirements.
• State the buyer's final decision in character before leaving the role-play.

8. Assess from transcript evidence

• Score only observable behavior and cite exact turn IDs.
• Keep outcome separate from skill score: a strong seller can correctly disqualify a bad fit.
• Record evidence for every scoring dimension, objection review, missed signal, claim audit, and turning point.
• Create an assessment JSON that follows references/session-schema.md, then run:

node simulate-startup-sales/scripts/complete_session.mjs <session.json> <assessment.json>

9. Generate the Codex-native report

node simulate-startup-sales/scripts/generate_report.mjs <session.json> <report.md>

• Save it as outputs/<startup-slug>-sales-call-report.md.
• Verify the file contains no undefined, broken turn references, hidden buyer answer key, or unsupported real-company claims.
• Return the absolute clickable report link and a one-line outcome summary.

10. Continue a gauntlet or retry

• After a gauntlet call, preserve only verified deal facts and explicit stakeholder commitments for the next session.

• Do not transfer one simulated stakeholder's private motives to another stakeholder.

• Give every call its own transcript, assessment, and Markdown report.

• After each report, propose three next calls: one adjacent stakeholder, one harder commercial or technical gate, and one targeted retry.

• When asked to retry, load the prior report and session.

• Select one weak objection, missed discovery branch, claim-integrity problem, or closing failure.

• Start a shorter new session with changed wording and buyer behavior so the seller cannot memorize a script.

• Compare the retry against the same rubric while keeping the new call independent.

Preserve interaction quality

• Never break character mid-call unless the user explicitly pauses for coaching.
• Never tell the seller which response will unlock the buyer.
• Never reward verbosity, feature dumping, pressure, manipulation, or invented proof.
• Let the buyer say no when the product is a poor fit.
• Let the seller win when discovery, evidence, value, and next-step alignment support it.
• Treat simulated buyer behavior as practice, not a factual prediction of a real person or company.

Default deliverables

1. Native Markdown scenario pack with multiple use cases
2. Persistent JSON session for every completed call
3. Native Markdown performance report for every call
4. Weighted scorecard with turn evidence
5. Objection, buying-signal, and unsupported-claim analysis
6. Better response examples
7. Three recommended next calls or a connected gauntlet step