A customer uses the portal, submits a request and then calls the service team. Was that a successful digital interaction or a failed attempt at self-service? The answer depends on what the organisation measures.

Visits, registrations and submissions reveal activity. They do not establish that the customer’s job was completed. A service can attract substantial digital usage while preserving the manual work it was intended to reduce, or adding another step before that work begins.

Find the point where the job stops

A request may fail because the customer cannot find the right option. It may also fail later: the portal accepts information but cannot update the operational system, a rule is unclear, or the customer receives no useful confirmation.

Gartner’s 2024 self-service research found that 43% of self-service failures involved customers being unable to find content relevant to their issue. That is evidence about service encounters, not a benchmark for every portal or a forecast of potential savings.

For your own organisation, follow a sample of requests across channels. Look at what customers were trying to achieve, what the digital service completed and why staff became involved. A navigation problem, a missing capability and a necessary approval require different responses.

Submission is not resolution

Take an illustrative resident repair request. A form may successfully create a ticket. The resident’s job, however, also includes understanding what happens next and checking progress. If the system cannot provide a meaningful update, repeated calls may follow a technically successful submission.

There may be no reason to automate the physical repair itself. The opportunity could be better status information and clear ownership. Measuring the end-to-end job prevents the team from investing in the wrong part of the service.

Define a small set of useful measures

  • Successful job completion: completed eligible jobs divided by attempts, with a clear definition of completion.
  • Human intervention: which requests need staff, why, and how much work is involved.
  • Customer effort: steps, repeated information, elapsed time and direct feedback.
  • Repeat contact: whether the same unresolved job returns through another channel within an agreed period.
  • Cost per resolved request: relevant service costs divided by genuinely resolved requests over a consistent period.

Keep denominators visible. Excluding difficult requests from the success measure can make a system look better without improving the service. Separate jobs outside the agreed scope from unsuccessful attempts within it, and report both.

Not all intervention is failure

A sensitive exception may require human judgement. An unauthorised request should be refused. An uncertain identity should not be resolved by guessing. These are legitimate controls, even when they reduce the proportion of requests completed without assistance.

Distinguish appropriate escalation from avoidable rework. A well-prepared handoff can reduce customer effort and staff handling time while retaining necessary oversight. The goal is useful resolution within policy, not the elimination of every human interaction.

Test change against a fair baseline

Compare similar jobs, populations and operating conditions. Account for demand shifts, staffing changes and seasonal peaks. Record failures as well as successes. A short demonstration of an ideal case is not enough to establish an annual saving.

Where routine work falls, decide how the released capacity will be used. Better responsiveness and more time for complex cases are different benefits from a reduction in cash expenditure. Avoid counting both unless the evidence supports them separately.

A Proof of Value should make these measures explicit before configuration begins. The useful question is whether the service completes agreed jobs more reliably and with less effort, while keeping the right human decisions in place.