Shipping an Enterprise Voice AI Agent in 100 Days

A customer calls for help. The frontline agent must pick up, answer the question, and recognize when a human should take over. Fin Voice brings that experience to inbound phone support. Peter Bar reports that Intercom built it in about 100 days.

The starting point was an established customer-service platform. Intercom had grown from a web and mobile messenger into a system supporting email, WhatsApp, and phone. Shortly after GPT-4 arrived, it introduced the text-based agent Fin. That gave the voice project both an existing product and experience answering support questions.

Bar reports more than 5,000 Fin customers and an average chat resolution rate of 56%, with some customers reaching 70–80%. Here, resolution meant an interaction handled by Fin without human intervention; these were results for the existing text agent, not measured Fin Voice performance.

Fin also included the surrounding optimization loop: analyze conversations, train agent behavior, test changes, and deploy them. Adding voice meant extending that system to phone calls, rather than shipping an isolated speaking interface.

For an urgent or sensitive problem, typing may be the wrong interaction. A customer may simply want to talk. Bar cites phone support usage by more than 80% of support teams and says more than one-third of customer-service interactions globally happen by phone. These figures frame a channel that remains central to support, rather than one being retired.

Bar estimates that a human-supported phone call in the US costs $7–12 and predicts voice AI will be at least five times cheaper. The proposed service improvements go beyond cost: a bank could answer on weekends, callers could avoid hold queues, and natural speech could replace menus that require pressing one for support or two for payments.

Bar also describes voice AI generally as capable of supporting 30–40-plus languages; this is not a Fin Voice language count. For businesses, the attraction is capacity that can grow with demand and absorb peaks. Turning those advantages into a product required decisions across seven areas: the initial use case, MVP scope, technical stack, conversation design, support workflows, evaluation, and pricing.

Many voice-agent products begin with a narrow transaction, such as scheduling a dentist appointment or reserving a restaurant table. Intercom considered those options but chose a more flexible knowledge-based agent. Questions about pricing plans or a returns policy could be answered from existing help articles.

The choice followed evidence already available to the team. Fin had handled similar questions in chat, customers reported receiving the same issues by phone, and analysis of call transcripts confirmed that many queries could be answered from knowledge-base content. That made help articles a useful starting point without requiring API integrations to resolve every initial use case.

After-hours support provided a low-risk adoption path. During office hours, a new agent would enter a working support operation. Outside those hours, it could replace voicemail without disrupting the team's main workflow. Teams could try the agent, build confidence, and then expand it into office hours.

Other useful jobs remained in view:

• Authentication: Verify a caller's identity through another channel.
• Information gathering: Collect an order ID or account ID before a human takes over.
• Smart routing: Send the caller to the appropriate team.

These tasks could save substantial agent time without resolving the issue end to end. They were useful supporting capabilities, but not the primary purpose of the initial release.

With thousands of customers already using Intercom's native phone-support product, the team had access to potential testers. The immediate challenge was to put something meaningful in their hands quickly. The MVP centered on three experiences, beginning with a playground where customer-service managers could simulate conversations and ask questions grounded in their own knowledge base.

Bar says the Fin Voice playground shipped approximately within the first four weeks. Managers could hear answers and understand how the product behaved, giving the team external feedback alongside its internal assessments.

Deployment then let managers put the agent on their phone lines, configure basic behavior, and specify how it should interact with team workflows. Monitoring completed the loop by exposing transcripts, recordings, transcript summaries, and call outcomes to customer-service agents. Testing made the behavior tangible; deployment made it usable; monitoring made the resulting calls inspectable.

A conventional voice-agent loop chains three operations: speech-to-text converts the caller's speech into text, an LLM generates a response, and text-to-speech converts that response back into audio. Direct voice-to-voice models offer another route, processing audio without that intermediate text layer.

Intercom initially used the Realtime API on its own because it enabled rapid testing. The team subsequently evolved the stack while retaining Realtime API in the core architecture. Bar does not specify the final topology or a complete provider list.

Two other components were essential. Retrieval-augmented generation, or RAG, supplied knowledge-base content for answering support questions. Telephony connected the agent to real phone lines. Intercom already had RAG for chat and a native phone-support product, so the voice team could build on both rather than create them from scratch.

Voice changes the meaning of a pause. In chat, a customer can tolerate a few seconds before an answer appears. On the phone, a second or two of silence may suggest that something has gone wrong. A voice conversation needs to remain legible while the system is working.

Bar reports roughly one-second responses for simple queries and three-to-four-second responses for more complex queries. Simple queries needed no extra conversational filler. For slower answers, the team injected a short acknowledgment—such as saying it would look into the issue—while generating the substantive response in the background. The acknowledgment maintained the flow without requiring the answer to be ready.

Answer length required a separate adaptation. A long chat response can be skimmed; a spoken response has to be heard in sequence. For complex or multistep answers, Fin Voice broke the response into chunks and asked whether the caller wanted to hear the next step. Troubleshooting is a natural fit: deliver a step, let the caller follow it, and confirm before continuing, rather than speaking uninterrupted for a minute or two.

Early callers also brought habits learned from older interactive voice response systems. They initially used terse inputs such as support, password reset, yes, or no. As they heard the agent speak in full sentences, some began speaking in full sentences themselves. A colleague captured the reversal: the human was speaking more like a bot while the bot was speaking more like a human.

Bar expects familiarity with voice agents to change those habits over time. Until then, conversation design has an additional job: help callers discover that natural speech works. The agent's own behavior provides that cue during the call.

Once teams began considering deployment, the largest source of feedback surprised Bar. Most feedback concerned how Fin Voice fit into support workflows, rather than the voice, model, or latency. Those core qualities still mattered, but workflow integration became the larger blocker.

Two integration points were especially consequential:

• Escalation paths: Teams needed configuration for how calls would reach human support.
• Context handoff: After every AI-agent call, a transcript summary gave the receiving human context about what had happened.

Together, these features defined where the call went and what the next agent knew when it arrived.

Neither feature was especially flashy. Both were essential to moving larger customers from trying a demo to deploying the agent in their support operation.

The team maintained test conversations to run on every major code change. Initially, evaluation was mostly manual and tracked in a spreadsheet; automation was added over time. For troubleshooting, internal Streamlit apps brought together logs, transcripts, and recordings so a customer-reported issue could be investigated at the level of the actual conversation.

Resolution rate was the North Star metric. Bar's definition counts a call as resolved if the caller explicitly confirms resolution, or disconnects after hearing at least one answer and does not call back within 24 hours. The second route requires an observation window: a hang-up after an answer is not enough on its own.

That rule can be expressed as a small Python classifier. The example call has heard one answer but has no explicit confirmation. It remains pending after two hours; after a full day with no callback, it qualifies as an assumed resolution under the stated rule.

from datetime import timedelta


def resolution_status(
    *,
    confirmed: bool,
    disconnected: bool,
    answers_heard: int,
    elapsed_since_disconnect: timedelta,
    callback_within_24h: bool,
) -> str:
    if confirmed:
        return "confirmed"
    if not disconnected or answers_heard < 1:
        return "not_counted_as_resolved"
    if callback_within_24h:
        return "not_counted_as_resolved"
    if elapsed_since_disconnect < timedelta(hours=24):
        return "pending"
    return "assumed"


call = {
    "confirmed": False,
    "disconnected": True,
    "answers_heard": 1,
    "callback_within_24h": False,
}

assert resolution_status(
    **call, elapsed_since_disconnect=timedelta(hours=2)
) == "pending"
assert resolution_status(
    **call, elapsed_since_disconnect=timedelta(hours=24)
) == "assumed"

This captures the historical rule described in the talk. Current product reporting should be read through its own definitions rather than assuming this callback condition still applies.

Finally, the team was experimenting with LLM-as-a-judge: another model analyzed call transcripts to identify problems and opportunities for improvement. This added a way to inspect conversation quality alongside regression conversations, troubleshooting tools, and the resolution metric.

Bar estimates typical voice-agent operating costs at $0.03–0.20 per minute, depending on query complexity and the providers selected. This is an operating-cost estimate, not a Fin Voice selling price or a universal API tariff. The commercial question is then which part of the service the customer should pay for.

Bar describes usage pricing as the more common model at the time. It is straightforward to charge per minute or per call, but those units do not necessarily capture whether the agent helped the customer. Outcome pricing instead charges when an issue is resolved.

A long, unresolved call still incurs operating costs. Under outcome pricing, the provider must absorb them. Bar nevertheless expects the market to move toward outcome pricing because it more closely aligns the provider's revenue with the customer's result. That is a forecast, not a reported market transition.

Bar reports that the roughly 100-day build reached several enterprise customers' main phone lines. Latency and resolution outcomes remained important, but reaching that point also depended on choosing a useful initial problem, designing for phone conversations, building internal and customer-facing tools, and fitting into support workflows.

The support team ultimately decides whether the agent goes live. Its trust is therefore part of the product's deployment requirements. The work behind the scenes may be complex, but callers and support teams need an experience that feels effortless: a question gets answered, a necessary handoff carries context, and the people responsible for the service can understand what happened.