Discovery found a broken process, not a slow one

A process lead at an accounting firm told me about a reconciliation that took her team three days every month and that everyone assumed was simply slow. Staff matched transactions across two systems by hand, chasing down the ones that did not line up. It was tedious, it was late every month, and the request that came to her was the natural one. Get AI to do the matching. Turn three days into an afternoon.

She agreed it was worth looking at. But before scoping a matching model, she asked her team to walk her through exactly what they did during those three days, step by step. What she found was not a slow process. It was a broken one, running slowly enough that the breakage stayed hidden.

Speed was covering for error

The two systems disagreed constantly, and the reason they disagreed was that an upstream step wrote the same transaction differently into each one. The staff were not really matching. They were compensating, applying a set of undocumented mental rules to force two records together that never should have diverged in the first place. Sometimes they compensated correctly. Sometimes they guessed. The three days of slow, human work was absorbing a data error nobody had fixed, and the slowness was the only thing keeping the guesses small enough to catch.

Now imagine automating that. An AI trained to match the way the staff matched would have learned the guesses along with the good judgment, and it would have applied them at speed, across everything, without the pause where a person notices something is off. The firm would have taken a process that was quietly wrong three days a month and made it confidently wrong in an afternoon. Faster, cleaner-looking, and harder to catch. Automation does not fix a broken process. It scales it.

The process lead’s real problem was upstream. Fix the step that wrote transactions inconsistently into the two systems, and most of the mismatches disappeared. The reconciliation that was left was small, mechanical, and genuinely fine to automate, because now it was matching records that were supposed to match.

A colleague who runs operations at a logistics company described the same lesson. His team wanted to automate a shipping-exception workflow that took forever. When he traced it, the exceptions were being created by a bad address-validation rule two steps earlier. The workflow was slow because it was cleaning up a mess it should never have received. He fixed the validation, the exceptions dried up, and the workflow he had planned to automate barely needed to exist.

Ask whether the process deserves to exist

The discipline is to separate two questions that feel like one. Is this process slow, and is this process right? Speed problems and correctness problems look identical from the outside, because a wrong process staffed by careful people is always slow. The care is what hides the wrongness. Automate before you check, and you remove the care and keep the wrongness.

A few questions that surface it during discovery:

If this step vanished, would the work be correct, or does it exist to patch an earlier mistake?
Where do the exceptions this process handles actually come from?
Are the people doing this applying judgment, or compensating for bad inputs?
Would automating this preserve a workaround that should not exist?

If the process is compensating for something broken upstream, do not point AI at the compensation. Fix what is broken, and see how much process is even left.

How we handle it at Density Labs

Telling a slow process from a broken one is part of what we do in the AI Opportunity Assessment, our two-week fixed engagement at $2,500. We trace the work back to where the mess originates, and more than once the honest finding is that the process a client wants to automate should be shrunk or repaired first, not sped up. That is a cheaper answer than a matching model that scales an error across the whole ledger. Fixing the process sometimes removes the need for the AI entirely, and we would rather say that than build the wrong thing well.

A slow process is sometimes a broken one wearing a disguise. Fix it first, because AI does not correct a bad process, it just runs it faster.