Running Voice AI for Clients: Multi-Tenant Setup, Billing, and Support Boundaries

Running voice AI for clients is a different job from building one agent well. The work that decides whether it scales past five accounts is structural: how client data is separated, how each client's usage gets attributed to their invoice, who is allowed to change an agent, and what you will and will not fix on a Friday night.

Agencies, BPOs, and platforms reselling voice agents hit the same three walls in the same order. Tenancy, billing attribution, and support.

This is how to set each one up before it becomes a problem, plus the offboarding terms worth agreeing while everyone is still happy.

TL;DR

• Separate every client at the workspace level from day one. Retrofitting separation after ten clients share one workspace is a migration, not a setting.
• Workspace creation is manual. There is no provisioning API, so build the onboarding runbook early.
• Numbers are the messiest part. Decide who buys them, whose name is on the caller ID, and what happens to a ported number on exit.
• Billing attribution comes from each client's own workspace usage totals, so reconcile per workspace rather than against one aggregated bill.
• Write down who can change an agent. Uncontrolled client edits and vendor-only edits both fail, in opposite directions.
• Support boundaries are a pricing decision. Define included changes per month, response windows by severity, and what is out of scope.
• Agree the offboarding terms in the first contract: number release, recording export, and what happens to the agent configuration.

What multi-tenant actually means here

Multi-tenancy means one system serving many clients while keeping each one's data, configuration, and users separate. For a voice AI agency, that separation has to hold across four things at once.

• Data. Call recordings, transcripts, and any customer records one client's agent touches must not be visible to another client.
• Configuration. Agents, prompts, knowledge, and transfer rules belong to a client, and a change to one must not reach another.
• Access. Your team needs access across all clients, each client needs access to their own, and nobody needs access to anyone else's.
• Usage. Minutes and calls have to be countable per client, because that is the invoice.

Get the first three right and the fourth becomes easy. Get the first three wrong and the fourth becomes a spreadsheet you maintain by hand every month.

One workspace per client, or one workspace with many agents?

One workspace per client, in almost every case.

Putting every client's agents in a single workspace is faster to set up and produces three problems that get worse with headcount.

1. You cannot give a client visibility into their own calls without exposing everyone else's.
2. Usage arrives as one aggregate number you then have to divide.
3. A mistaken edit or deletion reaches the wrong client's live agent.

Workspace-level separation with role-based access solves all three, and it maps onto how Retell separates things: each workspace is a fully isolated boundary, with its own agents, API keys, members, webhooks, telephony settings and billing. The developer docs are the place to start on everything else, but provisioning is manual. Retell does not expose an API to create, delete or switch workspaces, so each new client workspace is set up by hand in the dashboard. Budget the time per onboarding and put the steps in a runbook before client eleven rather than after.

Two cases justify a shared workspace. A handful of tiny accounts running an identical agent where no client ever gets direct access, and a pilot you intend to migrate. Both need an explicit plan for the day they stop being true.

Keep a naming convention from client one. Client code, use case, environment, in that order, on every agent, number, and knowledge base. It costs nothing on day one and saves an afternoon per incident later.

Phone numbers, caller ID, and porting

Numbers cause more client friction than anything else in the stack, because they are the one part of the setup the client already owns.

Three decisions to make before the first launch.

• Who buys the number. Numbers bought under your account are simpler to manage and harder to hand over. Numbers the client owns and points at the agent are the reverse. Pick per client and write it in the agreement.
• Porting or forwarding. Clients almost always want to keep their existing business number, and many assume they cannot because the setup flow offers to sell them a new one. Forwarding the existing number to the agent is usually the faster path and avoids touching their carrier at all.
• Whose identity shows on outbound. On outbound calls the client's brand should appear, not yours. Branded call ID and verified phone numbers affect whether the call gets answered at all, which matters more than dial volume.

One trap worth naming. If you buy numbers under your own account for convenience and the client later leaves, you are holding a number their customers dial. That is a dispute waiting to happen, so decide the release terms at signing rather than at exit.

Where billing attribution comes from

It comes from per-client usage records, and you need them to reconcile to the usage totals on each client's workspace to the minute.

Build the invoice from three components and keep them separate on the client's bill.

Reconcile monthly, not quarterly. If a client invoice and that client's workspace usage disagree, the gap is nearly always a number or an agent sitting in the wrong workspace, and it is much easier to find inside 30 days.

Per-workspace usage records make this arithmetic clean, because the number you pass through to a client is the number that workspace was charged. Each workspace carries its own payment method, credit balance, invoices and usage totals, so there is no aggregated bill to unpick at month end. Read the whole bill when you design the invoice. Recurring charges for phone numbers, extra concurrency, knowledge bases, verified numbers and SMS sit alongside the usage rate, and they belong in your fixed per-client line rather than in the pass-through. Check the current pricing model before you design your invoice around it.

Add a margin check to the same monthly ritual. Minutes per client, revenue per client, and support hours per client, in one view. The account that is quietly losing money is usually the one with the most pleasant client.

Who owns the agent when the client wants a change?

Someone has to, and the answer should be written down before launch rather than discovered during an incident.

Both extremes fail. If only you can make changes, you become the bottleneck on every holiday message and price update, and the client experiences your ticket queue as the product. If the client can change anything, someone edits a live prompt on a Friday and you get the call about it on Monday.

The workable middle is a split by risk.

• Client can change directly: business hours, holiday messages, FAQ answers in the knowledge base, notification recipients.
• You change, same day: prompt wording, qualification questions, transfer rules, escalation thresholds.
• Project work: new call types, new integrations, anything touching the booking flow or a system of record.

The capability that makes this split safe is versioning and a test path. Change in a non-production version, test it on calls, then promote. Without that, every change is a live experiment on the client's customers. The call transfer rules are the ones to be strictest about, because a broken transfer is invisible in the dashboard and obvious to the caller.

The reason to keep this inside your own hands rather than a platform vendor's is speed, and it is the pillar the whole operating model rests on. You own the CX improvement loop for every client on your book. Unlike managed AI vendors and BPOs, a change does not become a ticket, a queue, or another SOW. Across the platform, 80% of production minutes run through agents customers build and manage themselves, which is the same arrangement you are offering your clients one level down.

When the person who heard the failed call can fix it that afternoon, agents improve weekly. When every change is a vendor ticket, agents decay as the client's business moves.

Support boundaries: tiers, response windows, and what you refuse

Support is where agency margin goes to die, so it needs to be specified as tightly as the price.

Write three things into the agreement.

1. Included changes per month. A number, not a vibe. Anything above it is a change request with a price.
2. Severity levels and response windows. Agent not answering calls is not the same as a wording tweak, and they should not share a response time.
3. Out of scope, explicitly. Their CRM being down, their carrier outage, a change to their own website form, and anything requiring a decision only they can make.

A severity table that clients accept without argument usually looks like this.

What to refuse: open-ended availability, unpriced rebuilds, and taking responsibility for systems you do not control. Refusing these is what keeps the rest of the service sustainable at twenty accounts.

One more boundary that saves real time. Route the client's reports of call problems to a single channel with the call ID attached. A screenshot of a text message from the client's customer is not a bug report, and chasing the call it refers to can take longer than the fix.

What to monitor across a book of clients

Monitor at the portfolio level, not per client, or you will only ever see the problem the loudest client noticed.

• Answer and completion rate per agent. A drop here is the earliest signal that something upstream broke.
• Transfer success rate. Failed transfers are the most common silent failure and the most damaging to the client's customers.
• Average call length trend. Rising length means either the agent is handling more, which is good, or it is stuck in loops, which is not.
• Escalation and unresolved reasons. The recurring reason an agent could not resolve a call is your next week of improvements, across every client with a similar agent.
• Usage against plan per client. Catch the account that is about to break your pricing model before the invoice does.

This is what makes a multi-client book manageable by a small team. Post-call analysis gives you the per-call record, and AI quality assurance scores calls against criteria you define, so you find the failures the client has not complained about yet. Fixing those is the difference between a renewal conversation and a rescue.

If you deliver through an agency platform your clients already use, check the integration path early. The Go High Level integration is one of the most common paths, and how leads and call outcomes flow back into the client's existing system usually decides whether they consider the deployment finished.

Offboarding without a dispute

Agree the exit in the first contract, because every term is easy to write now and contested later.

1. Number release. Who owns each number and how long a port or release takes.
2. Recordings and transcripts. What gets exported, in what format, and what you delete afterwards, with the retention period stated.
3. Agent configuration. Whether the client receives the prompts and flow logic, or whether that is your work product. Either answer is defensible. Silence is not.
4. Notice period and final invoice. Including how usage in the final part-month is billed.
5. Data deletion confirmation. Especially where the client is in a regulated industry and needs it on paper.

Clients rarely negotiate these at signing and always ask about them at exit. Writing them early also signals that you have done this before, which helps close the deal you are writing them into.

The first ten clients checklist

If you are setting this up now, do these in order.

1. One workspace per client, created by hand in the dashboard, with a naming convention applied to agents, numbers, and knowledge bases.
2. Role-based access, with client users scoped to their own workspace only, and your own team invited into each client workspace with the role that job needs. Roles are assigned per workspace, and the invite dialog offers Admin, Developer and Member.
3. Number ownership and caller ID decided per client and written into the agreement.
4. Per-client usage reconciliation, run monthly against that client's workspace usage totals.
5. A change-rights split by risk, plus a test-then-promote path for anything live.
6. A severity table with response windows, and an explicit out-of-scope list.
7. A portfolio monitoring view covering answer rate, transfer success, and usage against plan.
8. Offboarding terms in the first contract.

None of it is difficult. All of it is much harder after client ten than before client one.

Frequently asked questions

How do you keep client data separate when running voice agents for many clients?

Use one workspace per client with role-based access, so recordings, transcripts, configuration, and usage are scoped to that client. Each workspace is a fully isolated boundary. Scope client logins to their own workspace only, and invite your own team into each client workspace with the role that job needs, because roles are assigned per workspace rather than above it. The invite dialog offers Admin, Developer and Member. Confirm what a given role can reach before you hand a client a login, since separation is what you are selling.

Should each client have their own phone number?

Yes. Either the client owns the number and forwards or ports it to the agent, or you buy it on their behalf with release terms agreed in writing. Sharing a number across clients breaks attribution and caller identity.

How do you bill clients for voice AI usage?

Bill three separate lines: platform usage taken from that client's workspace usage records, fixed per-client costs such as numbers and integrations, and your own work as a retainer or change allowance. Reconcile monthly, workspace by workspace, because each workspace carries its own invoices and usage totals.

Should clients be able to edit their own agents?

Give them the low-risk surface, such as hours, holiday messages, and knowledge base content, and keep prompts, transfer rules, and integrations with your team behind a test-then-promote path.

What support level should an agency commit to?

Define severity levels rather than one response time. Calls not being answered warrants an out-of-hours response; a wording change does not. Then state how many changes are included per month and what sits outside scope.

What happens to the agent if the client leaves?

Whatever your contract says. Cover number release, recording export, data deletion, and whether the agent configuration transfers. Decide it at signing, because at exit it becomes a negotiation.

Run one client or a hundred on the same setup

Retell is a Customer Experience AI Platform for Autonomous Customer Relations. Set up one client workspace, run that client's real calls through it for a week, then check the isolation, the usage record and the call review against this checklist before you onboard the second. Run a pilot on your own calls.

##