A voice AI client onboarding and fulfilment SOP should move through nine controlled stages: intake, scope and guardrails, knowledge build, integrations and telephony, internal testing, client approval, launch, support handoff, and first-week review. The agency should require evidence at each gate rather than promise that every client will launch within a fixed number of hours. This SOP defines the work, owner, output, and approval needed at every stage.
Fast configuration is useful, but speed is not readiness. A simple missed-call receptionist may need little integration work, while a regulated intake flow or multi-location deployment needs more review and testing.
What Is the Voice AI Client Onboarding Process?
The voice AI client onboarding process converts a signed scope into an approved, monitored call workflow. It begins with operational discovery and ends when the client accepts the launch configuration, support ownership is clear, and the first live-call review is complete.
| Stage | Owner | Required output | Gate |
|---|---|---|---|
| Intake | Account lead | Complete source pack and contacts | Required fields complete |
| Scope | Solution owner | Call map and prohibited actions | Client signs scope |
| Knowledge | Agent builder | Reviewed knowledge base | Sources verified |
| Connections | Technical owner | Working systems and phone route | Connection tests pass |
| Testing | QA owner | Test matrix and defect log | Critical tests pass |
| Approval | Client owner | Approval and accepted limitations | Launch authorized |
| Launch | Technical owner | Controlled routing and rollback | Monitoring active |
| Support | Support owner | Responsibility and severity map | Ownership accepted |
| Review | Account lead | Findings, fixes, and decision | Review completed |
This page owns the executable intake-to-support fulfilment SOP: owners, deliverables, evidence, and gates. The first seven days client onboarding checklist is the shorter day-by-day execution companion, while the white-label onboarding best-practices article covers higher-level principles and common pitfalls rather than the operating procedure.
What to do: Put every deliverable in one onboarding record. Chat messages and meeting memory are not an operating system.
Stage 1: What Information Should the Agency Collect?
The agency should collect business facts, call rules, system access, privacy requirements, and named decision-makers before building the agent. Missing source information should block configuration rather than be filled with assumptions.
Collect:
- Names, locations, time zones, hours, holidays, and service areas.
- Services, exclusions, eligibility, approved prices, and policies.
- Common call types and the intended outcome for each.
- Urgent, sensitive, prohibited, and human-only scenarios.
- Transfer destinations, schedules, and unavailable-person fallbacks.
- Appointment types, durations, buffers, staff, and locations.
- Existing number, carrier, calendar, CRM, and notification channels.
- Recording, consent, retention, access, and deletion requirements.
- Operational, technical, privacy, launch, and rollback contacts.
Use vertical addenda for the details that change. A home-service form needs service radius and emergency definitions. A medical form needs approved intake and a no-clinical-advice rule. A legal form needs matter types, conflict-check fields, and a no-legal-advice boundary.
What to do: Separate launch requirements from enhancement ideas. An incomplete requirement should not hide inside a wishlist.
Stage 2: How Should Scope and Guardrails Be Defined?
Scope should state what the voice AI may answer, collect, book, route, and trigger, plus what it must refuse or escalate. Each call type needs an allowed action, required information, success condition, and fallback.
| Call type | Allowed action | Required information | Fallback |
|---|---|---|---|
| Standard enquiry | Answer from approved source | Caller question | Take a message if source is missing |
| New lead | Qualify and book or notify | Name, contact, need, location | Callback request |
| Urgent request | Apply approved urgency rule | Location, issue, callback number | Immediate escalation |
| Complaint or exception | Collect context, do not decide | Contact and summary | Named human owner |
| Out-of-scope request | Explain boundary | Minimal information | Approved referral or callback |
Guardrails should cover professional advice, safety, refunds, discounts, contractual promises, identity verification, sensitive data, and system actions. For regulated work, the client's qualified reviewer should approve the actual workflow, not merely the vendor's compliance page.
What to do: Write prohibited actions as testable statements, such as “must not provide clinical advice.” “Use common sense” is not a guardrail.
Stage 3: How Should the Knowledge Base Be Built?
Build the knowledge base from client-approved sources, reconcile contradictions, and assign an owner to every time-sensitive fact. Website extraction can create a first draft, but it cannot decide whether an old page or an owner's verbal exception is authoritative.
Prioritize signed policies and live system records, then approved service documents, current website pages, approved FAQs, and reviewed discovery notes. Mark hours, prices, service areas, staff availability, and promotions for recurring review.
Trillet White-Label can create an agent from a client's website, which shortens the blank-page stage. The agency still needs to verify the resulting business knowledge before client testing.
What to do: Ask the client to approve the facts, not just the voice. A pleasant agent reading obsolete policy is still obsolete policy.
Stage 4: How Should Integrations and Telephony Be Connected?
Connect only the systems required for the approved launch scope, test each write and failure path, and document who owns the credentials. Telephony should include normal routing, unavailable destinations, after-hours behavior, and rollback.
For Trillet White-Label, named integrations include GoHighLevel, Google Calendar, Cal.com, Stripe, APIs, and webhooks. Other systems may require API, webhook, or MCP work, so confirm the implementation instead of describing every CRM as native.
Check the correct calendar, service, duration, buffer, time zone, duplicate prevention, confirmations, and behavior when a system is unavailable. For phone routing, check missed, busy, declined, immediate, and after-hours conditions, plus each transfer destination.
Trillet uses call forwarding so a client can retain the existing business number. The agency should still test the client's carrier and exact forwarding condition before launch.
What to do: Use synthetic customer data where possible and keep credentials in the approved secret store, not the intake form.
Stage 5: Which Calls Must Be Tested Before Approval?
The internal test matrix should cover happy paths, boundaries, prohibited actions, poor audio, system failures, and human handoff. Every case needs an expected result, actual result, evidence, severity, owner, and retest status.
Test:
- Correct and incorrect service enquiries.
- In-area and out-of-area leads.
- Available, unavailable, and invalid appointment requests.
- Normal, urgent, sensitive, and life-safety phrasing.
- Busy, unanswered, rejected, and closed transfer destinations.
- Unknown policies and requests to invent an exception.
- Interruptions, background noise, spelling, addresses, and numbers.
- Disconnected calendar, CRM, webhook, or notification paths.
- Requests for a human at different points.
- Privacy, recording, and data-access questions.
Classify safety, privacy, prohibited action, data exposure, and false action confirmation as critical. Wrong bookings, routing, eligibility, prices, and policies are high severity. Fix critical and high defects and rerun neighboring cases before client testing.
What to do: Do not send a known serious defect to the client as a “test experience.”
Stage 6: What Should the Client Approve?
The client should approve scope, business facts, voice and disclosure, booking and routing outcomes, escalation rules, known limitations, and launch plan. Approval should identify the tested configuration rather than apply indefinitely to future changes.
Give the client structured calls: a common question, valid and invalid booking, urgent scenario, available and unavailable transfer, unknown question, interruption, and changed intent. Record feedback as a defect, new requirement, or preference so approval does not become an unbounded redesign.
What to do: Require written approval from the named launch owner, including accepted limitations and the rollback contact.
Stage 7: How Should the Agency Launch the Agent?
Launch should begin with a controlled routing window, active monitoring, and a tested rollback path. The agency should know who is watching, what triggers intervention, and how the old phone route will be restored.
Freeze and record the configuration, confirm transfer recipients, verify monitoring, activate only the approved scope, make a live-route smoke test, and inspect the first representative calls and downstream records. Pause for any critical failure or repeated high-severity defect.
Do not promise a universal same-day or under-24-hour launch. Timeline depends on scope, client response, integrations, telephony, risk, and test results.
What to do: Put rollback steps where the launch operator can reach them without searching old messages.
Stage 8: Who Owns Support After Launch?
Support ownership should distinguish platform incidents, client-data changes, workflow changes, integration failures, and caller-specific questions. The client needs one intake route, while the agency needs an internal escalation map.
Define support hours, severity, acknowledgement targets, change approval, integration ownership, provider escalation, retainer boundaries, test and rollback procedure, and the evidence clients should submit. The Trillet white-label platform provides branded client workspaces, while the agency remains responsible for its client promise, workflow choices, and first-line communication.
What to do: Hold an operations handoff even if the same person built and supports the agent. The record should survive staff changes.
Stage 9: What Should the First-Week Review Cover?
The first-week review should compare live calls with the approved scope, identify recurring defects and missing knowledge, reconcile system actions, and decide whether to maintain, narrow, pause, or expand. Answered-call volume alone is not fulfilment evidence.
Review correct answers, safe fallbacks, bookings against calendar records, transfer attempts against connected handoffs, message usability, critical defects and retests, caller effort, complaints, human requests, maintenance time, and new client requests.
Expansion requires separate evidence. A successful booking workflow does not validate payments, outbound calling, another location, or regulated intake.
What to do: Finish with a signed decision: continue, continue with fixes, narrow, pause, or approve a separately tested expansion.
Which Documents Make This SOP Repeatable?
Agencies should package the SOP as reusable templates with vertical addenda. The stages stay consistent, while intake questions, prohibited actions, systems, and tests change by industry.
Maintain a sales handoff, intake and source register, call map, prohibited-actions sheet, access register, test matrix, defect log, approval record, launch and rollback checklist, support matrix, review template, and change history.
The white-label voice AI agency guide covers the wider business model. Current plan boundaries and inclusions belong on the canonical Trillet White-Label pricing page, not inside a fulfilment SOP that will outlive a pricing revision.
Frequently Asked Questions
How quickly can an agency onboard a voice AI client?
The timeline depends on workflow complexity, source quality, client response, integrations, telephony, risk review, and test results. Promise gates and responsibilities rather than a universal launch time.
What should block a voice AI client launch?
Unresolved safety or privacy failures, prohibited actions, false action confirmations, broken rollback, missing escalation ownership, and lack of client approval should block launch. Serious policy, routing, and integration defects should also be fixed and retested.
Should the client or agency write the knowledge base?
The agency can build and structure it, but the client should supply and approve authoritative facts. The agency should not invent missing prices, policies, service rules, or professional guidance.
Who owns changes to hours or prices?
The service agreement should name who submits, approves, applies, tests, and confirms each change. Without that chain, stale client information becomes an avoidable production defect.
Is client approval enough to stop quality review?
No. Approval authorizes the tested scope, while live monitoring checks caller variation, integration behavior, and drift. Continue sampling and retest after material updates.
Updated for August 2026: Rebuilt this page as the canonical intake-to-support fulfilment SOP, removed unsupported speed and outcome claims, and added approval, rollback, ownership, and evidence gates.
