Sankey Diagram for Public Service Demand: Cases, Stages and Outcomes
How to chart demand and outcomes in a public service as a Sankey: choose the case as the unit, count at decisions, show cases that leave, and avoid a league table. Worked example.
Permits, benefit claims, emergency calls and housing applications all arrive as demand and leave as an outcome. A Sankey diagram shows how many cases reached each stage and where the others left, which a single total or an average cannot.
The example is a fictional service that received 1,000 requests in a quarter. 820 were accepted for processing, 90 were rejected as out of scope and 90 were withdrawn before triage. Of the 820, 700 were decided, 60 lapsed because nobody replied and 60 were withdrawn during processing. The 700 decisions are 560 approved, 70 approved with conditions and 70 refused.
The same shape fits /sankey/permit-application-flow, /sankey/benefits-claims-processing, /sankey/emergency-call-dispatch and /sankey/housing-waiting-list. This guide covers the choices that make such a diagram fair to the people it counts.
The figures are invented and the example does not describe any real authority.
Choose the unit: one case, counted once
Decide what a single case is and count each one once. A household that submits two applications is two cases or one household; either can be right, but the diagram must say which. Mixing cases, people and documents in one chart gives bands that cannot be added up.
If a case can be reopened, decide whether the reopening is a new case. A loop back to an earlier stage is possible in the editor, but counting the same case twice makes the totals larger than the demand.
Pick stages the service itself uses
Use the stages staff and applicants would recognise: received, triage, processing, outcome. Three to five columns are usually enough. More columns spread the same story thinly.
Count at the decisions. A decision such as 'complete?' or 'eligible?' is where cases split, so each exit should be its own node with its own count.
Show the cases that leave
Withdrawn, lapsed and out-of-scope cases are part of the story. If they are left out, the service looks as if it decided everything it received. Give each way out its own node and label it plainly.
A lapsed case and a refused case are different things. Keep them apart, because they point to different questions: one about communication, the other about eligibility.
Fix the time period, and watch cases still open
Choose one period and a rule for cases that are still open at the end of it. Either add an 'Open at end of period' node or limit the diagram to cases received early enough to have finished. Without that, recent cases look as if they vanished.
Compare periods by drawing one diagram per period at the same unit, not by stacking them in one chart.
Do not turn it into a league table
A diagram of outcomes invites comparison between offices, teams or applicants. Different areas receive different kinds of cases, so a wider refused ribbon does not mean worse decisions. If you do compare, show the same stages for each and say what differs in the mix.
Avoid showing individuals. Counts of a few cases can identify a person; combine small groups or leave them out and say so.
Key points
- 1,000 requests arrive and 820 are accepted for processing.
- 180 requests never reach processing: 90 are out of scope and 90 are withdrawn.
- Of the 820 processed, 700 are decided and 120 leave as lapsed or withdrawn.
- Approvals, with or without conditions, are 630 of 700 decisions; 70 are refused.
- The figures are invented, and every node balances.
The example’s data
Invented counts of requests for a fictional public service in one quarter. Each inner node balances. Replace with your own case counts and state the period and the rule for cases still open.
| From | To | Amount (requests) |
|---|---|---|
| Requests received | Accepted for processing | 820 |
| Requests received | Rejected as out of scope | 90 |
| Requests received | Withdrawn before triage | 90 |
| Accepted for processing | Decided | 700 |
| Accepted for processing | Lapsed, no reply | 60 |
| Accepted for processing | Withdrawn during processing | 60 |
| Decided | Approved | 560 |
| Decided | Approved with conditions | 70 |
| Decided | Refused | 70 |
The same data as CSV
source,target,value
Requests received,Accepted for processing,820
Requests received,Rejected as out of scope,90
Requests received,Withdrawn before triage,90
Accepted for processing,Decided,700
Accepted for processing,Lapsed, no reply,60
Accepted for processing,Withdrawn during processing,60
Decided,Approved,560
Decided,Approved with conditions,70
Decided,Refused,70How it works
Define the case
Say what one unit is and make sure each is counted once for the period.
List the stages and decisions
Write down the stages the service uses and the decisions where cases split, with every exit named.
Count cases at each exit
For each decision, count how many cases took each exit, including withdrawn, lapsed and out of scope.
Enter the counts
Add one flow per exit, from the stage to the next stage or to the final outcome. Paste a source, target, value list as CSV or type the table.
Check the balance
Each stage must pass on exactly what it received. Then read the widest exits first and ask what the numbers cannot tell you.
Frequently asked questions
Should withdrawn cases be in the diagram?
Yes. Leaving them out hides demand the service did not complete. Give withdrawn, lapsed and out-of-scope their own nodes.
Can I compare two offices in one Sankey?
It is better to draw one diagram per office with the same stages and unit. If you compare them, explain differences in the mix of cases first.
What about cases still open?
Add an 'Open at end of period' node, or only include cases received early enough to have finished. State which.
Edit this service demand Sankey
Open the example as your own chart and enter your case counts.