The Unpaid Shift: Auditing the Customer Labour Hidden in Your Service Model

Most service operating models are drawn from the inside out. They show the queue, the case management system, the escalation route and the management checkpoints. What they often omit is the work that happens after a letter is sent, a portal message is posted or a call ends: the customer chasing proof, uploading the same document twice, interpreting a technical phrase or explaining their circumstances again to a second team. That work is real. It consumes time, creates errors and shapes whether a service is experienced as fair. For UK operations leads, it should be treated as part of the operating model rather than as an unavoidable feature of modern service delivery.

Why customer labour belongs in the operating model

Customer effort is often discussed as a satisfaction metric. It is more useful to see it as a design signal. When a customer has to gather evidence that the organisation could obtain itself, re-enter information already held, translate an internal letter into a practical next step, or coordinate between two suppliers, they are performing integration work. The service is not simply inconvenient; it is relying on unpaid Labour to complete its process.

This matters for three reasons. First, hidden customer work creates operational risk. If a customer fails to complete a step they did not understand, the case may stall, the statutory clock may continue and the organisation may record the delay as customer non-compliance. Second, it creates fairness risk. Customers with time, confidence, digital access and good English can absorb more effort than others. A model that depends on customer resilience will produce uneven outcomes, particularly for vulnerable customers and those with additional needs. Third, it creates evidence risk. Under regimes such as the Consumer Duty, firms are expected to evidence that they are delivering good outcomes. A journey that requires repeated chasing is difficult to defend as good outcome design, even if each individual team believes it is meeting its own service level.

The starting point is not to remove all friction. Some effort is legitimate: giving informed consent, choosing between meaningful options, completing security checks or disclosing information needed to assess vulnerability. The distinction is between productive effort, which belongs to the customer, and parasitic effort, which exists because internal process design is incomplete.

Build a customer effort ledger

A useful audit begins with a small number of journeys rather than a whole service catalogue. Select two or three high-volume or high-risk journeys: a change of circumstances, a claim, a complaint, an application or a repair. Then reconstruct the journey from the customer’s side, not the organisation’s.

The core tool is an effort ledger. For each stage, record the task the customer must perform, what triggers it, the channel used, the time or repeated contacts involved, the evidence they must supply, the consequence of getting it wrong and the internal owner who benefits from that task being done. Capture the language customers actually use. A portal instruction such as “provide supporting documentation” may conceal a cluster of tasks: finding a document, understanding which version is acceptable, scanning it, uploading it, checking whether it was received and phoning to confirm.

Do not rely only on customer surveys. Observe real journeys where possible, review call recordings and webchat transcripts, inspect letters and portal messages, and speak to frontline staff who repeatedly explain the same step. Ask customers to walk through the last case in their own words. The aim is not to produce a perfect process map but to expose where the model assumes customer capacity that it has not designed for.

Four forms of hidden work

Most customer labour falls into four broad categories. Evidence chasing is the work of obtaining, formatting and resubmitting proof—proof of address, income, identity, ownership or authority. Data re-entry is the work of supplying the same information to multiple teams or systems. Translation is the work of interpreting a letter, form or portal message and deciding what action is required. Handoff management is the work of pursuing a case between teams, suppliers or channels because no internal role owns the join.

These categories are useful because they point to different remedies. Evidence chasing may be removed by data-sharing or verification. Data re-entry may be automated through better identity and case management. Translation may be improved through clearer drafting and proactive contact. Handoff management usually requires an ownership fix, not a new customer-facing tool.

Five tests for the audit team

First, apply the ownership test. If the customer stopped performing a task, which internal role or control would fail? That failure point reveals the true owner of the work. Second, apply the evidence test. Is the customer being asked to supply information that the organisation could obtain through an existing relationship, a trusted supplier or a public register? Third, apply the repetition test. Is the same data requested more than once, and does the customer experience it as a new demand each time? Fourth, apply the translation test. Does the customer need specialist knowledge to understand what is being asked or what happens next? Fifth, apply the handoff test. Is the customer acting as the integration layer between teams that do not communicate?

Score each finding by frequency, duration and consequence. A task that takes five minutes but affects 40 per cent of cases may be more damaging than a rare 45-minute ordeal. Consequence should include failed submissions, repeat contacts, complaints, missed deadlines, vulnerability indicators and abandonment. This prevents the audit from becoming a list of irritations and keeps attention on operating risk.

Remove, automate or keep visible

The output of the audit should be a decision, not a catalogue. For each task, choose one of three treatments. Remove it where it exists only because of internal habit, unnecessary duplication or a control that no longer serves a purpose. Automate it where the organisation already holds the data, can verify it through a reliable route, or can complete the step without requiring the customer to act as a messenger. Keep it visible where the effort is genuinely part of consent, security, choice or vulnerability support.

Deliberate visibility is important. Some tasks should remain because they protect the customer or preserve their agency. The mistake is to leave them opaque. A retained task should be explained in plain English, supported through the channel the customer prefers and monitored for failure. It should also be recorded as a deliberate design choice, with a named owner and a rationale that can be reviewed.

Put customer labour under governance

Customer effort should appear in the same governance routines as service performance. Add effort findings to the service improvement backlog, assign owners and report the top three sources of avoidable customer work to the relevant governance forum. Track repeat contacts, failed uploads, abandoned journeys, complaint reasons and the number of times a customer is asked for the same information. Use customer effort measures alongside traditional service levels, but do not let a single score hide the specific tasks that drive the effort.

A pragmatic 90-day sequence is usually enough to create momentum: baseline two journeys, validate the effort ledger with frontline staff and a small customer sample, select three tasks for removal or automation, and publish a short decision log setting out what will change and what will deliberately remain. The aim is not to eliminate all customer effort. It is to ensure that the effort the model requires is chosen, justified and visible—rather than passed silently to the people the service exists to serve.