Business Process Mapping Examples: Six Real Workflows Mapped Step by Step

A business process map is a diagram of how a piece of work moves through an organisation: who does each step, in what order, with which systems, and where decisions send it down different paths. The examples below are written as swimlane tables, which carry the same information as a drawn diagram and are easier to review in a document or a ticket.

Every example is an illustrative process written for this guide. Company names, roles and thresholds are made up. They are realistic enough to copy as a starting point, but the value of mapping comes from mapping your own process as it actually runs today, including the parts nobody is proud of.

Pick the format before you start

Most mapping arguments are really format arguments. Four formats cover nearly every need:

Format	What it shows	Use it when
SIPOC	Suppliers, inputs, process (5-7 steps), outputs, customers	Agreeing the scope of a process before mapping detail
Basic flowchart	Steps and decisions in sequence	A single team owns the whole process
Swimlane map	Steps and decisions, grouped by who performs them	Work crosses teams; you’re hunting for handoff delays
BPMN diagram	Events, tasks, gateways, message flows in a standard notation	The map will be read by developers or fed into a process engine

BPMN (Business Process Model and Notation) is a formal standard maintained by the Object Management Group; the BPMN 2.0.2 specification defines its symbols and their meaning. You don’t need it for an internal improvement exercise, but if the map is the spec for an automation, its distinction between tasks, events and gateways forces useful precision.

For automation work, a swimlane map with one extra column for the system involved is usually enough. That’s the format used below.

How to read the examples

Each map has:

• Lane: the role or system performing the step.
• Step: what happens.
• System: where it happens.
• Output / next: what the step produces and where the work goes next, including decision branches.

After each map there’s a short note on where the process typically breaks and which steps are candidates for automation.

Example 1: Inbound lead routing

Trigger: a prospect submits a demo request form on the website.

#	Lane	Step	System	Output / next
1	Prospect	Submits demo form	Website form	Form submission → 2
2	System	Create or update lead; match to existing account	CRM	Lead record. If account exists → 3a; else → 3b
3a	System	Assign to account owner	CRM	Owner set → 5
3b	System	Enrich company data; check fit criteria	Enrichment tool	Fit → 4; not fit → 8
4	System	Assign by territory and round robin	CRM	Owner set → 5
5	System	Notify owner with lead summary	Chat + email	Notification → 6
6	Sales rep	Contact lead and qualify	Phone, email	Qualified → 7; not qualified → 8
7	Sales rep	Book meeting	Calendar, CRM	Meeting booked; lead converted
8	Marketing ops	Add to nurture programme	Marketing tool	Lead in nurture

Where it breaks: step 2. Matching a new lead to an existing account by email domain fails for personal email addresses and subsidiaries, so leads get routed to the wrong owner or duplicated. Write the matching rules out explicitly (domain, then company name, then manual review) before automating anything downstream. This guide to lead routing covers the matching and assignment rules in more depth.

Automation candidates: steps 2-5 are pure system steps and should run without a person. Step 6 stays human. Add a timer: if step 6 hasn’t happened within the response-time target, reassign or alert a manager.

Example 2: Supplier invoice approval

Trigger: a supplier invoice arrives in the accounts payable inbox.

#	Lane	Step	System	Output / next
1	Supplier	Emails invoice PDF	Email	Invoice received → 2
2	AP clerk	Extract supplier, amount, PO number, due date	Accounting tool	Draft bill → 3
3	System	Match to purchase order and goods receipt	ERP	Match → 5; no PO or mismatch → 4
4	AP clerk	Query budget owner about missing PO or difference	Email	Resolved → 5; rejected → 9
5	System	Route for approval by amount	Accounting tool	Under the approval threshold → 7; over → 6
6	Budget owner	Approve or reject	Accounting tool	Approved → 7; rejected → 9
7	System	Schedule payment for due date	Bank / payments	Payment scheduled → 8
8	System	Post to ledger, attach PDF	Accounting tool	Closed
9	AP clerk	Notify supplier of rejection with reason	Email	Closed

Where it breaks: step 4. Invoices without a PO end up in someone’s inbox with no deadline. Give the query step an owner, a due date and an escalation, and track how many invoices pass through it; a high number usually means the purchasing process upstream is being skipped.

Automation candidates: step 2 (document extraction, with a person checking low-confidence fields), step 3, step 5 and steps 7-8. The approval itself in step 6 stays human, but the request should arrive with the PO, the receipt and the budget remaining, so the approver doesn’t need to go looking.

Example 3: Employee onboarding

Trigger: a candidate signs an offer.

#	Lane	Step	System	Output / next
1	Recruiter	Mark candidate as hired	Applicant system	Hire record → 2
2	System	Create employee record with start date and manager	HR system	Employee record → 3, 4, 5 in parallel
3	IT	Order laptop; create accounts and licences	IT service desk	Equipment and accounts ready → 6
4	HR	Send contract, tax and payroll forms	HR system	Forms complete → 6
5	Manager	Prepare first-week plan; assign a buddy	Shared doc	Plan ready → 6
6	System	Check all three branches complete before start date	Workflow tool	Complete → 7; incomplete 3 working days before → alert HR
7	New employee	First day: collect equipment, sign in	—	Onboarded → 8
8	Manager	30-day check-in	Calendar	Closed

Where it breaks: the parallel branches. Each team assumes another team has started. The join step (6) is the most valuable part of the map, because it turns “someone should have ordered the laptop” into a check with a date on it.

Automation candidates: step 2, account creation in step 3, form sending in step 4, and step 6. A mirrored offboarding map, where access removal runs in parallel and is checked at the end, matters more for security than onboarding does.

Example 4: Customer support escalation

Trigger: a customer opens a ticket.

#	Lane	Step	System	Output / next
1	Customer	Opens ticket via email or form	Help desk	Ticket → 2
2	System	Categorise and set priority from content and account plan	Help desk	Priority set → 3
3	Tier 1 agent	Respond; resolve if a known issue	Help desk	Resolved → 8; not resolved → 4
4	Tier 1 agent	Escalate with reproduction steps	Help desk	Escalated → 5
5	Tier 2 specialist	Investigate	Help desk	Resolved → 8; product bug → 6
6	Tier 2 specialist	File bug with customer impact	Issue tracker	Bug linked to ticket → 7
7	System	Update ticket when linked bug is released	Integration	Customer notified → 8
8	System	Send satisfaction survey; close after set days	Help desk	Closed

Where it breaks: step 6 to 7. Once a ticket becomes a bug, nobody owns telling the customer. Linking the ticket to the bug and updating it automatically on release closes that gap.

Automation candidates: step 2 (rules, or an AI classification step with human review of low-confidence cases), step 7, step 8, and a timer on every status that pages a lead when a priority ticket waits too long.

Example 5: Customer refund request

Trigger: a customer asks for a refund.

#	Lane	Step	System	Output / next
1	Customer	Requests refund	Help desk	Request → 2
2	Support agent	Check order, payment and refund policy	Billing, policy	Eligible → 3; not eligible → 7
3	System	Check amount against agent’s refund limit	Billing	Within limit → 5; over → 4
4	Finance	Approve or reject	Billing	Approved → 5; rejected → 7
5	System	Issue refund to original payment method	Payment provider	Refund issued → 6
6	System	Update order, revenue records and ticket	Billing, help desk	Closed
7	Support agent	Explain decision to customer	Help desk	Closed

Where it breaks: step 2, when the policy lives in a wiki page agents interpret differently. Turning the policy into explicit rules (days since purchase, product type, prior refunds) is a prerequisite for automating step 3.

Example 6: Sales quote with discount approval

Trigger: a rep is ready to send a quote.

#	Lane	Step	System	Output / next
1	Sales rep	Add products and quantities to the deal	CRM	Line items → 2
2	System	Apply list prices and volume tiers from the catalogue	CRM / CPQ	Priced quote → 3
3	Sales rep	Apply discount if needed	CRM / CPQ	Discount within rep’s limit → 5; above → 4
4	Sales manager	Approve, counter or reject discount	CRM / chat	Approved → 5; rejected → 3
5	System	Generate quote document	Document tool	PDF → 6
6	System	Send for e-signature	E-signature	Signed → 7; expired → rep notified
7	System	Mark deal won; create order in billing	CRM, billing	Closed

This one is covered in full, including approval rules and the pricing-data problems that break it, in automated quoting.

How to map your own process

1. Pick one trigger and one end state. “From demo request to meeting booked” is mappable. “Sales” is not.
2. Map what happens, not what the policy says. Sit with the people doing the work, or follow three or four real cases from start to finish through the systems. The workarounds are the point.
3. Write one row per step, in a table first. Lane, step, system, output and next. Draw it afterwards if you need a diagram for presentations.
4. Add every exception branch you found. Rejections, missing data, timeouts. Most of the cost of a process is in its exception paths, and a map with only the happy path will automate the easy part and leave the expensive part manual.
5. Mark waits. Wherever work sits waiting for a person, note it. Waits between lanes are usually where the elapsed time goes, not the steps themselves.
6. Validate with the people in each lane. Each lane should recognise its own steps.

From map to automation plan

Once the map is agreed, tag each step with one of four labels:

Label	Meaning
Remove	The step exists for historical reasons and nobody uses its output
Automate	Deterministic, rule-based, data already available in a system
Assist	A person decides, but the system prepares data or drafts the output
Keep	Judgement, relationship or accountability that should stay human

Remove first, then automate. Automating a step that should be deleted just makes the waste run faster. The workflow readiness rubric is a useful check on whether an “Automate” step is actually ready, and the workflow design patterns guide covers how to structure the resulting workflow with retries, approvals and error paths.

Common process mapping mistakes

• Mapping the ideal process. The map then describes something that doesn’t exist, and the automation built from it fails on the first real exception.
• Too much detail. “Click Save” is not a process step. If a step wouldn’t have its own owner or its own failure, merge it.
• No systems column. Without it, you can’t see where data is retyped between tools, which is often the cheapest thing to fix.
• Lanes named after people. Use roles. People change; the map should still be correct when they do.
• Never updated. A process map is a document with an owner and a review date, not a one-off workshop output.