Mapping Service Users and Harm

Mapping users and harm means describing, for one service, who relies on it, what they use it for, and what a disruption would do to each group in practical terms. The map starts with the user journey: the moment a person or a firm turns to the service, the outcome they expect, and the steps they would have to take if that outcome were unavailable. It then distinguishes between groups whose needs differ, because a failure that is an irritation for a well resourced user can be a crisis for someone with urgent need, limited alternatives, or dependence on the service at a particular time. A good map names groups in concrete terms, states the harm for each group without jargon, and traces how harm grows if the disruption lasts, affects many people at once, or coincides with a wider event such as a storm, a market shock, or a peak period.

Users are broader than direct retail customers. They include businesses that pay or receive through the service, intermediaries who act for others, market participants who rely on its output, and people who are affected indirectly, such as employees of a merchant who cannot be paid or beneficiaries of a payment that never arrives. Within a broad user base, distinct groups matter: people who use the service daily and people who use it rarely but critically, people who can switch channels easily and people who cannot, and people whose need is time critical, such as someone reporting a burglary, settling a house purchase, or paying for essential goods. A map that records only an average customer hides exactly the variation that determines harm. Segmenting by need, urgency, and ability to find an alternative produces a map that can support a tolerance decision, because it shows whose harm sets the limit.

Trace harm step by step rather than asserting it in general terms. Take a customer trying to pay a supplier: the payment fails, the supplier withholds goods, the customers business stalls, and late fees or reputational damage follow. Take a policyholder after a flood: the claim cannot be reported, emergency repairs cannot be authorised, and temporary accommodation cannot be arranged. Each step adds a layer of harm that the first step alone does not reveal. Mapping should therefore note not only what goes wrong, but when it becomes serious, for whom, and what users would do in the meantime. Those notes later shape both the tolerance and the recovery sequence.

A credible map rests on evidence from the service itself, not on imagined users. Customer journey records, contact centre themes, complaint analysis, incident histories, and usage patterns all show who actually uses a service and where they struggle. Front line staff often know the groups that a data dashboard misses, including people who contact the firm by phone because digital channels do not work for them, or small businesses whose cash flow depends on a single daily settlement. External evidence matters too, where a service feeds a market or another firm, since those users may never appear in the firms own customer data. Where evidence is missing, the gap should be marked as a gap and filled, rather than papered over with a generic user description.

The most common weakness is writing the map from systems inward, listing applications and teams instead of people and outcomes. A second weakness is treating all users as identical, which flattens serious harm for a minority into average inconvenience for the majority. A third is stopping at the first harm, such as a failed transaction, without following the chain to missed obligations, lost access, or wider market effects. A fourth is confusing the firms own loss with user harm: lost revenue, regulatory attention, or media coverage are consequences for the firm, but they are not a substitute for describing what happens to users. The map should be readable by someone who has never worked on the service, because that readability is a test of whether the harm reasoning is real or merely asserted.

Test a map by rehearsing a disruption against it. Choose a severe but plausible failure, walk through each user group in turn, and ask what each group would experience, what they would do next, and where they would be left if the service stayed down. If a group has no described experience, the map is incomplete. If two groups have identical descriptions despite clearly different needs, the map is too coarse. If the harm described could apply to any service in the firm, the map is too generic. This guide is educational only and does not advise any particular firm on its own mapping.