How to Map a Service Properly
Most organisations have a service map somewhere. Far fewer have one that anybody consults after the workshop that produced it. The difference usually has very little to do with drawing skill, and almost everything to do with what was settled before the first box went on the wall.
Why most service maps stop being useful
The common failure is not an inaccurate map. It is a map that is accurate and inert. Everyone in the room recognises the service it describes, everyone agrees it is a fair picture, and then nothing follows from it. That happens because the map was built to represent a service rather than to answer a question. Representation has no natural stopping point and no natural consequence, so the work expands until people are tired and then quietly ends.
The second failure is narrower. A map records only what the user experiences, and the thing causing the trouble is not something the user can see. Journey maps are protagonist-shaped by design, which is a real strength for a large class of problems. But when a service keeps breaking at the same point, and redesigning the visible step does not fix it, the cause is generally sitting somewhere the drawn path never went.
A map earns its keep by making a decision easier. That is the standard worth holding it to.
What to settle before you draw anything
Three things need agreement first, and skipping them is the most common reason a mapping session drifts. The first is scope: where the service starts and where it ends. Does the journey begin when someone books an appointment, or when they first suspect they might need one? Does it end at delivery, or at the point the person no longer needs the service at all? There is no universal boundary here, only a boundary that suits the question, and the group should choose it deliberately rather than inherit it from whoever drew the last version.
The second is the decision the map exists to serve. Whether to invest in a new channel, why a handover between two teams keeps failing, where effort could be removed without harming the outcome. These produce visibly different maps of the same service, at different resolutions, and naming the decision at the start prevents the familiar argument about level of detail halfway through.
The third is an evidence standard. Agree in advance how you will mark what has been observed, what has been reported by someone who works in the service, and what is currently an assumption. Assumptions are not a problem. Assumptions that look like findings are.
Separating what the user experiences from what makes it possible
The most reliable structural move in service mapping is the blueprint separation: what happens in front of the user, what happens behind the line of visibility, and the supporting processes and systems that neither party thinks about until they break. This is well-established practice and it survives contact with almost any service, digital or physical, commercial or public.
In use, it comes down to a repeated question. For every visible step, ask what has to be true for that step to happen. Which system produces the information, which person makes the judgement, which rule sets the timescale, which team receives the thing that has just been passed along. Working downwards from each visible moment tends to be more productive than trying to describe the back end as a whole, because it keeps the enabling detail attached to something the user actually notices.
The payoff is usually in the handovers. A delay a person experiences as a single unexplained wait is frequently three separate waits in three different teams, none of which believes it is the slow one. That is not visible on a map that only records the wait.
Finding the actors who never appear on the journey
Even a good blueprint has a limit. It shows the organisation delivering the service, but a service is rarely delivered by one organisation acting alone. Service-dominant logic, developed by Stephen L. Vargo and Robert F. Lusch, reframes value as something co-created through interaction among a network of actors rather than something a firm hands to a passive customer. Their later work replaced producer and consumer language with actor-to-actor networks, which is a more accurate description of how most real services behave. Within that view, institutions, meaning the humanly devised rules, norms and shared meanings that let independent actors coordinate without a central conductor, do a great deal of the work that no single actor is doing on purpose.
Turning that into a mapping step needs something practical, so we use a simple three-layer sort. This is The Curious Society's own way of working rather than an established model from the literature, and it is deliberately coarse:
direct-delivery actors: front-line staff, the user, anyone present at the point of service
adjacent and supporting actors: partners, suppliers, referral sources, informal or family carers, subcontractors
institutional and context actors: regulators, funders, professional bodies, and the norms that decide what is even possible
A concrete case makes the difference obvious. Someone applying for financial support experiences one long unexplained wait after submitting a form, so the visible service looks like a form and a confirmation screen. What actually sets the length of that wait is a verification step carried out by a third party, a funding rule deciding which cases may be fast-tracked, and a professional norm about how much evidence is enough before a decision gets signed off. None of those three appears anywhere on the journey map, and none of them can be improved by rewriting the confirmation screen.
None of this replaces journey mapping, and reaching for an ecosystem view when a journey map would answer the question is its own kind of waste. The layers are simply somewhere to look once the first layer has stopped explaining what keeps going wrong. In most services that resist repeated fixes, the interesting material is in the second and third.
How to know when the map is finished enough to act on
Completeness is the wrong target, because a service map is never complete and the pursuit of completeness is what produces the beautiful inert artefact. A more useful question is whether the map has passed three tests.
The first is correction. Show it to someone who works inside the service daily and see whether they can point at something and tell you it is wrong. If they can, the map is specific enough to be checked, which is the minimum condition for it being specific enough to act on. A map nobody can correct is usually a map nobody can use.
The second is surprise. A map that contains nothing the team did not already know has documented existing belief rather than investigated a service. Somewhere on it there should be at least one thing that made someone say they had no idea that was happening. The third test is the decision you named at the start. Read it again, and ask whether the map now makes that decision easier than it was last week. If it does, stop. Further detail past that point tends to raise confidence without raising accuracy.
What a good map is actually for
A service map is not a record of a service. It is an argument about where the effort, the risk and the value sit, made in a form that a group of people who see different fragments of the same system can look at together and disagree with productively. That is why the preparation matters more than the drawing, and why a rough map built around a real decision beats a polished one built around a wish to be thorough.
It also means a map is allowed to be provisional. Services change, partners change, rules change, and a map that was accurate in March is a hypothesis by October. Treating it as a living document rather than a deliverable keeps it honest, and keeps people willing to mark it up.
The map is finished when it changes what somebody does next. Everything after that is decoration.
Companion resource: 🗺️ The Service Mapping Canvas