Definition of done and the exception list
State done as a count that balances by a deadline, and give each of three exception classes an owner and a clock, so no item ever waits silently.
On this page
"Handled" is the most expensive word in an SOP. It cannot be false, so a run that stalled on its twelfth item and a run that finished all 35 report the same thing. Done has to be a state someone else can check from a record at a stated time, and the items that do not reach it need a list of their own: what kind of exception each one is, whose it is, and how long it may wait.
"Chased" is not a state
The first draft of the chase SOP in SOP to workflow ended "Done: overdue invoices chased." Here is the Monday that line was written for. The mail server starts rejecting messages after the twelfth reminder. The workflow logs the rejections, finishes its loop and reports the run complete. The operations manager sees a green tick and moves on. Twenty-three clients get no reminder. At an assumed average invoice of $750, about $17,000 of overdue money sits unchased for a week, and nothing on any screen says so.
Nothing in that run was a model error. The failure is in the definition: "chased" describes an intention, and an intention is satisfied by any run that tried.
Done as a count that balances
A done line a workflow can be held to has three properties. Every item ends in exactly one named end state. There is a time by which that must be true. And it can be checked from records by someone who did not run it.
For the chase: by 10:00 Monday, every open invoice 7 or more days past due is in exactly one of four end states, written on the invoice record:
- reminder sent, stage 1 or 2, with the message id the mail server returned;
- call task created, stage 3, with the account manager's name and a due date;
- dropped, with the reason: paid, disputed or founder-handled;
- in the exception queue, with its class and an owner.
The check is arithmetic. Invoices pulled must equal the sum of the four states. On a typical Monday 35 are pulled: 29 reminders, 2 call tasks, 2 dropped, 2 exceptions, and 29 + 2 + 2 + 2 = 35. On the Monday above, the count is 35 pulled against 12 sent and nothing else, and 23 invoices in no state are an alarm at 10:00, not a discovery a week later. Only a message id counts as sent, so the rejected reminders cannot pass as sent.
A count can balance and still be wrong if the input is wrong. An empty receivables report balances at 0 = 0. So done carries a floor too: a pull of fewer than half last week's count stops the run and pages its owner, because the likelier explanation is a broken export, not a week in which every client paid.
This is a definition of done for an AI deployment at the size of one task: a number, a way to measure it, a time. It is also the field of that name in the virtual employee frame. When the chase's one model step gets an eval set, its pass condition comes from here: a reply sorted to the right label, a case in the sense of evals as the unit test of LLM work.
Three classes of exception
The first draft's exception list was one line: "escalate anything difficult to the account manager." One owner, no classes, no clock. In the week that account manager is on leave, a client's reply saying "we paid on Friday" waits eight days. The invoice crosses 21 days, the firm stage-2 reminder goes to a client who has paid, and the agency pays the $100 error the scoring frame priced for exactly that.
Exceptions differ in what went wrong, and each kind needs a different person at a different speed:
Unknown input. The item does not fit the inputs the SOP names: no billing contact, a currency the templates do not cover, an invoice status the report has never used. The rules may be fine; the data is not. Owner: the operations manager, who owns the data. Clock: seen within 15 minutes of the run.
Ambiguous rule. The data is fine but no rule applies, or two do: a reply claiming payment with no matching payment, a part payment, a disputed line. Owner: the client's account manager, who knows the client. Clock: 4 hours, the same working day.
External failure. Something the automation depends on is down: the accounting system returns errors, the mail server rejects, the bank feed is a day late. This is not one item's problem, because every item behind it is unprocessed. The run stops and pages the automation's owner, the operations manager, at once.
Any clock that runs out goes to you. Nothing waits silently: every item in the queue carries an owner's name and a time by which it must be seen. Module 4 sets these clocks for every live flow, and the numbers here match it.
The queue is a cost and a measurement
Exceptions are person time, and person time is a line in sum 2. A typical Monday for the chase raises about one unknown input, a missing contact at 5 minutes, and about five replies needing a decision at 6 minutes each: 5 + 30 = 35 minutes a week, 2.5 hours a month, $76 at $30 an hour. That is the people line the scoring frame used when it put the chase's payback at 4.9 months. If the queue doubles, so does the line, and payback stretches.
The queue also says where the SOP is thin. An ambiguous-rule exception that recurs is a decision nobody has made. When one kind runs to more than a few a week for a month, write its rule into the SOP and the class shrinks. External failures that recur are a different signal: the dependency, not the SOP, needs work.
In practice
Tell the team what done means in one sentence they can check: "By 10:00 Monday, invoices pulled equal reminders sent plus call tasks plus dropped plus exceptions; if it does not balance, the missing invoices are the problem." Ask the builder, or the vendor, one question: "Show me where an item goes when it fails, and whose name is on it." A dashboard that reports runs succeeded, rather than items in end states, could not have shown the Monday the chase stopped at twelve.
The mistake that costs money: a done line that cannot be false. "Chased" reported success on a run that stopped at item 12 of 35, and about $17,000 of overdue invoices waited a week with nobody looking.
Check yourself
1. Monday, 10:00: 35 invoices pulled, 29 reminders sent, 2 call tasks, 2 dropped, 1 exception. Is the run done?
No. 29 + 2 + 2 + 1 = 34, so one invoice is in no state. That invoice comes before everything else in the queue, because it is the only item no person and no rule will ever reach on its own. Find it, then find why the workflow let it through without a state.
2. A client replies: "Please send reminders to our new accounts address." Which class is it, who owns it, and what is the clock?
An ambiguous rule: the data on record is complete, but the rule (send to the billing contact on file) now conflicts with the client's instruction. It goes to the account manager within 4 hours, who confirms the change by phone with a contact they already know before the record is edited. An emailed change of billing details is a known invoice-fraud pattern, so the operations manager does not just update the field.
3. Ambiguous rules run at 5 a week at 6 minutes each, and 3 of the 5 are "says paid, no matching payment". Writing a rule for that case takes you an hour. Is it worth it?
The 3 cost 18 minutes a week, about 78 minutes a month, roughly $39 at $30 an hour. An hour of yours is $100, so the rule pays back in about 2.6 months. Write it: "an unmatched paid claim holds chasing for 5 working days, then the invoice re-enters at its stage." The class drops from 5 a week to 2.