Most organisations evaluating AI for a workflow start with the technology. What can it read, summarise, predict, or draft. That question has an answer almost every time, because modern AI is genuinely capable of a great deal. The trouble is that "can AI do this" and "should AI do this, here, now" are different questions, and only one of them protects you from making things worse.
Over a series of engagements, I built a structured way to answer the second question instead of the first. Not a checklist for evaluating AI tools. A method for diagnosing a workflow properly before deciding what belongs to a person, what belongs to a rule, and what belongs to a model. This is particularly relevant to leaders responsible for finance, operations, shared services, and technology-enabled transformation — areas where recurring workflows often become complex long before anyone redesigns them.
"Automation applied to an undesigned workflow produces faster problems. AI applied to unstructured inputs produces confident wrong answers."
The sequence is the argument
Every workflow that has become a burden got that way for a reason, and the reason is rarely a shortage of technology. It's usually that the process was never deliberately designed — activities accumulated to compensate for gaps elsewhere, decisions get made without anyone naming them as decisions, and effort concentrates on preparing information rather than acting on it.
Introducing automation or AI into that condition doesn't fix it. It executes the dysfunction faster and with more confidence. So the framework runs in a fixed order, and the dependency order should not be skipped — each stage exists to make the next one reliable.
Understand the workflow end to end before recommending anything. Not what it looks like on the surface — what is actually constraining it. A data problem and a process problem often present identically and require opposite fixes.
Decide what the workflow should look like. This is a structured conversation, not a client questionnaire — the practitioner brings design judgment, the process owner brings context neither party has alone.
Evaluate every activity against a structured hierarchy: process redesign, standardisation, automation, then AI. Each activity gets one of several explicit outcomes, not a default assumption that technology is the answer.
Install the ownership, measures, and review cadence that keep the design working after the engagement ends. If it needs the practitioner's continued presence to function, it wasn't actually designed.
The distinction that matters most
The single question that separates a defensible recommendation from a technology-first guess is this: when someone changes a number or an output by hand, are they compensating for bad data, or are they adding real business context the data doesn't capture?
Those look identical from the outside. They require opposite interventions. Three patterns cover most cases:
Data correction — the source data is wrong. Fix it at source. Automating the correction automates the production of wrong data faster.
Business judgment — the data is correct, but something real isn't captured yet. Preserve and structure the judgment. Automating it removes a safeguard rather than a burden.
Integration gap — two systems were never connected, so someone bridges them manually. The fix is closing the integration gap, not preserving the manual step.
Getting this distinction right, activity by activity, is most of what separates a workflow that gets meaningfully better from one that gets faster at being wrong.
A rigorous assessment will usually identify activities that should remain entirely human-led. If every activity in a workflow gets marked for automation or AI, the assessment wasn't done rigorously — it was done with a predetermined answer.
What this means for AI specifically
AI earns a place in this framework at a specific point, not as a default. It belongs where an activity involves interpreting or synthesising more information than a person can reasonably process at speed, and where a human reviews the output before it's acted on. It does not belong where the underlying inputs are still unstructured — extracting meaning from a messy email after the fact is a weaker fix than making the submission structured in the first place, because the first approach still generates the follow-up cycles the second one prevents.
Even where AI is the right call, the review discipline matters as much as the initial decision. A human reviewing every AI output, forever, doesn't scale. A human reviewing nothing, ever, drifts silently until something goes wrong in public. The right answer sits between those two, calibrated to risk, and revisited deliberately as evidence accumulates — not left running on the assumption that day-one settings are still correct eighteen months later.
The lesson isn't that every workflow needs AI. It's that every transformation effort should determine the right intervention before selecting the technology.
This is one methodology. It has been applied in full to two different workflow types — a recurring management review and a hiring operating model redesign — and tested against patterns it wasn't originally built for. The pattern appears consistently because it starts from the same place every time: understand the constraint before proposing the fix.
The article explains the principle. The framework overview shows how to apply it — covering the four-stage diagnostic sequence, six dimensions for identifying the real constraint, activity-level intervention outcomes, AI feasibility and human-review design, and governance mechanisms that keep the workflow working after handover.