Plan requirement
| Subscription | Suite Professional or higher, Support Professional or higher |
| Also required | Copilot |
| Access | Admin |
Eight ways procedures go wrong, drawn from what happens rather than the theory. The step everybody knows by heart is the one nobody writes down.
One: too broad
"Handle returns" covers a customer asking about the policy, one wanting a label, and one whose item arrived broken. Three different handlings, one procedure, and the AI picks between them on the basis of a sentence.
Two: the obvious step is missing
Everybody on the team checks the order status first, so nobody writes it down. The procedure starts at step two and proposes an answer before anything has been verified.
Write the steps as if for somebody on their first morning.
Three: conditions with one branch
"If the order is within thirty days, send a label." What about day thirty-one? Unwritten branches are where the AI improvises, and it improvises helpfully.
Four: no prohibitions
The rules everybody knows, so nobody writes them: no refunds without approval, no dates you have not verified, no exceptions to the policy. These matter more in a procedure than in any human instruction.
Five: written from the manager's view
Describing how the process is supposed to work rather than how a case arrives. Real tickets are incomplete, contain two questions, and often start in the middle.
Six: never revisited
The process changed and the procedure did not. It is now followed faithfully and wrongly, at scale, and nothing announces this.
Seven: it only works in one language
A procedure that matches reliably in English can miss in French or Dutch, even when the customer is asking the same thing. Matching goes on wording and meaning, and a translated question rarely lands as close to the phrasing you optimised for; the agent then picks a different procedure.
Where you serve more than one language, test each procedure with real questions in each of them rather than translating your English test.
Eight: it branches on a value that is not there yet
A procedure that reads a session parameter takes a different route when that parameter is empty, and empty is a state you rarely test. The value may be fetched by an action that has not finished when the conversation starts, so the branch is decided before the answer arrives. Nothing errors; the procedure follows the wrong path, consistently and quietly.
Two habits avoid it. Set the parameter again with a conversation action at the start, so it is there whatever the timing. And never write the same value into two differently named parameters, because then no reader of the procedure, human or otherwise, can say which one is authoritative.
The test that catches most of it
Give the procedure to somebody who does not do this work and ask them to follow it exactly. Every place they hesitate is a place the AI will guess.
Comments
0 comments
Article is closed for comments.