The rule was never the hard part
Every automation gets designed around one story. An enquiry arrives, a record is created, the acknowledgement goes out and the sequence starts counting days. That story is the one the team tests on the morning it goes live, and it works, because it is the story the build was written from. Someone watches the first message leave and the job is called done.
The calls we get afterwards are almost never about that story. They are about the form that submitted twice because the page hung and the sender pressed the button again, or the quote accepted on Thursday and cancelled on Friday morning while the chase sequence was still running against it. Each of those was already happening when the process ran by hand. A person saw the duplicate and deleted it, saw the cancellation and stopped chasing, and neither action was ever written down as a step, because to the person doing it, it wasn't a step.
None of that reached the build. Software does what the ordinary case told it to, at speed, to every record that matches, and a duplicate record matches perfectly. Nothing in the written logic is wrong. The gap is in the decisions a person made without calling them decisions.
Where the exceptions come from
Most of them sit in the gap between what a person does and what the person says they do. The person who logs enquiries sees the same email address twice in a morning and merges the two records without thinking about it. The one chasing quotes knows which customer said they'd be away for a fortnight and leaves that quote alone until they are back. Asked to describe the process, neither mentions any of this. They described the rule, and the automation got written from the description.
The tools produce their own share. A web form fires its webhook twice on a slow connection and two records appear a second apart. A booking tool records a rescheduled call as a cancellation followed by a fresh booking, which reads to a sequence as one person leaving and a stranger arriving. We didn't write either of those and we can't change them, so the automation has to expect them, and the only way to expect them is to have seen them happen.
Contacts do the rest. They reply to the wrong message, reply from an address that isn't the one on the record, book a call and then fill in the form again to be sure, or unsubscribe and write back a week later asking why nobody has been in touch. A sequence built for one tidy contact does something with each of these, and it is usually the wrong thing, sent politely, to a person who was about to buy.
Listing the exceptions before launch
Before anything goes live we sit with the person who does the task by hand and walk the process one step at a time. At each step we ask what has gone wrong there in the last year. The wording matters. A question about what could go wrong produces a list of disasters that have never happened, and a question about the last year produces the ones that did, because each of those cost somebody an afternoon and afternoons are remembered.
The list that comes out is shorter than the team expects and longer than the build allowed for. Every entry sits against the step it happened at, in the words of the person who dealt with it, next to what they did about it. That last part is the useful part. Where the person can say what they do every time, the fix becomes a rule in the automation. Where they say it depends, the record gets handed to a person, and the automation's only job is to hand it over with everything attached.
A few entries get left alone. An exception that happened once and cost nothing goes on the list with the word manual next to it, so that whoever inherits the system knows it was seen and left. That is a different thing from never having looked.
Then the exceptions get tested, because the rule was tested on the day it was written. Two identical submissions thirty seconds apart. A reply to the third message of a sequence that had already stopped. A cancellation on a deal at the stage after the one the sequence watches. An unsubscribe followed by a fresh enquiry from the same address. Each of those runs through the system before a client's contact does, and the one that produces a message nobody would want to receive is the one that gets fixed first.
The default is to stop
The rule that matters most is the one for the record that fits no path on the list. Ours is to stop. The automation leaves the contact alone and writes what it saw to a place a person already looks. A message that did not go out gets sent by a person in the morning. A message that went to a contact who cancelled the day before is a complaint.
Where it writes to gets decided with the team. An error log nobody opens is the same as no log, so the entry goes wherever they already look on a normal morning, which in most teams is the shared inbox or a channel, and occasionally a row on the sheet the person opens first thing. It carries the record and the step the automation stopped at. The person reading it can finish the job by hand without opening the automation at all.
Duplicates get a rule of their own, because they are the most common exception in every system we've been asked to look at. Before a record is created the automation matches on email address and then on phone number, and it creates nothing when either one matches. A contact who changed their email address is still one person. Treating them as two sends the same sequence into the same inbox twice.
The stops get counted. At day thirty we read how many times the automation stopped and at which step, because that count says which exceptions were common enough to deserve a rule and which happened once. A few of the entries on the list move from manual to rule at that point, and one or two rules usually go the other way, because a case the team was sure about turned out to depend on something after all.
