# 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.

Source: https://replicatelabs.ai/docs/admin/roleplay-config
Last updated: 2026-09-03

---

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.

<figure class="dfig">
<div class="dframe dark">
<div class="dflow">
<div class="dstep"><span class="dstep-n">1</span><b>Persona</b><span>The buyer. Required.</span></div>
<div class="dstep"><span class="dstep-n">2</span><b>Product</b><span>Optional. Prepared asynchronously, so create it before you need it.</span></div>
<div class="dstep"><span class="dstep-n">3</span><b>Scorecard</b><span>Required. The standard the conversation is graded against.</span></div>
<div class="dstep"><span class="dstep-n">4</span><b>Roleplay</b><span>Binds persona and scorecard, optionally a product, plus the scenario itself.</span></div>
</div>
</div>
<figcaption><b>Four objects, in order.</b> Attempting the binding before a product has finished preparing is the usual first-time stumble.</figcaption>
</figure>

## The persona

Covered in detail in [Personas](/docs/roleplay/personas). The fields that most change the conversation:

<figure class="dshot">
<img src="/img/docs/admin-personas.webp" alt="The persona configuration screen listing the buyers on an account" width="1440" height="900" loading="lazy" />
<figcaption><b>Personas on an account.</b> Build the buyers your team actually meets, then bind them into scenarios.</figcaption>
</figure>


- **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.

<figure class="dfig">
<div class="dframe">
<div class="danat">
<div class="danat-row"><b>Starting sentiment</b><span>Where the buyer begins. Sceptical, neutral, warm, actively defensive.</span></div>
<div class="danat-row"><b>Sentiment drift</b><span>Which 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.</span></div>
<div class="danat-row"><b>Custom instructions</b><span>The specifics of this encounter. What has already happened, what they are not going to volunteer, what they will do if pushed on price.</span></div>
</div>
</div>
<figcaption><b>The scenario is three fields.</b> Drift is the one most often left at default and the one that most improves realism.</figcaption>
</figure>

<div class="dnote key">
<span class="dnote-h">Design the drift, not the difficulty</span>
<p>"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 <i>for</i>, then set the drift so that behaviour is the thing that moves it.</p>
</div>

## 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.

<figure class="dshot">
<img src="/img/docs/admin-roleplays.webp" alt="Configured roleplays showing the persona, scorecard and product bound into each" width="1440" height="900" loading="lazy" />
<figcaption><b>Configured roleplays.</b> Each row shows what it binds: the buyer, the standard it grades against, and the product in play.</figcaption>
</figure>


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](/docs/roleplay/scorecards).

## Making one that reps take seriously

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

## 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.