If your team double-checks every automated task, you automated nothing

A client walked me through his new automation last month, and he was proud of it. Supplier invoices come in, get read automatically, matched against the purchase order, and if everything lines up they go straight into the accounting system, approved. Solid build. Then I asked the person who used to do that job by hand how much time it saved her. She thought about it and said: none, really. She still opens every invoice and reads it. You never know.

That is the most expensive state an automation can be in. It runs, it costs money, someone spent days building it, and next to it a human keeps doing the exact same work. The company now pays twice for one task.

I run into this more than I would like. A twelve-person shop, a department inside a large corporation, same story. The automation works. It just did not solve the problem it was built for. Because the goal was never "a machine creates invoices." The goal was "a person no longer has to." And that part did not happen.

Why people keep checking

Nobody double-checks out of stubbornness. Checking is a rational response to a lack of trust, and the trust is usually missing for good reasons.

Someone got burned once. At some point the automation waved through a mistake, a wrong number, a swapped invoice, and the person on the other end had to clean it up. After that, she checks everything. One visible failure outweighs a hundred silent successes. That is not irrational. That is how people who are accountable for outcomes actually behave.

The automation is a black box. It shows a result but not how confident it was. Was the purchase-order match obvious, or a guess? You cannot tell from the approved record. If I cannot see when the system is sure, I have to distrust all of it, all the time.

And nobody ever tells the human how often the automation was right. No number, no log they actually see. Trust does not grow in the dark.

So should you just trust it blindly?

No. The fix is not to remove the checking. The fix is to move from full inspection to sampling. Full inspection means a human reviews every case and quietly replaces the automation. Sampling means she reviews a small slice and uses it to measure whether the automation still works.

In practice: instead of opening a hundred invoices a day, she opens ten picked at random. Weeks go by with no errors in the sample, and that is a real signal. She finds one, and now you know something is off and you look closer. Dull permanent control turns into a measurement. But that only holds if the automation tells you when it is sure and when it is not.

Building trust instead of asserting it

You do not earn trust by announcing that the system is reliable now. You earn it with three things you actually build.

The automation reports its own uncertainty. Clean match, exact amounts, it runs through. Anything off, an amount that does not agree, two candidate orders, it lands in a review queue instead of the approved pile. The human gets exactly the cases that need judgment and none of the ones that do not.

There is a visible error rate. For the first few weeks the automation runs alongside the old way and you count. On one project the match rate was 98 percent after a month, and every one of the remaining two percent had correctly flagged itself into the review queue. Not a single error slipped through unseen. That number did more for adoption than any explanation I could have given.

The logs are readable by the person affected, not just by IT. When you can see why the system decided what it decided, you stop distrusting it wholesale.

A word on that review queue, because this is where it usually goes wrong. If thirty or forty percent of cases keep landing there, you did not build an automation, you built a filter. The person is back to handling almost everything, just in a different order. The queue is a valve for genuine exceptions, not the default path. When its share climbs, that is a signal to fix the process upstream, not to make the clerk click faster.

What I took away from it

An automation is not finished when it runs. It is finished when the people next to it stop shadowing it. That is a higher bar, and most projects stop short of it.

Before you automate the next process, ask an uncomfortable question: will someone actually do less afterward, or will they just get a machine to babysit on top of their existing work? If you do not know the answer, the process is not ready to be automated. It is ready for a conversation with the people who do it today.