Breaking Down a Workflow: What to Map Before You Automate

Automation usually fails not because the tools are weak but because the process was never described clearly. This piece uses a common scenario: each week a team compiles feedback scattered across chats, forms and email into one report.

Step 1: Record the current state, not the ideal one

Write down who does this today, when, and how — including the implicit steps people just do out of habit. An idealised diagram tends to omit exactly the parts that consume the most time.

Step 2: Split it into nameable nodes

Divide the flow into trigger, retrieval, processing, output and review. Each node should have a one-sentence description of its input and output.

Step 3: Mark the decision points

Where does someone currently "judge based on the situation"? Those are decision points. Each must either become an explicit rule (safe to automate) or stay with a person (becoming a review node). Vague decision points are the main source of later rework.

Step 4: Define failure boundaries

What happens when data is missing, the format is unexpected, or the output is plainly wrong? Every failure mode needs a defined fallback and an owner. A process without failure design only works on good days.

Step 5: Only now choose tools

After the first four steps the tooling choice is usually obvious, because the requirement is already expressed as concrete inputs, outputs and rules. Choosing the tool first tends to force the process to fit the tool.

Summary

The output of mapping is a diagram a new colleague could follow. If the diagram works, automation is worth doing; if it does not, automation only executes the confusion faster.