Skip to content

Before you worry about the AI's mistakes, count the ones you already make

Two side-by-side panels: scattered hidden error icons on the left, a logged count grid on the right with a green check badge.

Ask an owner why a repetitive job is still done by hand, and the answer is rarely cost. It is some version of "what if it gets one wrong?"

That is a fair question with a hidden flaw. It compares the automation against a manual process that never makes mistakes. No such process exists. The mistakes are already happening. They are spread across three people, fixed quietly by whoever spots them, and never written down. So nobody knows how many there are.

I have argued here that the gap between having AI and running on it is a missing starting point, and that the safest first automation checks rather than does. This is the objection that stops owners before either of those. The answer is not reassurance. It is a number you have never had.

The right question against the wrong standard

"What if it gets one wrong?" is the right question. The standard behind it is wrong.

The owner measures the automation against perfection. Not because the manual error count is zero. Because it is invisible. Nobody on the team is careless. The mistakes stay hidden because nobody counts them.

Why a machine's mistake feels worse than a person's

A person's slip looks like a one-off. Someone was busy, it got fixed, everyone moves on.

An automated slip looks like the system failing. And it can repeat. So owners hold the machine to a stricter bar without noticing. The same number of mistakes feels acceptable from a person and alarming from software.

Count for two weeks before you decide anything

Pick the one process you are considering. Count the mistakes in the manual version for two weeks. Three rules:

  • Agree up front what counts as a mistake.
  • Whoever fixes one logs a single line. What went wrong, and when.
  • Record whether it was caught inside the business or by a customer.

Paper works. A shared sheet works. Do not build a tool for this. The point is a number, not a project.

What a count looks like in a nine-person logistics firm

This is a pattern I see often. A nine-person logistics firm has a coordinator who re-keys delivery details from customer emails into the booking system. The owner has held off automating it. A wrong address would send a truck to the wrong place.

A two-week hand count finds 14 re-keying mistakes. Most are caught only when a driver phones from the road.

The feared failure was already happening. It just had no number attached.

Write the new standard down before you build

"Never wrong" was never the real bar. Replace it with three tests:

  • Fewer mistakes than today's count.
  • Caught before the customer sees them.
  • Each one traceable to a cause.

Write this down before anything is built. I would not start without it: if the standard is not on paper first, the first slip reopens the whole decision. With it on paper, the first slip is a data point you compare against the count.

When the count comes back close to zero

Sometimes the count comes back near zero. That is a real answer. Leave the process alone and move to the next candidate.

I would rather an owner skip a process that already works than automate it to prove a point. The count protects you in both directions.

Count first. Then decide.


Keep exploring

If you want help finding which process to count first, contact FIT. You might also find why the safest first automation checks rather than does useful.

Share this post LinkedIn X Email