Automation Fit Assessment: Is This Process Worth Automating?

How this assessment decides

It is not a score out of ten. A handful of the answers describe conditions that make an automation a bad idea today no matter how much time the process consumes — no agreed source of truth, a redesign already scheduled, nobody who owns it when it breaks. Those decide the verdict on their own. Everything else decides how much runs unattended, and how much stops to ask.

1. The work itself

   The first question is what shape the work has, because the shape predicts how well it automates far better than the industry does. Pulling numbers together, watching for a condition, keeping two systems in step, chasing people for a response — each of those has a known build and known failure modes. The second question is whether anyone can state the rule. An automation is a rule written down; where the answer is “someone weighs it up each time”, there is nothing yet to write. Which processes are worth automating goes through each shape in turn.

2. Data and systems

   Software can only act on what it can read, so this step is where most ambitious projects quietly shrink. Two answers matter more than the rest: whether the systems expose an API or an export, and whether one system is the agreed record. Without that second one, an automation does not settle a disagreement between two databases — it publishes one side of it faster and more often. The integration checklist covers the questions to ask about a system before you commit to connecting it.

3. Cost of being wrong

   Reading data is safe at any scale. Everything past reading — publishing something customers see, messaging people, moving money, deleting records — has a cost when it goes wrong, and that cost is what decides whether a step may run unattended. Reversibility and detection do the work here: a mistake you can undo in minutes needs a different design from one nobody notices until month-end. This is the step that produces the approval matrix in your result.

4. Who keeps it running

   The last step is about the six months after launch. A process that is about to be redesigned, one that only exists in a single person’s head, or one that nobody owns when it breaks will defeat a technically perfect build. Every automation eventually meets a case its rules never covered, which is why it should be designed to fail safely from the start — failure-ready automations covers what to do with the run that dies at 2am.

Why this is a separate tool from the ROI calculator

The two answer different questions and it is worth running both. This one asks whether the process is the kind of work that can be handed over, and which half of it can run without anyone watching. The automation ROI calculator asks what it would be worth: hours saved, payback period, and what it costs to run. A process can score an excellent return and still be the wrong thing to build this quarter, which is the case this assessment exists to catch.

What an approval step looks like in practice

Requiring approval is not the same as staying manual. In this billing and receipts automation everything up to the receipt is prepared automatically and a person presses one button to create it — most of the time saved, almost none of the risk. Where the decision itself is judgment, the same idea applies one step earlier: in this AI medical intake assistant the interview and the summary are automated and the diagnosis stays with the physician.

Automation fit FAQ

Is a repetitive task the same as an automatable one?

No, and assuming it is accounts for most abandoned automation projects. Repetition tells you what a process costs; it says nothing about whether the work can be handed over. The three things that decide that are whether anyone can state the rule the process follows, whether the information it runs on sits somewhere software can read, and what it costs when a run goes wrong. A task repeated fifty times a day where each case is decided on its merits is expensive and still not automatable — while a weekly report that follows a fixed rule usually is.

What if only part of the process follows rules?

That is the normal case, and it is a good one. Almost no real process is entirely rule-based; what most of them have is a set of rules plus a short list of known exceptions. The right design runs the rules and routes the exceptions to a person, rather than trying to guess at them. If you cannot list the exceptions, that is the work to do first — whoever builds the automation will have to write them down anyway, and discovering them in production is the expensive way to find out what they are.

Should anything ever run without a person approving it?

Yes — most of what a business does every day, in fact. Reading data, producing reports, comparing two sources, raising an alert to your own team, and preparing drafts are all safe to run unattended, because the worst outcome is a wrong number you can correct or a message nobody needed. The line worth drawing is not automation versus manual, it is reversible versus not. Publishing something customers see, sending messages to people, moving money, and deleting history are the four categories that earn an approval step, whatever the volume.

Why does the source of truth matter more than the tool?

Because an automation copies faster than a person does, including the wrong number. Where two systems disagree, a person notices the discrepancy and asks; software propagates one side of it on schedule, and it is believed precisely because software produced it. Deciding which system wins every disagreement is a half-hour conversation that costs nothing, and skipping it is how a company ends up with three dashboards showing three different revenue figures, all of them automated.

How is this different from the ROI calculator?

They answer different questions and it is worth running both. This assessment asks whether the process is the kind of work that can be handed over, and which half of it can run unattended. The ROI calculator asks what that would be worth — hours saved, payback period, and the cost of running it. The order matters: a process can show an excellent return and still be the wrong thing to build this quarter, because the systems behind it are about to be replaced or because nobody agrees which number is the right one.

What if the process is about to change?

Then wait, in almost every case. Automating against systems that are being replaced, or a procedure that is mid-redesign, means paying for the same build twice — and the second time under deadline, because by then people depend on it. The exception is the read-only half: reports and alerts built on top of whatever exists today are cheap enough to be worth having during the transition, and they tell you what the new process actually needs to do.

Does a process with no written procedure disqualify it?

It does not disqualify it, but it moves the first task. Whoever builds the automation has to produce that written procedure regardless, because the build is the procedure stated precisely enough for a machine. Writing it down first, with the person who actually runs the process, is what surfaces the exceptions while they are still cheap to handle. A process that lives entirely in one person's head is also a continuity risk with or without automation — if they are away for two weeks, it stops.