Playbooks

Playbooks let you personalise the AI agent from where the visitor is, how they arrived, and what you already know about them — without adding a second lead form.

Each playbook is a rule you write in the editor: when these conditions are true, then apply these journey effects. More than one playbook can match the same chat. When that happens, the matching cards stack for the rest of the session rather than competing for a single winner.

The order of the cards still matters, but not because only the first one fires. Order is priority for the things a chat can only have one of: which specialist agent to use, which hours mode to overlay, and which CRM lead source to send. Prompt text from every matching card is kept and combined. The AI does not choose a playbook — your rules do.

Think of the cards as layers you can mix, not as mutually exclusive scripts. A campaign card can add extra instructions and a lead-source label, while a country card pins the International Admissions specialist. Put more specific cards (a named campaign, a single country) above broader ones (any /study/ page, or a catch-all).

What this is

A playbook is a journey overlay for one chat session. It does not replace your specialist agents, visitor profile, or staffed hours. It sits on top of them for visitors who match the conditions you set.

Example uses

• Someone arriving from an India open-day campaign should talk to International Admissions, receive campaign-specific instructions, and be tagged in the CRM as that campaign.
• Visitors on nursing course pages should be asked for an email before a callback, without changing the agent for every other page on the site.
• After hours, a campaign landing page can offer Human-Supported AI even when the weekly schedule for the rest of the site is AI Only.

What to use instead

Playbooks are easy to confuse with nearby features. If you are trying to do one of the following, use the tool in the right-hand column instead.

Visitor profile vs playbook. The visitor profile stores facts about the person (name, email, campus). A playbook decides the journey from the page, campaign, country, how the chat is embedded, staffed hours, and those facts. A capture override on a playbook only changes how fields are collected in this session. It does not change the visitor-profile defaults for everyone else.

Page pin vs playbook agent pin. Put data-agent-id on a page that must always use one specialist — for example an installer finder that should never go through Frontline. Use a playbook pin when the specialist depends on campaign, country, or another matcher, or when you also need extra instructions, a capture change, an hours overlay, or a CRM lead source.

How it works

Each time the visitor sends a message, the AI agent looks at what is true right now for this chat:

That snapshot is rebuilt every turn from the live page, location, hours, and profile. It is not a form the visitor fills in, and it is not saved as a separate “playbook context” record. What is remembered on the session is which playbooks have already matched, plus the combined effects (prompt, capture, agent, hours, lead source).

Then the following happens, in this order:

1. Disabled playbooks are skipped.
2. Every enabled playbook whose When conditions match this turn is collected, in the order the cards appear in the editor.
3. Those playbooks are added to the session’s active layers. Layers are sticky: once a campaign playbook has matched, it stays even if the visitor navigates to a page that no longer has the UTM tags. New facts can add a layer — for example a CRM lookup filling in an email — but they never remove one.
4. The active layers are applied using today’s saved playbooks, still in list order. If you have since turned a playbook off or deleted it, it is skipped here, but the session still remembers that it matched.

How effects combine

When several layers are active, their effects are merged. List order is priority: card #1 is highest. For anything a chat can only have one of, the first active card that sets it wins.

Keep campaign and country wording on the playbook. Shared identity and tone still belong in prompt components. Do not put journey text into agent prompt files.

How to configure it

Open Configuration & Design → Playbooks on the service card. This editor is always available; it is not behind the visitor-profile editor flag.

Add and order rules

1. Click Add playbook.
2. Set an id like intl_open_day. It must start with a lowercase letter, then letters, numbers, or underscores, and be no more than 64 characters. Each id must be unique.
3. Use the enable switch to turn a rule off without deleting it. New chats will not match a disabled rule. Chats that already matched it keep the sticky id, but the effects are skipped until you turn it back on.
4. Use the up / down arrows to set priority. Card #1 is applied first for agent, hours, lead source, and the order of prompt fragments.
5. Click Save playbooks.

When (matchers)

Choose All match if every condition must be true, or Any match if at least one is enough. Click Add condition to add rows.

A playbook with no filled conditions matches everyone. Use that only as a last-card catch-all, underneath more specific rules.

Matching ignores capital letters. If a condition row is left blank, it is ignored and does not count.

Then (effects)

Leave any effect blank to skip it. A blank effect does not block other matching cards: a URL card can change capture while a campaign card adds a prompt.

Playbooks do not create CRM records themselves. A CRM lookup is search-only. Writes still follow the usual visitor-profile CRM sync.

Match preview

At the bottom of the editor, paste a page URL and optional country, then click Preview. This does not call the AI. It lists every enabled playbook that would match this hypothetical visitor.

Preview is a “what would match right now” check. It does not replay sticky history from a live chat, and it does not simulate city, embed, hours, or CRM attributes. For those, use a live Admin Chat session.

Testing

The aim of testing is to confirm two things: that the right cards match, and that the combined journey is what you intended (prompt, agent, hours, capture, and CRM label). Match preview is the quick check for URL and country. A live Admin Chat session is how you see stacking, sticky layers, and everything the preview cannot simulate.

Start with Match preview in the Playbooks editor. Paste the campaign landing-page URL, including UTM tags if the rule depends on them, and type the country if the rule is geo-based. You should see every matching playbook listed, not only the first card. If a catch-all is also listed, that is expected — check that it sits below the specific cards and that its effects are the ones you want to fill in when a more specific card left them blank.

Then open Admin Chat for the same service. Admin Chat conversations do not affect Insights or quota, so they are safe to use as a sandbox. Set the chat URL to the campaign page (again including UTM query parameters). Send a normal visitor question. If the playbook also depends on a visitor-profile field that only appears after a CRM lookup, send a second message after identify has had a moment to run — the first answer may not yet include those fields.

Open the Trace Log from the widget (the document icon, or the backtick key in fullscreen). Look for a Playbook match step. It lists all active layer ids for this session, plus the specialist, hours overlay, and CRM lead source that were chosen from those layers. If a campaign layer is missing, the URL probably did not include the UTM tags. If an extra layer is present, check whether a broader card also matched and whether that is what you wanted.

If you set prompt fragments, open the expert-agent payload in the same Trace Log and confirm there is a Journey instructions section. Each stacked playbook should appear under its own heading. If the specialist is wrong, check whether a data-agent-id on the page is pinning the session (that pin always wins), or whether a higher-priority playbook named a different live agent.

Country rules on a live chat use the tester’s own network location. You do not need to travel to test them: use Match preview and type the country, or test from a network in that country if you want to see the live path end to end.

Precedence

When more than one mechanism could apply, this is the order that wins:

1. Page agent pin — data-agent-id on the script tag (or the equivalent agent_id on the protocol), once it has been set for the session.
2. Playbook agent pin — the highest-priority active layer that names a live specialist. Ignored if a page pin is already set.
3. Frontline Delegate — usual specialist routing from role descriptions, when nothing has pinned the session.
4. Handoff mode — the Hours control in Desk settings, then the highest-priority active playbook overlay, then the weekly schedule (or manual desk mode).
5. Visitor-profile attributes — what the visitor said (or the follow-up extract). A CRM lookup fills empty fields only; it does not overwrite a value from the chat.

Important limits

• Layers are sticky. Once a playbook matches this session, it stays even if the visitor changes page, campaign tags drop off the URL, or hours roll over. New matches add layers; they do not replace the ones already active.
• A CRM lookup can add a layer later. That lookup runs in the background after the session is identified, and does not delay the first answer. A playbook that matches on a hydrated field (for example email) can join on a later turn without dropping URL or country layers. Do not rely on CRM fields for the opening reply.
• CRM lead source freezes after the first successful write. A later higher-priority layer will not change the label already sent.
• Persist chat keeps the same session — and therefore the same sticky layers — across pages for the hours you have configured on the script tag.
• Turning a playbook off skips its effects on chats that already matched it. The session still remembers the id. New chats will not match a disabled rule.
• Insights does not yet filter conversations by playbook id. Use the Trace Log while testing.
• There is no visual decision tree. The ordered cards are the tree: put specific campaign and country rules above broader URL or catch-all rules.
• Location matching uses names, not codes. India matches; IN does not.

Related documentation

• Visitor Profiles — Person facts vs journey rules; capture modes
• Visitor Profiles and CRM — Lookup on identify; HubSpot and Marketo writes
• Website integration script tag — data-agent-id and persist chat
• Desk settings — Staffed hours vs a playbook overlay
• Agents — Live specialists the pin dropdown can use
• Admin Chat — Trace Log Playbook match
• What to use when — Choosing playbooks vs agents vs visitor profile