A persona in Leed is a written description of one kind of buyer, plus one structured field: the buying-committee role that kind of buyer plays. The writing is for your team. The role is for the product — it is the only part of a persona that anything mechanical reads, and getting it right is the difference between a persona that gathers matched contacts and one that sits at zero forever.
Personas live in the Personas section of Engage: open Engage in the left rail and pick Personas from the section picker, or go straight to /engage/personas. The section does not auto-select anything, so it opens on the prompt Select a persona, or create one to segment your audience.
What a persona holds
Nine fields. One is required, one is mechanical, and the other seven are free text that nothing validates and nothing parses.
| Field | Purpose | Counts toward Definition coverage | Hint shown when empty | Acted on by the product |
|---|---|---|---|---|
| Name | What you call this buyer — “VP of Engineering”, “Solo practitioner” | — | Persona name (on the create form) | Shown everywhere; searchable |
| Committee role | The buying-committee role this persona maps to | — | — | Yes — this is the whole mechanism |
| Summary | Who they are and what they care about | Yes | No summary yet. Describe who this persona is and what they care about. | No |
| Goals | What they are trying to achieve | Yes | No goals captured yet. | No |
| Pains | The problems that motivate them | Yes | No pains captured yet. | No |
| Triggers | What makes them start looking | — | What makes them start looking. | No |
| Objections | Why they might say no | — | Why they might say no. | No |
| Preferred content | Formats they engage with | — | Formats they engage with. | No |
| How we measure them | Signals of progress (stored as kpis) | — | Signals of progress. | No |
“Acted on by the product” is a column worth reading twice. Nothing reads Goals, Pains, Triggers, Objections, Preferred content or How we measure them. They are not matched against contacts, not compared to your pages, and not fed to the scoring pipeline. They exist so that everyone writing for this buyer is writing for the same person, and so that the AI assistant has something concrete to work from when you ask it to draft against a persona.
Creating a persona
The + button at the top of the left panel opens the create form, and so does the URL /engage/personas/new directly. Creating needs contact:write, whose minimum role is Content Publisher — a stronger requirement than editing a form carries, and one of the asymmetries roles and permissions explains. Below that role the + is not rendered.
The form is one screen: a Persona name field, a committee-role select beside it, a Summary textarea, then the six block fields two to a row with their own hints.
Editing a persona
A persona reads as a document rather than a form. The summary sits at the top as running prose, the role appears beneath it as a labeled chip, and the six blocks follow, each with its own colored rule and heading.
Every one of them edits in place. Click a block, type, click away — each field saves on its own, with no edit mode, no dirty state and no Save button. An empty block shows its italic hint instead of nothing, which is the difference between “we decided not to write this” and “this is broken”. Editing needs the same contact:write as creating; without it the whole body is read-only text.
Reading the list
The left panel lists every persona under the group label Personas · N, showing the persona’s name, its role as a subtitle, and — on the right of the row — the number of contacts currently matched to it. Search matches the name and the role, nothing else.
Personas do not auto-select. Unlike Accounts and Contacts, opening the section leaves the center card empty until you pick one.
The one thing a persona actually does
During a score recompute, Leed builds a map from committee role to persona: it walks your personas in creation order and keeps the first one that declares each role. Then, for each contact, it takes the role inferred from that contact’s job title and looks it up in the map.
That is the entire matching algorithm, and it has two consequences that nothing in the interface tells you.
The second consequence is quieter: a contact with no job title, or a title Leed’s patterns do not recognize, never matches any persona. The persona could describe them perfectly and it makes no difference; the matcher never reads the text. When a persona you are sure is right shows no matches, the title convention on your contacts is the first thing to check, not the wording.
Why nobody matches my persona
Work down this list in order — it is roughly the order of likelihood.
- No recompute has run since you created it. Matching happens only during a recompute; nothing runs on a schedule. Press Recompute scores in the Engage header and look again.
- The role is Champion or Blocker. Neither is ever inferred from a job title, so a persona set to either can only match a contact whose role was written in through the API. Champion is the create form’s default, which makes this the single most common cause.
- An older persona already claims that role. First persona wins, permanently. Check whether another persona has the same role and was created earlier — the list’s subtitle shows each persona’s role.
- Your contacts have no titles. No title means no role means no persona. Look at a handful of contacts in the segment you expect to match and see whether the Title field is filled at all.
- Their titles do not contain any recognized word. The patterns are substring tests against a fixed list — “Solutions Architect” and “Consultant” match nothing. The full pattern table is on the scores page.
The facet rail
Definition coverage is a donut with three checkbox rows beneath it, reading N of 3 core fields filled (summary, goals, pains). It turns green at 60% — which, over three fields, means two of them.
Matches lists the contacts currently assigned to this persona, sorted by readiness, with a count badge on the facet. Each row jumps to that person’s record in Contacts. Empty, it reads No contacts matched to this persona yet.
Campaigns lists the campaigns whose audience targets this persona, each with a status dot — gray for draft, amber for scheduled, green for active. Empty, it reads No campaigns target this persona yet. Targeting is done from the campaign side, in campaigns and deliverables, and needs the Growth plan like the rest of campaigns.
Actions holds one button, Draft a campaign for this persona. It hands the assistant a written prompt naming the persona and its role and asking for something that speaks to its goals and pain points. It does not create a campaign by itself — it opens a conversation and you take it from there.
Deleting a persona
The Delete action sits in the header beside New persona and needs contact:write. It removes the persona row immediately.
What it does not do is clean up after itself. A contact matched to that persona keeps the stored persona reference on its score until the next recompute overwrites it, so for that window the Match facet on those contacts shows a placeholder like Persona #4 where the name used to be.
Personas from an AI client
Three persona tools are available over MCP, all subject to the same contact:* permissions as the screen:
| Tool | What it does |
|---|---|
list_personas | Lists every persona in the workspace |
create_persona | Creates one; only name is required |
update_persona | Updates a persona by id; only the fields you supply change |
Deletion is deliberately not among them. delete_persona exists but is marked high-risk and assistant-only, so the in-product assistant can offer it behind an approval step while an external MCP client cannot reach it at all. The campaigns and personas tool reference has the argument shapes.