ROI vs Safety: Two Different Automation Decisions

High ROI is not a reason to automate. It is one of two reasons. The other one can veto it.

Most automation projects die because those two reasons get answered as one question. They are not one question.

Does this workflow save money?

Is this workflow safe to automate?

Here is what mixing them costs. An invoicing workflow had obvious ROI. It saved a person about six hours a week, and the spreadsheet said so. It shipped on a Friday. Over the weekend a retry path no one had designed re-ran the charge step, and eighty customers were invoiced twice. Nobody noticed until Monday, when a customer replied “why have I been charged twice.” The ROI was real. It was also irrelevant the moment the safety question went unasked.

So separate them on purpose, because they are answered in different units. ROI is a money question, and it has an arithmetic answer: take the manual time, multiply by how often the work happens and how many people do it, subtract the human time the automated version still costs (review, exception handling, the monitoring someone now has to do), and subtract what it costs to build and keep alive. If what remains is negative, the workflow is not worth automating, and nothing about safety can rescue it; there was never anything to win. If it is positive, you have passed the money gate. The money gate has no opinion about anything else.

Safety is a different question in a different unit, and the unit is consequence, not currency. It asks what happens when this workflow fails silently. Not loudly. Silently, the way the invoicing one did. Who notices. How long until someone does. What it costs to undo. Risk is not one magnitude; it is a category. A duplicate notification email is a shrug. A double invoice is the Monday you just read about: recoverable, but only after it has reached customers and trust. Stale state overwriting production data is not the same animal at all; some of those failures cannot be undone, only apologised for. The invoicing workflow had real ROI and real risk at the same time, and the correct move was never “ship it because the math is good.” It was a human-review step on the charge path: cheap, obvious in hindsight, and never added, because the math was good and the math was the only thing anyone looked at.

That is the trap, and it is almost always the same trap: the money number is concrete and the risk number is hypothetical, so the concrete one wins by default. Nobody decides to override safety. They answer the question that has a number and ship before they have answered the one that does not. High ROI does not earn a pass on the safety question. Low ROI does not get rescued by being safe. Each is answered on its own terms, and only then are the two read together: worth it and survivable, or it does not ship.

The rule

Score the two separately, or one quietly overrides the other. It is always money overriding risk, never the reverse.

ROI tells you whether automating is worth it. Safety tells you whether you are allowed to. A workflow ships only when both answer yes.