Pick one queue, one metric and one month. A pilot that starts with 87 scenarios never starts. Choose the queue where the pain is (renewals due this month, 1 to 30 day collections, inbound order status), name the one number your board already reads for it, pull last month's figure for that number from your own reporting, and that is the baseline. The AI runs the queue at the pilot rate with no commitment; a person is on the same queue from day one. Everything else is added after the first month holds.
Why 87 scenarios never starts
A lender brought us a list in October: 87 scenarios plus 7 proactive ones, with API checks and priority logic between collections and service. It was a good list. It was also a six-month project dressed as a pilot. The scenarios were real, but they were the shape of the whole programme, and a pilot exists to find out whether the first piece holds before the rest is built.
Scope by queue. A queue has a volume, a window and a number attached to it already; a scenario has none of those.
The three choices
- One queue. The one with the most calls per week and the clearest outcome: renewals due in the next 30 days, early-bucket collections, inbound order status, lead callbacks within the hour. Avoid the queue with the most exceptions; it comes second.
- One metric. The number your board already reads for that queue: renewal conversion in the window, promise-to-pay rate, first-contact resolution, qualified leads passed live. Automation rate and containment are our numbers; yours is the one your board reads.
- One month. Long enough for the AI share to move (it starts low and reaches up to 40% by month 3 on a typical programme), short enough that nobody is committed to find out. The pilot runs at the pilot rate with no minimum bill.
What we need from you
Before the first call: read access to the account view (read-only is fine; a file exchange works if live access takes longer than the pilot can wait), the list or the inbound number, your scripts and the do-not-say list, a signed data-processing agreement with the field scope written down. To connect your people: a SIP trunk and a webhook address for your agent desk, or seats on Vox Agent Desktop. To run it: one named owner on your side who can approve script changes and look at the first week of transcripts with us.
The baseline is agreed in writing before the first call is placed, from your reporting, not ours. It becomes the floor: nothing you measure on that queue is allowed to drop while the pilot runs.
After the month
If the number held or moved, the second queue goes on, the scenarios from the long list that belong to it go on with it, and the rate steps down with committed volume. If it did not hold, we say why, in the weekly review, and usually it is the list or the handover rather than the model. Either way you will know in 30 days, and month six will not be the first time anyone looks.
Questions people ask
How long should a Human + AI pilot run?
One month on one queue is enough to see the AI share move and to test the handover. Oriserve runs the pilot at the pilot rate with no commitment and no minimum bill.
What should the pilot metric be?
The number your board already reads for that queue: renewal conversion, promise-to-pay rate, first-contact resolution or qualified leads passed live. Not automation rate.
What does Oriserve need to start a pilot?
Read access to the account view or a file exchange, the list or inbound number, scripts and a do-not-say list, a signed DPA, and a route to your people (SIP trunk plus webhook, or Vox Agent Desktop seats).
How is the baseline set?
From your own reporting for the same queue and window, agreed in writing before the first call. It is the floor for the pilot.