The Boring 80%: Where AI Pays Off First in Operations

Every operations team runs on a handful of decisions that need real judgment and a very large volume of steps that do not. Someone opens an email, finds the purchase order number, checks it against the ERP, notices the quantity is off by two, writes to the supplier, waits three days, chases again. Repeat four hundred times a week.

That work never makes the strategy deck. It is also where AI pays back first, and by a wide margin.

Why the boring work wins

Two reasons, and both are about risk rather than ambition.

The first is that repetitive work is measurable. You already know how many invoices arrive, how long a claim sits in the queue, what a support ticket costs to resolve. When you automate something you measure, you can prove the result in a quarter. When you automate something novel, you spend the quarter arguing about whether it worked.

The second is that the boring 80% is where the volume lives, and volume is what turns a small improvement into a real number. Cutting four minutes off a task performed twice a month is a rounding error. Cutting four minutes off a task performed nine hundred times a month frees a person. The economics are driven by frequency, not by how clever the automation is.

The hard 20% — pricing exceptions, contentious claims, anything a regulator will ask about — should stay with your people for now. It is genuinely difficult, it is where your margin and your reputation sit, and it is the worst possible place to learn how AI behaves in your business.

How to find it

Do not run a survey asking people what they would like automated. You will get a wish list. Instead, look at where work queues up and where information gets retyped.

• Rekeying between systems. Any time a human reads one screen and types into another, that step is a candidate. Email to ERP, PDF to spreadsheet, portal to CRM.
• Unstructured input at the front door. Invoices, delivery notes, claims, CVs, RFQs, inspection reports. Anything arriving as a PDF, a photo, or a paragraph of prose that someone has to turn into fields.
• Triage and routing. Tickets, complaints, and inbound requests that a person reads only to decide who should actually handle them.
• Drafting from a template. Status updates, standard responses, first-draft summaries of a long thread or document.
• Reconciliation. Comparing two lists that should match and explaining why they do not.

Score each candidate on volume, how consistent the inputs are, and how much a mistake costs. Start with high volume, consistent inputs, cheap mistakes. That combination is unglamorous and it is exactly right.

Exceptions are the real design problem

Here is where most first projects go wrong. A team automates the happy path, hits 85% accuracy, celebrates, and then discovers that the 15% of cases that fall out now take longer to handle than the whole process did before. The exceptions arrive with no context, nobody owns them, and the queue grows.

Design the fallback before you design the automation. When the system is not confident, what happens? Who sees it, what do they see, and how long do they have? A process that handles 70% of cases end to end and hands over the rest cleanly beats one that claims 90% and dumps the remainder into an unwatched inbox.

Set the confidence threshold deliberately, too. For invoice coding you might accept a 2% error rate because the downstream check catches it. For anything touching a payment or a patient, you route far more to a human and accept a lower automation rate. That threshold is a business decision, not a technical one, and it belongs to the person who owns the process.

What the first six months should look like

Pick one process. Instrument it before you change anything, so you know the baseline touch time, cost per transaction, and error rate. Ship something narrow into real use within eight weeks. Measure the same numbers again.

Then do it a second time, and a third. The compounding gain is not the individual automations — it is that your team learns what these systems are reliably good at, your data gets cleaner because something depends on it, and the next project takes half as long.

Carrying the dull, heavy, high-volume work is what this technology is actually good at right now. Give it that load first, and keep your people on the decisions that need them. If you want help picking the first process and proving the number, that is the work we do.