Imagine a person at a library desk with a government form open on their phone. The page loads. The fields work. The service dashboard may count the session as successful. Yet the person still needs someone to explain which document qualifies, whether a deadline applies, or who can correct a record that does not match their life.
Institutions usually classify that conversation as support: necessary, but separate from the “real” digital service and ideally reduced. This gets the relationship backwards. A help desk is also a sensor. It detects uncertainty, exclusion, contradictory rules and broken handoffs that a transaction log cannot see. The serious question is not simply how to answer enquiries more cheaply. It is how to turn recurring enquiries into evidence that the service itself should change.
The dashboard sees the designed journey
Digital services are good at observing events inside their boundary: a page view, a failed validation, a completed application, a payment. They are much worse at observing the work people do around that boundary. A relative reads the letter. A librarian helps create an account. An applicant submits twice because no confirmation arrived. A resident travels to an office because a telephone menu never exposes the relevant option.
That surrounding work is often invisible precisely because somebody rescued the transaction. The form eventually arrives, so completion looks healthy. The institution records one success; the household experiences an hour of uncertainty and a favour owed. When the rescue fails, the person may disappear from the data altogether.
The OECD’s Going Digital Toolkit describes digital government in terms of holistic, user-centred services rather than isolated interfaces. That distinction matters. A service is not the website. It is the full route by which a person learns what is required, supplies evidence, receives a decision, obtains help and corrects an error.
Support demand is a form of observability
Engineers add observability to complex systems because uptime alone does not explain why a system is slow, fragile or close to failure. Logs, traces and alerts expose what happens between components. Public services need an equivalent view of the human journey. Support contacts are one such trace.
The mechanism is simple. A service condition creates uncertainty or inability. The person attempts recovery. That attempt becomes a call, visit, chat, repeated submission or request to an intermediary. A worker supplies an explanation or workaround. If only the individual case is closed, the institution pays the same cost again. If the contact is classified and connected to the responsible service step, it becomes evidence for repair.
This is not a speculative management metaphor. The UK Government Service Manual says user support should act as the organisation’s “eyes and ears”, feed continuous improvement, and not be isolated from the service team. Its guidance goes further: treat enquiries as faults, while recognising that the apparent issue may originate elsewhere in the journey.
Four faults that look like one question
A person asking “what do I do now?” may be facing four very different conditions. The instruction may be incomprehensible. The channel may be inaccessible because of disability, language, equipment, time or location. The worker may understand the problem but lack authority to decide or correct it. Or the route may be sound while demand exceeds appointment and processing capacity.
These distinctions determine what a repair can achieve. Better wording cannot fix a missing decision-maker. Another phone line cannot resolve a contradictory eligibility rule. A chatbot cannot create an appointment slot. The classification must therefore remain small enough to use but precise enough to point toward a different owner.
Assisted support is not merely an emergency exit for people with low digital skills. The UK guidance on assisted digital support expects in-person, telephone or webchat routes to be designed, funded, secured and measured as part of the service. It also insists that people must be told the support exists. A hidden fallback is not a fallback.
Accessibility standards remain essential, and the European Accessibility Act addresses barriers in important products and services. But technical conformance and human assistance answer different questions. An accessible form can still ask for evidence a person cannot obtain, route a rare case into a dead end or leave nobody authorised to interpret an exception.
The strongest objection: contacts are noisy
A help desk is not a representative survey. The people who contact it are those who found the channel, trusted it and had time to persist. A surge in calls may follow a successful campaign announcing new support. A quiet channel may indicate an excellent service—or one that people have abandoned. Front-line notes may also reproduce staff assumptions or contain sensitive personal detail.
That is the strongest reason not to turn raw contact volume into an automatic product backlog. A support contact is a clue, not a verdict. It becomes useful when it is linked to a precise journey step, stripped of unnecessary personal data, separated into observation and hypothesis, and checked against another signal: repeated submissions, abandonment, waiting time, rejected appointments, staff rework or evidence from people who never reached support.
The same caution applies to performance targets. If a call centre is rewarded only for short calls, it may hide complex problems by ending conversations quickly. If a digital team is measured only by online completion, it may push work into libraries, families and local offices. Metrics shape where the burden becomes visible.
Give front-line knowledge a route to authority
The difficult part is rarely collecting more feedback. It is connecting evidence to someone who can alter wording, workflow, staffing, policy or legal interpretation. A useful friction record therefore needs both a current owner and an authority owner. The first knows where the problem appears. The second can decide whether the underlying rule may change.
This restores agency on both sides of the counter. The person seeking help is no longer treated as an exception to be processed; their difficulty can improve the route for others. The worker is no longer asked to perform the same invisible rescue indefinitely; their practical knowledge becomes part of service governance. Neither role should carry responsibility that belongs to the institution.
Start with one repairable signal
A realistic experiment does not require a new platform. Choose one recurring question from a bounded period. Record the exact journey step, what was observed, the suspected cause and who could change it. Then test one reversible intervention: clarify a single instruction, expose an existing support route, repair one handoff or instrument one missing event. Preserve the old route, define what must not worsen and stop if rights, deadlines, privacy or safety could be affected without competent review.
The test is not whether support disappears. A humane service will always need conversation, judgement and exceptions. The test is whether avoidable uncertainty stops recurring, while people who need assistance can still reach it. The remaining bottleneck is institutional: will the organisation treat front-line knowledge as maintenance data, or keep paying people to absorb the same defect?
Turn this idea into a project
The companion capsule helps you create a privacy-conscious Public Service Friction Ledger, test whether a recurring request reveals a service defect, and design one small reversible repair.
Version 1.0 · Experimental. Download the text file and upload it to your AI assistant, or copy the complete capsule below into a new conversation. For example: “At our association, members repeatedly call after submitting the online form because they receive no confirmation; help me build the first friction-ledger entry without including personal data.”
Read or copy the complete capsule
# Public Service Friction Ledger **Capsule ID:** ALK-PUBLIC-SERVICE-FRICTION-2026-09-21 **Version:** 1.0 **Date:** 2026-09-21 **Canonical article:** https://alkemata.com/2026/09/21/help-desk-service-sensor/ **Status:** Experimental; not validated across organisations or service types. ## Scope This capsule helps a public-service team, civic group, library, school, association or internal service owner turn recurring requests for help into evidence about service design. It is not a complaint-handling system and does not replace legal appeal, safeguarding, emergency response or accessibility assessment. **Intended reader:** someone who can observe a service journey or discuss it with the people who operate it. **Capability:** distinguish individual assistance from recurring system friction, then test one small repair. **First-session artifact:** a one-page Public Service Friction Ledger containing a journey step, observed obstacle, affected group, recovery route, evidence gap and proposed owner. ## Essential causal model A service can report high transaction completion while still imposing hidden work. People may call, visit, ask a relative, submit twice or abandon the task before the successful transaction appears in a dashboard. Front-line support therefore sees part of the service that analytics miss. Use this chain: **Service condition → user uncertainty or inability → recovery attempt → support contact or abandonment → local workaround → recurring institutional cost.** The important unit is not “a difficult user”. It is a repeatable interaction between a person, a rule, an interface and an organisational handoff. A support contact is evidence of a possible fault, not proof of one. Four different causes can look identical at the help desk: 1. **Comprehension:** the instruction, term or required evidence is unclear. 2. **Access:** the channel, device, language, ability, time or location excludes someone. 3. **Authority:** the person cannot obtain a decision, correction or exception from someone empowered to act. 4. **Capacity:** the designed route is sound, but demand exceeds staffing, appointments or processing capacity. Do not merge these causes. A clearer webpage cannot repair a missing legal authority; more staff cannot repair a contradictory form. Authoritative starting points: - UK Government Service Manual, assisted digital support: https://www.gov.uk/service-manual/helping-people-to-use-your-service/designing-assisted-digital - UK Government Service Manual, user support as feedback and fault evidence: https://www.gov.uk/service-manual/helping-people-to-use-your-service/set-up-and-manage-user-support - OECD Going Digital Toolkit, digital government and user-centred services: https://goingdigital.oecd.org/ - European Commission, European Accessibility Act overview: https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/european-accessibility-act-eaa_en ## Assumptions and limits You have access to observations, anonymised support themes or your own documented journey. You may not have authority to change the service. Use only the minimum data needed; never paste names, case numbers, addresses, medical details, credentials or free-text case histories into an AI assistant. Support data are biased. They overrepresent people who can find and use the support route and underrepresent silent abandonment. High contact volume may reflect promotion of a useful support channel rather than a defect. Low volume can mean success, invisibility or fear. Verify with another signal where possible. ## Activation If the reader has a concrete service and one observed friction point, start Mission 1 immediately. Otherwise offer these missions and ask no more than three questions: Which service or journey? What repeated request or failure is visible? What evidence can be used without exposing personal data? ## Mission 1 — Build the first ledger entry **Input:** one documented support contact, observation or anonymised recurring question. **Action:** describe the intended user goal; locate the exact journey step where help became necessary; classify the primary cause as comprehension, access, authority or capacity; record the recovery route and who could act. **Output:** one ledger entry using the template below. **Progression criterion:** another person can understand the obstacle without seeing personal data, and the entry distinguishes observation from inference. ## Mission 2 — Test recurrence **Input:** five to twenty anonymised contacts, observations or failed attempts from a bounded period. **Action:** code each with the same small taxonomy. Count repeats, but also note severity, affected groups and whether the user ultimately completed the task. Look for the same obstacle appearing through different channels. **Output:** a short pattern note: “X of Y observations involved [step]; the leading hypothesis is [cause]; missing evidence is [gap].” **Progression criterion:** the proposed pattern is supported by at least two independent observations or one observation plus a second signal such as abandonment, repeat submission, waiting time or staff rework. ## Mission 3 — Propose one reversible repair **Input:** one supported pattern and an owner who can consider a bounded change. **Action:** choose the smallest intervention matched to the cause: revise one instruction; expose one support route; add one authority handoff; change one appointment rule; or instrument one missing event. Define what must not worsen. **Output:** an experiment card with hypothesis, change, measure, stopping condition and next decision. **Progression criterion:** the intervention can be removed, does not remove an existing access route, and produces observable evidence within a defined period. ## Public Service Friction Ledger template **Service and user goal:** **Journey step:** **Observed evidence:** **Do not include personal data:** **Primary cause:** comprehension / access / authority / capacity **Secondary cause, if any:** **Recovery route used:** **Outcome:** completed / delayed / repeated / abandoned / unknown **Affected group or condition:** **Current owner of this step:** **Who has authority to change it:** **Hypothesis, clearly labelled:** **Evidence needed next:** **Smallest reversible change:** **Risk or metric that must not worsen:** **Review date and next action:** ## Smallest useful reversible experiment **Hypothesis:** changing one high-friction instruction at the moment it is needed will reduce repeat clarification without reducing successful completion. **Resources:** one service page or letter that can be safely varied; five to twenty anonymised observations before and after; one responsible owner; a simple tally sheet. **Procedure:** establish a short baseline. Rewrite only the confusing instruction, keeping eligibility rules and legal meaning unchanged. Make the recovery route visible. Run for one normal service cycle. Record clarification contacts, completion where observable, and any new confusion. **Success:** fewer contacts about that exact point, stable or improved completion, and no new accessibility or legal ambiguity. **Failure:** contacts move to a different point, completion falls, vulnerable users lose access, or staff create new workarounds. **Stopping conditions:** stop immediately if the change alters rights, deadlines, eligibility, privacy expectations or safety instructions without competent review. Stop if staff cannot identify which version a person saw. **Next action:** keep, revise or revert the wording; then update the ledger with the evidence and unresolved question. ## Hypothetical example A municipal appointment page says applicants must bring “original proof of residence”. Six callers ask whether a utility PDF qualifies. The observation is repeated uncertainty at the evidence step. The inference—not yet a fact—is that “original” is ambiguous for digital documents. A reversible test adds authority-approved examples beside the requirement and keeps the phone route visible. Success is fewer clarification calls with no increase in rejected appointments. This example is simulated, not field evidence. ## Verification checks Before drawing a conclusion, ask: Is the observation documented? Is the cause labelled as evidence or inference? Could missing contact volume hide abandonment? Is the comparison period normal? Did the experiment preserve accessibility, privacy, appeal and offline help? Does the proposed owner actually control the relevant rule or system? Has a competent person reviewed any legal, medical, financial or safety-critical wording? ## Counterexample and boundary This method does not apply when an individual needs an urgent decision, statutory appeal, safeguarding response or emergency assistance. Do not delay that action to collect pattern data. It also does not justify surveillance of staff or service users. Aggregate only what is necessary for repair. ## Manual or offline route Use paper index cards or a local spreadsheet with no personal identifiers. One row per observation is enough. If no analytics exist, tally repeated contact reasons and outcomes by hand. If no service owner will engage, produce a one-page evidence note that separates facts, hypotheses and requested decision. ## Portable checkpoint **Decision made:** **Evidence retained:** **Change tested or proposed:** **What happened:** **Unresolved questions:** **Risk boundary:** **Owner or decision-maker:** **Next action and date:** On request, an AI assistant may help turn this checkpoint into a project passport, a field report based only on actual observations, or a precise request for help. Remove private information before sharing. Nothing is sent automatically. To share a carefully anonymised case or explore collaboration, visit https://alkemata.com/collaborate/.
If you develop an anonymised field report or need a precise request for help, share what you choose through Alkemata’s Collaborate route. Nothing is sent automatically.
