Documentation · Replicate Labs

The product, page by page. Every page is also served as Markdown, so the same words reach the models a team works in.

Administration

Building roleplays

Composing a roleplay from a persona, a scorecard and a product, the order things must be built in, and how to make one feel like a real call.

A roleplay is a binding of configured objects. Build the parts, then bind them.

#Build order

The order matters, because two of the objects are prepared asynchronously and a roleplay cannot bind something that is not ready.

1PersonaThe buyer. Required.
2ProductOptional. Prepared asynchronously, so create it before you need it.
3ScorecardRequired. The standard the conversation is graded against.
4RoleplayBinds persona and scorecard, optionally a product, plus the scenario itself.
Four objects, in order. Attempting the binding before a product has finished preparing is the usual first-time stumble.

#The persona

Covered in detail in Personas. The fields that most change the conversation:

The persona configuration screen listing the buyers on an account
Personas on an account. Build the buyers your team actually meets, then bind them into scenarios.
  • Responds well to and responds badly to. These do more work than anything else. Write them from real buyers: what actually opens your buyers up, and what actually shuts them down.
  • Industry knowledge. How much they already know about your category. Get this wrong and a first-meeting scenario plays like a bake-off, or the reverse.

A persona can carry an avatar so it appears on camera as a person.

#The scenario

There is no difficulty setting. The scenario is expressed through three things.

Starting sentimentWhere the buyer begins. Sceptical, neutral, warm, actively defensive.
Sentiment driftWhich way they move as the conversation goes on, and what moves them. This is what makes it feel like a call rather than an interrogation.
Custom instructionsThe specifics of this encounter. What has already happened, what they are not going to volunteer, what they will do if pushed on price.
The scenario is three fields. Drift is the one most often left at default and the one that most improves realism.
Design the drift, not the difficulty

"Hard" is not a useful target. A buyer who starts sceptical and warms only if the rep quantifies the problem teaches quantifying. A buyer who starts polite and cools as the rep presents features teaches restraint. Decide what the roleplay is for, then set the drift so that behaviour is the thing that moves it.

#Binding and publishing

The roleplay binds the parts. Once built you can publish it so it appears for reps, and deploy it across a team so everyone runs the same scenario.

Configured roleplays showing the persona, scorecard and product bound into each
Configured roleplays. Each row shows what it binds: the buyer, the standard it grades against, and the product in play.

Publishing to a team is how you get comparable results. Keep the scorecard stable while a cohort works through it, or the comparison is not a comparison. See Scorecards.

#Making one that reps take seriously

Do
  • Build from a conversation your team actually has this quarter.
  • Put a real objection in the buyer's own words into the custom instructions.
  • Give the buyer something specific to withhold until it is earned.
  • Match the scorecard to the conversation type. A discovery scorecard on a negotiation scenario marks reps down for the wrong thing.
Do not
  • Build a generic difficult buyer. Nobody sells to one.
  • Reuse another organisation's scenario unedited. The specifics are the whole value.
  • Make the buyer uniformly hostile. It is not harder, it is just unwinnable, and reps stop running it.
  • Ship a scenario nobody has run end to end at least once.

#Reps can build them too

Where enabled, reps can turn a real situation into a roleplay from inside the coach. That is usually the best source of scenarios you have, because it comes from a conversation someone actually had. Review what they build and promote the good ones to published.

Last updated 3 September 2026

View as Markdown