Swimlane Diagram Explained: Lanes, Handoffs and Where Delays Hide (Full Example)
Why does a simple refund take nine days when the real work takes twenty minutes? A swimlane diagram shows you. In this video I take one slow refund process from a made-up online shop and draw it as a swimlane diagram: the 6 parts (pool, lanes, events, tasks, gateways, flows), 5 checks that show where delays hide in the handoffs between lanes, the improved process built in bpmn.io, and the 5 mistakes to avoid.
Step by step
A swimlane diagram shows who, not just what
- A swimlane diagram is not just a flowchart with coloured stripes. Each lane belongs to one role, team or system, so the diagram shows what happens and who does it. When work moves from one lane to another, that is a handoff. It is also called a cross-functional flowchart.
Explain like I'm 5: the relay race
- Think of a relay race. Each runner is fast, but races are lost at the handoff, when the baton is dropped or the next runner isn't ready. A process works the same way, from customer service to the warehouse to finance. The diagram shows where the baton is lying on the ground.
Process modelling and process analysis (BABOK)
- In the BABOK Guide, drawing the work is the process modelling technique. Notations include flowcharts, UML activity diagrams and BPMN, and all 3 can use lanes. Finding the slow spots is process analysis. This example uses BPMN shapes because BPMN is a standard with many free tools.
Before you draw: edges, lanes, evidence
- Before you draw, get 3 things. The edges: here the process starts when a customer reports a lost parcel and ends with a refund or an answer. The lanes: customer service, warehouse, sales manager and finance. The evidence: 10 real claims with the date of every step.
The slow refund
- The problem: refunds for lost parcels take 9 days on average across the 10 claims. Each team says their part takes minutes, and the real work adds up to about 20 minutes. Nobody sees the whole process, so nobody can see where the 9 days go.
Parts 1-2: the pool and the lanes
- Part 1 is the pool, the box around everything: here, Online shop. Part 2 is the lanes, each running the full width of the pool: customer service, warehouse, sales manager and finance. Name lanes after roles, not people, and put the lane where the work starts at the top.
Parts 3-5: events, tasks and gateways
- Part 3, events: a thin circle starts it (Lost parcel reported), thick circles end it (Refund paid, Claim closed), and a double circle with a clock is a timer, where it waits. Part 4, tasks: rounded boxes named verb + noun, like Approve refund. Part 5, gateways: diamonds, here Parcel delivered?
Part 6: flows, and the handoff
- Part 6 is the sequence flows, the arrows that show the order of work. The arrow from Log claim in customer service to Check courier tracking in the warehouse crosses a lane line. That is a handoff: the claim lands in another team's inbox and waits in a queue.
Check 1: count the lane crossings
- Check 1: trace every arrow and count the ones that cross a lane line. This process has 4: Log claim to the tracking check, the No path to the sales manager, Approve refund to Pay refund, and the Yes path back to customer service. Write the count in the corner of the diagram.
Check 2: find the waits
- Check 2: look for timers and anything on a schedule. The sales manager approves refunds in a Monday meeting, so a claim that arrives on Tuesday waits almost a week for a 2-minute approval. Batches like weekly meetings, nightly reports and payment runs often hide waits.
Check 3: question every approval
- Check 3: for each approval, ask what the approver checks and whether the answer has ever been no. In the last 3 months, every claim under $100 was approved. Don't remove the control yourself: ask the owner what risk it covers and agree a limit together.
Check 4: put times on the handoffs
- Check 4: use the claim dates to write the average wait next to each crossing. Logging takes up to 1 day, the warehouse inbox 2 days, the tracking check 5 minutes, the Monday meeting 4 days and payment 2 days. Almost all of the 9 days sits between the lanes.
Check 5: walk it with every lane
- Check 5: book 30 minutes with someone from each lane and follow 1 real claim on the diagram. Ask if this is what really happens. Here the warehouse often emails customer service for a missing order number: a hidden loop with 2 more handoffs. Add it to the diagram.
Worked example: the new refund process
- Customer service logs the claim and checks tracking in the courier's own portal. If delivered, they send proof. If not, a new gateway asks: refund under $100? Yes goes straight to finance; no goes to the sales manager the same day. A normal claim has 1 handoff, not 4. Target: 2 days.
Build it in bpmn.io
- In bpmn.io, start a new diagram and name the start event Lost parcel reported. Drag a pool from the palette on the left, name it Online shop and make it bigger. Move the start event into the top lane, then divide the pool into 3 lanes: customer service, sales manager and finance.
Confirm it, measure it, where it goes
- Walk the new diagram with every lane and get the owners to agree. After a month, pull 10 new claims and check the dates. Keep the diagram in bpmn.io, draw.io or Visio, on a Confluence page next to the requirements it creates, such as refunds under $100 paid without approval.
5 common mistakes
- 5 mistakes: naming lanes after people, drawing the process you wish you had, putting 30 boxes in one lane, placing a task on a lane line so nobody owns it, and leaving times off. Without times you can see the handoffs, but not the delays.
Recap
- Recap: lanes show who does each step. The 6 parts are pool, lanes, events, tasks, gateways and flows. The 5 checks: count the crossings, find the waits, question every approval, time the handoffs and walk it with every lane. Then fix the biggest waits and measure again.
Common mistakes
- Naming lanes after people. People go on holiday or change jobs, and the diagram goes out of date. Name each lane after the role, like Finance or Sales manager.
- Drawing the process you wish you had. Draw the current process first, including workarounds like the warehouse emailing for a missing order number. Walk it with each lane to confirm it before you design the new version.
- A task sitting on a lane line. If you can't say whose lane a task belongs to, nobody owns it. Record that as a finding and agree an owner, instead of hiding it in the drawing.
- No times on the diagram. Without times you can see the handoffs but not the delays. Use real ticket dates to write the average wait next to each lane crossing.
When a business analyst uses this
In a current-state workshop for a slow approval process, a business analyst draws the swimlane diagram live with one person from each team, counts the lane crossings and adds average waits from real ticket dates. The future-state version then goes on the Confluence page next to the requirements it creates, ready for sign-off.
Questions people ask
What is a swimlane diagram?
It is a process map divided into lanes, one for each role, team or system. It shows what happens, who does each step, and where work is handed from one team to another.
What is an example of a swimlane diagram?
A refund for a lost parcel, with lanes for customer service, warehouse, sales manager and finance. It shows 4 handoffs and a weekly approval meeting that turn about 20 minutes of real work into 9 days.
Is a swimlane diagram the same as a cross-functional flowchart?
Yes, they are the same idea: a flowchart split into lanes by role or team. Swimlanes can also be drawn with BPMN or UML activity diagrams.
