Service Mapping Workshops

A service mapping workshop brings together the people who actually run a service, in one room or one session, to trace that service aloud from its customer outcome down to its deepest dependencies. The value is not the diagram produced, though that matters. It is the conversation: the moment when an operations specialist mentions a manual step nobody else knew about, or a technology colleague reveals that two systems share a platform, or a supplier manager explains a dependency that was never written down. A workshop surfaces knowledge that lives in heads and habits, and turns it into a shared, owned record that responders can use.

Invite the people who touch the service, not only the people who manage it. That includes the operating team, the technology team that supports its systems, the team that handles customer impact, and anyone who owns a manual workaround or a supplier relationship for the service. A senior sponsor helps, because the workshop may reveal gaps that need decisions, but the sponsor should not dominate the tracing. The most useful contributions often come from staff who do the work daily and know where the documented process and the real process diverge. If those voices are absent, the workshop will produce a map of the intended service, not the actual one.

Start with the service and its customer outcome, then work backwards step by step, asking at each stage what is needed to complete that step and what happens if it is unavailable. Use plain language and visible notes, so everyone can see the trace growing and challenge it. Record owners as you go, and mark uncertainty rather than papering over it. A link that nobody can confidently describe should be flagged for follow-up, with a named person to investigate it, rather than guessed at for the sake of a tidy picture. The workshop should end with agreed actions, not merely a draft map, because an unowned draft is unlikely to become a trusted record.

Workshops fail when they become presentations rather than tracing sessions. If one person talks through a prepared diagram while others listen, hidden dependencies stay hidden, because the people who know them have no reason to speak. They also fail when the scope is too wide. Trying to map several services in one session produces a shallow picture of each and exhausts participants. They fail, too, when follow-up is neglected: the draft map is filed, the flagged uncertainties are never investigated, and the next workshop starts from scratch. A workshop is a beginning, not a deliverable, and its success should be judged by what happens afterwards.

Disagreement in a workshop is useful, provided it is handled openly. Two teams may describe the same process differently, or disagree about which system is authoritative, or about whether a workaround is authorised. Those disagreements usually point to a real ambiguity in how the service runs, and resolving them during the workshop improves both the map and the service. The facilitator should record the disagreement, seek evidence such as system records or contract terms, and agree a resolution with an owner. If a disagreement cannot be resolved in the session, it should leave as a named action with a date for resolution, not as a compromise wording that satisfies everyone and informs nobody.

Afterwards, the draft map should be written up promptly, circulated to participants for correction, and then adopted as the service map, with an owner and a currency routine. Flagged uncertainties should be investigated and the map updated when answers arrive. A short rehearsal using the new map can validate it quickly and give participants confidence that their work will be used. Under DORA in the EU and under FCA and PRA policy in the UK, workshops are a means to an end, not an end in themselves; the evidence that matters is a map that responders trust, owners that are named, and gaps that were found in discussion and then closed.