Business Process Mapping Samples: Real Maps from Small Service Businesses
Most process mapping examples online show the tidy version: three boxes, two arrows, a decision diamond.
Real maps don't look like that. They have steps that are sometimes skipped, decisions nobody had written down, and channels that nobody checks.
Four below, from different kinds of small business. Each one shows the map, what it revealed, and what changed as a result.
Details are anonymised and figures are rounded, but the shapes are real.
Sample 1 · New enquiry handling — service business
The most commonly mapped process, and the one that most often surprises the owner.
What the owner described: enquiries arrive through the website, get a same-day reply, and a quote follows if they're interested.
What the map showed:
TRIGGER: enquiry arrives
Channels: website form → one person's inbox only
phone → whoever is nearest
WhatsApp → owner's personal number
Facebook messages → checked roughly weekly
general email → checked twice daily
STEP 1 — Whoever notices first opens it — 0–8h delay
DECISION: "depends how busy we are" → same-day | next-day
[asked twice, no threshold stated — unresolved]
STEP 2 — Read and classify — judgement, undocumented
DECISION: "depends what they want"
→ standard job → quote from price list
→ unusual job → ask the owner
→ wrong fit → polite decline
[owner applies these consistently; nobody else knows the rules]
STEP 3 — Write reply from scratch — email — 10–20 min
EXCEPTION: existing customer → checks history, different tone
EXCEPTION: urgent wording → phones instead
STEP 4 — [SKIPPED IN 2 OF 3 CASES] Record in spreadsheet — 2 min
STEP 5 — [NO DEFINED STEP] Follow-up
[happens when someone remembers]
OUTPUT: a reply, sometimes a spreadsheet row
FAILURE POINTS
- Facebook: 3 enquiries from the previous month found unanswered
- No record of which enquiries received no reply
- Follow-up entirely dependent on memory
GAPS
- Monthly enquiry volume unknown — no single record exists
- Conversion rate unknown for the same reason
What it revealed: five channels rather than one, one of them effectively unmonitored, three decision rules known only to the owner, a recording step usually skipped, and no follow-up process at all.
What changed: channels consolidated to one destination. The three decision rules written down. Record created automatically on arrival, removing the spreadsheet step. A daily list of enquiries with no reply after four hours.
No new software was needed for the first three.
Sample 2 · Order fulfilment — small e-commerce
What the owner described: order comes in, gets picked and packed, ships the same day.
What the map showed:
TRIGGER: order placed on the store
STEP 1 — Order appears in the admin — automatic
DECISION: payment flagged for review?
→ yes: wait for manual check (0–24h, no owner assigned)
→ no: continue
STEP 2 — Print picking list — 1 min
[batched, printed twice a day at 10:00 and 15:00]
[orders arriving 15:01–09:59 wait until the next batch]
STEP 3 — Pick items — 3–8 min
EXCEPTION: item not on shelf despite showing in stock
→ check the back room → still missing → email the customer
→ observed in roughly 1 in 12 orders
STEP 4 — Pack — 4 min
DECISION: "depends on the item" → which box size
[experienced packer knows; new staff ask every time]
STEP 5 — Weigh, print label — 2 min
EXCEPTION: over 2kg → different courier, different system,
re-enter address manually
STEP 6 — Mark dispatched in the admin — 1 min
[observed done in batches at end of day, so the customer
notification arrives hours after the parcel has left]
OUTPUT: parcel shipped, customer notified
FAILURE POINTS
- Stock discrepancies: ~8% of orders hit a missing item
- Address re-entry for heavy items: 2 transcription errors
in the previous month
- Payment review has no owner; longest observed wait 26h
GAPS
- Could not establish how often the payment review flags
a genuine problem
What it revealed: the "same-day shipping" claim was true only for orders arriving before 15:00. The stock problem — not visible in the description — was the largest single cost. And the dispatch notification timing was making the service look slower than it was.
What changed: stock discrepancy was traced to returns not being booked back in, which was a different process entirely. Address re-entry eliminated by an integration. Payment review assigned an owner with a four-hour target.
The picking batch times stayed as they were. Twice a day was a deliberate trade-off, not an oversight — which the map made explicit rather than accidental.
Sample 3 · Monthly invoicing — professional services
A process that looked simple and consumed three days a month.
What the map showed:
TRIGGER: first working day of the month
STEP 1 — Chase timesheets — email to 4 people — 30 min
EXCEPTION: 2 of 4 reliably late
→ second chase on day 3
→ third chase on day 5 (observed every month for 6 months)
STEP 2 — Collect expenses — varies wildly — 2–4h
[receipts arrive by email, WhatsApp photo, and on paper]
[some have no job reference]
DECISION: "depends if I recognise it"
→ recognised: allocate to a job
→ not recognised: ask → often no reply → allocate to overhead
STEP 3 — Build each invoice manually — 20–40 min each — 8 clients
DECISION: billable or not?
[rules differ per client contract; held in the owner's memory]
STEP 4 — Check against the contract — 10 min each
[contracts in a folder; 2 of 8 not found during observation]
STEP 5 — Send — 5 min each
STEP 6 — Record in the accounting system — 5 min each
[duplicate entry: already entered in the invoice document]
OUTPUT: 8 invoices sent, recorded
FAILURE POINTS
- Days 1–5 consumed by chasing rather than invoicing
- Unallocated expenses: ~15% go to overhead by default,
meaning job profitability is understated
- 2 contracts not locatable
GAPS
- Could not establish the true cost of under-billing
What it revealed: the process wasn't invoicing, it was chasing. Over half the elapsed time was waiting for inputs. And the expense allocation default was quietly distorting every job's profitability figure.
What changed: timesheet deadline moved to the last working day of the month with an automated reminder sequence. One channel for expenses, with job reference required. The per-client billing rules written down — eight short documents, previously all in one person's head.
Invoice building stayed manual. At eight clients a month, automating it wouldn't have paid back.
Sample 4 · Client onboarding — agency
What the map showed:
TRIGGER: contract signed
STEP 1 — Send welcome email — 10 min
[written fresh each time; 3 versions found in sent items]
STEP 2 — Request access to client systems — 15 min
DECISION: which accesses?
"depends what we're doing for them"
[no list exists; assembled from memory each time]
EXCEPTION: observed twice — an access was forgotten
and requested in week 2, delaying the work
STEP 3 — [WAITING] Client provides access — 2–14 days
[no chase sequence; owner follows up "when it comes to mind"]
[longest observed: 14 days, during which the project
was counted as started]
STEP 4 — Kick-off call — 60 min
[no agenda; content varies by who runs it]
STEP 5 — Set up internal project folder — 20 min
[structure varies; 3 different structures found across
4 recent clients]
STEP 6 — Begin work
OUTPUT: project started
FAILURE POINTS
- Step 3 is the largest single source of delay and has no owner
- Forgotten accesses cause mid-project interruptions
- Inconsistent folder structure makes handover between
team members slow
GAPS
- Could not establish average time from signature
to work actually beginning
What it revealed: the delay wasn't in any step — it was in the waiting between them. And because the project clock started at signature, the elapsed time was coming out of the delivery window.
What changed: an access list per service type, so step 2 stopped being assembled from memory. A chase sequence on days 2, 4 and 6, with escalation on day 7 — including a decision to move the start date rather than absorb the delay. A standard folder structure. A kick-off agenda.
What the four have in common
The description is always shorter than the map. Not because anyone is hiding anything. Processes aren't visible from inside them.
The waiting is bigger than the working. In three of the four, elapsed time was dominated by waiting for an input, and in none of them did anyone own the wait.
Every map found a decision rule that existed only in someone's head. Applied consistently, never written. In each case it was the thing preventing delegation.
The biggest fix was never software. Consolidating channels, writing down three rules, assigning an owner to a wait. Automation came later, for less than people expect.
At least one step was always skipped in practice. Usually the recording step — the one that exists for the business rather than the customer. That's always worth noticing: a step that's routinely skipped is either unnecessary or badly placed.
Making your own
The format above is the same every time:
Trigger → steps with owner, tool and duration → decisions → exceptions → output → failure points → gaps.
Two rules make the difference between a real map and a tidy one:
Observe, don't interview. Watch the work happen with real cases.
Chase every "it depends." One follow-up question usually converts it into a written rule.
And include the gaps. A map with nothing in the gaps section stopped asking questions.
The map is only useful if it shows the version with the workarounds in it.
Want a map of your own process?
A free systems audit includes mapping your highest-volume process, in this format, confirmed with the person who does the work.