How do you map a workflow before automating it?

Short answer: map a workflow by tracing one real request from the moment it arrives to the moment it is finished, writing down the trigger, every step someone or something takes, the information each step needs, and where the work hands off from one person or system to another. Do this with actual examples, including the messy ones, before deciding what to automate. The map tells you which steps are stable enough for a rule, which need interpretation, and where a person has to stay in the loop.

What actually counts as "the workflow"?

A workflow is not the diagram someone drew during a planning meeting. It is what actually happens to a real request between arrival and completion, including the parts nobody wrote down: the message that sits in an inbox for two days, the spreadsheet someone keeps privately to track exceptions, the phone call that resolves the case a form could not. If the map only reflects the intended process, the automation you build from it will handle the easy cases and quietly fail on everything else.

The most useful map starts from a trigger you can name precisely, such as an email arriving or a form being submitted, and ends at an outcome you can check, such as a record being updated or a reply being sent. Everything between those two points belongs in the map, even the steps that feel obvious to the people doing them today.

How do you map it in practice?

1. Pick one workflow and one real, recent example of it, not a hypothetical "typical" case.
2. Write down the trigger: what starts this workflow, and how do you know it started.
3. List every step in order, including who or what performs it and what information they need to do it.
4. Mark each handoff, meaning any point where the work moves from one person, team or system to another.
5. Note where the example deviated from the ideal path, such as missing information, a delay, or an escalation.
6. Write down what "done" looks like and how anyone would confirm it happened.
7. Repeat the exercise with a second, different example before treating the map as complete.

Two examples usually reveal more than one, because the second one exposes whichever branch the first one happened not to take.

Where do delays and rework usually hide?

Delay tends to collect at handoffs rather than inside any single step. A request waits in a queue because nobody owns the next action, or it gets reassigned because the first person did not have the information they needed. Rework tends to follow from the same cause: someone re-enters data that already exists somewhere else, because the tools involved were never connected and nobody wants to ask a colleague to look it up again.

Mapping the workflow surfaces both problems before you write any automation, because you can see exactly where the request stalled and what information was missing at that point. Automating a workflow without first finding these spots usually just makes the existing delay happen faster and more invisibly.

What belongs to a rule and what belongs to a review?

Once the map exists, look at each step and ask whether the decision inside it is explicit and stable, or whether it depends on judgment that varies by case. A step that always does the same thing given the same input is a candidate for a rule. A step where a person currently uses discretion, weighs context, or makes an exception is a candidate for human review, at least until you have enough examples to describe that judgment explicitly.

When this is the wrong choice

Mapping a workflow is not free, and for a very small, rarely repeated task it can cost more time than it saves. If a task happens once a month and takes five minutes, a full map is unlikely to be worth the effort; a short note of the steps is enough. Mapping is also the wrong first move if the underlying process is still changing, since you would be documenting something that will look different in a month. In that case, it is often better to let the process settle for a few cycles first, then map the version that has stabilised.

How we approach it at Ribhu Labs

We follow a real request through its full path before proposing any automation, including the exceptions and the manual workarounds that formal descriptions tend to leave out. That map becomes the basis for deciding what to automate as a rule, what needs an AI step, and where a person should keep the final say. Read more on the AI & automation page, see the same idea of a workflow with a clear next step in the decision-path study in the Lab, an illustrative browser demonstration rather than a live system, and try mapping a small example yourself in the Build with AI lesson.