A material study in bright daylight. A dense radial wheel of clear turquoise glass blades with one clear opening at its centre, and a single pearl silver ribbon curving down and away from that opening across the pale floor.
  1. Home
  2. Insights
  3. Agentic Operating Systems
  4. Worth automating

Decision guide

Whether a processis worth automating.

A process is worth automating when three numbers hold: it runs often enough, each run costs enough, and the share of cases that need a person is small enough. The third is the one that decides it, the one that sinks projects after a successful demonstration, and the one almost nobody measures.

The exception rate can be measured in an afternoon from fifty real cases. It is the cheapest input on this page and the one that most often changes the decision. Written 23 September 2026.

HUREAL / Material studies

The arithmetic

Three numbers,and the third decides.

Every case for automating a process reduces to the same three quantities, and two of them are easy. How often the process runs is a query. What each run costs is an hourly rate multiplied by a duration, plus whatever the delay costs. Both of those tend to be generous, which is why proposals are built on them.

The third is the exception rate: the share of runs that do not follow the standard path and need a person to decide something. It is the term that determines whether the first two matter, because automation captures the standard path and the exceptions come back, in a batch, to somebody who now has less context about them than the person who used to handle them as they arrived.

A process with a very high exception rate is not really a process. It is a series of decisions that share a name and a form. Automating the shared part of it produces a system that handles the easy half and returns the hard half with a status code, which is often a net loss once somebody has to work out what the status code meant.

This is why the demonstration is not evidence. A demonstration is necessarily built on the standard path, because a demonstration full of exceptions is a bad demonstration. The exceptions are exactly the part that decides whether the thing pays for itself, and they are exactly the part not shown. The useful request is to see it run against ten cases you pick, including the three most awkward from last month.

The measurement

An afternoonand fifty cases.

  1. Take fifty consecutive cases from an ordinary recent month

    Consecutive, not selected. A sample chosen by anybody who remembers the cases will be a sample of memorable cases, and memorable means unusual. Pick a month that was neither the quietest nor the busiest.

  2. For each one, write down whether it followed the standard path

    One line per case. Followed it, or did not, and if it did not, what was different. The person who runs the process can do this faster than anybody else and should, because they are the only one who knows what standard means here.

  3. Count, and then read the exceptions properly

    The count is the headline. What the exceptions say is the useful part, and there are only three possibilities.

  4. Ask which of the three you are looking at

    If the exceptions are all different, the step involves judgement and automating it means gating it. If several are the same kind, that is a second rule hiding inside the first, and writing it down has just lowered the exception rate. And if most of them trace back to a missing piece of information at the start, the problem is the input rather than the process, which is a far cheaper thing to fix.

What the exceptions are telling you, and what to build as a result
If the exceptions are Then the step is And the thing to build is
Rare and each one different Genuinely standard, with occasional judgement. A rule, and a clean hand-off for the rest. The cheapest outcome on this table.
Rare and mostly one kind Two processes sharing a name. Two rules. Writing the second one down has removed most of the exception rate for nothing.
Common and each one different A judgement step, not a process step. Either a system that prepares and waits for a person, or nothing at all. Both are legitimate.
Common and traceable to a missing input Fine, once the input arrives complete. A better form. This is the least expensive fix in the whole category and the most commonly skipped.
Unknown, because nobody has counted Unmeasured, and therefore unpriced. The count. Fifty cases, one afternoon, before anything is spent.

Scroll the table sideways to read it.

The second number, properly

Waiting costs morethan handling.

The cost of a process is usually calculated as labour: minutes multiplied by a rate. For anything a customer is waiting on, that undercounts it substantially, because the expensive part is not the work, it is the gap before the work starts.

A quote that sits for two days is not two days of labour. It is two days during which a buyer is talking to somebody else, forming an impression, or losing the urgency that made them ask. The same is true of a document request that holds up a file, an approval that holds up a job, and a question that holds up a decision somebody else is waiting on.

The measurement is available in most systems that already record a timestamp. Group cases by how long they waited before a first substantive response, and compare what happened next: how many converted, how long the whole thing took, how many needed a second chase. The pattern usually shows up without any statistical work at all.

The confounder, named rather than ignored

Cases handled quickly are not a random sample. Urgent work gets handled faster because it is urgent, important customers get handled faster because they are important, and simple cases get handled faster because they are simple. All three of those also predict a better outcome on their own, with no causal contribution from the speed.

So the comparison is suggestive rather than conclusive, and it should be presented that way rather than converted into a headline figure. The way to get closer to an answer is to look within a single case type and a single customer tier, where the confounders are at least partly held still, and to accept that the remaining number is an indication rather than a measurement.

An automation proposal that puts a precise revenue figure on faster response, with no method behind it, is asserting something it cannot know. The honest version is that the direction is clear and the magnitude is not.

The ladder

Five rungs.Stop at the first that works.

Automation is the fifth answer to a process problem, not the first. Four cheaper things sit below it and each of them solves a meaningful share of what gets brought to a supplier as an automation request.

  1. Delete the step

    The cheapest automation is the one nobody builds. Ask what would happen if the step stopped tomorrow, and ask the person who does it rather than the person who designed it. A surprising amount of routine work exists because something used to require it.

  2. Change the input so the step is unnecessary

    Most back and forth is caused by information that was not collected at the start. A form with the right fields, validated properly, removes the chase entirely rather than automating it. This rung solves more requests than the four above it combined.

  3. Turn on what you already own

    Most established software has a rules engine, a workflow tool or a notification system that was never configured. It is not glamorous and it is included in a licence that is already being paid. Check before commissioning a replacement for it.

  4. Build a rule

    One condition, one action, no judgement. Cheap, predictable, will not drift, and correct forever if the rule is correct. Where the process is genuinely one stable rule, this is the right answer and anything more sophisticated is overhead with a subscription.

  5. Build something that reasons

    Justified where there is judgement in the step, it crosses more than one system, and the work currently waits in a queue until somebody gets to it. All three conditions, not one. Meeting one of them is a reason to look at the rungs above.

The order matters because each rung is roughly an order of magnitude cheaper than the one below it, and because a process fixed at rung two stays fixed. A supplier who arrives at rung five without having walked the first four is selling a rung rather than solving a problem, and the first four are where most of the available value actually is.

Afterwards

An automated processis still somebody's job.

The business case usually ends at launch, and the costs do not. Five things continue, and a project that is only justified when they are omitted was not justified.

  • Somebody owns the exception queue

    The exceptions did not disappear. They arrive in one place instead of arriving continuously, which is better, and somebody works them.

  • Somebody notices when it stops

    A process that quietly stops running produces no errors, no complaints and no output, and the absence of output is hard to notice in a busy week.

  • The rules drift away from the business

    Prices change, policies change, a product line is added. The rules written in month one describe the business of month one, and a review cadence is part of the cost.

  • The connected systems change underneath it

    Every vendor at the other end of a connection ships changes on their schedule rather than yours.

  • Knowledge of how it works leaves

    The person who specified it moves on, and what remains is the documentation that was written, which is usually a reason to have written some.

And the honest case for automating anyway. Those five are real and they are smaller than the thing being replaced, which was a person doing the same work continuously, with the same drift, the same knowledge loss and no log. The argument for automation is not that it is free to run. It is that its running cost is visible and bounded, which the current one is not.

The verdict

When to do it,and when not to.

The arithmetic usually works

  • Volume is high and the exception rate is low, measured rather than asserted.
  • Work arrives outside working hours and waits for the office to open, which makes the delay cost a real number.
  • Two systems are bridged by a person and a spreadsheet, and everyone knows which spreadsheet.
  • Volume is seasonal and the peak is currently covered with overtime rather than with headcount.
  • Something is written down: a price list, a policy, a document set that an answer could be grounded in.

The arithmetic usually does not

  • The process runs a few times a week and one person holds it comfortably. At that volume the overhead exceeds the saving, whatever the demonstration looked like.
  • The exception rate is high and the exceptions are all different. That is a judgement step, and the useful project is to support the judgement rather than to route around it.
  • Nothing is written down. Grounding needs documents. Where the price list lives in one person's head, writing it down is the first project and it is a different one.
  • Nobody has counted anything. A business case built on impressions will be defended with impressions, and the first contradicting month will end it.
  • The requirement is that the company should be using AI. There is no process in that sentence, so there is nothing for the three numbers to be measured against.

Where the answer is one of the first four rungs of the ladder, that is the answer worth giving, even by somebody who would have been paid for the fifth.

Questions

Questions peopleactually ask.

  • How many cases do we have to look at?

    Fifty consecutive real cases from a recent ordinary month is enough to tell a low exception rate from a high one, which is the distinction that changes the decision. Consecutive matters more than the count: a sample chosen by anybody who remembers the cases will be a sample of memorable cases, and memorable means exceptional.

  • The demonstration worked perfectly. Why is that not proof?

    A demonstration is built on the standard path, because that is what makes a clear demonstration. The value of an automation lives in what happens to the cases that do not follow it, and those are not usually shown. The useful request is to see it run against ten cases you choose, including the three most awkward ones from last month.

  • What if we cannot get the numbers out of our systems?

    That is itself a finding, and it usually points at a different first project. A process nobody can measure is a process nobody can manage, and the cheapest thing to build is frequently the visibility rather than the automation. It is also the thing that makes the automation decision answerable next quarter instead of unanswerable again.

  • Is it cheaper to hire somebody?

    Sometimes, and it is worth the comparison rather than the assumption. A person is flexible, handles exceptions natively, and costs the same whether volume is high or low. Automation is the opposite on all three. Where volume is seasonal and the peak is covered by overtime, the arithmetic usually favours automation. Where volume is steady and modest, it frequently does not.

  • Where do these projects most often go wrong?

    Scope, in one specific way: the first process chosen is the most visible rather than the most tractable. The most visible process is usually customer facing, high stakes and full of exceptions, which is the worst combination for a first build. A dull internal process with a high volume and a low exception rate proves the machinery, and it proves it where a mistake costs an apology rather than an account.

Read next

Three that followfrom this one.

The service behind this article

The counting happensbefore the building.

An Agentic Operating Systems engagement opens with the process mapped by the people who actually run it, exceptions included, and it is a short conversation where the arithmetic says the answer is a rule, a form or nothing at all. Where the answer is the smaller thing, that is the recommendation.

The discovery call runs the three numbers on a real process with the people who run it. Volume from a system, cost from your own figures, and the exception rate from actual cases rather than from an impression. The written proposal carries the arithmetic, and a scope only if it is justified.

Book a discovery call

More on this subject in the Agentic Operating Systems index, and everything else at Insights.

A material study photographed in bright daylight. A tall fan of clear turquoise glass fins rises on the right of the frame with a polished pearl silver ribbon curving through it, standing in a shallow film of still water. The left of the frame is empty pale mint.

Software you own from day one.

HUREAL / Material studies