Roleplay scenario builder

Give sellers a realistic opportunity to practise a specific behaviour, receive evidence-based feedback, and try it again.

A scenario tests one behavior under one pressure. A recorded-call review is call-review-coach. A pass/fail gate is certification-program-builder.

Practice. Participant sees: "VP Ops, 12 minutes, they already have a process." Facilitator holds: they will not name the cost until you ask who owns the escalation. Score: did the rep diagnose before pitching.

Weak scenario. A four-page buyer bio, a memorized script, and "be more consultative" as the score.

If the participant can succeed by performing confidence instead of the target behavior, it is not a drill.

Inputs

Reuse supplied context first. If a missing company fact would change the result, check the relevant sections of .enablement/context.md when available. Preserve source dates and approval limits.

Ask only for the inputs that change the drill:

1. Who is practicing, and which one behavior must change
2. Segment, persona, and stage
3. Difficulty: baseline, stretch, or advanced
4. Timebox, participant count, and who facilitates
5. Whether a pass threshold already exists. If the result controls readiness, route the standard to certification-program-builder

Label fictional company and buyer details as invented. Do not present them as real customers, competitors, or proof.

Supporting material

Read references/roleplay-scenario-framework.md for tension design, reveal rules, and worked pass/fail excerpts. Skip it if the user already has a scenario and only wants the scorecard or run protocol.

Procedure

1. Name the behavior and the evidence that would prove it. Separate a critical failure from a coachable miss. Done when a facilitator can see the behavior without inferring mindset.
2. Build one focused scenario. Add a progression only when asked, changing one difficulty variable at a time.
3. Ground it in field evidence when you have it. Anonymize. Invented details stay labeled.
4. Split the briefs. Participant sees what a seller would reasonably know. Facilitator holds hidden blockers, reveal conditions, anchors, and escalation cues. Done when nothing in the participant brief gives away the test.
5. Write the pressure the behavior has to survive. One unexpected turn. Buyer responses follow what the seller does, not a memorized dialogue.
6. Write the run protocol. Set roles, timebox, reveal rules, observation, and debrief order. Choose coached practice or an unassisted observation round to suit the objective. Participants should know whether the facilitator may pause and coach; assessment conditions must follow the supplied standard.
7. Anchor the score to visible behavior. Cite what happened. Use a supplied pass rule; do not invent one. In a certification, supply only the scenario and evidence prompts.
8. Debrief and retry. Ask the participant what they noticed. Give evidence-based feedback on the target behaviour, then rerun the relevant moment. Compare attempts and agree where to apply the change in live work.

For a real call use call-review-coach. For a discovery baseline use discovery-rubric-auditor. For the gate itself use certification-program-builder.

What to return

For a full scenario, include the items below. For a revision or short drill, return only the material needed to run it:

• One scenario, or a progression that changes one variable at a time
• Participant brief: context, objective, constraints, visible success criteria
• Facilitator-only guide: hidden facts, reveal conditions, timing, cues
• Buyer responses tied to seller behavior
• Observable anchors, critical failures, and a pass rule only if one was supplied
• Run protocol and debrief that ends in one next-practice action

Do not leak facilitator facts. Do not issue a readiness decision.

Quality bar

• One target behavior, visible without scoring personality or confidence.
• Participant brief and facilitator guide do not share hidden facts.
• At least one turn the seller cannot script in advance.
• Feedback cites what happened and names one retry.
• Fictional proof stays labeled. No invented customer result.
• The facilitator can compare the first attempt with the retry and name what changed.