Get the callback number first. Everything else on the call becomes recoverable the moment you have it.
Most intake scripts are ordered by what the business wants to know. They should be ordered by what survives a dropped call.
The single most useful change most businesses can make to their phone intake is reordering it. Ask for the callback number early, confirm it, and everything after that becomes recoverable: a dropped call, a misheard name, an unanswered question can all be fixed by calling back. Ask for it last, as most scripts do, and a call that ends early leaves nothing at all. The rest of intake design follows from the same principle: order by what is unrecoverable if you lose it.
What order should the questions go in?
Callback number, then the reason for the call, then everything else. It feels abrupt written down and it does not sound abrupt in practice, because the reason for asking is easy to give in four words: in case we get cut off.
There is one exception worth building in: a caller who sounds distressed or is describing an emergency should not be asked for a phone number first. Urgency outranks process, and a rule that fires on those cases is worth having explicitly rather than relying on judgement in the moment.
| Field | Typical position | Better position | Why |
|---|---|---|---|
| Callback number | Last | First | Makes every later error recoverable |
| Reason for calling | First | Second | Useless without a way to respond to it |
| Name | First | Third | Nice to have; not what you call back on |
| Address / property | Middle | Middle | Needed for the work, confirmed carefully |
| Preferred time | Middle | Last | Easiest to resolve on a callback |
The reordering costs nothing and changes what a half-completed call is worth.
Which fields need confirming, and which do not?
Confirm anything that has to be exact and cannot be inferred: the callback number, the address, an email. Do not confirm things a human will obviously correct; a slightly wrong spelling of a name that is already attached to a phone number costs nothing.
Confirmation is a budget, not a virtue. Every read-back costs a few seconds and a small amount of the caller's patience, and a script that confirms everything spends that budget on fields where it buys nothing. The test is whether being wrong on this field breaks something that a callback cannot fix.
- Always confirm. Callback number and service address. These are the two that make the rest work.
- Confirm if it is being written to something. Email addresses, and any reference number that will be typed into another system.
- Do not over-confirm. Names of existing customers, times already stated twice, anything the callback will resolve anyway.
How should the questions themselves be worded?
Short, closed, and answerable in noise. An open question produces better information in a quiet room and worse information from a job site, and most first calls to service businesses come from somewhere noisy.
- Prefer "morning or afternoon" to "when suits you" when audio is likely to be poor.
- Ask one thing at a time. Compound questions get one answer.
- Avoid questions whose answers are letters or codes unless you must.
- Leave one open question for the reason they called; that is where the useful detail is.
Ask for the callback number first and everything else on the call becomes recoverable; ask for it last, the way most scripts do, and a call that ends early leaves you with nothing at all.
Field order is one of the first things we set in a build, because it is free and it decides what a half-finished call is worth.
Start free pilotQuestions this raises
- What should you ask first on an inbound business call?
- The callback number, with a short reason for asking. It makes every subsequent error on the call recoverable, which nothing else does.
- Doesn't asking for a number first sound pushy?
- Not when the reason is given: "in case we get cut off" is enough. Callers who have been disconnected mid-call before understand it immediately.
- Should every field be read back to the caller?
- No. Confirmation costs time and patience, so spend it on fields where being wrong breaks something a callback cannot fix, principally the number and the address.
- How should questions change for noisy environments?
- Shorter and more closed. A choice between two options survives background noise far better than an open-ended question, and most first calls to trades come from somewhere loud.
- What about emergencies?
- They should bypass the script. A caller describing something urgent should not be walked through intake, and that exception is worth writing down as a rule rather than leaving to judgement.
Sources
- Recording of Customer Telephone Calls: guidance for organizationsOffice of the Privacy Commissioner of Canadaupdated 2018-04-18, consulted 2026-08-09
Want an AI receptionist built around these rules rather than despite them?
We build a working receptionist on your calls, your booking rules and your escalation rules, and you call it yourself before committing to anything. About 14 days, no call limit during the pilot.
Start free pilot