# Personas

What a persona is configured from, how those settings show up in the conversation, and what makes one worth practising against.

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

---

A persona is the buyer in a roleplay. It is a configured object, not a prompt someone wrote once, and the fields it carries map directly onto behaviour you will feel in the conversation.

## What a persona is made of

<figure class="dfig">
<div class="dframe">
<div class="danat">
<div class="danat-row"><b>Role and title</b><span>Who they are and what they are accountable for. Sets what they care about and what they will happily ignore.</span></div>
<div class="danat-row"><b>Personality</b><span>How they behave in a conversation. Brisk, sceptical, discursive, deferential. This is the texture you notice in the first thirty seconds.</span></div>
<div class="danat-row"><b>Responds well to</b><span>What opens them up. Specific numbers, peer examples, being asked about their own targets, brevity.</span></div>
<div class="danat-row"><b>Responds badly to</b><span>What closes them down. Feature lists, being sold to before being understood, jargon, an early price conversation.</span></div>
<div class="danat-row"><b>Industry knowledge</b><span>How much they already know about your category. A buyer who has evaluated three vendors behaves nothing like one who has never considered the problem, and this is the field that decides which you get.</span></div>
</div>
</div>
<figcaption><b>Persona fields.</b> "Responds well" and "responds badly" are the two doing most of the work in a live conversation.</figcaption>
</figure>

## Where the material comes from

Personas are configured per account, because a persona who is not recognisably your buyer wastes the rep's time.

Good ones are built from things the organisation already has: the titles you actually sell to, the objections that keep coming back, the incumbent you keep displacing, the reasons deals in your business genuinely die, and where relevant a specific live opportunity's own history.

That last case is the strongest. A persona carrying a real deal's history knows what was said on the last call, which turns a rehearsal from theoretical into specific.

## Study the buyer before you practise

The Training Lab lists the personas on your account separately from the roleplay scenarios, and you can open one to read their profile: what they are accountable for, what opens them up, what shuts them down, and the topics they are currently preoccupied with.

<figure class="dshot">
<img src="/img/docs/rep-persona-profile.webp" alt="A persona profile showing what the buyer responds well and badly to" width="1440" height="900" loading="lazy" />
<figcaption><b>A persona profile.</b> What they are accountable for, what opens them up and what shuts them down, before you ever speak to them.</figcaption>
</figure>


Doing this before you run a scenario for the first time is worth the three minutes. Most reps who feel a roleplay went badly went in without knowing who they were talking to, which is not a mistake they would make before a real meeting.

## Choosing one

Pick the persona for the conversation you are about to have, not the one that will go well.

<div class="dsplit">
<div class="dpanel yes">
<div class="dpanel-h">Useful</div>
<p>"I have a first meeting with a finance director who has already told my champion the timing is wrong."</p>
</div>
<div class="dpanel no">
<div class="dpanel-h">Comfortable</div>
<p>"I will practise against the enthusiastic champion again because I did well last time."</p>
</div>
</div>

## Personas have faces

A persona can carry an avatar, so it comes up on camera as a person rather than a name. This matters more than it sounds: rehearsing eye contact and reading a face are part of the conversation you are practising for.

## Getting one added or changed

Personas are part of account configuration. If your team is meeting a buyer that no persona covers, or an existing one behaves in a way your real buyers do not, that is a configuration request rather than something changed from the rep surface.

Give your administrator the specifics: the title, what actually opens them up, what shuts them down, and a real objection in the buyer's own words. Those map straight onto the fields above. See [Building roleplays](/docs/admin/roleplay-config).
