Before You Automate, Try Undoing the Result

Imagine a hypothetical enterprise team choosing between two automation proposals. One prepares a draft summary from completed work. The other changes delivery commitments when a request meets certain conditions. Both involve repetitive steps. Both could save effort.

Now imagine that each produces a wrong result. A draft can be corrected before anyone relies on it. A changed commitment may already have shaped someone else’s plan.

My direct answer is this: automate work when the inputs, decision boundaries and recovery path are clear—not merely because the steps repeat. Leave consequential judgment with people when the system cannot recognise its limits or support a workable correction.

Repeatability is more than repeated activity

Enterprise automation services are part of Vahmine’s work. In thinking about technology consulting and SaaS product decisions, I find it useful to separate a familiar task from a repeatable decision.

A team might process the same kind of request every day. That does not necessarily mean it makes the same decision every day. Behind an apparently standard action, someone may be interpreting an incomplete instruction, weighing competing priorities or recognising an unusual dependency.

The useful question is not simply, “How often does this happen?” It is, “Could another person reach the same result from the information available, without needing an unwritten explanation?”

If the answer is uncertain, automating execution may conceal the uncertainty rather than resolve it.

I would first distinguish what can be established from records, what follows an agreed rule and what still requires interpretation. That distinction gives a product team something more useful than a list of manual clicks.

Make the correction path part of the proposal

For every automation candidate, I would ask the team to describe one plausible wrong result and walk backwards from it.

Who would notice? What evidence would they need? Could they correct it themselves? Would the correction also need to reach another system or another person?

This is not an argument for automating only trivial work. It is an argument for understanding the commitment an automated action creates.

In our hypothetical example, preparing a draft summary may have a modest recovery burden, provided its source material remains available and someone reviews it before use. Changing a delivery commitment is different. Restoring the previous value does not necessarily restore the previous situation. Another team may already have rearranged its work.

An undo button reverses a system action. It does not always reverse its consequences.

That difference should influence the automation boundary. A system might prepare a proposed change while leaving its release to a person. Or a well-defined class of changes might proceed automatically, while cases with unresolved dependencies remain manual.

A human handoff needs a complete packet

“Send it for human review” can sound like a complete solution. I do not think it is one unless the reviewer can act without reconstructing the entire task.

A useful handoff carries the original request, the relevant inputs, the action proposed or already taken, and the specific reason the system stopped. It also makes clear whether work is waiting or whether a correction is required.

Those are different responsibilities. Someone reviewing a proposal has choices that someone repairing a completed action may no longer have.

Constraints matter here. Source information may arrive late. Different systems may disagree. The person authorised to decide may not be available. A workflow needs an explicit response to those conditions, rather than quietly treating missing information as permission to continue.

For a SaaS team, this means the review experience belongs inside the product decision. It is not administrative work to be designed after the automation is built.

Use a recovery checklist before approving the work

I would use this checklist before committing an automation candidate to delivery:

• Repeatability: Can the decision be explained using available inputs and agreed rules?
• Visibility: How will a wrong or incomplete result become noticeable?
• Reach: Who or what might act on the result before it is checked?
• Recovery: Can a person correct it, and what downstream repair would remain?
• Handoff: Will the reviewer receive enough context to make the next decision?
• Constraints: What happens when information, dependencies or decision-makers are unavailable?
• Net effort: Does the proposal reduce work after review and correction are included?

The outcome need not be a simple yes or no. It might be automatic execution, preparation for approval, or keeping the current human-led process because the recovery burden outweighs the benefit.

I want automation to make work easier to carry, not merely faster to initiate. Before asking how quickly a system can finish a task, I would ask how calmly a team could recover if it finished the wrong one.