🧮Exception budget

My own term, so handle with care. I said it in the blameless retro on 19 March and wrote it down two days later so that I would stop redefining it mid-sentence.

Three things follow if the idea holds.

1. The budget is a property of a person and a shift, and it is small. It rests on 🧩 Working memory limits and on the minutes in a morning.
2. Anything shown beyond the budget is not handled later. It becomes background, and the screen teaches the dispatcher to ignore it.
3. So a product that surfaces exceptions is spending someone's budget every time it adds a row. An exception type that cannot justify the spend should be grouped, delayed or handled by a rule.

What it is not: a target, a service level or a cap on how many things may go wrong. Freight goes wrong at whatever rate it likes.

It is the practical half of 💎 An exception is information about the process and not a nuisance in it. Information nobody has the capacity to receive is not information yet.

Where I have seen it

Rotterdam, February. Rafael Quint said show me Tuesday, and Tuesday had 214 open exceptions per dispatcher before nine. Whatever the budget is, it is not 214.

Launch night, March. In 📂 Exceptions Inbox general availability the duplicates from auto-triage did their damage by this route. Each duplicate was harmless. Left on until morning, they would have spent every dispatcher's budget on nothing, which is why switching it off at 02:40 was right.

The digest. 🔍 Exceptions digest by e-mail is the idea in product form: five things at 07:00.

Open questions

• Nobody has measured it. My guess is tens per shift, not hundreds, and a guess is all it is. To ask Bao Nguyen: could closing times in the event stream give a first number?
• Is it one budget, or one per kind of exception? A customs hold and a late scan are not the same weight.
• Does it shrink through the shift? Parked with the other queue questions in 🔭 Queueing theory for support and dispatch.