A pilot should answer one decision: whether a defined deployment is ready for a wider release. Establish acceptance criteria, a comparator and stop conditions before sending it live traffic.
The following is a proposed four-stage plan, not a promise that procurement, security review and implementation will fit into 30 days:
| Stage | Work | Exit evidence |
|---|---|---|
| Define | Select one workflow; establish baseline, permissions and ownership. | Signed scope and outcome definitions. |
| Test | Run ordinary, difficult and failure scenarios against permitted integrations. | Reviewed call evidence and correct downstream records. |
| Limit | Route a controlled share of eligible traffic with active recovery coverage. | Reconciled outcomes, costs and incident records. |
| Decide | Compare with the agreed alternative and inspect failure groups. | Scale, modify, extend or stop decision. |
Separate the examples used to tune the agent from a held-back acceptance set. Give competing suppliers equivalent setup information and testing opportunities.
Use real telephone-path tests as well as simulations. Vapi’s documentation distinguishes text-level Evals from voice Simulations and notes that actual phone routing and live integrations require additional checks. (docs.vapi.ai)
Pre-agree stop conditions for unauthorised disclosures, incorrect consequential actions and failed urgent escalation. Do not let a good average booking rate override a serious control failure.
A small pilot can expose defects. It does not, by itself, prove a rare failure cannot occur.