Collecting details from the caller

Take a message and Appointment request rows in the playbook collect a list of details. A detail is one piece of information you want back from the call — a name, a phone number, an order number, whether they want delivery or pickup.

The short version:

You describe each detail once. On the call, the agent asks for them one at a time, in the order you listed them, checks each answer, reads important ones back, and won't finish the request until everything you marked required is there.

Everything collected arrives under Tasks in your portal, tagged with the row it came from. Row-level settings — task priority and the optional SMS confirmation text — are covered on the playbook page.

Step 1 — the detail itself

Each detail has three settings on its top line:

A note on Optional, because it surprises people: an optional detail is still asked for. The difference is what happens if the caller won't or can't answer — with Optional the agent moves on, with Always it comes back to it and won't complete the request without it.

Drag the handle on the left of a detail to reorder it. That order is exactly the order the caller will be asked in, so lead with what matters most and keep the list short. The task is only created once the request is finished, so a long interrogation that makes callers give up costs you the whole enquiry — five details a caller completes beats ten they abandon.

Under each detail you'll see a grey tag like {{collected.order_number}}. That's the detail's reference name, for dropping the answer into a webhook body or an SMS confirmation template. You can ignore it entirely unless you're using either of those.

Making one detail depend on another

Set a detail's Required? control to Only when… and you get a small rule: Required only when ⟨other detail⟩ equals ⟨value⟩.

The classic case:

• Delivery method — One of options: Delivery, Pickup
• Delivery address — Required only when Delivery method equals Delivery

Callers who pick up are never asked for an address; callers who want delivery can't finish without one.

The value you type has to match what actually got saved, ignoring capitals. This is exactly why One of options pairs so well with conditional rules — it guarantees the deciding detail only ever holds one of a few known values, so your rule can't miss because someone said "deliver it" instead of "Delivery".

A few limits worth knowing: a rule can only test one other detail, only for "is equal to", and a detail can't depend on itself. If you delete the detail a rule points at, the rule is dropped and the detail goes back to Optional.

Step 2 — Collection behavior

Below each detail is a panel headed Collection behavior. This is where you control what the caller actually hears. It has four boxes:

1. Question (up to 240 characters) — the exact words the agent says to ask for this detail. It is spoken verbatim, so write it as a question to a customer, not as an instruction to the agent:

• ✅ "What's the best number to reach you on?"
• ❌ "Get the caller's phone number and validate it"

Leave it blank and the agent falls back to a plain "What is your ⟨label⟩?", which works but rarely sounds like you.

2. Validation — the check the answer has to pass before it counts as collected. This runs on our side, as a straight rule — it isn't the AI deciding whether it liked the answer:

You usually don't need to touch this. Choosing an answer type sets it for you: Email → Email, Phone number → Phone, Date → Full date. A detail whose label contains "name" defaults to Full name, and one containing "address" defaults to Postal address.

3. Confirmation — whether the agent repeats the answer back and waits for a "yes" before accepting it. No confirmation, Read back (says it normally), Spell back (letter by letter), or Digits (digit by digit, in short groups). Phone and Email details have this locked on — see Getting numbers and emails right.

4. Clarification (optional, up to 240 characters) — what the agent says when an answer fails the validation check. Also spoken verbatim. Without one, the agent simply asks the original question again, which sounds robotic the second time round. With one, it can be helpful:

Question: "What date suits you?"
Clarification: "Sorry, could I get the day and month — for example, the 4th of March?"

One of options, explained

This is the one that trips people up, so here it is in full.

One of options is a validation rule that says: the answer must be one of a short list of values I'm about to give you. Use it when a detail only has a few legitimate answers.

Pick One of options in the Validation box and a new field appears underneath. Type your allowed values separated by commas:

Delivery, Pickup

Now write the question so the caller is actually offered the choice:

Question: "Would you like that delivered, or will you pick it up?"
Validation: One of options → Delivery, Pickup
Clarification: "Sorry — is that delivery, or pickup?"

On the call it goes like this:

Note what's stored: the agent saves your option value, not the caller's exact words. That's what makes this rule useful — callers can answer naturally, but your tasks and reports come back with tidy, consistent values.

The two things everyone gets wrong:

1. The agent does not read your options out. The list is a checking rule, not a menu. If your question is "How would you like to receive it?" the caller has no idea "Delivery" and "Pickup" are the only answers you'll accept. Put the choices in the question.
2. If you pick One of options and leave the list empty, the rule is dropped and the detail behaves as No validation. There's no error — it just stops checking. Always fill the list in.

Some practical notes:

• Up to 20 options, each up to 80 characters.
• Matching ignores capitals and surrounding spaces — delivery and Delivery are the same value.
• Whatever you type is what gets saved and shown on the task, so write the options the way you want to read them later: Delivery, Pickup rather than del, pu.
• Keep the list short and clearly different from each other. "Morning, Afternoon" works. "Morning, Early afternoon, Afternoon, Late afternoon" will frustrate everyone.

Good candidates: delivery method, new-or-existing customer, which branch, urgency, which product line, preferred contact method.

What happens when the caller doesn't cooperate

Real callers mumble, ramble, and give you the wrong thing. The agent won't trap them in a loop:

• If an answer fails validation, the agent says your clarification line and asks again. It will do this twice at most. After the second failed attempt it accepts whatever it has and moves on, so the caller is never stuck in a circle. The imperfect answer still reaches your task — better a slightly odd note than a hung-up caller.
• Confirmation works the same way. If the caller doesn't confirm a read-back after two goes, the agent accepts the value and continues.
• If the caller corrects themselves — "no wait, it's 0412 …" — the new answer replaces the old one and the agent re-confirms it from scratch. It doesn't patch what it thought it heard.
• If the caller abandons the request partway ("actually, never mind"), no task or booking is created.

Because of the two-try limit, treat validation as a nudge towards good data, not a lock. If a detail absolutely must be correct, set it to Always required and give it a confirmation mode.

Getting numbers and emails right

Phone numbers and email addresses are what voice systems mangle most, so the agent handles them strictly and you can't switch it off:

• Phone numbers are always read back digit by digit and must be confirmed. The agent says "eight, eight, eight" rather than "triple eight", but still understands you if you say it the other way. Correct it and it asks for the whole number again rather than patching a guess.
• Email addresses are always spelled back and must be confirmed the same way.

You'll see these two locked in the Confirmation box, showing Digits (required) and Spell back (required). For any other detail, confirmation is yours to choose.

If a caller offers the number they're calling from, the agent can use that instead of making them recite it.

A note on "Legacy guide history"

Older agents may show a collapsed Legacy guide history box under a detail. That's a free-text note from an earlier version of the Studio, kept for your records only. It is never sent to the agent and has no effect on calls. Everything that shapes the call now lives in the Collection behavior panel above it.

If you see an amber Needs review badge on a detail, it means we couldn't translate an old setting automatically — open the Collection behavior panel, check the four boxes read the way you want, and save.

Common mistakes

Everyday tasks

• Offer the caller a set choice → set that detail's Validation to One of options, list the values, and put the same choices in the Question.
• Make one detail conditional on another → set its Required? to Only when…, then pick the deciding detail and its value.
• Change the exact words the agent uses → edit the Question in that detail's Collection behavior panel.
• Stop the agent sounding robotic on a retry → write a Clarification line for that detail.
• Text the caller a confirmation once the request is captured → that's a row-level setting — see the playbook page.

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