Guide
Call Flow Design Checklist
Write the boundaries before the script. What the system must never say does more work than any amount of careful wording, and it is the part most people leave until last.
Five things to settle first
- What the caller is trying to achieve
- What a good outcome looks like
- What must never be said or promised
- What triggers a handover to a person
- What happens when nobody answers that handover
Start From Real Calls
Do not begin with a blank script. Begin by listening to, or sitting through, twenty actual calls of the type you intend to automate. Write down what people ask, in their words rather than yours.
Two things emerge reliably. The first is that customers use different terminology from the business. The second is that a small number of questions account for most of the volume, which is what makes automation viable.
This exercise is worth doing whether or not you automate anything. Most teams discover inconsistencies in how they answer the same question.
The Checklist
Before writing anything
- Twenty real calls reviewed and summarised
- The enquiry types ranked by volume
- A defined good outcome for each
- Prohibited topics written down
- Escalation situations listed by qualified staff
While designing
- Greeting states the business and that it is automated
- Questions asked in the order callers expect
- Minimum questions needed, not the maximum possible
- Confirmation of numbers and key details
- An exit to a person available at any point
Failure paths
- What happens on the second misunderstanding
- What happens if the caller goes silent
- What happens if the escalation contact does not answer
- What happens outside working hours
- Exact wording for anything the caller must be told
Before going live
- Every escalation path triggered and verified
- Tested with interruptions and background noise
- Tested by someone who was not involved in building it
- Content approved by whoever owns it
- A review date set for the first month
Common Design Mistakes
Asking too many questions is the most frequent. Every additional question loses callers, and the fourth or fifth rarely changes what happens next. Capture the minimum needed to act.
The second is designing only the happy path. A flow that handles a cooperative caller and nothing else will fail on its first genuinely confused customer.
The third is writing escalation rules without the people who understand the risk. Clinical escalations belong to clinicians, safety escalations to operations, and neither should be drafted by whoever is configuring the system.
Testing Properly
Adversarial testing means deliberately being a difficult caller. Interrupt mid-sentence. Change your mind. Give a vague answer. Ask something entirely outside scope. Call from a noisy street on a poor connection.
Have someone who did not build the flow do this, because the person who designed it unconsciously avoids the paths they know are weak.
Judge the result by the failures rather than the successes. A flow that escalates cleanly when confused is finished; one that loops or improvises is not.
Questions People Ask
How many questions is too many?
Beyond five or six for most enquiries. Capture what you need to prioritise and leave the rest to the person following up.
Who should write the escalation list?
The people accountable for the risk. Not the person configuring the system, and not us.
How long does design take?
The writing is quick; the approvals are not. Content sign-off is usually the slower half.
Can we change the flow after launch?
Yes, and you should. The first month of transcripts almost always suggests worthwhile improvements.
Should one flow handle everything?
No. Separate flows for distinct enquiry types outperform one flow attempting all of them.
Bring One Enquiry Type
We will map the flow with you, including the failure paths, and then let you try to break it.