Configure

Personas & tone

A persona is a self-contained configuration that controls tone, goals, tool access, and routing for a specific part of your site. Most customers run one general-purpose persona; teams with complex funnels often run three or four.

What a persona owns

• Name, color, and avatar for identifying it in the dashboard and in chat (see Avatar).
• Role description — a short paragraph that sets the agent's identity (e.g. “Enterprise SDR for B2B SaaS”).
• Tone — friendly, formal, playful, concise, detailed, etc.
• Primary goal — book a meeting, qualify, deflect support, answer pricing, etc.
• Welcome message and proactive greeting overrides.
• BANT profile — what counts as qualified for this persona (see BANT).
• Allowed tools — which integrations this persona can use.
• URL patterns — which pages this persona answers on.
• Job function — the role visitors can ask for by name (“sales”, “support”, “HR”), in chat and on the phone (see Ask-by-function routing).
• Social channels — under Channels → Where visitors reach this persona → Social, claim a connected Facebook Page, Instagram account, or WhatsApp number so this persona answers that channel's DMs and comments (see Assign a persona to each channel).
• Phone numbers — under Channels → Where visitors reach this persona → Phone, assign one or more of the widget's inbound phone numbers to this persona so calls to those numbers are answered by it (see Phone numbers).

Create a persona

Open Personas in the dashboard sidebar and click New persona. A short three-step dialog builds the persona for you — you never start from a blank prompt:

1. Role name & color. Type the role this persona plays (“Sales”, “Technical Support”, “Pharmacist”, “Recruiter” — anything) and pick a bubble color. We use the role to suggest relevant skills on the next step.
2. Skills & desired outcomes. Tick the capabilities and end results this persona should drive toward, add any Additional details in plain English, then click Generate prompt — or Write manually to skip straight to the editor.
3. Review system prompt. Edit the drafted System prompt (or Re-generate it), then click Create persona.

The drafted prompt is about your business, not a generic template. Generation is grounded in the company profile captured when your brand was created — the website analysis that recorded what your company does — and when a brand has no stored profile, Quincer derives one from the same knowledge base your agent already answers from. Either way the prompt describes the real business, and only facts found on your website are stated as specifics — so a “Pharmacist” persona at a compounding pharmacy and one at a national chain come out as two different prompts.

In the dialog above, the ticked Skills and Desired outcomes plus your Additional details are handed to the model to draft the system prompt; nothing is saved until you reach the final review step and click Create persona. The whole editor is then available to refine what you started here, across four tabs:

• Persona — Identity, Voice & phone, System prompt, Agent mode, and — once this persona has its own connected mailbox — a Tools section for how it books meetings and shares files (see Meetings & documents).
• Workflows — the step-by-step processes it follows (see Workflows).
• Channels — where visitors reach it and where your team gets notified (see Channels).
• Knowledge — the content scoped to this persona.

Avatar

Each persona can have its own avatar — the small picture shown next to its messages in the chat. Open a persona and click its avatar to choose from:

• Default — the persona’s initials on its bubble color; no image.
• Company icon — one click sets the avatar to your brand’s own logo, sourced from your website (we look for the site’s touch icon, then its favicon). Shown only when the brand has a website on file. The quickest way to give every persona a branded, consistent look.
• Presets — a set of ready-made illustrated avatars (people and objects).
• Upload image — use your own picture; it’s compressed to a square in your browser before upload.
• Generate with AI — describe the avatar (the box is prefilled from the persona’s name and role) and the AI draws a clean, flat-illustration headshot. When your brand has an accent color set under Customize, generated avatars are nudged to match your palette so they feel on-brand.

The AI illustrator can’t paint a specific logo onto a character (text-to-image garbles real logos and text). To use your actual logo as the avatar, choose Company icon — it uses the real thing.

Channels

Everything about where a persona shows up lives on its Channels tab. The tab is organised by direction — two groups of collapsed rows, plus a dashed group for what isn’t connected yet.

• Where visitors reach <persona> (the group heading uses the persona’s own name) — Inbound. A visitor lands here and the persona picks up. Rows: Website widget (its URL patterns), Email inbox, Phone, and Social. The Add channel button in the top-right corner goes to Integrations, where channels are connected for the whole brand.
• Where your team gets notified — Outbound. Escalations, live pings and summaries — one row per destination. Rows: Slack, Microsoft Teams, Google Chat, Telegram, and Escalate on negative sentiment.
• Not set up yet — a dashed, muted group: Off until you connect them. Nothing here affects the persona today. Anything the brand hasn’t connected sits here as one line with one button (Connect, Assign, Add a number, or Upgrade) — never a greyed-out form you can half fill in. Google reviews also lives here, with a Coming soon pill and a disabled Set up button while Google reviews our Business Profile API access.

A channel only gets a row in one of the first two groups once it exists for this persona — a connected mailbox, a number on the widget, a claimed social account, a connected messaging platform. Until then it is a line in Not set up yet. (The Website widget row is hidden for brands with no website, which route by social account rather than by URL.)

Every row is collapsed, and its one-line subtitle is your saved configuration — not a description of the fields inside. As in the figure above, Website widget reads Activates on /pricing, /demo, Phone reads the numbers routed here, and Slack reads Escalations → #sales-escalation · live → #sales-live · 2 DM recipients. When nothing is set, the line says so in plain language (No URL patterns — this persona is never auto-selected, No number assigned — calls fall back to the default persona). The pill on the right is the state at a glance:

One row is open at a time. Opening a row closes the previous one, and every row starts collapsed — with one exception: a row that needs attention opens itself when the tab loads, because a problem nobody can see is a problem nobody fixes. Five rows can claim that slot — Slack, Microsoft Teams, Google Chat, Escalate on negative sentiment and Phone — and because only one row can be open, the first of those with a problem wins, in that order. (It waits for the Slack, Teams and Google Chat lists to finish loading first, so nothing pops open mid-load.) From your first click onward, you control which row is open.

The one amber pill that opens nothing is Email inbox down in Not set up yet: when inbox monitoring is switched on for this persona but no mailbox is connected, that line carries a Needs attention pill of its own. It is a one-line stub with a Connect button and no form behind it — there is nothing to expand, and it is already fully visible.

One Save for the whole page. No row has a save button of its own; the sticky Save changes bar at the bottom writes every row on every tab. Three controls apply immediately instead of waiting for it: assigning or unassigning a phone number, connecting or disconnecting an inbox, and the Send email as alias picker inside the Email inbox row — choosing an address there saves the moment you pick it, with no Save changes step. (That picker only appears on a Gmail-connected inbox that has verified send-as aliases; see Integrations.)

What each destination asks for

Slack, Microsoft Teams, Google Chat and Telegram are all driven by the same form. On the three that pick a destination from a list, the labels are identical — Escalations go to and Live activity goes to — and only the noun changes: Slack and Teams pick a channel, Google Chat a space. Telegram is the odd one out: its field is labelled Escalation chat ID and is a plain text box you type a numeric chat ID into (like -1001234567890) — no dropdown, and no live target. Which fields a row shows depends on what the platform can actually do:

• Escalations go to — where the persona hands a conversation to your team; team members reply in the thread. On Slack, Teams and Google Chat this is a dropdown, so leave it on None — escalation off to switch escalation off for that platform. Telegram has no such option: its Escalation chat ID is a plain text box, so clearing that box is what switches escalation off there.
• Live activity goes to — keeps proactive pings out of the escalation channel or space. Leave it unset and pings fall back to the escalation target.
• <Persona> can DM — the teammates this persona may message directly, picked as chips. Slack and Teams only.
• Assistant channel (Slack only, optional) — your team can chat with the persona here: a plain post or an @mention is answered in-thread using its knowledge and tools. Invite the agent to the channel first. It counts as a conversation.
• Send these to your team — the three ping chips: New conversations (posted the moment a visitor engages, with a Take over button), Qualified leads (when a lead first gives an email, or their score crosses the qualified threshold), and Conversation summary (see Conversation summaries).

URL routing

Each persona can own one or more URL patterns. When the widget loads, it picks the persona whose pattern matches the current page. If none match, the default persona answers.

Patterns live under Channels → Where visitors reach this persona → Website widget. Expand that row to add, edit, or remove patterns; the collapsed row shows the first few and a count.

You can also hard-pin a persona from the embed snippet (see Shopify install or the deploy page).

Ask-by-function routing

Visitors don't always know a persona's name — they ask for a role instead: “let me speak to sales”, “someone in support”, “is there anyone in HR?” The Job function field on each persona makes that work. When a visitor asks for a function, the AI hands the conversation to a persona that has it — in the chat widget and on voice calls alike. Asking by name (“can I talk to Quinn?”) still works exactly as before and takes priority.

What goes in the field. Pick one of the common functions from the dropdown (Sales, Customer Service, Finance, Recruiting, Human Resources (HR), Technical Support, IT, Reception, Legal, Investor Relations), or choose Other… and type anything (“Onboarding”, “Parts department”) — matching is case-insensitive and tolerant, so “support” finds Technical Support. Leave it on None and the persona is only reachable by name.

Multiple personas with the same function. That's a supported setup, not a conflict: each request for that function is routed to one of the matching personas at random, so conversations spread evenly across the team instead of always landing on the same persona. Use it to run, say, three Sales personas with different styles or territories and let the traffic distribute itself.

Phone numbers

Each persona can have inbound phone number(s) — DIDs — routed to it. An incoming call is routed by the number that was dialed to the persona that owns it, so calls to a sales line reach your Sales persona and calls to a support line reach Support. A number you leave unassigned falls back to the widget's default persona.

How to assign. Open the persona, go to the Channels tab, and expand the Phone row under Where visitors reach this persona. Click Assign to this persona on any of the widget's numbers (or Unassign to release it back to the widget default). This applies immediately — it doesn't wait for Save changes. The persona card in the list then shows the assigned number.

If the widget has no inbound numbers at all there is no Phone row to expand: it appears in the dashed Not set up yet group with an Add a number button instead (see Channels).

Numbers themselves are added under Integrations → Telephony (see Phone numbers). Assigning here only changes which persona answers a call — it doesn't buy or configure the number.

A common pattern is one persona per location or branch, each with its own line — the same persona name and brand voice, but its own number, hours, and escalation.

You can also assign numbers programmatically via the phone-numbers API.

Meetings & documents

When a persona connects its own Gmail or Outlook inbox (under Channels → Where visitors reach this persona → Email inbox), it can also work directly with that account’s calendar and Drive/OneDrive. The persona books meetings on the connected rep’s own calendar and shares documents from their own files — so a persona bound to david@brand.com books on David’s calendar and sends David’s documents, not the widget’s shared account.

Once an inbox is connected, a Tools card appears on the Persona tab — not on Channels. Meetings and documents aren’t a channel; they’re what the persona can do on any channel, so they live with the rest of its behaviour. The card is only shown when this persona has its own connected Google or Microsoft account, and it names the account it’s acting as. It lets you set, per persona:

• Book meetings on — which of the account’s calendars the persona books on. Defaults to the primary calendar.
• Always include attendees — people added to every meeting this persona books, alongside the visitor. Their free/busy is checked too, so a slot is only offered when everyone is free. Start typing a name to pick someone from your people directory or your team, or type a full email address to add anyone else. If someone you picked later leaves the directory, they show highlighted here and the persona will say so rather than quietly booking the meeting without them.
• Meeting platform — add a Google Meet (Gmail) or Microsoft Teams (Outlook) video link to the invite, or choose No online meeting link.
• Share documents from — the Drive/OneDrive folder the persona searches when a visitor asks for a document. Leave it on Entire Drive/OneDrive to search everything, or pick a folder to scope it (e.g. a “Customer-facing” folder).
• Calendly link — the persona’s own scheduling link. This is what fixes the “persona sent the wrong rep’s Calendly” problem — each persona carries its own link instead of the widget’s default. Setting it takes priority over booking on a calendar: when a persona has a link, visitors are sent to it rather than being offered live slots, even if the persona also has a connected calendar. Leave it empty if you want this persona to book real calendar slots.

The card has no save button of its own — these settings are written by the page’s single Save changes bar, along with everything else on the persona.

Existing personas must reconnect. Calendar and drive access was added to the inbox connection later, so a persona connected before then only has mail access. Disconnect and reconnect its inbox to grant calendar + drive; until then the card shows only the Calendly field and a reminder to reconnect. Booking + document sharing from the widget’s shared integrations continues to work as before for personas without their own connected account.

Which system this persona uses

Connect two CRMs — or a calendar alongside a scheduling link — and nothing you could configure decided where a persona actually wrote. That is how a call could end with a Calendly link sent while your real calendar sat connected and marked as the default.

Tools and Skills are different things

On the Persona tab you will find two cards, one above the other. They look similar and they do different jobs:

• Tools decide what this persona can do. Switching a tool off takes the capability away from this persona on every channel — web chat, phone calls and your team channels.
• Skills decide whether it is told how. Switching a skill off removes a written procedure from the prompt and leaves the tool exactly where it was — the assistant can still do the thing, it just isn’t walked through the steps.

Everything is on by default. You never need to switch anything on; the Tools card lists what this persona already inherits from your connected integrations, and switching something off is the only thing it stores.

Each row shows three small icons — Web, Phone and Team — lit where that tool actually runs. Email tools, for example, are not offered during a phone call. Some tools are only offered to signed-in visitors; those are marked too.

If you switch off a tool that a skill depends on, the card tells you before you save — the skill would still be switched on but its instructions would never be used. That warning is why the two controls stay separate.

On the Persona tab, under Skills, a Which system this persona uses card appears once you have more than one connected system of the same kind. It sets, per persona:

• CRM — where contacts, deals and notes are written (HubSpot, Pipeline CRM, or a connected MCP server set up as a CRM).
• Calendar — where meetings are booked and availability is read (Google, Microsoft, Calendly or HubSpot).

The choice applies on chat, voice and the persona’s email inbox, and only to this persona. Two personas on the same widget can write to two different CRMs. That is the point for a multinational: a Europe persona can capture European enquiries into a European CRM while a US persona uses another, so where a customer’s details are stored follows who they spoke to.

Captured leads follow it too. When a lead is captured, it is written to the CRM belonging to the persona that handled the conversation — alongside the lead notification email and the ADF export, as part of the same step. If that person is already in the CRM they are linked rather than duplicated, and a lead with neither an email nor a phone number is not written at all. The end-of-conversation summary follows the same choice.

If the system you picked gets disconnected, that capability switches off. The persona does not quietly fall back to another one — writing a customer’s details into a system of record you did not choose is worse than not writing them. The card shows a warning naming the missing system, and still lets you switch to a different one or clear the choice.

Two things this deliberately does not change. Campaign audience counts still read across every connected CRM, because narrowing who a campaign can reach is a different decision from where a conversation is recorded. And manually linking a contact from the dashboard still works against any connected CRM, because you are choosing the target yourself.

Leave both on Any connected… (default) and the choice is made for you rather than by you: writes go to whichever connected system is ranked first on your Integrations list. The assistant is no longer handed one tool per CRM to choose between — it gets a single set of CRM actions, and the destination is resolved on the server. That is what makes a per-persona choice binding instead of a suggestion.

What this persona is for

Under the system prompt there are three boxes that travel with this persona everywhere it answers — web chat, voice calls, its email inbox, social DMs and public comment replies. They are the difference between an agent that knows its job and one that only knows its personality.

• Successful outcome — what a good conversation ends with. “A booked demo”, or “the caller knows our hours and where to park”.
• Unsuccessful outcome — what counts as a failure even when the chat felt pleasant.
• When this persona escalates — which topics leave its scope, and who takes them.

Each box shows its default. Leave one blank and that default is used; write something and it replaces the default rather than being added to it, so the persona is never given two definitions of success to choose between.

Tone & role tips

The agent is highly responsive to how you describe its role. Specific beats generic.

Prompt review

A system prompt is a plan, and real visitors are the test. Prompt review reads this persona’s newest real conversations and measures the prompt against them: questions the prompt never covers, visitors correcting the agent, and confident claims with nothing behind them. It lives on the persona’s Knowledge tab, in the Prompt review card — run it any time with Run review (Re-run review after the first), and once a persona has real traffic a review also runs by itself monthly, on the 1st of the month.

A persona qualifies for its first review after 50 finished conversations — ones where a visitor actually engaged, and that have since closed or gone idle. The monthly run also waits for at least 10 new conversations since the last review; running by hand just needs something new, and the card says so plainly when there’s nothing to analyze yet. Each review works through the conversations since the last one, newest first, up to 200 per run, with a progress bar — and you can leave the page: an interrupted run resumes where it stopped the next time the card is open (or at the next monthly run).

What it finds — with receipts

A review produces at most 12 findings, each typed — Coverage gap, Hallucination risk, Ambiguity, or Overreach — with a high / medium / low severity. Every finding cites verbatim quotes from the conversations that triggered it, and each quote is a link that opens that conversation — you never have to take a finding on faith.

Hallucination suspects get an extra honesty check before you see them: each suspect claim is looked up against what your knowledge base actually retrieves for that topic, using the same thresholds live chat retrieval uses. A claim your knowledge base backs is dropped — whatever happened there, it isn’t a prompt problem. A confident claim that retrieves nothing is flagged high.

When more than one prompt version answered conversations in the window, the card adds a per-version comparison — conversations, corrections, suspects, and uncovered questions counted for each prompt version, with a small sample flag on any version that answered too few conversations to judge.

Suggestions only ever add

The review’s suggestion is shown as a line-level diff against your current prompt, so you see exactly what would change and where. Applying is additive by construction: Apply changes appends a clearly-marked “Prompt review guidance” section under your prompt, holding one instruction line per finding — it can never delete or rewrite anything you wrote. If a finding argues something should be removed, that edit stays yours to make; the finding tells you what and why. (Show the full merged prompt (what Apply writes) under the diff shows the exact text Apply would save.)

• Nothing changes unless you apply it. A review that just sits there changes nothing on any channel; Dismiss clears it without a trace.
• Every apply is a version. The result is recorded as a new prompt version — Show prompt history under the System prompt card keeps the last 10, with a Restore button on each.
• Edited the prompt since the review ran? The suggestion is marked outdated and can’t be applied — re-run the review so it analyzes what’s actually live.

A suggestion waiting for a decision is hard to miss: it puts a badge on Personas in the dashboard sidebar, a red dot on the persona’s card in the list, and a red light on the persona’s Knowledge tab. Applying or dismissing clears all three.

Workflows

A persona's System prompt defines who it is. Its Workflows define how it handles specific situations — the step-by-step process you'd give a new rep, written in plain English. Each workflow is tied to a trigger (an event), so it only runs when—and where—it should.

Open the Workflows section on a persona and click Add a trigger. For each workflow you pick the event that fires it and write the steps:

In the card above, the When dropdown fixes the trigger event (here New lead captured) and the On toggle enables the rule; you write the steps as a numbered list underneath. The Review & refine button runs the AI checker (see below), and the Tools this persona can use list at the bottom shows exactly which connected integrations you can name in a step. The header pill (2 active) is what you see when the section is collapsed.

A workflow only enters the prompt for its trigger's channel — so a social-comment workflow never clutters a web-chat reply. Write the steps as a numbered list and reference your connected tools by name. For example, on New lead captured:

1. Look the company up on Apollo and note their HQ.
2. If they look like a strong fit, offer to book a meeting.
3. Use the rep for that region — send their Calendly link or check
   Google/Outlook availability and book it.
4. Update the CRM with everything you learned.

Each persona has a tool palette listing exactly which tools it can use (from your connected integrations). A workflow step that names a tool you haven't connected simply won't run, so the palette is the quickest way to see what's available — and to restrict a persona to a specific subset.

Few workflows? The section stays collapsed and just shows how many are active. Expand it to add, edit, enable, or remove them.

Review & refine

Not sure your workflow is clear enough? Click Review & refine under the Workflows box. The AI checks it for clarity, missing steps, and vague conditions, suggests improvements, and — because it knows which tools this persona has connected — flags any step that names a tool you haven't set up (and suggests one you have). It also flags steps whose tool isn't available on the channel — for example a “send an email” step won't run on a voice call (use a conversation summary for that). It proposes a cleaned-up version you can accept with Use this or ignore; nothing is changed unless you choose to apply it.

Conversation summaries

When a conversation ends — a chat that goes idle, or a phone call that hangs up — Quincer can post a summary to your team. There is no separate card for it. Each messaging destination carries a Conversation summary chip on its own row under Channels → Where your team gets notified, and email carries an Email the conversation summary chip on the Email inbox row under Where visitors reach this persona. No workflow needed; it works out of the box.

Each destination is an independent chip — tick any combination, on any number of platforms. The chips share one wrapping row under Send these to your team, and the caption under that label spells out where each one lands: New conversations and Qualified leads post to the live channel or space you picked on that row, while Conversation summary posts to the brand’s conversation-history channel or space, which is set once per integration under Integrations — not on the persona. That’s also the catch: a ticked chip has nothing to post to until that history channel or space exists.

The summary can go to any combination of:

• Slack — posted to your Slack conversation-history channel. The chip starts ticked once this persona has a Slack channel set.
• Microsoft Teams — posted to your Teams conversation-history channel. The chip starts ticked once this persona has a Teams channel set.
• Google Chat — posted to your Google Chat conversation-history space. The chip starts ticked once Google Chat is connected to this brand.
• Email — the Email the conversation summary chip on the Email inbox row. Ticking it reveals Send the summary to for the recipient address(es), comma-separated; leave that blank to send to your team members instead. The email goes out from the brand’s connected Gmail or Microsoft mailbox — the one connected under Integrations — and from Quincer when the brand has none. It is not sent from the persona’s own mailbox: if this persona has an inbox connected, its provider only biases which of the brand’s mailboxes is picked (Gmail or Microsoft). Every summary includes a View conversation button. Off by default — it needs a recipient.

In every case an explicitly ticked or unticked chip wins over the default above.

Each summary includes the visitor/lead details, message count, topics, and a link to the full conversation. It also adds, when available:

• Caller ID and date/time for phone calls.
• Sentiment — when conversation sentiment is enabled for the widget.
• CSAT — the post-chat survey rating, when surveys are enabled and the visitor responded.

Required visitor details

Some actions can’t be done well for “someone” — a support ticket without an email can’t be answered, and a meeting without a name is a calendar mystery. Required visitor details lets a brand declare which identity fields its agents must collect — Name, Email, Company, Phone, Job title — and when to ask for them. It’s off until you configure it, and available on every plan.

The brand-level default lives in Customize & Deploy → AI agent, in the Visitor information card. Tick the fields to require, and the Ask for this information list appears with the moments to collect at:

The timing list mixes two kinds of moment. At the very start, whenever it becomes natural, before sending any email, and before escalating or transferring to a person steer the persona’s behaviour — it’s instructed to ask at those moments. The two marked enforced are stronger: the tool itself checks. Pick no moment at all and “whenever it becomes natural” is assumed, so a configured list always gets asked sometime.

Enforcement is real, not a hint

When required details are missing, the support ticket and meeting booking tools refuse to run and hand the persona an ordered recovery: it’s told exactly which details are missing, forbidden from claiming the ticket was filed or the meeting booked, and instructed to ask for them naturally, save the answers, and only then try again. A visitor who declines gets an honest apology and a promise the team will follow up in chat — never a false confirmation. And a throwaway placeholder email (like test@example.com) doesn’t count as captured — the gate holds until there’s a real address.

The asking itself stays human: one item per exchange, woven into the help the persona is already giving — it never interrogates, and never refuses to help while it waits. Details the conversation already knows — a signed-in visitor’s identity, or anything already captured as lead info — are never asked for again.

On your website, they just fill it in

In the chat widget the persona doesn’t have to ask at all. When details are still missing, a small form appears under the reply with one box per detail — the visitor types them, taps once, and the conversation carries on — and if the persona was waiting on those details to file a ticket or book a meeting, it goes ahead and does it without being asked twice. It shows up in two places: on the first reply (when you’ve chosen At the start of the conversation) and attached to a refusal, so “I need your email before I can file that” arrives with the box to type it in rather than another question.

The form speaks the visitor’s language. Labels and buttons are translated automatically from the visitor’s browser language — a French visitor sees E-mail and Entreprise, a Japanese visitor sees メール アドレス, and Arabic and Hebrew render right-to-left. Nothing to configure: you pick the fields in English, and each visitor sees them in their own language. A language we don’t carry yet falls back to English rather than showing a machine guess on a form asking for someone’s phone number.

Filling the form is never mandatory — there’s a Not now, and declining just returns the conversation to normal (the persona can still ask later if it needs to). Answers are saved exactly as though the persona had collected them: they land on the lead, show on the conversation, notify your team, and sync to your CRM.

Per-persona override. A persona can carry its own list instead of the brand’s: on the persona’s Persona tab, under the System prompt card, the Visitor information to collect (before key actions) selector offers Default (inherit from brand) or Customize for this persona. A custom list replaces the brand’s entirely — the classic case is an HR persona that needs employee details rather than the sales fields the rest of the brand collects.

Guardrails

Every persona has a Boundaries field where you can list things the agent must never do. Typical entries: don't promise pricing, don't make roadmap commitments, always escalate HIPAA or legal questions.

Plan limits

Deleting a persona

Deleting a persona removes it from every channel it was answering on, and permanently deletes its email inbox history — the messages sent and received through that persona’s own mailbox. That part cannot be undone, so the confirmation says so plainly.

You can’t delete a widget’s last persona, and you can’t delete one that a campaign is still using — reassign or delete those campaigns first.

What happens to its knowledge

If the persona has knowledge items of its own, the confirmation asks what to do with them. There is no default: you pick one.

• Delete knowledge — removes those items for good. A large library is removed in the background, so the page doesn’t wait on it; the items disappear from the Knowledge tab as the removal works through them.
• Move knowledge to Shared — keeps the items and makes them available to every persona on the brand.
• Cancel — nothing is deleted.