Trace an outcome across channels

An organization reports 900 digital submissions in a month, while its call team says customers still phone to find out what happened to their requests. Both observations can be true. One describes a form event; the other describes a person's journey to a usable result. Operating model design starts by choosing the boundary of the service. If we improve submission alone, work may simply wait in another queue while the dashboard displays progress that the user cannot feel.

Define the unit before calculating a rate. An **attempt** is one person's effort to obtain the service, even if it crosses channels. A **transaction** is a processing record that a system may open for each submission or call. A **completed outcome** means the person receives an actionable decision, with enough explanation to take the next step, within the service's stated scope. One attempt may create two transactions when an initial submission fails. A transaction may be marked closed internally even though the person has not been informed. Dividing closed transactions by page visits cannot establish a whole-journey completion rate.

Write the journey boundary in one sentence: “from the first attempt to obtain a permit to delivery of a usable decision, or a clear refusal and next step.” Include portal, phone and email when they help the person reach that outcome. Mark entry, exit and exceptions. What happens to someone who withdraws voluntarily, reapplies under a new reference number, or calls because the portal gives no status? Do not silently discard hard-to-link cases. Hold them as unresolved until the team can examine them. The GOV.UK Service Manual distinguishes transaction measurement from an end-to-end journey that may span transactions, and recommends combining performance indicators with user research and sources beyond digital analytics. We adapt that measurement distinction here; the UK guidance is not a legal requirement for this fictional organization.

Joining records is the difficult step. Each submission may have a different transaction number, so the analysis needs a stable attempt identifier or an authorized matching rule that respects privacy. A useful event table has attempt ID, start time, channel, transaction ID, event type, decision time, notification time, and whether the person had to recontact or correct the submission. Keep “submitted” distinct from “accepted for review,” and “decision made” distinct from “decision communicated.” If notification time is missing, do not substitute decision time. Manually inspect a sample of cross-channel cases before applying a matching rule across the full population. A bad join can hide rework or duplicate people in the denominator.

Whole-journey completion within the window is (720 + 110 + 70 + 40) / 1,000 = 940 / 1,000 = 94%. First-pass digital completion among **all service attempters** is 720 / 1,000 = 72%. A different question, first-pass digital completion among people who **started digitally**, needs a different denominator. We know that 720 + 110 + 40 started digitally, but the facts do not tell us how many of the 60 unresolved attempts did so. Therefore the case does not support a precise “of digital starters” rate. Withholding that percentage is a sound measurement decision, not an arithmetic failure.

What should a manager infer? The 22-point difference between 94% and 72% does not on its own show that staff failed or that telephony succeeded. It shows that assistance completes a meaningful part of the journey and that the first submission is an incomplete picture of the service. Inspect why 110 people moved to the phone, time from first attempt to decision, decision accuracy, and the team's rework burden. A clearer portal explanation of missing documents might improve the service more cheaply than buying a new platform. Human contact may be appropriate for exceptions; removing it merely to improve a digital uptake chart could harm users. Ask applicants whether the decision was understandable and usable, and ask service staff whether the matching rule catches repeated requests. The figures point to questions; case review and user research help explain them.

For a valid month-to-month comparison, retain the definition of unique attempt, the allowed delay for late decisions, justified exclusions, and the meaning of “completed and communicated.” The 60 pending cases should not automatically become final failures if the agreed service time has not elapsed. Display them separately, then update the cohort when it matures, or measure cohorts by attempt start date. If eligibility rules or the mix of complex requests changes, show those changes before attributing a movement in the rate to the digital redesign. Add time-to-decision and recontact measures, but keep them visible rather than hiding a tradeoff between speed and decision quality inside one composite score.

Test the matching rule before using this rate to justify investment. For example, sample 30 journeys from portal and call records and reconstruct each event sequence with a staff member who understands the process. If a shared phone number joins two different people's calls, the rule invents a cross-channel journey. If it splits a resubmission from the original attempt, it inflates the denominator and depresses completion. Record false and ambiguous matches. Do not publish a rate to decimal places that imply more certainty than the linkage quality permits. Improve the rule and recalculate before choosing between a portal fix and more support capacity.