How to Map a Business Process Before Automating It

To map a business process, write down the trigger, each step, who owns it, what information it needs and what ends the work. Do this for the process as it runs today, before choosing any automation. A map shows missing decisions and stops you from speeding up the wrong step.

Where do you set the boundary?

Choose one outcome. Here it is: a fictional enquiry has been reviewed and assigned. Keep payment, enrolment and marketing outside this exercise. Define the trigger as a submitted request, not "someone seems interested", because a trigger must be something you can point to.

List the people and systems involved. For each step, record who owns it, which information it needs and what changes afterwards. Distinguish a stored request from a message sent to a person. A request sitting in a spreadsheet has not yet reached anyone.

What does a normal case look like?

A student asks about a cloud track. The desk receives the request, checks the contact field, identifies the topic, assigns a counsellor and records the status. Write the handoff condition between each pair of steps, for example "contact field present and topic chosen".

Now ask what "assigned" means. It could be a name in a spreadsheet, an accepted task or a confirmed appointment. Different definitions produce different workflows, and different amounts of waiting.

How do you add exception paths?

Test a missing contact field, repeated request, unknown topic and unavailable counsellor. Each needs an explicit next step and an owner. Avoid a generic "error" box that leaves work unassigned.

Include waiting states. A request awaiting clarification is not completed and should not appear in the same count as a handled request. Give every waiting state an owner and a point at which someone looks again.

What steps should you follow?

1. Write the outcome in one sentence. 2. List the trigger and the data that arrives with it. 3. Walk the normal case with the person who does the work, not with a manager's description. 4. Record each step, owner, input, output and system. 5. Add the exceptions above. 6. Write the field dictionary: name, meaning, allowed values, who fills it. 7. Mark candidate steps for automation, and steps that need a person.

Where are the improvement opportunities?

Look for repeated copying, avoidable handoffs and unclear ownership. Fix confusing form fields before adding AI classification, because a clearer form often removes the need for it. Use automation when a step is sufficiently defined and the outcome can be checked.

An illustrative measure is time from valid request to accepted assignment. Record the start and end events and separate working time from waiting time. Do not promise an improvement until you have measured both versions. If an AI step is added later, keep a human review for anything that affects a person, and write down the limits of what the model may decide.

What mistakes are common?

• Mapping the process as people say it should work.
• Using one box for several steps.
• Skipping the data fields, then discovering later that the form lacks one.
• Counting waiting items as done.
• Choosing software before the map is stable.

How do you check the map works?

Give your one-page map, a field dictionary and five example cases to a peer. Ask them to follow it using only the written instructions. If they have to invent a rule, revise the map. Include one tricky case, such as a duplicate request with a different phone number.

A short scenario

A desk lead says, "We assign enquiries the same day." Mapping shows that enquiries arriving after evening are only looked at next morning, and two people sometimes assign the same one. The map exposes a missing owner for late requests and a missing duplicate check. Neither problem needs AI. Fixing them first makes any later automation simpler and safer.

What to build next

Write a final note that explains one step you would automate, one you would leave manual and why. Include permission, duplicate handling and recovery requirements before selecting any software. Then read workflow automation vs AI automation to decide which steps need a model, and turn the map into a build using AI automation project ideas. The AI Automation track shows where process mapping fits in a longer path.

Sources & further reading

• NIST AI Risk Management Framework

Examples and practice recommendations are educational illustrations. Tool documentation and programme inclusions should be checked for your intended use.