How to Set Acceptance Criteria for a Support Pilot
Published by The CX Team. Last reviewed .
Quick answer
Set pilot acceptance criteria before live work begins. Define the contact scope, required behaviours, evidence sources and conditions that must stop or limit the pilot. Review quality, ownership and controls alongside service measures. Agree who can authorise expansion and what happens if evidence is inconclusive. A pilot is a way to test an operating arrangement, not a promise of a fixed result.
Key takeaways
- Agree acceptance criteria before seeing the results.
- Assess control failures separately from averages.
- Allow a decision to extend, narrow or stop the pilot.
State what the pilot is testing
Choose a bounded question, such as whether the partner can handle a defined contact group with correct ownership and escalation. Specify channels, hours and exclusions. A pilot with no boundary can expand faster than its controls are reviewed.
Record assumptions about volume, case complexity, access and internal support. If those assumptions change, discuss whether the pilot still answers the original question.
Define observable acceptance criteria
Tie each criterion to evidence and a decision owner. Avoid importing generic targets without checking your baseline and obligations. Critical controls, such as authorised data access, need explicit pass conditions rather than being averaged into a general score.
| Area | Example evidence | Decision needed |
|---|---|---|
| Resolution accuracy | Reviewed cases against approved policy | Can this contact type remain in scope? |
| Escalation | Accepted handovers and owner records | Are exception routes working? |
| Access control | Approved accounts and permission review | Is live access appropriate? |
| Customer communication | Clear next steps in sampled replies | What coaching or guidance is needed? |
Agree sampling and review responsibilities
Include representative cases and difficult exceptions. Decide who selects the sample, who reviews it and how disagreements are resolved. A supplier's own sample can be useful, but should not be the only evidence where independent verification is needed.
Illustrative uncertainty: the pilot receives only simple contacts although the intended scope includes complex exceptions. Good results on the easy sample do not establish readiness for the wider scope. Record the missing evidence.
Make expansion a deliberate decision
Choose among continuing, expanding, extending the test, narrowing scope or stopping. Record unresolved issues and the owner of each corrective action. Do not let the arrival of a calendar date automatically trigger expansion.
Define how cases return to the internal team if the pilot is paused. Keep the customer communication owner clear throughout. Contractual changes and commercial terms should be agreed separately to the operating review.
Common mistakes
- Defining success after the results are known.
- Letting good averages hide a critical control failure.
- Expanding because the pilot period ended.
Action checklist
- Write the pilot question and exclusions.
- Agree criteria and evidence owners.
- Record stop conditions and a return route.
- Hold an explicit expansion decision.
Frequently asked questions
How long should a support pilot run?
Long enough to gather representative evidence for the agreed scope, subject to the contract and operating constraints. Time alone does not establish readiness.
What if the pilot evidence is inconclusive?
Identify which question remains unanswered. Decide whether to extend a bounded test, reduce scope or stop, rather than treating uncertainty as a pass.
Keep learning
Discuss your support requirements
Tell us about your operation and the challenge you want to address. We will discuss scope and requirements before preparing a proposal.
Discuss your support requirements