When to Automate a Step, Assist It, or Leave It Alone

Ask these of every step on the map, in this order. The first "no" ends the interrogation.

1. Is it high volume? Count instances per week or per month, not per year. Volume is what pays for the build. A step that runs 40 times a week justifies engineering attention; a step that runs four times a quarter almost never does, even when it is tedious. Be honest about what high means in your context: a 12-person finance team and a 400-person shared service center have different thresholds. The useful test is whether the step consumes enough hours that a 30 percent reduction is visible on someone's timesheet.

2. Is it low variance? Sample twenty instances and lay them side by side. If the inputs look broadly the same and the required output is broadly the same, variance is low. If one in five instances needs a phone call to resolve, variance is high, and the automation will spend its life in the exception path. This is the question teams skip most often, and it is the one that decides whether the project survives contact with production.

3. Is it reversible? If the step runs wrong at 2 a.m. with nobody watching, how much does it cost to undo? Reversible means the output can be checked, corrected and re-run, and the correction is cheaper than the original work. A draft email to a colleague is reversible; the same email to a customer is not. A journal entry reversed before close is reversible; a released payment is not. Reversibility is also a governance question, and mature programs treat it as a gate: a named owner for the decision and a system the recommendation lands in, or no go per the gating conditions in the Umbrex framework.

Three yes answers mean automate. Any single no means assist. There is a fourth outcome the questions do not catch on their own, covered after the examples: leave it with people.

The last row is where most teams misread the rule. Exception handling is high volume and highly variable. The instinct is to automate the whole thing because the volume is large. The correct move is to split the step: classifying and routing an exception is a different step from resolving it, and the two get different answers.

Take a three-way match in accounts payable. The invoice arrives, the system looks up the purchase order and the goods receipt, compares line items, quantities and prices, then clears the invoice or flags it.

Volume is high by any measure. Variance is low, because suppliers invoice against orders placed in a structured system. The step is reversible, since a bad match is caught on review before payment and the correction is a re-run. Three yes answers. Automate the matching and the tolerance rules, and route failures onward.

Now the adjacent step. The invoice has no purchase order because someone bought a service without raising one. Volume is still meaningful. Variance is high: sometimes a subscription, sometimes a consultant's milestone payment, sometimes a duplicate. The step is reversible before close. Two yes answers and one no. Assist it. The system proposes a supplier, a category and a GL account from the vendor's history and the invoice text; the clerk accepts or overrides, and nothing posts without a human keystroke.

Then the payment run. Volume is high and variance is low, but it is not reversible. This is the case where the rule protects you from your own enthusiasm. Do not automate the release. Let the system assemble the run, perform the duplicate and sanctions checks, and present a file for a named approver to sign. The work is prepared; the decision is not. If you need a small amount of plumbing behind several assisted steps, one API for text and embedding models keeps it manageable, which is the practical appeal of Quanta Inference when a team is wiring more than one step.

The numbers worth recording are unglamorous and they are the argument. For the matching step, log instances per month, the percent that matched within tolerance, and the percent of failures that were genuine errors rather than data problems. If the third number is low, the tolerance is wrong, not the model.

Legal review earns the rule its keep, because the temptation to automate the first pass is strongest and the cost of getting it wrong is highest.

Split the step in two. The first part is clause detection and comparison: does the draft contain a limitation of liability clause, an indemnity clause, a data protection clause, and how does each compare to the playbook position? Volume is high if your team sees a steady flow of commercial agreements, variance in detection is low because clause types recur, and the task is reversible because the output is a mark-up a lawyer reads. Three yes answers. Automate the comparison and the flagging.

The second part is the decision about what to accept. Is this indemnity acceptable given the customer's size and the deal's value? Should we concede on the liability cap to win the renewal? This depends on context that is not in the document: relationship history, negotiating position, the risk appetite of a partner who is accountable for the outcome. No after-the-fact check tells you a concession was wrong, because the counterfactual is the deal you did not sign. That is accountability that cannot be checked after the fact. Leave it with people, and keep the model out of the loop beyond surfacing the clause and the playbook position.

In practice this is a checklist the lawyer works through, not a document the model rewrites. The system extracts clauses, matches them to playbook positions and drafts the covering note. The lawyer decides. Deals outside the playbook go straight to a human, unaided.

Exception handling deserves its own treatment because a naive reading of "automate the repetitive work" causes the most damage there.

Consider an order management queue. Orders arrive, most flow straight through, and a minority fail a validation: an address that does not resolve, a declined payment, an out-of-stock item, a quantity over the credit limit. Every failure lands in the same queue. The queue is high volume, the variance across exception types is high, and the variance within a single type is often low.

Apply the rule to the queue as a whole and you get "assist." Apply it per exception type and you get a shortlist:

The design rule that falls out is that exception triage (classifying which type an exception is and routing it) is itself a step. It is high volume, its variance is low if your taxonomy is stable, and a misroute is reversible because the item is simply reassigned. Automate the triage and assist the resolution. That single split usually returns more hours than any attempt to automate the hard cases.

The shortlist is only as good as the notes behind it. Record these fields per step and keep them next to the step on the map, not in a separate document that drifts out of date.

step_id: AP-04
step_name: Match invoice line to PO and goods receipt
owner: Accounts Payable team lead
volume: 2,400 instances per month
variance_sample: 20 instances reviewed, 3 failed to match
variance_cause: 2 genuine price discrepancies, 1 missing goods receipt
reversibility: Output held for payment approval; corrections re-run before close
rule_answer: yes / yes / yes
decision: automate
error_budget: 2 percent of lines may need manual correction
review_trigger: manual correction rate above 5 percent for two months

Three fields do more work than the rest. Variance sample forces someone to look at real instances rather than assert the step is routine. Error budget states in advance how often the automated step may be wrong, which turns "reversible" into a measurable property rather than a feeling. Review trigger makes the decision something you revisit. A step that passes today can fail in six months when volumes fall or a new supplier changes the input mix.

Recording an error budget also gives you the number you need for the reversibility question. If the output cannot be checked before it takes effect, you cannot set an error budget, and that is a strong signal the step belongs in the leave-alone column.

Teams treat "assist" as a phase on the way to automation. Sometimes it is. Often it is not, and saying so out loud saves years of failed attempts.

The variability work is useful here because it separates variance you can design around from variance you cannot. Some variation comes from inputs (a supplier sends a scanned invoice instead of an electronic one) and some from the task itself (judging whether a clause is commercially acceptable). The first kind shrinks with better upstream data, and the step may qualify for automation later. The second is a property of the work. It does not go away with a better model, and treating it as a data problem is how programs land in what the portfolio literature calls pilot sprawl: many proofs of concept that never scale because the workflow and the decision ownership were never settled as Agility at Scale's prioritization guidance puts it.

There is a practical reason to stop at assist. Assisted steps are the ones where the spend is easiest to justify. The time saving shows up on a visible population of work, and a human still signs off, so the risk conversation is short. Practitioner guidance is consistent: pick a first project that is both valuable and feasible, start small with a proof of concept, and let its measured impact earn support for the next one per Unit8's project selection guide. Assisted steps are usually the best proof of concept you have, because the fallback is the process you already run.

For small teams the logic holds with lower stakes. Owners of small firms tend to know exactly which tasks consume the day, which makes them good at spotting assisted opportunities without a formal program as Harvard Business School's account of small business adoption describes. Their failure mode is the opposite of an enterprise's: not sprawl, but a scattered set of tools nobody owns.

A rule only helps if the whole team applies it the same way. Four practices make that happen without turning it back into a matrix.

Calibrate once, together. Take ten steps and have three people independently answer the three questions. Argue about the disagreements, not the steps everyone agreed on. Most disagreements are about volume thresholds or about what counts as reversible, and both settle with a shared definition. Write the definitions down in a paragraph.

Separate volume from effort. A step can be frequent and fast, or rare and slow. The rule keys on frequency because automation pays back over instances, but record minutes per instance too. A step that runs 500 times a month at two minutes each is not worth automating; the same 500 instances at fifteen minutes each clearly is.

Set the review trigger before you build. Every automated step needs a number that sends it back for review. Without one, the step degrades quietly and nobody notices until an auditor does. The error budget is that number.

Keep the leave-alone list visible. The steps you deliberately did not touch are a decision, and the reason is worth recording. It stops the same proposal being re-litigated every quarter and protects people doing judgment work from being told, repeatedly, that their job is about to disappear.

If you want a second opinion on the shortlist before committing engineering time, a structured conversation usually catches the obvious mistakes, and a free 30-minute discovery call is a low-cost way to get one through Quanta Consulting.