How to map a business process before you automate it

Before configuring an automation, follow one piece of work from its arrival to its completed outcome. Record who touched it, what they needed and where it stopped. That record gives the team something specific to improve. It also exposes decisions that a software configuration would otherwise make by accident.

The method below produces a current-process map and a proposed target version. Use a shared document or diagram that everyone involved can read. Keep supporting case notes alongside it. You can complete an initial map with plain labels; detailed notation can follow if the people maintaining the process need it.

1. Pick one trigger-to-outcome process

Write a starting event and a finishing condition in a single sentence. “From an accepted customer order to a delivery team confirming that it has the information needed to begin” is a usable boundary. “Improve customer operations” leaves too many possible starts and finishes. Keep related activities outside the map unless they change the outcome being examined.

Choose a recurring process whose records and participants are accessible. Name the person responsible for the overall outcome, then ask that person to confirm the boundary. Agree what counts as completion. An email being sent may be one step, while the receiving team acknowledging a usable handover may be the actual finish.

Worked hypothetical example: A company hands accepted orders from sales to delivery. Its operations lead wants to understand why delivery repeatedly asks for missing setup information. The map will start when sales records acceptance and end when delivery accepts the handover. Contract negotiation and the delivery work itself sit outside this first map.

Record the scope at the top of the document so later discussions have a reference point. When someone raises an adjacent problem, add it to a separate questions list. That preserves the observation without expanding the exercise into a review of every customer interaction.

2. List the roles involved

List roles before individual names. Include the person who initiates the work, anyone making a decision and the person who receives the finished result. Add supporting roles that supply missing information. For each role, note what information it needs and what authority it has. Being copied on an email does not establish responsibility for an action.

Ask participants who covers their work during absence. If coverage depends on an informal agreement, record that as part of the current process. Avoid filling the gap with an ideal backup arrangement at this stage. The map should show what happens today, including uncertainty.

In the hypothetical example, the roles are the account manager, a delivery coordinator and a technical lead. The customer supplies setup details through the account manager. The technical lead answers unusual requirements questions but does not review every order. That distinction matters: drawing a mandatory technical review would misrepresent the ordinary route.

3. Record the steps as they happen

Walk through recent cases with the people who handled them. Ask them to show the original request, the handover and any returned questions where access permits. Capture each step as a verb and an object: “review setup details,” “request missing address,” or “confirm handover.” Note the input and output so another person can understand what changed.

Separate observed behavior from a policy someone says should apply. If the written process calls for a complete form but a recent case began with a message, include the message route in the current map. Keep a note explaining the difference. Where records are incomplete, label the uncertainty instead of guessing the missing action.

For the example, sales records acceptance, sends an order summary and marks the order handed over. Delivery opens the summary, checks the setup details and asks sales for missing information. Sales contacts the customer, adds the answer and sends another message. Delivery then checks the revised information before accepting the handover.

Draw the steps in their actual order. If a diagram needs a formal notation, the Object Management Group's BPMN specification provides a flowchart-like notation for business processes. For a simple team exercise, a small shared legend may be sufficient. Make the map readable to the people who must correct it.

4. Mark handoffs and waits

A handoff occurs when responsibility moves to another role. Mark what is transferred and how the recipient knows that action is required. Then identify intervals when the case waits. Distinguish waiting for an internal decision from waiting for information outside the team; each may need a different response.

Where timestamps exist, record them with their source. An email timestamp can establish when a message was sent, but it does not establish when the recipient began work. Treat that gap honestly. If you need better timing evidence, agree to observe a future set of cases using a consistent method.

In the hypothetical handover, one wait begins after sales sends the summary. Another begins when sales asks the customer for missing information. The first raises a queue-ownership question: who notices a new handover? The second raises an input question: could the required information have been collected earlier? These are different design decisions even though both appear as delay.

Add a named owner to each waiting state where one exists. If nobody can name an owner, mark it as unresolved. Do not silently assign ownership to whichever person happens to be in the workshop.

5. Find the rework loops

Trace every route that returns to an earlier step. Record the condition that starts the loop and what the requester must change before resubmission. A loop for missing information differs from a loop for a changed customer requirement. Combining them under “rework” can hide the action needed to address each one.

Ask whether the loop corrects an avoidable omission or handles a legitimate exception. Some returns are necessary. The aim is to make their cause and ownership clear, then decide which ones can be prevented. Keep the original request and revision connected so the map reflects how the case is resolved.

In the example, delivery returns an order because the installation location is missing. The current sales template has no field for that location. A separate order returns because the customer changes the location after acceptance. The first suggests a template change. The second needs a defined change path, even after the template is improved.

6. Write the target version

Create a separate target map. Keep the current version intact so people can compare them. For each proposed change, state the observed problem, the new action and its owner. Include the information required to enter a step and the condition for leaving it. Describe exceptions before selecting automation features.

The hypothetical target begins with the account manager completing a readiness check after acceptance. The check includes the installation location and the information delivery has agreed it needs. A complete handover enters the delivery coordinator's queue. An incomplete one remains with the account manager, with the missing fields visible. A later customer change follows a separate revision route.

Delivery acceptance remains an explicit action. The target does not assume that receiving a complete form guarantees readiness in every case. Unusual technical requirements can go to the technical lead, with the coordinator retaining responsibility for the handover. That gives the exception a route without making technical review mandatory for every order.

Test the map before configuring it

Walk a normal case and an exception through the target with the people who will use it. At each step ask who acts, what they see and how they know they are finished. Try an absent coordinator and a customer revision after acceptance. If the group has to invent an answer during the walk-through, record a decision to resolve before configuration.

• Can every step be linked to an input and a visible result?
• Does each pending state have a responsible role?
• Can a returned request identify what must change?
• Are the current map, target map and unresolved questions kept distinct?
• Has the process owner agreed how a limited pilot will be reviewed?

Choose automation only after those questions have usable answers. A notification might help an assigned owner notice work, while a required field might address a missing input. Neither resolves a disagreement about who may accept the handover. Map one process this week before buying or configuring a tool.