Your Automation Covers Less Than You Think. Here Is How to Get the Number.

You can almost certainly state your automation's success rate. Someone reports it monthly. It is probably high.

Now try stating its coverage — what share of the work it was supposed to handle it actually touched.

For most businesses that second number does not exist. Not because anyone is hiding it. Because nothing produces it, and nobody has asked.

These are two different claims

• Does it work? Point it at a case and watch. Easy, satisfying, always demoed.
• Does it cover? Enumerate everything it is supposed to handle, count what it actually touched, subtract. Tedious, never demoed, and the only one of the two that predicts whether the automation is doing its job.

Automation reports on what it did. It is structurally incapable of reporting on what it never saw. A summary reading "all items processed, zero errors" can be completely accurate and completely silent about everything that never entered the queue.

The absent case does not generate a log line. That is the whole problem in one sentence, and it applies to every automated system I have audited.

Why the gaps stay invisible

Coverage gaps rarely announce themselves as failures. Each one is small, specific, and individually reasonable: a credential nobody finished setting up, an integration that broke on a Thursday and got a one-line note, an item added to a contract but never added to the system.

Each of those reads as housekeeping in the week it appears. The damage is that they are never added together. A dozen one-line footnotes across a dozen reports do not read like "a meaningful share of the work is not happening," because no single report ever contains more than one of them.

Where this shows up in an operation

The pattern generalises well past software maintenance. These are the shapes it takes most often — illustrative, not case studies:

• An invoice-processing workflow handles the standard layout. A few vendors send something different, so those quietly go to somebody's inbox. A year later the automation reports excellent straight-through processing and nobody can say what the remainder costs.
• An AI email triage handles the common categories and skips anything unusual. The unusual ones are the ones that matter.
• A reporting automation pulls from most of the systems that hold relevant data. The dashboard looks complete, because a dashboard cannot render an absence.

In each case the automation is working. In each case the organisation believes it is covered, plans around that belief, and stops staffing the gap.

That last part is the actual damage. An acknowledged manual step gets staffed. A gap you believe is covered gets nothing — no owner, no budget, no attention — and it degrades silently until a customer finds it for you.

The measurement, which takes an afternoon

You do not need tooling to start. You need a denominator.

1. Write down the full population. Every case the automation is meant to handle — every client, every invoice type, every request category. Get it from the contract, the customer list, or the accounting system. Critically: not from the automation's own records, which only know what it has already seen.
2. Count what it actually touched last period. Distinct items, not runs.
3. Subtract, and name every item in the gap. Not a percentage — names. A percentage is dismissable; a list of named customers is not.
4. State coverage alongside the success rate. "97% success on 65% of the population" is the honest sentence. "97% success" is the one that gets reported, and it is the one that lets a share of the work disappear.

Then automate the counting, so the number appears without anyone deciding to look. That is the step that makes it durable: a coverage figure someone has to remember to calculate will be calculated exactly twice.

Build it so the count comes from the contract side, not the automation side, and so it runs before the work does. A measurement that can be skipped on a busy week will be skipped on exactly the weeks it matters.

The test

If you are running any automated process right now, you can probably produce its success rate today. Try producing its coverage.

If the second number is meaningfully harder to get than the first, that asymmetry is the finding. It means the system is built to tell you about the work it did and has no mechanism at all for telling you about the work it missed — and you have been making decisions on the half that reports itself.

Where this applies to your business

The mechanism is not specific to any one industry. It shows up anywhere a process reports on itself: invoicing, inventory sync, lead routing, backup jobs, any automation whose output is a green check mark.

If you are running automation now and could not, today, produce the list of things it is supposed to cover — not the list of things it did — that gap is worth a conversation. Request a workflow review. We look at what your systems actually reach before we talk about adding anything to them.