Adoption
Part of Customer success programme improvement
Testing a new service model on a limited segment
Define a limited customer success service trial, protect the help route and use customer and team evidence to decide what happens next.
Test a new customer success service model with a defined group whose work the team understands. Set the intended improvement, keep a clear help route and decide beforehand what would justify extending, revising or ending the trial. A small pilot can expose delivery problems; a favourable result alone does not prove the model caused the improvement.
Define the change and the eligible group
Specify the customer experience. If pooled coverage replaces a named manager, describe the contact route, how an active request gets an owner and how existing commitments transfer.
If the change adds guided resources, state when a person will review an exception. A label such as “more digital” does not explain how a blocked customer gets help.
Choose a group with a shared task and comparable stage of work. Record the inclusion rule before selecting accounts. Note exclusions and their reasons. Selecting only customers already easy to serve would limit what the trial can show about other customers.
For a hypothetical approvals product, a trial might cover customers using one standard route after onboarding. Accounts coordinating several regional policy owners could remain outside the first group because their work involves different decisions. These are trial boundaries, not permanent service tiers.
Pre-Trial Setup Checklist
- Define the new service model clearlyInclude contact route, ownership transfer process, and exception handling.
- Select a homogeneous group of customersEnsure shared task type and comparable work stage; avoid only easy-to-servce accounts.
- Document inclusion and exclusion rulesNote reasons for exclusions to maintain transparency and validity.
- Set trial boundariesClarify that these are temporary limits, not permanent service tiers.
Establish a starting view
Before the change, record whether customers complete the relevant task, what help they request, unresolved issues, handover work and staff time spent delivering the current service. Define the population and period for each observation. Allow enough time for an occasional task to arise.
Ask participating customers whether the current route meets their needs. Their account may reveal work that product events or contact counts miss. Record missing or unreliable baseline information rather than presenting a comparison built on it as firm evidence.
Before vs After: Key Metrics in the Trial
- Task Completion Rate
- Baseline: [recorded value] | Post-trial: [recorded value]
- Average Help Requests per Customer
- Baseline: [recorded value] | Post-trial: [recorded value]
- Unresolved Exceptions
- Baseline: [recorded count] | Post-trial: [recorded count]
- Staff Effort (hours per week)
- Baseline: [recorded hours] | Post-trial: [recorded hours]
Operate the trial with safeguards
Appoint a trial owner, an owner for each live customer request and a condition that triggers additional human help. Tell participating customers how to reach the team and what will happen to open commitments. Prepare for requests created by the change itself. A reduction in scheduled calls may increase shared-team work; include it in the review.
Check early for a material task customers cannot complete, ownership lost at handover or an unusable help route. Fix problems during the trial and date each correction. If the model creates an unacceptable gap, restore a workable route for affected customers while reviewing the wider decision.
Compare what happened with what was intended
At the agreed review point, examine task completion, customer-reported experience, unresolved exceptions and total staff effort, including preparation and follow-up. Compare against the starting view with consistent definitions where possible. Changes in customer mix, product behaviour or timing may affect the result; state those limits.
Decide whether to extend, revise or stop. Any extension should state the conditions under which the model appeared workable and the capacity needed at larger scale. If few eligible tasks occurred, keep observing or narrow the conclusion. Record what was actually tested.
