Hundreds of Exceptions, a Few Dozen Decisions

A big backlog of exceptions does not shrink because you work faster through the rows. It shrinks when you turn rows into decisions, then make the decisions that clear the most rows first. Hundreds of rows usually hide a few dozen real choices.

I have faced this shape of problem twice, on two very different teams. One was a pile of stuck records with a deadline the next morning. The other was a list of naming conflicts left behind by years of people setting up projects their own way. The fix was the same idea both times: stop counting rows and start counting decisions.

In one back office: hundreds of rows, due by morning

A hold backlog had grown into the hundreds. Every row was a record the system would not process, and the whole lot needed to be cleared or routed by the next morning.

My first worksheet was the natural one. One line per row, a status column, and a summary at the top that counted what was cleared. The summary looked rows up by their position in the sheet. Then I sorted the sheet to put similar rows together, and every summary formula broke at once. The numbers still showed. They were just counting the wrong rows.

That was the first lesson, and it is a small one with a big cost: never let a formula depend on row order. Every lookup has to point at something that stays with the row when it moves, like an ID.

The second lesson came from the sort itself. Once similar rows sat together, it was obvious that most of them were not separate problems. The same account, the same person and the same code showed up again and again, once per date. One fix would clear every one of those rows.

So I grouped the rows by that key: account plus person plus code. Each group became one check, with its own stable ID, and every lookup was rebuilt on that ID. Hundreds of rows became a few dozen checks. That is about five times fewer decisions, and roughly half of them were cleared in one morning. The rest went to the people who owned them, each with only their own checks attached.

On another team: a hundred naming decisions

Somewhere else, I was reconciling a task tracker that many people had set up over time. Lining the projects up produced about a hundred naming decisions. Was "In Progress" the same as "Doing"? Should "Completed" become "Done"? What should an untitled section be called?

I started at the top of the list and worked down. The first hours went into names that each appeared in exactly one project. Meanwhile one unnamed section appeared across dozens of projects, waiting near the bottom of an alphabetical list.

The fix was a single extra column: reach. For each value, how many distinct places does it appear? Sort by that, descending, and the list reorders itself by payoff. The first decision now cleared dozens of places. The first ten cleared most of the list.

Find the smallest key

Grouping only works if the key is right. The test I use is one question, asked of every group: would one action fix every row in it?

If the key is too broad, the answer is no. Group by account alone and you merge different people with different problems into one check that nobody can close. If the key is too narrow, you get your rows back. Add the date to the key and every group is a single row again.

The right key is the smallest one where the answer is yes. In the back office it was account, person and code. In the tracker it was the normalized name. Write the key down at the top of the sheet, so the next person groups the same way.

Rank by reach, rule once

Reach is the number of distinct places an exception touches: records, projects, people. Count places, not occurrences. A value printed twice in the same project still has a reach of one.

Before counting, normalize the obvious variants: case, spacing, punctuation. "Untitled section" and "untitled Section" are the same problem, and they should land in the same row.

Then take the list in batches of about ten, one sitting per batch. For each item, write the ruling once in a crosswalk:

The crosswalk does two jobs. It means no exception is ever decided twice, because you check it before deciding. And it is the only source for changes: rulings are applied from the crosswalk in bulk, never by scattered hand edits that drift from what was agreed.

The crosswalk starts empty on purpose. Nothing gets applied without a ruling, and rulings that belong to someone else go to that person as a batch, not one message per item.

Stop at the tail

Every reach-sorted list ends in a long tail of items that each touch one place. Working the tail feels productive, because each item closes quickly. It is mostly not worth the time.

So set a stop rule before you start. When the remaining items touch one record each, stop and decide, as a separate question, whether the tail is worth clearing at all. Sometimes it is. Often it can wait for the next time someone opens those records anyway.

What goes wrong

• Formulas keyed on row number. One sort breaks every summary. Key everything on a stable ID.
• Rows printed twice in the export. They make groups look bigger than they are. Remove exact duplicates before grouping.
• One message hiding two causes. Two rows with the same wording can need different fixes. Spot-check one row per check after fixing.
• Normalization that merges too much. Two values can look alike and mean different things on different boards. Check before you merge.
• A group with no owner. Name an owner for every check before moving on.

When the fixes are in, re-export the backlog and compare it with the original. That is the proof the fixes landed, and that nothing new appeared while you worked.

If your exceptions come from matching payments to invoices, the same grouping logic applies to the payment reconciliation exception queue. For any list, the free backlog grouper ranks values by reach, cuts them into batches of ten, and shows how much each batch clears. The full method, with the crosswalk template and checklists, is in The Backlog Playbook (PDF).

The takeaway

Before you work any exception list, add two things. A grouping key, so rows become decisions. And a reach column, so the decisions that clear the most go first.

Rule each one once, write it in a crosswalk, and apply only from there. Never let a formula depend on row order. Stop at the tail and decide it on purpose.