Piloting new service processes: Limit pilot audience to one request type with traceable outcomes; Record excluded customers and plan later checks for complex cases; Track case log with handoffs, outcomes and unresolved issues
Image: Customer Experience Desk

Service Recovery

Part of Testing redesigned customer experiences

Piloting a new service process with a limited audience

Set pilot eligibility, prepare the complete service route, monitor live cases and decide when to widen a new process.

Define who may enter a limited pilot, keep a reliable route for people outside it, and decide in advance when to pause, revise or widen it. The pilot lets a team see whether a new process works in real cases while controlling volume and correcting problems. Cover the customer’s complete task, including the work after first contact.

Choose the audience deliberately

Begin with the process change and the cases it is designed to handle. A proposed route for replacement requests, for instance, could first cover one request type whose cases the team can trace through to delivery or a usable decision. State who is eligible, how they enter, and whether participation is invited or offered at a service point.

Record who is excluded and why. If complex cases, assisted routes or customers with particular access needs fall outside the first group, the pilot cannot show whether the process works for them. Plan a later check; do not describe the first group as representative of everyone.

Tell participating customers which route they are using and where to get help. Staff need to know which requests belong in the pilot and which follow the existing process. Avoid leaving a customer between the two.

Prepare the complete route

Before admitting cases, walk both an ordinary request and an exception through the proposed process. Check who receives it, what information they need, who decides, who updates the customer and how the outcome is verified. Confirm that staff guidance, customer messages and any system status describe the same next step.

Name an owner for live pilot issues. Give staff a way to flag a request that cannot proceed, an inaccurate answer or an unexpected consequence. Decide how to help affected customers if the pilot is paused. Any transfer back to the established route must preserve case history and promises already made.

Observe cases while the pilot runs

Keep a case log with entry date, request type, process version, key handoffs, customer update, outcome and unresolved question. Record failures and unknown outcomes alongside completed cases. Feedback about clarity or confidence can help locate a problem; check the service result separately.

Review the log often enough to act on live difficulties. If a replacement is approved but never dispatched, the new intake may work while fulfilment does not. If staff repeatedly ask for information already supplied, inspect the handoff. These are possible diagnoses for the hypothetical route, not reported pilot results.

Decide whether to widen it

Compare observed cases with the agreed success condition and any adverse-effect triggers. Note the eligible audience’s size and makeup, completed cases, open cases and groups not tested. A small pilot may reveal a serious failure even when it cannot estimate how common that failure would be at full scale.

Document the next step: continue within the current limit, revise and run another round, widen with monitoring, or stop and restore the established route. State what evidence would change the decision. Keep monitoring after expansion, when the case mix and service volume may differ.

More from Service Recovery