The exceptions nobody ever wrote down

A written procedure rarely describes the way the work is really done. The gap between the two gets a section of its own in every blueprint we write: exceptions (the rules that live only in the heads of the people who do the job).

They accumulate quietly: a client invoiced differently because of an earlier agreement, a step skipped when a request comes from a particular department, a threshold applied differently in practice. None of it is in the manual, and all of it decides whether a system works.

1. Hi, I'm calling about the water damage at our warehouse. I sent the photos on Monday.

2. Thanks for calling, Dana. I'll pull up your claim. First, I'll text a six digit code to the number on your policy.

3. send_verification_code

4. Got it, the code is 4K7M21.

5. Thanks. Let me check that code for you.

6. verify_codecode: 4K7M21

7. All set. One moment while I open your policy and the claim file.

8. get_policy_record
9. get_claim_documents

10. I can see claim 48213, filed on April 20th, with twelve photos and the plumber's report. The policy covers sudden water damage at that address. Is this the warehouse on Dock Street?

11. Yes, that's the one.

12. get_blueprint_rulerule: Stock damage over $25,000

13. Thank you. Because the stock damage is estimated above $25,000, an adjuster reviews it before anything is approved. I've sent them the file with everything you gave us, and they'll call you by noon tomorrow.

14. refer_to_adjusterclaim_id: CLM-48213

15. That's done. You'll get a confirmation by email in the next few minutes. Is there anything else I can help with today?

16. No, that's great. Thank you so much!

Where the exceptions are kept

We find exceptions in the head of the person who has done the job longest. Sometimes in a spreadsheet on one machine, sometimes in an email folder, occasionally on a note taped to a monitor.

That person is also the reason the process works. They are not obstructing anything by holding the rules in their head, which is why asking for documentation produces the procedure again rather than the truth. The cases worth finding arrive late, in the wrong format, from an older system, or with a history attached: a client invoiced differently, a step skipped, a threshold applied by feel.

The chart below is illustrative. It shows the share of a process's exceptions each approach recovers, measured on three exception-heavy queues with late documents, missing records, interruptions and handoffs between teams. How we map a process.

The work it was measured on is the hard kind: late documents, records that disagree, requests that change halfway through, and people who are interrupted while they explain. The same method holds in insurance, construction, energy and financial services alike.

How we get them out

So we sit with the people who do the job and watch the work. Not a workshop and not a questionnaire: the actual queue, on an actual morning, including the cases they would normally handle without mentioning. A rule stated once, corrected twice and applied by feel is still a rule, and it goes into the blueprint the way it is really applied.

Why they decide whether a system works

A system that handles only the clean path automates the part that was never expensive. The value is in one that recognises the exception, applies the rule where a rule exists, and hands the case to a person with the working attached where it does not.

The exceptions are the design

Systems built from the manual default to a confident, plausible answer on the cases they do not recognise, and the answer is wrong. We write exceptions into the blueprint before anything is built, so the system recognises them before it answers and stops where no rule exists.

And they keep arriving

New exceptions appear as the business changes. At a multinational insurer, the exposure system we built and operate reprices every policy each morning for the underwriting desk. The same engineers stay with it after go-live, and review each new exception with the people who do the work:

• 20% of cases flagged. In 1 out of every 5 repricings, a rule the manual never mentioned decides the outcome.
• 70% resolved by rule. The majority of flagged cases are settled by a rule now written into the blueprint, with a record of which rule applied.
• 28 systems of record. A single process reads and writes across dozens of systems, each connection reviewed by the client's engineers.
• A person decides the rest. Anything without a rule goes to an underwriter with the working attached. We review new exceptions with them, not against a dashboard.

Tell us about the process you want handled

Book aScoping SessionOr simplyTalk to us