Process Flow Template

Most teams already have a diagram of their process. A box, an arrow, a diamond for a decision, all neat. It tells you the order of the work and almost nothing about the cost of it. The reason a process feels slow is rarely visible in the shapes, because the slow part is usually the empty space between two boxes, the time an item spends waiting for someone to pick it up.

The numbers are stark. Lean studies of real workflows find that the time a unit is actively worked on is often only 5–15% of the total time it spends in the process, and the other 85–95% is waiting. Knowledge work is no better. Kanban University reports that teams who have never measured it typically land around 15% flow efficiency, meaning roughly 85% of a request’s life is spent queued, blocked, or sitting in someone’s inbox. If your map only shows steps and arrows, it is describing the 15% and hiding the 85% that actually makes you slow.

This template fixes that by giving wait time its own column, separate from process time, on every row. That one split is the whole point. When you fill it in honestly, the read-out usually surprises the people who run the process every day: the step everyone complains about (the export script, the long form, the slow tool) is fast, and the real loss is a two-day queue with no owner that nobody ever named. You cannot argue for the right fix until the map shows you which kind of problem you have. A slow process step wants better tooling or a smaller batch. A long wait wants an owner, an SLA, or a removed approval. Pour automation onto a step that was never the constraint and the work comes out the other end exactly as slow, because the bottleneck just moved to the next queue.

Map the process that runs, not the one written in the policy doc. The fastest way is to walk one real item from trigger to done, asking at each step: what started this, who did it, how long were they actually on it, and how long did it sit before they started. Write the messy truth. A row that says "unclear" under owner is doing more work than a row that names a role nobody really fills.

A weak row looks like this: Step 2 | Data team | takes a while | sometimes slow. It blames a team, gives no split between work and wait, and offers nothing to act on. "Takes a while" cannot be ranked against anything.

A strong row for the same step looks like this: Step 2: sits in data queue | Owner: unclear | Trigger: ticket tagged "data" | Process: 0 | Wait: 2 days | Handoff: none | Loop: none | Value: waste | Note: no SLA, ordered by hand FIFO. Now the step is observable. Process time is zero because no one is working, the cost is 2 days of pure wait, the owner is honestly marked unclear, and the value tag calls it what it is. A reader can immediately see the fix is an owner and an SLA, not a faster tool.

Work the columns in this order. First the easy four with the team in the room: step name, owner, trigger, handoff. Then the two that take real data: process time and wait time. Estimate them live to start the conversation, then go get the truth, a week of timestamps from your ticket or build system beats anyone’s memory, and the gap between the estimate and the measurement is itself a finding. Tag value last, from the customer’s point of view. Three tags are enough. Value-add is a step the customer would happily pay for. Necessary is a step you must do but the customer would not pay for on its own, like a compliance check or a required approval. Waste is everything that only moves, copies, re-keys, or waits. Most queues are waste. Most checks are necessary. Be ruthless, because every waste tag is a candidate for removal before you reach for any tool.

Finally, fill the read-out block. Add up process time for total active work. Add work plus wait for total end-to-end. Divide the two for flow efficiency. Name the single slowest step and, crucially, whether its cost is process or wait. Name the biggest rework loop. Then commit to one fix aimed at the top constraint. One per pass is deliberate.

Four traps make a map feel finished while leaving the work undone.

• Mapping the ideal, not the real. The cleanest maps describe how the process is supposed to run. The useful ones describe the workaround everyone actually uses, the approval that gets skipped when the approver is out, the spreadsheet kept on the side. If your map has no "unclear" owners and no rework loops, you probably mapped the brochure.
• Collapsing process and wait into one number. A single "duration" column erases the most common finding. Keep the two columns apart on every row, even when one of them is zero, because a zero in process time next to two days of wait is exactly the picture you are hunting for.
• Ranking from feelings. The loudest step is rarely the slowest one. Estimates open the conversation, but do not declare a bottleneck until you have pulled real timestamps. The export script in our example feels slow and gets all the complaints; the queue in front of it is four times more expensive and silent.
• Fixing everything at once. Relieve one constraint, let the process settle, then re-measure. The bottleneck moves. A queue you drained last month is no longer the problem this month, and a second map taken after the fix is the only honest way to know it worked.

On a team, the map stops being a one-time exercise and becomes a shared baseline. Put one role’s name in the owner column for the map itself, the way you put owners on the steps, so it gets re-walked on a cadence (a quarter is a reasonable default) and after any real change. The rows tagged handoff deserve special attention at scale: a handoff is where an item waits for a new person to notice it and where context gets dropped, so those rows are where most of your wait time and most of your rework will cluster. When two teams share a process, map it together in one room; the disagreement about how a step really works is the finding, and resolving it on the page is half the value.

When the map points at a fix, hand off to the right companion. For the symbols and the basics of drawing the flow, see Process Flow Basics in Better Ways of Working. For the rows you tagged as handoffs, Handoff Quality covers what must be complete and traceable before work moves on. And when the fix you land on is to automate or delegate a step to an agent, run that one step through the Agent Readiness Checklist first, naming its blast radius and rollback, before you let it approve, send, or write anything on its own. On your next real task, pick one process that everyone agrees is slow, walk a single item through it, and fill just the process-time and wait-time columns. The split alone will usually tell you where to start.