Map a manual workflow by following one real piece of work from its starting event to its finished result. Record the steps, decisions, handoffs, and exceptions that actually occur. Do not begin with a diagram of how you wish the process worked.
Choose a clear boundary
Define where the process starts and stops. "Handle customer work" is too broad to map usefully. "Receive an approved appointment request and add it to the internal schedule" is a more manageable boundary. It also makes clear what remains outside the first automation project.
Write down what a completed result must contain and who is responsible for it. Otherwise, a workflow may look finished while a required review or communication step is missing.
Walk through the current process
Ask the person doing the work to describe a typical case, then compare that description with an actual authorized example. Use non-sensitive or appropriately redacted information. Do not transfer customer data to a diagramming service without checking permissions.
- Note the event that starts the task.
- List the information received and where it comes from.
- Record each action in order, including approvals.
- Mark decisions and the information needed to make them.
- Identify the result and how someone checks it.
Keep waiting and rework visible. A handoff that takes time or a repeated request for missing information may be the most important part of the map.
Draw the exception paths
What happens when information is missing, the same request arrives twice, or an approver is unavailable? These are not decorative branches. They show where a straightforward automatic sequence might need to stop or ask for help.
For an invented appointment example, the normal path could create an internal draft. A request without a confirmed date would follow a clarification path instead. The example describes a process boundary, not a working integration or a recommendation to contact customers automatically.
Validate the map before automating
Review it with the people who own the inputs, decisions, and outputs. Ask which steps are unnecessary, unclear, or handled differently in practice. Resolve those differences before treating the diagram as an implementation specification.
Sometimes the best first improvement is a clearer intake form or approval rule. Mapping can expose that need even when automation is not the right answer yet. Keep the approved version where a future maintainer can find it.
Browse the Automation collection for resources that connect process definition with implementation and review.
For a structured next step, explore Preparing SOPs for Automation - Automation. Browse Automation resources in AI & Technology.
For the broader context, read The 5 AI skills every professional should learn in 2025 and Which small-business task should you automate first?.
Your map is a working description
Capture reality, define a bounded result, and include exceptions. A useful process map gives the team a shared account of the work before a tool turns that account into actions.
