News and analysis
Voice AI for sales: deciding whether to build or buy
How to choose voice AI: compare telephony ownership, human handoff, CRM integration and the cost of keeping the service running.
Choosing voice AI starts with ownership of the process, rather than the quality of a demonstration call. Who is responsible when a caller interrupts, a transfer fails, or the conversation outcome never reaches the CRM? Buying a platform and building a service allocate those duties differently. Even a successful pilot leaves ongoing operating costs.
In Close's build-or-buy comparison, the vendor recommends assessing infrastructure, integrations and the source of competitive advantage. It also describes a middle ground: buy the voice technology while building rules for lead selection, human handoff and outcome processing separately. The timelines and costs in the publication should not be treated as estimates for a particular project. Its questions are more useful as inputs to an independent decision.
Define one job for the initial launch
Consider a sales team that needs to receive inquiries outside working hours. The job is to establish why someone is calling, record contact information and create the next task for a salesperson. That is a different responsibility from negotiating prices, changing a contract or promising a delivery date.
Describe the permitted actions. What information may the agent provide? Which answers require clarification? When must it stop? Those limits belong in the product requirements regardless of who develops it. If the system only collects inquiries, its quality assessment should reflect that role.
The voice channel depends on telephony and routing. The loan call center case study offers context for organizing calls and roles; it does not establish use of a particular AI provider or predict pilot results.
What a platform buyer still owns
A managed service may take on some voice infrastructure, but the business still defines permitted actions and owns its process. Compare proposals using a responsibility table: numbers and carriers, recording, storage, access settings, model updates, error monitoring and integration support.
Check whether conversation history can be exported, numbers transferred and the provider replaced. What happens to unfinished calls when the contract ends? In which format are recordings available? Can the relationship between a conversation and its customer record be recovered? These answers matter before real inquiries are connected.
Buying a platform does not automatically resolve consent, recording or disclosure requirements. Those depend on jurisdiction, call type and data handling, and need checking for the particular use case. The provider's duties should be explicit in its contract, with a responsible person inside the business overseeing verification.
What building involves
In its discussion of voice agent operations, Close highlights narrow intake and routing scenarios, conversational latency, CRM connections and transferring context to a person. This is a vendor's operational perspective rather than a universal quality guarantee. It is useful because it extends evaluation beyond how natural the voice sounds.
A development team must connect speech recognition, a model, speech synthesis and telephony, then maintain their interaction. Testing covers more than completed answers: interruptions, silence, noise, misrecognized names, an unavailable external system and an abruptly terminated call. Each failure needs a responsible component and an operational owner.
Building can be justified when the technology is itself the company's product, data constraints rule out available platforms, or an essential integration is unsupported. Test that constraint first. An unusual call script does not, on its own, require ownership of the entire voice stack.
Human handoff is part of the product
Ask the vendor or developers to demonstrate the whole transfer. What does the caller hear while waiting? Does the operator receive recent turns and the reason for escalation? What happens when no operator is available? The system must distinguish a successful connection, a callback task and an unsuccessful attempt.
A handoff should provide more than several pages of transcript. The operator needs the reason for contact, information collected, the unresolved question and the promised next action. These concerns are explored in AI support conversation design, while chatbot development provides context for connecting conversations to business systems.
If a support request follows the call, agree on the event that starts the response clock. “The agent spoke” and “an employee accepted the task” may represent different commitments. Explicit SLA rules are needed at that boundary.
Compare full operating cost and run a limited pilot
For each option, assess more than call minutes. Include setup, engineering time, recording storage, error investigation, employee training, telephony support and changes to business rules. A custom build adds continuing responsibility for components; a platform brings plan restrictions and provider dependence. Use actual proposal terms when putting numbers against these items.
A pilot can be limited to one inbound inquiry type, a defined time window and a clear fallback route. Compare correctly captured inquiries, successful transfers, calls without a recorded outcome and cases in which callers had to repeat themselves. Examine unsuccessful conversations separately instead of relying only on averages.
Choose the option that performs the defined job and has a clear owner for its operation. That may be a platform, a custom service or a hybrid. Make the decision after checking boundaries, access to data and responsibility for the next action, before expanding call volume.