The playbook: what your agent handles

Your voice agent answers the phone. The playbook is the list of things it knows how to deal with once it has said hello.

You'll find it in the agent's Studio, in the section headed "Figures out what the caller needs". Each line in that list is a playbook row, and a row is just two halves:

When a caller wants this … do that.

"Wants to book an appointment" → take their details. "Asks how much it costs" → answer from our knowledge. "Wants to speak to accounts" → put them through. That's the whole idea.

One row per kind of request — never one row per person.
You do not need a row for every staff member. If callers ask for people by name, use the built-in "Caller asks for a person" row with the Anyone in the directory destination (below) — one setting covers your whole team, whether that's 5 people or 500.

What's in a row

Every row has four parts:

• Request name — a short label, like "Pricing question". Mostly for you, but it also helps the agent tell its options apart, so keep it descriptive.
• How to recognise it — a plain-language description of what a caller who wants this sounds like. The agent compares real callers against this description, so write it the way customers actually speak: "wants a quote, asks how much something costs, asks for pricing" — not a list of keywords.
• Then… — what to do about it, chosen from the six actions below.
• Agent instructions (optional, up to 1,000 characters) — extra handling notes that apply only after this row has been chosen. Good for tone or process on one specific request: "check whether they're an existing customer before quoting". It cannot override your safety rules, your required details, or where the call goes.

There's no limit on the number of rows, but resist adding one for every possible phrasing. A handful of well-described rows beats dozens of near-duplicates — the more alike two rows look, the harder it is for the agent to pick the right one.

What a row can do

Answer from knowledge — the agent answers from your approved knowledge and nothing else. If the answer isn't in there it says so rather than guessing, then follows your no-answer path.

Take a message — the agent collects the details you specify and creates a task for your team. This is the one most playbooks lean on; see Collecting details from the caller.

Appointment request — the same detail collection, plus optional real booking into a connected calendar: the agent checks availability, books the slot, and can later look up, cancel, or reschedule. Setup is on the Calendars page. With no calendar connected, the row simply captures the appointment request as a task.

Transfer the call — sends the caller to a person or team; see Transfer destinations.

Notify a system — sends the call's details to an external system over a webhook (your URL, GET or POST, with optional bearer, basic, or API-key authentication). Use it to drop a lead into a CRM or kick off an internal workflow while the caller is still on the line.

Read a message & end — the agent reads out a short message you write, then hangs up. Best for simple, self-contained answers like opening hours or an address.

Two of these must be switched on for the agent as a whole before any row can use them: Answer from knowledge needs the Knowledge capability enabled, and Notify a system needs a webhook URL saved. If you turn either off later, rows pointing at it quietly fall back to taking a message — the caller still gets looked after, and the Studio shows you a warning naming the affected rows.

The two built-in rows

Every inbound agent has two rows that are always present and can't be deleted:

• Caller asks for a person — handles "can I speak to someone?" and requests for a specific person or team.
• Agent can't help / unclear caller — the safety net for when the agent can't match a request to anything it handles.

Both are limited to the three actions that always leave the caller somewhere sensible: transfer the call, take a message, or read a message and end.

Collecting details from the caller

Take a message and Appointment request rows collect a list of details — one piece of information each, asked for in order, checked, and read back where it matters. The questions, validation rules, confirmation modes, One of options choices, and Required when… conditional rules all have their own page: Collecting details from the caller.

Finishing a request: priority & SMS confirmation

Alongside its details, each Take a message / Appointment request row sets:

• Task priority — low, normal, high, or urgent, on the task your team sees.
• SMS confirmation (optional) — a text to the caller once the request is captured. This needs a mobile number detail on the row, which is why deleting one can be blocked (you'll see a padlock instead of a bin).

The SMS confirmation text

The confirmation is built from a template you write once — the agent never composes the message itself.

The template box offers insert chips: {businessName} plus one chip for every detail on the row, written like {{collected.delivery_method}}. On the call, our system fills each slot with the value the caller confirmed and sends the result — the agent can't change the wording or add anything of its own.

Two rules shape what you can do with it:

• One template per row. There's no way to send different wording depending on an answer.
• A slot with no value stops the text. If the template references a detail that wasn't collected on that call, the SMS simply isn't sent — it never goes out with a blank in it.

That second rule is genuinely useful. To text callers only in one case — say, only when they chose email delivery — make the deciding detail a One of options choice (Email, Post), add an Email address detail set to Required only when Delivery method equals Email (the Only when… option on the detail), and reference {{collected.email_address}} in the template:

{businessName}: your delivery method is {{collected.delivery_method}} and we'll send it to {{collected.email_address}}.

Callers who chose Post are never asked for an email and never get that text.

To text every caller regardless of their choice, only reference details the row always collects — for example one always-required detail labelled "Email or postal address":

{businessName}: your delivery method is {{collected.delivery_method}}. Delivery details: {{collected.delivery_details}}.

How to set up the choices and conditional rules themselves is covered under Collecting details from the caller.

Transfer destinations

A transfer sends the call to a destination you pick: an extension, a ring group, a call queue, an auto attendant, another voice agent, a voicemail box, or an external number.

Transfers are always warm: the agent puts the caller on hold, briefs whoever is receiving the call, and only connects them once that person accepts. You can write the announcement the receiving person hears.

Anyone in the directory (dynamic transfer)

The "Caller asks for a person" row has a special destination: Anyone in the directory. Instead of sending every person-request to one fixed place, the agent matches what the caller asked for against your live directory — every named extension, ring group, and call queue on your account.

With it enabled, callers can say things like:

• "Can I speak with Kevin?" — the agent finds Kevin's extension and transfers.
• "Transfer me to extension 100." — the agent matches the number directly.
• "Put me through to the sales team." — named ring groups and queues match too.

If more than one entry matches — two Kevins, say — the agent asks which one they mean. It only ever transfers to a real entry in your directory; it can never invent an extension or dial an outside number from this row.

Because the directory is checked live on every call, hiring, renaming, or removing staff needs no changes to the agent — no editing, no republishing. Keep your extensions' display names accurate and the agent stays current by itself.

Screening before the transfer

Three toggles control what happens before connecting (all on by default):

• Ask for the caller's name — collected before the transfer.
• Ask what the call is about — a short reason for the call.
• Announce the caller before connecting — the receiving person hears a private summary and accepts before the caller is put through.

When no match is found

You choose what happens if the agent can't find who they asked for, or the caller can't say which match they meant:

• Take a message — collects their details and creates a task.
• Transfer to a fallback destination — one fixed place, such as reception or a ring group.

Common mistakes

Everyday tasks

• Let callers reach any of your staff by name → open the Caller asks for a person row → Edit → set the destination to Anyone in the directory → Save, then Publish.
• Capture enquiries as tasks → add a row with a Take a message action and list the details to collect — see Collecting details from the caller.
• Text the caller a confirmation → enable SMS confirmation on the row and build the template with the insert chips.
• Send new enquiries straight into another system → use a Notify a system row.
• Answer a simple question without involving anyone → use a Read a message & end row.
• Handle emergencies or angry callers immediately → see Business hours & escalations.

Changes don't reach live calls until you Publish the agent.