The workflow is a decision system
Why a process map is not an automation spec, and what has to be true before a step can be trusted to run without a person watching it.
Almost every automation project starts with a process map. Boxes, arrows, a swimlane or two. It is a useful artifact and it is also the most common reason automation projects fail, because a process map describes the sequence of a workflow while saying almost nothing about the decisions inside it.
The map says: request comes in, gets reviewed, gets approved, gets fulfilled. What it does not say is what “reviewed” means. Who reviews it. What they look at. What makes them reject one and approve another that looks identical on paper. What they do when the request is missing a field that the form says is required but which everyone knows is optional in practice. What happens when they are wrong.
That is the actual system. And it is the part you have to understand before you automate anything, because automation does not execute the map — it executes the decisions.
Four questions before anything gets automated
We work through the same four questions on every workflow, and the answers determine not just how we automate but whether we should.
- What is the decision, stated precisely? Not “review the request” but “determine whether this request meets criteria A, B, and C, where C is a judgment call about vendor risk.” If the decision cannot be stated, it cannot be delegated — to software or to a new hire.
- What does the decision actually consume? The inputs on the form are rarely the inputs to the decision. People bring context: history with that vendor, a conversation last quarter, knowledge that a particular field is unreliable. If that context is not in a system, an automated version of the decision does not have it.
- What are the exceptions, and who owns them? Every real workflow has a long tail. The question is not whether exceptions exist but whether they are known. An automation designed against the happy path will meet the tail on day three and someone has to own what happens then.
- What is the consequence of being wrong? This sets the rigor. A misfiled internal document and a mispriced customer contract are not the same risk and should not receive the same engineering ceremony, the same review, or the same level of autonomy.
Consequence sets the autonomy, not the technology
The most common architectural mistake we see is treating autonomy as a binary — either a person does it or the system does it. In practice the useful design space is wider than that, and where you land should be driven by the fourth question above rather than by what the technology can technically pull off.
A step can be fully automated. It can be automated with a human approving the output before it takes effect. It can be automated with a human reviewing a sample after the fact. It can be automated only for the cases that fall inside a confidence band, with everything else routed to a person. It can stay entirely human while the system removes the tedium around it — assembling the context, pre-filling the obvious, surfacing the history.
That last option is undersold. A significant share of the value in these engagements comes from making a human decision faster and better-informed rather than from removing the human. It is less impressive in a deck. It is frequently the correct answer.
A faster bad process is still a bad process. Automation is not the objective — improvement is.
The uncomfortable finding
Working through those four questions produces an uncomfortable outcome often enough that it is worth naming in advance: sometimes the honest conclusion is that the workflow should not be automated yet, or at all.
The data underneath is too unreliable to support the requested autonomy. Nobody actually owns the process, so no one can define what “correct” means. The exceptions are the majority. The step exists because of an upstream problem, and fixing that upstream problem eliminates the step entirely — which is a better outcome than automating it beautifully.
This is why the commercial arrangement matters as much as the technical one. If the firm doing the analysis only gets paid when the analysis recommends a build, the analysis is not worth reading. We charge for discovery, credit it toward implementation where that is appropriate, and accept that some engagements end with a recommendation not to proceed. That is not a failed engagement. It is the engagement working.
What understanding actually costs
None of this is an argument for a six-month discovery phase. Discovery must never become billable archaeology — understanding a workflow to the level described above is usually a matter of weeks, not quarters, and most of it comes from sitting with the people who do the work rather than from reading documentation that describes a process nobody follows.
The goal is to understand only as much as necessary to make a responsible decision and design the right solution. Then build. The rule is not “study everything.” The rule is: we do not automate what we do not understand.