The workflow has a consequence before it has an AI problem

When someone says, “We should use AI for this,” I have learned to slow the conversation down.

Not because the idea is wrong. Often it is exactly the right instinct. A team is spending too much time copying information, chasing an owner, preparing the same update, or answering a question that should already have a clear path. There is probably a better way to move the work.

But the first useful question is not which model or automation tool to choose. It is: where does the work become expensive to carry?

That moment is usually easier to see than the proposed solution.

An inquiry arrives and someone has to reconstruct what the person wanted.

A sales call ends with a meaningful detail, but the follow-up owner only sees a generic summary.

A support issue moves between teams while the customer repeats the story.

A weekly report gets assembled by hand, even though the underlying information already exists in several systems.

The task looks like administration. The consequence may be delay, rework, unclear ownership, an avoidable escalation, or a senior person becoming the human reminder system.

That consequence is the reason to map the workflow.

I also write down the cost in the language the team already uses. Is someone spending a block of time every week preparing the handoff? Does a request wait until one person is online? Does a customer receive a second question because the first answer never reached the next owner? Is a decision delayed because the source record is incomplete? The point is not to manufacture a dramatic ROI story. It is to make the current burden concrete enough that a team can decide whether the workflow deserves attention.

That baseline can be simple. Count the manual touches, the time from trigger to next action, the number of corrections, and the number of times the owner has to ask for missing context. A small honest baseline is more useful than a large estimate with no owner behind it.

My starting template is deliberately plain:

1. Trigger — what event starts the work?
2. Input — what information is available at that moment?
3. Transformation — what has to be checked, classified, summarized, or moved?
4. Decision — what next action should become clear?
5. Owner — who can accept, change, or stop that action?
6. Exception — what makes the normal path unsafe or incomplete?
7. Handoff — what must the next person know without reconstructing the history?
8. Measure — what would tell us that the process is moving better?

The eighth line is important, but it comes last for a reason. If the trigger, decision, and owner are unclear, a metric can make confusion look precise.

This map also prevents a common category error: treating every repetitive step as an AI problem.

Some steps need deterministic automation. A system should not ask a model to apply a rule that can be expressed clearly and checked reliably.

Some steps need human judgment. A model can prepare context or suggest a next action, but the decision belongs to a person with the authority and information to make it.

Some steps should be removed altogether. Automating a needless approval or a duplicate report only makes the unnecessary work faster.

The map is not a strategy deck. It can fit on one page. Its value is that a team can look at the same work and agree on what is actually happening.

Once that agreement exists, an implementation conversation becomes more specific. We can decide where an AI component helps, where a deterministic rule is safer, what the system is allowed to see, and how an owner knows the result is ready for the next step.

This is also where the business consequence becomes visible. Perhaps a lead waits for a handoff. Perhaps a customer has to repeat information. Perhaps a partner reviews the same status twice. Perhaps a founder is pulled into a process because nobody trusts the record.

None of those observations requires a grand claim about transformation. They are simply reasons to improve one recurring moment.

If you want to try this exercise, choose the workflow that people complain about most often. Write the trigger, input, decision, owner, exception, and consequence. Leave the tool blank for now.

The blank space is useful. It keeps the team focused on the work that needs to move, rather than the tool that happens to be popular this week.

What recurring workflow would you map first, and what happens when it is late or wrong?