Swimlane Diagram Example: Who Does What, When
A customer emailed support asking for a refund. Eight days later, they emailed again — angrier — because nobody had told them anything. The refund had actually been approved on day two. It just sat in a finance queue that support didn't know existed, waiting on an approval the manager assumed support would chase. Three people, each certain it was someone else's turn.
That gap is exactly what a swimlane diagram exists to expose. A normal flowchart tells you the order of steps. A swimlane diagram tells you the order and who owns each one — and it makes the hand-offs between people impossible to ignore. If you've ever watched work disappear into the space between two teams, this is the tool you want.
What a swimlane diagram actually adds
Picture a regular flowchart of a process: a chain of boxes and arrows running left to right. Now draw horizontal lanes across it, like lanes in a pool. Each lane belongs to one role — Customer, Support, Finance, Manager. Every step lives inside the lane of whoever performs it. When the process moves from one person to another, the arrow crosses a lane boundary.
Those crossings are the whole point. A box that sits quietly inside one lane is low-risk: one person, one responsibility. An arrow that jumps lanes is a hand-off — and hand-offs are where work stalls, gets dropped, or waits on someone who doesn't know they're holding it up. Count the lane crossings and you've counted the places your process can break.
This is the difference between a swimlane and the linear flowcharts we covered in how to make a flowchart people actually read. A flowchart answers what happens next. A swimlane also answers whose job is that, and who's waiting on them.
A worked swimlane diagram example
Let's build one for that refund process. I'll do it the way you actually should — list the steps first, assign owners second, then draw.
Step one: list every step, in order, ignoring who does it.
- Customer submits a refund request
- Support reviews the request
- Support checks if the amount is over the auto-approve limit
- If under the limit, Support issues the refund
- If over the limit, Manager reviews and approves or rejects
- Finance processes the approved payment
- Customer receives confirmation
Step two: name your lanes — the roles, not the people. Four here: Customer, Support, Manager, Finance. Use roles ("Support"), not names ("Priya"), so the diagram survives someone going on vacation.
Step three: drop each step into its owner's lane.
- Customer lane: "Submit request" (start) and "Receive confirmation" (end).
- Support lane: "Review request," the decision diamond "Over approval limit?", and "Issue refund" (the under-limit path).
- Manager lane: "Approve or reject" (only reached when the amount is over the limit).
- Finance lane: "Process payment."
Step four: draw the arrows and watch where they cross lanes. Submit → Review crosses Customer → Support. The "over the limit?" diamond branches: a no stays inside Support's lane (Support just issues it), while a yes crosses into Manager, then crosses again into Finance, then finally crosses back to Customer for confirmation.
Now look at what the diagram just told you. The under-limit refund never leaves Support's lane — fast, low-risk, one owner. The over-limit refund crosses four lane boundaries. Each crossing is a moment the ball can get dropped. And there it is, drawn plainly: the original mess happened on the Manager → Finance hand-off, where neither lane had an explicit "notify the customer we're still working on it" step. The diagram doesn't just describe the process — it points at the exact seam that failed.
Three things people get wrong
Putting people in lanes instead of roles. "Priya" and "Dave" date your diagram the moment someone changes jobs. "Support" and "Finance" don't. Lanes are roles.
Too many lanes. If you've got nine lanes and half of them touch the process once, you're mapping an org chart, not a process. Group rarely-involved roles, or split a sprawling process into two smaller swimlane diagrams. Five or six lanes is a comfortable ceiling for one readable picture.
Hiding the hand-offs. The temptation is to make the arrows neat and forget them. Resist it. The lane crossings are the most valuable thing on the page — they're your list of "places to add a notification, a confirmation, or a clear owner." If your diagram looks clean because nothing crosses lanes, double-check you haven't quietly merged two roles that are actually separate.
From a messy process to a clean lane diagram
The hardest part isn't drawing — it's untangling who does what from a description that lives in someone's head or a thread of Slack messages. That's the same problem as turning messy meeting notes into a clear diagram: the structure is in there, it's just buried in prose.
This is where describing it to an AI tool beats dragging boxes by hand. In Ridvay, you write the process in plain language — "a refund request goes from the customer to support, support approves small amounts directly but sends large ones to a manager, then finance pays it out" — and you get back a swimlane diagram with the lanes already split by role and the hand-offs already drawn. From there you edit: rename a lane, move a step that's in the wrong place, add the notification you spotted was missing. You're refining a draft instead of starting at a blank canvas, which is exactly when most process maps die.
The version in your head feels obvious. The version on the page, with lanes, shows you the gap you've been stepping over for months.