· 7 min read
Designing a call flow for interruption
Real callers interrupt, change their mind, and answer a question you did not ask. Surviving all three is mostly a question of where you put the branches.
by Woise Team
Written conversation is turn-based. Spoken conversation is not. People start talking before you finish, change the subject halfway through a sentence, and answer the question you were about to ask instead of the one you did. A call flow drawn as a clean sequence of exchanges will meet all of that on its first day.
Interruption is not an error state
The first instinct is to treat being interrupted as something to recover from. It is not. It is how people signal that they already have what they need, or that you are heading somewhere useless.
A caller who cuts in with their postcode while the agent is still explaining that it needs the postcode has not broken anything. They have saved everyone eight seconds. The flow should be able to take the answer and move on rather than finishing the sentence first.
Design the barge-in, do not just allow it
Allowing an agent to be interrupted is a setting. Deciding what happens next is design work, and it differs by node.
On a question, an interruption is usually the answer, and the right move is to accept it. On a confirmation, where the agent is reading back a date and a time, an interruption is usually a correction, and the right move is to stop and ask what is wrong. On a legally required disclosure, it may be that the agent has to finish. These are three different behaviours and they belong to the node, not to a global switch.
Plan for the answer that arrives early
The most common structural failure is a flow that asks three questions in order and cannot cope with a caller who answers all three in one sentence. It asks again, the caller repeats themselves, and the conversation immediately feels like a form.
The fix is to treat the questions as things that need answering rather than as steps to walk through. If the first turn already contained the answer to the third question, the third question should not be asked.
Test the messy paths, not the clean one
Everybody tests the path where the caller says yes at the right moments. That path was always going to work. The paths worth your time in the browser are the ones where the caller says something unexpected, changes their mind, goes quiet, or asks a question back.
Reading transcripts afterwards is the other half of it. The place a flow breaks is rarely where it was designed to branch; it is a turn nobody imagined, and it will be in the transcripts long before it is in anybody's feedback.