Knowing whether a workflow is actually automatable

Almost every operational workflow looks automatable from a distance.

A request arrives. Someone checks a few systems. A decision is made. A transaction is completed.

It appears linear.

Then you sit with the people doing the work.

The request is incomplete. One system is wrong. A supplier does not respond. The customer has an undocumented preference. The obvious option violates a policy. The policy itself has an exception. Someone remembers what happened the last time.

The workflow was never a sequence of clicks. It was a sequence of judgments.

This distinction matters because many automation projects begin by documenting the happy path. The happy path is usually the least expensive part of the operation. The labor, delay and customer dissatisfaction live in the exceptions.

Before automating a workflow, I would ask five questions.

• Can the required inputs be reliably observed?
• Can the decision rules be stated explicitly?
• Can the system take action, or can it only recommend an action?
• Can the outcome be verified?
• Can failures be safely escalated?

If any of these are missing, the workflow may still be partially automatable, but it is not ready for full automation.

The most dangerous category is a process that works automatically 80 percent of the time but fails unpredictably in the remaining 20 percent. That can create more operational burden than a manual process because employees must supervise the automation while also being prepared to recover from its mistakes.

This is why exception classification matters.

Some exceptions are data problems. Some are policy conflicts. Some require supplier negotiation. Some require customer judgment. Others appear exceptional only because the underlying workflow was never standardized.

These categories should not be treated the same.

A good automation program does not start with the question, “How much of this can AI do?”

It starts with, “Why does a person intervene?”

Every intervention should be captured with a reason. Over time, the company learns which interventions can be eliminated through better data, which can be converted into rules, which can be handled through improved interfaces and which genuinely require human judgment.

That produces a more honest automation roadmap.

The goal is not to remove the human from the process. It is to make human intervention rare, intentional and valuable.

A workflow is truly automatable when the system can handle normal cases, recognize when it is outside its competence, and transfer the exception with enough context that a person can resolve it quickly.

Anything less is usually a demo.