Business Process Expert·10 min read
How to use these examples
The examples below are deliberately simple - the happy path plus the one or two decisions that shape each process. That is the right level to start at. You learn the method by mapping the normal flow first, then layering in exceptions. If you want the step-by-step method behind these, read How to Map a Process and What is Process Mapping.
For each example, notice the pattern: a clear trigger, a sequence of verb-noun steps, a decision point, and a defined outcome. Read past the chips to the "what it reveals" note - that is where the value of mapping actually lives.
Employee onboarding (HR)
Trigger: a candidate accepts an offer. Outcome: the new hire is fully set up on day one. This process crosses HR, IT, and the hiring manager, which is exactly why it breaks so often.
What it reveals
IT provisioning and buddy assignment can run in parallel, not in sequence - mapping shows the two-week "waiting for laptop" delay is self-inflicted. The map also exposes that nobody owns the "contract not signed on time" branch.
Order-to-cash (Sales & Finance)
Trigger: a customer places an order. Outcome: payment is received and reconciled. This end-to-end revenue process is a classic mapping target because every handoff is a place where cash can get stuck.
What it reveals
The credit check sits before order confirmation on paper, but the map shows the team actually confirms first and checks credit later - creating disputes. Mapping the as-is versus the intended flow makes the gap undeniable.
"When I map order-to-cash with a client, the invoice step is almost always where the money leaks. Not because invoicing is hard, but because it waits on a handoff nobody has named. Draw the handoff and the fix becomes obvious."
Expense approval (Finance)
Trigger: an employee submits an expense claim. Outcome: the claim is paid or rejected. A short process, but a great example of how a single threshold decision changes the path.
What it reveals
Claims under the threshold do not need manager sign-off, yet the current process routes every claim through a manager. The map shows a whole approval loop that adds delay without adding control - a prime candidate to simplify.
Support ticket resolution (Customer Support)
Trigger: a customer raises a ticket. Outcome: the issue is resolved and the ticket closed. Support processes live or die on their escalation and triage logic.
What it reveals
The map surfaces a missing loop: when L2 needs more information, there is no defined path back to the customer, so tickets stall silently. Naming that return path is the single biggest fix for resolution time.
Purchase requisition (Procurement)
Trigger: a team needs to buy something. Outcome: goods are received and the invoice is paid. Procurement is a multi-approval process where mapping exposes hidden waiting time.
What it reveals
The three-way match (PO, goods receipt, invoice) is where exceptions pile up. The map shows that most delays are not the approvals themselves but the wait between them - requisitions sitting in an inbox for days. Visibility is the first step to fixing it.
Patterns you will see in every map
- -Waiting beats working. The delay between steps is almost always longer than the steps themselves. Map the handoffs and the wait becomes visible.
- -Unowned branches. Every "what if it fails?" that nobody owns is a place work goes to die. Maps expose these gaps instantly.
- -Approval theatre. Approvals that never reject anything add delay without control. The map lets you question each one.
- -Sequential work that could be parallel. Steps drawn in a line often do not depend on each other. Seeing them side by side reveals the shortcut.
From map to improvement
A map is not the goal - it is the instrument. Once you can see a process end to end, you can decide what to change: remove a redundant approval, run two steps in parallel, or hand a repetitive step to a system. It is also the point at which you can sensibly decide which steps become AI-assisted or automated, and then measure the before-and-after so you know the change actually helped.
If you want to take any of these examples further, sketch it in the Crismo playground and then read Process Mapping for Automation to turn the map into an action plan.
Keep going
Frequently asked questions
What is a good first process to map as an example?▼
Pick something you know well and that has a clear start and end - employee onboarding, expense approval, or support ticket resolution are ideal. They are small enough to finish in one sitting but complex enough to reveal real insights.
How detailed should an example process map be?▼
Start with the happy path plus the one or two decisions that shape the outcome, like the examples on this page. Add exceptions and parallel work only after the normal flow is agreed. If it does not fit on one screen, you are too detailed.
What is the difference between these and BPMN examples?▼
These examples focus on the process-mapping method - identifying the flow, decisions, and handoffs across departments. BPMN examples focus on the notation itself. You can map any of these processes in BPMN once the flow is clear.
What should a process map example reveal?▼
The value is in what becomes visible: bottlenecks, waiting time between steps, unowned failure branches, redundant approvals, and steps that could run in parallel. If a map reveals none of these, look harder at the handoffs.
Can I use these examples as templates?▼
Yes. Each flow is a starting skeleton you can adapt to your organization. Copy the sequence, rename the steps to match your reality, then validate with the people who actually do the work.