The exceptions are the workflow

A demo shows a request arriving in the expected format, from the expected person, with every field filled in. It gets classified, routed, drafted, and closed in ninety seconds. Everyone in the room can see the future.

Then you go back to the office, where roughly none of the requests look like that.

The happy path is not the workload

Ask an operations team where a request actually spends its time and the answer is almost never the step a model could have done. It is somewhere else:

• A handoff nobody owns, where a request sits because two people each believe the other has it.
• An exception with no defined path, so it goes to whoever handled the last strange one.
• A decision that cannot be made because two systems disagree about the same number and nobody has ruled on which one wins.

A tool improves one link in that chain. If the improved link was not the constraint, the chain still takes as long as it did. You have made one step faster and the request still waits three days for a person who is not certain they have the authority to approve it.

None of those are model problems. A better model does not tell you who owns the handoff.

Why the exception cases are the ones worth collecting

The normal case is what people describe when you ask how the process works. It is the version that fits in a sentence, and it is usually accurate about the shape of the thing and wrong about the cost of it.

The exceptions are where the cost lives. They are also where the institutional knowledge lives, which is why processes end up depending on one person. That person is not the bottleneck because they are slow. They are the bottleneck because they are the only one who knows what to do when the normal path does not apply.

This is why a diagnostic collects normal cases and exception cases separately, and treats a workflow with no exception evidence as incompletely understood. If you have only seen the happy path, you have understood the brochure version.

The question that decides whether a step can be automated

There is a moment in a lot of these conversations where someone says they want an agent to handle an entire process. A useful reply is to ask what happens when it is wrong.

The pause that follows is the actual finding. Four questions have to have answers before any step is automated, and none of them is about the model:

1. What evidence does it need before it acts?
2. Who approves, and for which decisions?
3. How would you find out it was wrong?
4. What does undoing it look like?

A step whose four answers are clear can often be automated safely, sometimes with nothing more sophisticated than a rule. A step whose answers are unclear should not be automated yet, no matter how capable the model is. The capability was never the limiting factor.

The boring answer is usually right

Work through a fifteen step process honestly and the results tend to look like this. Several steps should be eliminated, because they exist for a reason that stopped being true years ago and nobody revisited them. Several should be standardized, because three people do them three ways and the disagreement is the delay. Several should become deterministic rules, which are cheap, testable, and fail the same way twice. A few should stay with a person, because they are judgment calls someone has to be able to defend.

And one or two might genuinely justify a model. Almost always drafting or classification over unstructured input, under review, never sent unread.

That is not a thrilling thing to be sold. It is a very good thing to have delivered.

If you want to know which of your steps are which, that is what the first conversation is for.