The exception queue
The exceptions that are left are five different problems.
An exception queue is where an order goes when the automation could not finish it. What lands there is the part that needed a person's judgement. Whether the queue is work or rework depends on whether each item arrives as a formed question.
An exception is not a defect. It is the part of the process that required judgement.
The category treats the exception as an error: something that prevented automatic processing and should therefore be driven towards zero. Read any vendor glossary and you will find the same six causes — a part number that does not match, a price that expired, a missing unit of measure, a bad address, a duplicate, a customer reference that does not resolve.
Every one of those is real. Every one of those is also the easy half.
What is missing from that list is everything a person resolves by knowing something the document does not contain. The customer who writes wie letztes Mal and expects you to know. The free-text line that quietly changes the delivery terms. The substitution question that is not a data problem at all, because someone has to be accountable for whether the part fits.
Those do not go to zero, and a process designed on the assumption that they will is a process that breaks in month four.
Five kinds of exception, sorted by what closes them
Lists of exception causes are easy to produce and not very useful. What matters operationally is not what caused the exception but what it takes to close it — because that is what determines where it should be routed, how fast it can be answered, and whether it will still be there next year.
| Never reaches zero | What closes it | What that looks like | How far it automates |
|---|---|---|---|
| 1 · RuleA deterministic rule, written once |
| Fully. Goes to zero. | |
| 2 · LookupData that can be fetched |
| Almost fully. Goes to small. | |
| 3 · HistoryPast orders from this customer |
| Partly. Not below a floor. | |
| 4 · AuthorityA person with the right to decide |
| Never. And should not. | |
| 5 · EngineerTechnical judgement with liability attached |
| Never. And should not. | |
| Two of the five never reach zero, and should not. | |||
The first two groups are engineering. The third is data you probably already have and are not using. The fourth and fifth are governance, and no amount of model quality touches them.
This is also why we publish the method rather than an automation rate, and why anyone else's is worth reading carefully. A rate measured over group one looks extraordinary. The same rate measured over a real inbox in industrial distribution looks like something else entirely. Every number in this category is published by the company selling the product — which would include ours. So we publish the method instead, and measure yours on your own data before either of us says a number out loud.
What makes a queue work instead of a second inbox
The unit is the line, not the document. One unresolved line holds an entire order, and an order with eight clean lines and one open question is not eighty-nine percent done — it is not shipped. Systems that report per document hide this. The queue has to hold the line, release the rest, and know which customers accept a partial confirmation and which do not.
Every item arrives as a formed question. Not a list of candidates with confidence scores. A question with one missing attribute named, the evidence that produced the rest, and the reason the answer matters. The difference is measurable in seconds per item, and seconds per item is the whole economics of the queue.
Routing is by competence, not availability. A tolerance question goes to the person who can answer a tolerance question. A price deviation goes to the person authorised to accept it. Round-robin routing across a shared mailbox is how queues turn into backlogs.
Every item has a clock, and the clock is visible. A queue without an SLA is a folder. The clock also produces the only honest measure of whether the thing is working: not how deep the queue is, but how long items sit in it and how often a resolved item comes back.
Resolution writes a rule. This is the part that compounds. An exception closed by a person and forgotten is a cost. An exception closed by a person and turned into a rule — this sender, this phrasing, this default — is an asset that pays every time the pattern recurs. Over a year in one vertical, that accumulated body of resolved cases is worth considerably more than the engine that routes them. The engine can be rebuilt in a quarter. The corpus cannot.
One item, in full
EXC-2481Order 4471-B · line 3 of 9
- Received
"Sechskantschraube M10x50 A2-70, Vollgewinde, 250 St."
sender einkauf@[kunde].de · 14:06 · PDF attachment, page 2
- Resolved
Thread system Metric "M" Diameter 10 mm "10" Length 50 mm "50" Material group A2 · 1.4301 "A2" Property class 70 · at least 700 MPa "70" Thread length Full "Vollgewinde" Quantity 250 pcs "250 St." - Missing
Governing standard. Not stated in the line.
- Why it matters
A full-thread hex bolt is DIN 933 or ISO 4017.
At M10 the two differ — 17 mm across flats against 16 mm.
Stock holds ISO 4017. This customer's last four orders specified DIN 933 explicitly.
- Question
DIN 933 or ISO 4017 for this line?
- Routed to
Inside sales, [customer] account
Not to whoever is free. To whoever can answer this.
- Clock
Opened 14:06 · target 16:06
Order 4471-B held, 8 of 9 lines clear
- On answer
Writes a rule: from einkauf@[kunde].de, "Vollgewinde" with no standard named means DIN 933.
The next occurrence resolves without a person.
Note what is not in it: a ranked list, a confidence score, and a suggestion. One question, one recipient, one clock, one rule written on the way out.
Queue depth is the wrong number
Depth tells you almost nothing. A shallow queue can mean the system is resolving well, or that it is guessing and the errors have not surfaced yet. Three numbers are worth watching, and all three are uncomfortable at first:
Time in queue, per group. Broken out by the five groups above, because a 2-hour average across all of them hides that engineering questions sit for 2 days.
Rework rate. How often a resolved item comes back — as a credit note, a return, a complaint, or the same question next week. This is the number that tells you whether resolution is real.
Rules written per hundred resolutions. If this falls towards zero, the queue has stopped compounding and has become a permanent staffing line. That is a legitimate outcome for groups four and five, and a failure for groups one and two.
What a queue like this assumes
Intake and matching come first; the queue is what catches what they miss. In front of a fully manual process a queue is a second inbox, which is why it is the second thing built rather than the first.
Commercial decisions stay with your people. Groups four and five route to them, always. We build the routing, we form the question, we hold the clock — a price deviation and an engineering substitution are both answered on your side of the table.
What we sell is the queue, the rules that accumulate in it, and a resolution volume we commit to. If what you want is people at desks handling volume, hire them — it will be cheaper.
Your ERP stays as it is configured. We deliver into it.
The arithmetic changes somewhere above a few hundred exceptions a month. At a few dozen, a good spreadsheet and a named owner will do. The teardown below tells you which side you are on, on your own orders.
What it costs
Start with your own tail — C0, five-order teardown. 3 days. Send us five real orders exactly as they arrived: the email, the attachment, the mess. You get them parsed, and you get an honest account of what did not parse and why, sorted into the five groups above. Credited against a project within 60 days.
That report is the entire sales argument for everything below it, which is why we would rather show you your tail than describe ours.
Exception Desk — C6. A monthly retainer. Priced by resolution volume, not by seats. Includes routing, SLA, the rules written on the way out, and monthly reporting on the three numbers above.
Sold only after the queue exists. Nobody buys monitoring first, and it is sold in that order for the same reason. The queue itself is built inside the flow project — C4, priced per additional sender format.
You own what we build. Repository, documentation, configuration and prompts, with no lock to us and none to a model provider. The rules corpus is yours, including the part of it we wrote.
What we can and cannot show you
Catalog Brain, our own system for industrial distribution, has proven specification matching — the group-two work above, on real catalogues.
Order intake is a demonstrator. We have built it and we can run your documents through it. It has not yet run a live order stream at a customer, and we would rather write that here than have you find out on the third call.
Which is why the first step is 3 days on your own orders. What we can show you is our own, and the queue above came out of building it.
Questions
- We already have Conexiom / Esker / Rossum. Does this replace it?
- No. It sits behind it. Your vendor handles the share their rate covers; this is about what arrives after. In most streams we have looked at, what arrives after is not small and nobody owns it.
- Can you just plug into our existing exception mailbox?
- A mailbox is not a queue — it has no per-line unit, no routing by competence, no clock and no way to write a rule on resolution. We can read from it on day one, but the first work is turning it into something with those four properties.
- How long before the queue actually shrinks?
- Groups one and two shrink from the first weeks, because each resolution writes a rule. Groups three, four and five will not shrink much, and if someone tells you they will, ask which group they mean.
- Who resolves the exceptions — you or us?
- Groups one and two, the system. Groups three, four and five, your people, because those need history, authority or accountability that sits inside your company. On the Exception Desk retainer we operate the queue, chase the clock and write the rules; the judgement stays with you.
- What happens to the rules if we stop working with you?
- They are yours and they stay in your repository. The corpus is the valuable part and it is yours from the first rule written — the handover package is in every statement of work, rather than an upsell.
- Is this GDPR-relevant?
- Order documents contain names and business contact details, so yes, and it is handled in the DPA rather than waved at. Processing location and retention are set before the first document moves.
A 45-minute call. Bring the last five orders that came back to a person. We will sort them into the five groups on screen and tell you which ones will ever go away.