How to Map Your Workflows Before Automating Them
TL;DR:
- Process mapping is the step most teams skip and most failed automations trace back to
- Talk to the people who do the work, not the people who manage it. Managers describe how the process should work. Practitioners describe how it actually works.
- For every step, document six things: who, what, inputs, outputs, decisions, and what happens when things go wrong
- Mapping almost always reveals unnecessary steps. Eliminate these before automating; automating waste makes waste permanent.
Automation fails when you try to digitize a process you don’t fully understand. Process mapping forces you to define each step, decision rule, data requirement, and exception path before implementing technology. The mapping exercise itself often reveals more value than the automation that follows, because it exposes unnecessary steps, undocumented decisions, and hidden delays that no technology can fix.
This isn’t optional preparation. It’s the foundation that determines whether automation succeeds or fails in production. For the full implementation sequence, see our step-by-step automation playbook. For common mapping failures, see our guide to workflow automation mistakes.
Step 1: Talk to the Right People
Start with the practitioners, not the managers. Managers describe the process as it was designed. Practitioners describe the process as it actually runs. These are often different, and the automation needs to reflect reality.
Schedule 30-minute conversations with two to three people who perform the process regularly. Ask them to walk you through a recent example from start to finish. Prompt for specifics: “What did you do next? Where did that information come from? What would you have done if [X] hadn’t been available?” The goal is to capture the actual sequence including the workarounds, shortcuts, and undocumented decisions that formal process documentation never includes.
Step 2: Document Every Step
For each step in the process, capture six elements:
Who performs it (by role, not by name, so the map survives personnel changes). What they do (specific action, not a summary like “process the invoice” but “open the invoice PDF, verify the vendor name matches the PO, check the line items against the receiving report”). What inputs they need (the data, documents, or system access required). What outputs they produce (the deliverable, record, or decision that results). What decisions they make (and the criteria for each option: “if the total exceeds $5,000, route to VP; otherwise, approve directly”). What happens when something goes wrong (the exception paths that the happy-path documentation always misses).
The sixth element is the most important and the most commonly omitted. Every process has exceptions: data arrives in the wrong format, an approver is unavailable, a system is down, an input doesn’t match any defined category. Mapping these exceptions is what separates an automation-ready process map from a decorative flowchart.
Step 3: Identify Waste
With the current state mapped, look for steps that don’t add value. Common waste patterns:
Unnecessary approvals. An approval that hasn’t resulted in a rejection in the last 100 instances is adding cycle time without reducing risk. Consider converting it to a notification (the approver sees the decision and can intervene if needed, but the process doesn’t wait).
Duplicate data entry. Information entered into one system and then manually re-entered into another. The automation should move data between systems directly, eliminating the re-entry step entirely.
Manual status checks. Someone checking a system to see if a step is complete, then notifying the next person. The automation should trigger the next step automatically when the previous step completes.
Unnecessary handoffs. Work that passes between people when one person could handle the entire sequence. Each handoff introduces delay and potential for miscommunication.
IDC data suggests that 20 to 30% of annual revenue evaporates through re-keying, duplicated effort, and lost approvals. Some of that waste disappears through automation. Some disappears by deleting the step before automating.
Step 4: Design the Target State
With waste eliminated, redesign the process for automation. The target state map should show:
Triggers: What events start the workflow? Be specific: “new row added to Google Sheet” or “email arrives from vendor domain matching invoice pattern,” not “when we get an invoice.”
Actions: What happens at each step? Each action should produce a verifiable output that the next step can act on.
Conditions: What decision rules route the workflow? Convert subjective judgments (“if this seems urgent”) into objective criteria (“if the customer is on Premium plan AND issue category is ‘system down’”).
Exception paths: For every step, what happens if it fails? Define retry, reroute, alert, or default actions for each failure mode.
Decision node classifications: Mark each decision as fully automated, automated with human review, or human-only based on consequence of error, verification cost, and accountability requirements.
Step 5: Validate with Stakeholders
Review the target state map with three groups: the practitioners who do the work (to confirm the map is accurate and complete), the manager who owns the process (to confirm the redesign aligns with business objectives), and IT or the automation builder (to confirm the target state is technically implementable with available tools).
This validation step catches misunderstandings before they become misconfigured automations. A misunderstanding during mapping is a 15-minute conversation to resolve. A misunderstanding discovered after deployment is a multi-hour debugging session.
Mapping Formats
Use whatever format your team understands. The format matters less than the completeness.
Numbered list. The simplest format. List each step with its six elements as sub-bullets. Works well for linear processes with few branches.
Flowchart. Visual representation showing the sequence, decision points, and branches. Works well for processes with conditional logic. Free tools like draw.io, Lucidchart, or even a whiteboard photograph are sufficient.
Swimlane diagram. A flowchart organized by role or department, showing who does what at each stage. Essential for cross-departmental processes where handoffs are the primary source of delays.
BPMN notation. The formal standard for business process documentation. Required for enterprise BPM implementations (Camunda, Pega). Unnecessary for most no-code automation projects.
The target state map becomes the specification document for the automation build. Hand it to whoever is configuring the workflow platform, and they should be able to implement it without additional questions. If they have questions, the map is incomplete.
For implementation next steps, see our automation playbook. For best practices across the entire lifecycle, see workflow automation best practices. For the strategic context, see our complete guide to workflow automation.
Frequently Asked Questions
How long does process mapping take?
For a simple process (five to eight steps, one department), two to four hours including interviews and documentation. For a complex process (fifteen-plus steps, multiple departments, extensive exception handling), one to two days. The time investment pays for itself by preventing implementation failures that would cost far more to fix.
Do I need special software for process mapping?
No. A whiteboard, a shared document, or a free tool like draw.io is sufficient for most purposes. Specialized process mapping tools add polish but don’t change the quality of the map. The quality comes from the conversations with practitioners, not the tool used to document them.
What if different people describe the process differently?
This is common and valuable information. Different descriptions mean the process isn’t standardized, which is a problem worth discovering before automating. Reconcile the differences, decide which version the automation should implement, and document the decision. The standardization itself is a benefit of the mapping exercise.
How detailed should the map be?
Detailed enough that someone unfamiliar with the process could follow it. The test: hand the map to a new team member and ask if they could perform the process based on the documentation alone. If they’d need to ask questions, the map needs more detail on the steps that would prompt those questions.