The pilot was agreed in a meeting weeks ago. Everyone liked the demo, the use case is narrow, and the sponsor has a budget line. Yet no caller has reached the agent, and nobody can say exactly why. Security has a questionnaire open. Legal has not seen a data processing agreement. Telephony is waiting for a number. The knowledge owner was never asked.
This is a coordination problem, not a technology problem, and it has a practical fix: one mutual action plan that both sides own. It lists every approval that must close before traffic, names an owner on each side, shows which items block others, and keeps every open question in one register with a date.
This guide is for the pilot sponsor in a mid-size or enterprise contact centre, usually the head of CX or the contact-centre director, who has to get from signature to a first controlled call. It covers the path to the first call only. Designing the pilot itself, its scenarios, metrics and scale decision, belongs to the voice AI pilot guide. Choosing the vendor belongs to the RFP checklist. The controls themselves are covered in voice AI security.
This article is general information, not legal or security advice. Your own legal, privacy and security reviewers decide what your organisation requires.
Where pilots actually stall
A pilot rarely stalls on one big "no". It stalls on several small items, each owned by a different person, none of whom sees the whole list.
Four patterns are common enough to plan for:
- The reviewer is engaged late. Security or privacy sees the vendor for the first time after the commercial agreement, so their full review starts when the sponsor thinks the work is finished. A reviewer who can veto the pilot should see the plan in week one.
- Nobody owns the vendor side of the list. The vendor answers emails but does not track your internal approvals. Your team assumes the vendor is driving. Both sides wait.
- Items are done in sequence that could run in parallel. Telephony testing waits for the contract, although it can start on test numbers with no customer data.
- "Approved" means different things. One reviewer approves with conditions, another approves the document but not the data flow, and the conditions never reach the people who must meet them.
The fix for all four is the same: write the dependencies down, make both sides own their half, and review one register on a fixed rhythm.
A useful test before you start: can you name, today, the person who will say "yes, live calls may start"? If you cannot, that is your first open item.
Six workstreams and their owners
Every pilot that touches real callers needs answers in six areas. The names and order will vary by organisation; the categories rarely do.
| Workstream | Closes when | Typical owner, your side | Typical owner, vendor side | Needs real customer data? |
|---|---|---|---|---|
| 1. Security review | Your questionnaire is answered, the vendor's assurance documents are read, open findings have owners and dates | Security / information-security lead | Vendor security contact | No |
| 2. Data flow and processing terms | A data-flow diagram is agreed; a data processing agreement or equivalent is signed; retention is set | Privacy / legal | Vendor legal | No (it decides whether you may use it) |
| 3. Statement of work and acceptance criteria | Scope, scenarios, success criteria, decision date and exit terms are signed | Pilot sponsor + procurement | Vendor delivery lead | No |
| 4. Telephony and test numbers | A test call passes through the agent and returns to your agents' queue as designed | IT / telephony | Vendor solutions engineer | No |
| 5. Knowledge sources | The content the agent may use is listed, owned, current and approved | Knowledge or operations owner | Vendor conversation designer | Sometimes (policy text, not customer records) |
| 6. Recording and AI-disclosure notice | Approved caller wording for AI disclosure and recording notice is in the flow | Legal / compliance + CX | Vendor conversation designer | No |
A few notes on each, because the details are where pilots lose weeks.
Security review. Ask for the vendor's assurance documents at the start, not after signature, and read their scope: which system, which period, issued by whom. A point-in-time report covers a different question from a report over an observation period. Your reviewer will want to know which entity holds each certificate and what it covers. Record every finding with a disposition: closed, accepted with a condition, or blocking.
Data flow and processing terms. Draw what the pilot actually touches: audio, transcripts, recordings, CRM or ticket fields, logs, and any sub-processors. Under the EU GDPR and the UK GDPR, processing by a processor must be governed by a contract or other legal act that sets out the subject-matter and duration of the processing, its nature and purpose, the type of personal data and categories of data subjects, and the controller's obligations and rights (UK GDPR Article 28(3)). In the US the obligations depend on sector and state; your counsel decides. Agree retention for pilot data before the first call, including what happens to recordings if the pilot ends.
Statement of work and acceptance criteria. The pilot needs a written definition of success before traffic: which scenarios, which metrics, what counts as a pass, and the date a production decision will be made. Without it, the pilot cannot end cleanly. The pilot guide covers how to choose those criteria.
Telephony and test numbers. If the agent connects to your existing contact-centre platform over SIP, the integration test does not need customers. Use internal test numbers and staff callers. The acceptance check is concrete: a call reaches the agent, completes a routine step, and a transfer lands in the right queue with the context your agents expect.
Knowledge sources. Someone must approve what the agent is allowed to say. List each source, its owner and its version. A policy page that is out of date becomes a wrong answer on a live call.
Recording and AI-disclosure notice. The caller must be told they are speaking with an AI, and your recording notice must match where your callers are. See AI call disclosure and consent and call recording consent by state. Counsel signs off the final wording.
Critical path and what can run in parallel
Most of the six workstreams are independent at the start. What makes the plan move is knowing which items truly block live traffic and which only block each other.
Three rules keep the path short:
- Start every reviewer in week one. The longest item is usually a review queue, not the work itself. A reviewer who has the documents early can start while other work proceeds.
- Separate "no customer data" work from "customer data" work. Telephony tests on test numbers, conversation design and knowledge drafting can run before the processing terms are signed, as long as no real customer data enters the vendor's systems. That is the line your privacy team will care about most, so write it into the plan.
- Put a decision date on every blocker. An open item without a date is not a plan; it is a hope.
What genuinely gates the first live call is narrower than the full list: security findings dispositioned, processing terms signed, acceptance criteria signed, the telephony path tested end to end, knowledge approved, and disclosure wording approved. Everything else can follow.
A fictional six-week plan
The plan below is invented to show structure. Your durations depend on your reviewers' queues, which no vendor controls.
| Week | Your side | Vendor side | Gate at end of week |
|---|---|---|---|
| 1 | Name owners for all six workstreams; send questionnaire; share data-flow draft | Send assurance documents and draft processing terms; propose acceptance criteria | Every workstream has two named owners |
| 2 | Security reads documents; telephony allocates test numbers | Configure test route on test numbers; draft scenarios | Test numbers routed to the agent |
| 3 | Legal reviews processing terms; knowledge owner lists sources | Answer security follow-ups; draft first conversation flows on the listed sources | Security findings have dispositions |
| 4 | Sponsor and procurement agree the statement of work | Internal test calls on test numbers; transfer to agent queue | Test call passes end to end |
| 5 | Sign processing terms and statement of work; approve disclosure wording | Fix test findings; load approved knowledge versions | All six workstreams closed or conditionally closed |
| 6 | Go / no-go meeting | Controlled first live calls on the agreed slice | First live call |
The open-items register
The register is the single source of truth for everything that is not yet closed. It replaces scattered email threads. Keep it in one shared document both sides can edit, and review it at a fixed weekly meeting of no more than thirty minutes.
| Field | What to record | Example (fictional) |
|---|---|---|
| ID | Short stable reference | SEC-04 |
| Workstream | One of the six | Security review |
| Item | One sentence, specific | "Confirm where call recordings are stored for the pilot tenant" |
| Owner (your side) | A person, not a team | Information-security lead |
| Owner (vendor side) | A person, not a team | Vendor security contact |
| Blocks | Which gate it holds | First live call |
| Status | Open / answered / closed / accepted with condition | Answered |
| Condition | Anything still to be done if accepted with a condition | "Re-confirm before production" |
| Due date | Agreed date | Week 3 |
| Evidence | Where the answer lives | Link to the vendor's written response |
Two habits make the register work. First, an item is closed only when the person who raised it says so, not when the other side replies. Second, "accepted with a condition" keeps the condition visible on the register until it is met; otherwise conditions disappear at the go / no-go meeting.
A copy-ready version of the register, with the fictional rows above, is available to download (CSV).
Exit criteria to start live traffic
Hold one short go / no-go meeting with the owners from both sides. Live traffic starts only if every line below is true:
- Security: every finding is closed or accepted with a written condition and an owner.
- Data: processing terms are signed; retention for pilot data is set; the data-flow diagram matches what was built.
- Scope: the statement of work, acceptance criteria and production-decision date are signed.
- Telephony: a test call has passed through the agent and returned to your agents' queue as designed, including a transfer with context.
- Knowledge: every source the agent uses is approved and versioned.
- Callers: the AI disclosure and recording notice are approved and present in the flow.
- Stop path: someone on your side can turn the pilot route off, and knows how.
If any line is not true, the answer is "not yet", with a date for the item that is missing.
Where NextLevel fits
NextLevel.AI sells voice AI agents and pilots, so it has a commercial interest in pilots that start. That is also why this guide keeps the approvals on your side of the table.
For security review, NextLevel's compliance page lists the documents available to current and prospective clients, under NDA where applicable. The security documents NextLevel lists on its compliance page include a SOC 2 Type I report (point-in-time, 28 Aug 2025, NextLevel.ai Agentic Platform, under NDA) and an ISO/IEC 27001:2022 certificate held by SPsoft (Inc/FZE/LLC), scope software-development services. Your security team should read each document's scope against your own requirements. Whether your contact-centre platform and routing fit is confirmed on a scoping call, not assumed. Pilot commercial terms are on the live pricing page; confirm the current terms there on the day you plan.
Approval times depend on your reviewers and are not something any vendor can promise.
Next step: request the security documents for your security review, and book a scoping call from the pricing page to plan the pilot. Bring this register to the call and ask for the vendor-side owners and dates to be filled in before your first review meeting.
Frequently asked questions
Can telephony testing start before the data processing agreement is signed?
Often yes, if no real customer data reaches the vendor. Internal test numbers and staff callers let you prove routing and transfers early. Confirm the boundary with your privacy team and write it into the plan.
Who should own the mutual action plan?
The pilot sponsor on your side and a named delivery lead on the vendor side. Each owns their half of the register. Shared ownership without names usually means nobody owns it.
Is a SOC 2 report a certification?
No. A SOC 2 report is an independent auditor's report on a service organisation's controls; a Type I report assesses the description of the system and the design of controls as of a point in time. Read which system and date it covers. The RFP checklist covers this question in more depth.
How long should the path to the first call take?
It depends on your review queues. Plan with your reviewers' real lead times and put a date on every blocker. No vendor can guarantee your internal approval time.
Sources
- UK GDPR Article 28, Processor (legislation.gov.uk), read 9 Nov 2026.
- NextLevel compliance page, read 9 Nov 2026: documents listed as available on request, SOC 2 Type I scope and date.
- NextLevel pricing page, read 9 Nov 2026: linked for current pilot terms only; no term is quoted in this article.
- Related NextLevel guides: voice AI pilot, conversational AI RFP checklist, voice AI security, AI call disclosure and consent.