# 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/.