Deployment requirements usually arrive already decided.
A line in a questionnaire asks whether the system can run in the customer's own environment, and everything after that is treated as a yes or no question. It is worth slowing down at that point, because the requirement is rarely about topology and the answer that satisfies it is often not the one being asked for.
- Three arrangements, loose names Shared service, an environment the customer controls, and something run entirely in-house, with the labels used inconsistently across the market.
- The topology is a proxy Most deployment requirements are standing in for an obligation about data handling, access or evidence rather than about where servers sit.
- Calls leave the perimeter regardless Telephony crosses networks the buyer does not operate, so no deployment model makes a voice system fully self-contained.
There are three arrangements in common use and the names for them are inconsistent between organizations. Getting precise about what each one actually means is most of the work, because two people using the same phrase frequently mean different things by it.
Voice adds a complication that other software categories do not have. A phone call travels across networks nobody in the conversation operates, which puts a floor under how self-contained any voice deployment can be.
What the Deployment Question Is Actually Asking
Stripped down, there are two questions inside every deployment requirement, and they are frequently answered as if they were one.
- In whose environment does the software run, meaning whose cloud account or whose hardware holds it.
- Who operates it day to day, meaning who applies updates, watches it and is woken when it stops.
Those can be answered independently. Software can run in a customer's account while a supplier still operates it, and software can run on a supplier's platform while the customer holds meaningful control over configuration and data.
A third question gets folded in and should not be. Where the language model executes is a separate decision that can be made differently from the rest of the stack, and it is set out in who runs the inference for the model step.
Whether to assemble the system at all is also a distinct decision. Deployment is about where a chosen system lives, not about whether to construct one, which is covered in assembling a voice agent or adopting a platform.
Answer the two questions separately and most deployment conversations get shorter, because the thing the buyer needs usually turns out to sit on only one of them.
The Three Arrangements in Plain Terms
The vocabulary is unreliable, so it is worth describing each arrangement by what is true of it rather than by the label attached to it.
One shared platform serving many organizations, with data separated logically rather than physically. The supplier holds the infrastructure, applies every update and carries the operational duty.
The software runs inside an account or network segment the customer owns. The customer holds the perimeter and the logs, while operation is typically still shared with or delegated to the supplier.
The customer holds the environment and operates it. Updates, capacity, monitoring and recovery all become internal responsibilities, along with the expertise those require.
The middle option is the one with the most variation hiding in it. Terms such as single tenant, private cloud, dedicated instance and customer-managed deployment are used for arrangements that differ substantially in who can actually reach what.
Two questions cut through that quickly. Whose credentials would be needed to read the data at rest, and whose people can open a session against the running system. The answers describe the arrangement more accurately than the name does.
It is also common for one system to span two arrangements. A shared control plane with processing in a customer environment is an ordinary design, and it is neither of the pure forms.
What the Buyer Is Usually Trying to Achieve
A deployment requirement is rarely written by somebody who wants a particular network diagram. It is written to satisfy an obligation, and the diagram is the form the obligation arrived in.
- Where call audio, transcripts and derived records physically rest, and whether that is inside a specified territory.
- Which people at the supplier can reach production data, under what approval, and whether that access leaves a record.
- What evidence exists afterwards: who can produce a complete account of a call and how long it is retained.
- Which third parties process the data along the way, and whether that list can change without notice.
- What happens at the end of the relationship, including how records are returned or destroyed.
Read that list and the pattern is clear. Every item is about data handling, access or evidence. None of them is inherently a statement about topology, and several can be satisfied in more than one arrangement.
That is not an argument for ignoring the requirement. It is an argument for asking which obligation sits behind it, because a control that satisfies the obligation directly is often available sooner and with less operational cost than relocating the software.
What is actually required in any particular case depends on jurisdiction, sector, the legal basis relied upon and the nature of the calls, so the applicable position is one to establish with counsel rather than assume from a general pattern.
The controls and accountability structures these questions are really probing are described in governing what a voice agent says and what evidence it leaves.
What Each Arrangement Changes, and What It Does Not
The differences that matter in practice are operational rather than architectural, and they are the ones least often discussed while the requirement is being written.
| Dimension | Multi-tenant service | Customer environment | Fully self-hosted |
|---|---|---|---|
| Who applies updates | The supplier, on their schedule | Usually the supplier, on an agreed window | The customer, when they choose to |
| How fast new capability arrives | Immediately, whether wanted or not | After a coordinated upgrade | Only once someone plans and performs it |
| Who is paged at night | The supplier | Shared, and worth writing down precisely | The customer's own team |
| Where records rest | Supplier infrastructure | Customer account or segment | Customer infrastructure |
| Cost shape | Mostly usage-based | Usage plus dedicated infrastructure | Mostly fixed, plus staffing |
| Time to first live call | Shortest | Longer, with environment work first | Longest, and dependent on internal capacity |
The update rows deserve more weight than they usually get. A shared service improves without being asked, which is an advantage until an unannounced change alters how an agent behaves on a call.
Moving to a controlled environment reverses that. Nothing changes unexpectedly, and nothing improves unexpectedly either, so a fix that would have arrived on its own now needs a planned upgrade to reach production.
The night-time row is the one that decides whether an arrangement is sustainable. Holding the environment means holding the incident, and a team that cannot genuinely operate a real-time voice system will experience that as outages rather than as control.
What No Deployment Model Removes
Voice differs from most enterprise software in one respect that constrains this whole discussion. The call does not start inside the perimeter, and it never can.
A caller dials from a handset on somebody else's network, and the audio crosses carrier infrastructure before anything under discussion here touches it. Those networks and the parties involved in them are described in how calls actually reach a voice agent.
- The carrier path exists in every arrangement, and it is operated by organizations the buyer has a contract with rather than control over.
- Speech recognition, synthesis and the language model are separate services that remain external unless each one is brought in-house deliberately.
- Business systems the agent reaches into sit wherever they already sit, which is frequently somewhere else again.
- Operational duty does not disappear when it moves. Relocating the software relocates the pager with it.
The practical consequence is that self-hosting the orchestration layer while every speech and model call still leaves the environment achieves less than the requirement intended. The audio is still processed elsewhere.
Which is why the useful conversation is component by component. Naming which parts of a call must satisfy a constraint produces a workable answer, where a single question about the whole system rarely does.
Turning a Deployment Requirement Into Answerable Questions
A requirement written as a topology is difficult to satisfy and easy to fail. Rewritten as a set of statements about data and access, it becomes something a supplier can answer precisely and an evaluator can verify.
- Find the obligation underneathAsk which policy, contract or regulatory position the requirement exists to satisfy, and read the wording of it rather than the summary.
- Restate it as data and accessWrite what must be true of the records and who must not be able to reach them, instead of writing where the software has to run.
- Say which components it applies toAudio, transcripts, derived records, knowledge sources and the model step are separate items and the constraint may only bind some of them.
- Decide who can operate itEstablish honestly whether your own team can run a real-time voice system at the hours calls arrive, before requiring an arrangement that assumes so.
- Make it evaluableTurn each statement into something a supplier answers with evidence rather than assurance, and keep the answers alongside the rest of the assessment.
Doing this early is what stops a shortlist collapsing late. A requirement discovered to be unsatisfiable in month three is expensive in a way the same discovery in week one is not.
These questions belong with the rest of the evaluation rather than in a separate security appendix, and a structure for that is given in what to ask before selecting a voice platform.
The wider set of expectations that large organizations bring to this category is set out in what enterprise buyers expect from a voice platform.
Frequently Asked Questions
In a customer-controlled cloud environment the software runs inside an account the customer owns, while the supplier typically still operates it and ships upgrades to it. Self-hosting means the customer holds both the environment and the operation, including updates, capacity, monitoring and recovery. The first changes the perimeter; the second changes who is on call.
Only partly, and less than the phrase suggests. The call itself arrives over carrier networks nobody in the arrangement operates, and speech recognition, synthesis and the model step remain external services unless each is deliberately brought in-house. Working out which components the constraint actually binds gives a more useful answer than one question about the whole system.
It depends entirely on the obligation, and it is not ruled out by the arrangement itself. What matters is where records rest, who can reach them, what evidence exists afterwards and what the contract says about processors and exit. Since requirements vary by jurisdiction, sector and call purpose, the applicable position should be established with counsel.
A shared service, usually by a wide margin, because there is no environment to build or hand over first. A customer-controlled environment adds provisioning, network and access work before anything can be tested. Fully self-hosted adds all of that plus the internal capacity to run it, which is often the constraint rather than the software.
Sometimes, and it is easier to plan for than to retrofit. What makes it feasible is keeping configuration, knowledge sources and integration points portable rather than tied to one environment's conventions. Treat it as a question to ask during evaluation, since the answer varies and it is much cheaper to establish before a system is in production.
