Fin Voice was built as a flexible knowledge-based phone agent, with out-of-hours support as the initial low-risk use case.
2
Voice required different conversation design from chat, including about one-second responses, filler speech during longer requests, and shorter answers delivered in chunks.
3
Deployment depended as much on testing, monitoring, escalation paths, and context handoff as on the underlying voice model.
Summary
Peter Bar explains how Intercom built and launched Fin Voice, a phone support agent, in about 100 days. The team chose a flexible knowledge-based agent because Fin already handled similar questions in chat and call analysis showed that many queries could be answered from help content. It first targeted out-of-office-hours support, where companies could try the system without changing their main workflows. Bar covers the voice stack, including speech-to-text, language models, text-to-speech, retrieval-augmented generation, and telephony. He also describes why voice needs different behavior from chat: shorter answers, low latency, filler words during longer operations, and step-by-step troubleshooting. The largest deployment concerns came from support-team workflows. Escalation settings and transcript summaries helped human agents take over with context. Evaluation combined test conversations, internal debugging tools, resolution rate, and language-model review. Bar also compares usage-based and outcome-based pricing.
Fin Voice started with a flexible knowledge-based use case
Intercom considered narrow voice applications such as booking a restaurant table or scheduling a dentist appointment. The team chose an agent that could answer questions from a company's knowledge base, such as pricing plans or return policies. Fin had already handled similar conversations in chat for years, and customers reported seeing the same issues over the phone. Analysis of call transcripts supported that choice: a large share of queries could be solved with help articles rather than API integrations. The initial product focused on answering questions, while authentication, information gathering, and routing remained additional uses rather than the main end-to-end job.
Out-of-office-hours support gave companies a low-risk way to try voice AI
Bar describes support outside office hours as the first deployment wedge. In that setting, the agent replaces voicemail without changing the main support workflow during the day. Teams could try the technology and build confidence before considering use on their primary phone lines. Intercom also examined authentication, collecting order or account IDs, and routing callers to the right team. These tasks could save support agents time, but they did not necessarily resolve the customer's issue from start to finish. That distinction shaped what Intercom included in the first version.
The first product work focused on testing, deployment, and monitoring
Intercom had thousands of customers using its phone support product, so the team concentrated on learning quickly. It built the Fin Voice playground within the first four weeks. Customer service managers could simulate sessions, ask questions based on a knowledge base, and see how the agent responded. A deployment experience let managers put the agent on phone lines and configure its behavior and workflow interactions. Monitoring showed transcripts, recordings, transcript summaries, and call outcomes. These tools let Intercom improve the system using customer feedback rather than relying only on internal opinions.
The voice stack combined a chained speech loop with existing Intercom systems
The main loop used speech-to-text, a language model, and text-to-speech. Bar contrasts this with voice-to-voice models, which process audio directly and may sound faster or more natural but give less control over the output. Intercom started with the Realtime API to test quickly and later evolved the stack while keeping it part of the core architecture. Retrieval-augmented generation supplied answers from the knowledge base. Telephony connected the agent to phone lines. Existing chat retrieval and Intercom's native phone product gave the team a head start.
Voice conversations needed shorter delays and shorter answers than chat
Bar says voice is not simply chat with sound. A pause of one or two seconds can make a caller think something has gone wrong, even though chat users tolerate waiting longer. Fin reached about one second for simple queries. For complex requests that took three or four seconds, it inserted phrases such as "Let me look into this for you" while generating the answer. Voice answers also had to be shorter. For multi-step responses, Fin broke the answer into chunks and asked whether the caller wanted to hear the next step, which worked well for troubleshooting.
Support workflow integration became a larger deployment blocker than model behavior
The largest share of customer feedback was about how Fin worked with support teams, rather than voice quality, the model, or latency. Intercom focused on escalation paths and context handoff. Customers could configure how calls moved to human support. After each AI call, Fin generated a transcript summary so the human agent receiving the call could understand what had happened. Bar calls these features less flashy than the model, but says they were essential for moving from a demonstration to deployment with larger customers.
Evaluation combined repeatable conversations, debugging tools, and resolution rate
Intercom maintained a set of test conversations that ran after major code changes. The process began manually in a spreadsheet and became more automated over time. Internal web applications let the team inspect logs, transcripts, and recordings when a customer reported a problem. The main outcome metric was resolution rate. Intercom counted a call as resolved when the user confirmed the issue was resolved, or disconnected after hearing at least one answer and did not call back within 24 hours. An experimental language-model judge analyzed transcripts for problems and improvement opportunities.
Pricing creates different incentives depending on whether customers pay for usage or outcomes
Bar gives a typical voice-agent cost range of three to 20 cents per minute, depending on query complexity and provider choice. Usage-based pricing charges by minute or call and is predictable, but it does not directly measure whether the agent helped. Outcome-based pricing charges when the customer's issue is resolved, which aligns the provider more closely with the customer. It also shifts risk to the provider, since a long unresolved call still carries a cost. Bar expects the market to move toward outcome-based pricing because the incentives are better aligned.
"Crazy how the human speaks more like a bot and the bot speaks more like a human."11:47
Who should watch
You are building a phone-based AI agent and need to choose an initial use case that customers can adopt without changing their main support operation.
Your team has a voice prototype, but human handoff, testing, recordings, or deployment controls are still unresolved.
You are deciding how to evaluate or price a voice agent and want a concrete definition of resolution rate and a comparison of usage-based and outcome-based pricing.
