Measure Whether a New Contact Route Reaches the Right Person

List the inquiry types the new route serves and the role suited to each. Consider knowledge, authority and actual availability. The right owner may be a team queue with a defined coverage process rather than a named individual. Record that distinction. An inbox address alone does not establish who reviews the message or moves it forward.

Ask the service owner to confirm the intended next action for each type. A technical question, existing booking change and general sales request may legitimately follow different routes. Do not measure success against a vague expectation that everything reaches the same person quickly. The route should support the customer's task and the business's actual operating arrangement.

Record the entry point, system steps, delivery destination, triage stage and ownership handover. Identify what changed from the previous route and which dependencies remain. A new contact button may still use an old form or address behind the scenes. The map gives technical and operational reviewers a shared reference for testing the real path.

Include relevant exceptions such as incomplete requests, duplicates or inquiries outside the service scope. Define how those are handled without treating every exception as a routing failure. Keep genuine misroutes distinct from legitimate reassignment through an agreed process. This prevents a simplistic transfer count from encouraging staff to keep work they are not equipped to resolve.

Use clear events such as submission accepted, delivery verified, assigned, ownership accepted and first useful next action. Define the evidence source for each. A customer-visible success screen may establish one event while a mailbox record establishes another. Do not let the report imply more than the evidence actually shows.

[GOV.UK's measuring-success resources](https://www.gov.uk/service-manual/measuring-success) organize guidance on using data to improve services. Apply a task-focused measurement approach suited to this business. The event definitions proposed here are a practical local method; they should reflect what your systems and workflow can demonstrate rather than a claim that one universal metric captures every contact experience.

Record time intervals only when they answer a relevant question and can be measured consistently. A fast assignment to the wrong person is not the intended outcome. A brief triage step may be appropriate if it results in an informed owner. Keep correctness, ownership and timing distinguishable so one attractive number does not conceal a stalled customer question.

Avoid rewarding empty replies as proof of success. An acknowledgement can be useful when it accurately explains status, but it does not establish that the next action is owned. Ask what useful progress the customer needs and which event provides evidence of it. Keep response targets tied to actual business commitments and appropriate staffing rather than inventing a benchmark for the report.

Record a controlled reference, inquiry type, entry channel, expected destination, observed destination, relevant event times, accepted owner and status. Add a brief exception reason where useful. Keep private case details in the appropriate system rather than duplicating full conversations in a broadly shared worksheet.

Define unknown states explicitly. Missing evidence of delivery is not the same as confirmed delivery failure, and an unresolved owner is not automatically a lost inquiry. Assign investigation where the distinction matters. The log should let a reviewer trace the evidence without encouraging guesses to fill every cell or make the route appear complete.

Use appropriate test submissions covering the meaningful inquiry branches. Mark them clearly so staff can distinguish them from real customer work. Verify the customer view, actual delivery and operational handover through the responsible teams. A technical check of the form alone cannot establish that someone notices and accepts the message.

Test relevant changes in availability, such as the usual owner being absent. Check backup routing through the actual process, avoiding unauthorized changes to live workflows. Record the version and conditions tested. A successful test provides evidence for that path under those conditions; it should not be reported as proof that every future inquiry will be handled correctly.

Choose a defined sample or complete set within the route's scope. Include unresolved and misrouted cases rather than selecting only completed requests. Record the observation period, channels and classification rules. People who abandon the contact process before submission may be absent, so the routing log cannot explain every part of the customer experience.

Check expected owners against the actual content through authorized access. A customer's category selection may be imperfect, and triage can legitimately correct it. Distinguish a misleading form label from an operational assignment mistake. Record the reason and resulting action so the team can fix the actual source of the problem.

Ask whether the receiving owner accepted the case and could identify the customer question, current promise and next step. A forwarded email may only inform someone, while the original sender assumes responsibility has moved. Use the team's agreed acceptance mechanism and investigate gaps between those interpretations.

Keep relevant coverage arrangements visible during absences and business travel. A route that depends on one person's private mailbox may fail when they are unavailable. The measurement should reveal that dependency and identify the backup process. Do not assume that copying several colleagues creates shared ownership; it can make the next action less clear.

Imagine a new service-page button sends requests to a general inbox. The form acknowledgement appears immediately, but an existing-customer change request waits because everyone assumes the sales coordinator owns it. The routing log shows accepted submission and verified delivery, followed by no accepted owner for that inquiry type.

The team clarifies triage responsibility and tests the changed route with an authorized case. It then reviews comparable actual cases. This fictional example illustrates why acknowledgement time alone misses the failure. It supplies no claimed improvement percentage and does not establish that a different business needs the same inbox structure or software.

Use useful categories such as incorrect entry label, failed delivery, missing coverage, unclear assignment, unsupported authority or incomplete handover. Keep the categories connected to evidence. A message reaching an unavailable individual may need coverage changes, while a form sending to an obsolete address needs technical correction. Avoid treating every issue as a staff response-speed problem.

Give each fix an owner, review and rollback path. Research workflow support with the specific failure and intended customer task. If continuing coordination needs capacity, define the responsibility before exploring inquiry roles. A new title or tool should address the observed dependency rather than decorate the process with another status field.

If a baseline exists, keep definitions and route scope comparable. Note changes in traffic, service offer, staffing and customer mix. A higher number of correctly routed inquiries may reflect more submissions rather than improved routing, while a lower failure count may reflect reduced volume. Show the underlying counts and unresolved cases where they matter.

Do not claim a causal improvement from an uncontrolled small sample. Describe what was observed and what remains uncertain. The immediate verification can be concrete even when broader outcomes are unknown: a particular destination was corrected, a backup accepted the test handover or a previously ownerless inquiry type now has an approved route.

Review whether the log identifies useful decisions and remove unnecessary recording effort through the responsible process. Keep access and retention appropriate. A permanent detailed spreadsheet is not automatically needed once the route is stable and ordinary monitoring can cover it. Preserve definitions and material changes so later evidence remains interpretable.

Recheck when forms, teams, service scope or delivery systems change. Use real routing problems to trigger focused investigation rather than repeatedly testing unchanged paths without a reason. The practical outcome is accountable contact handling: the business can show where an inquiry entered, how it reached its destination and who accepted responsibility for the next useful step.