Intercom built and shipped Fin Voice in about 100 days, then deployed it on several enterprise customers’ main phone lines.
The economics made voice support a practical AI use case. In Peter Bar’s July 2025 talk, more than 80% of support teams still used phone support, and more than one-third of customer-service interactions happened by phone. A US call handled by a human cost about 7–12; Bar estimated that voice AI could be at least five times cheaper.
Intercom also had a production foundation. Its wider Fin platform served 5,000+ customers with a 56% average resolution rate, reaching 70–80% for some customers. These figures describe Fin overall, not Fin Voice traffic; Voice call volume and peak concurrency were not disclosed.
Fin Voice therefore extended an established AI support platform into a channel that was widely used and expensive to operate. Doing that required more than an LLM endpoint: telephony, speech processing, RAG, workflow integration, controlled deployment, observability, evaluation, and human handoff all became part of the system.
How Intercom introduced Fin Voice
Intercom began with knowledge-based questions already handled by its text agent. Call transcripts showed that help-center content could answer many phone requests.
Intercom first placed Fin Voice in after-hours support, where it replaced voicemail without changing the daytime workflow. This gave support teams real calls to review while limiting the effect of mistakes. Fin Voice later moved onto several customers’ main phone lines. Intercom’s current deployment guide recommends an initial 5–10% of calls.
Figure 1: Intercom moved from voicemail replacement to an after-hours pilot and then controlled production traffic.
Why 100 days was possible
Fin Voice reused four production building blocks:
Fin’s existing text-agent runtime and agent behavior.
A RAG system already connected to customer knowledge bases.
Intercom’s native phone product and call-routing workflows.
An installed customer base that could test the product and provide feedback.
The team was not building an AI platform, knowledge pipeline, and telephony product from zero. Its main work was integrating those systems and adapting the experience to real-time voice. That reuse explains more of the 100-day timeline than model choice alone.
Intercom Fin Voice solution architecture
This teaching diagram combines the public talk with Intercom’s deployment and telephony documentation. It is not an official internal diagram.
Figure 2: Fin Voice connected the real-time runtime to telephony, customer-service workflows, deployment controls, and evaluation data.
The system can be read as five layers:
Telephony and session ingress: Calls enter through Intercom Phone, PSTN forwarding, or SIP. External providers can register a phone number and call ID through the Fin Voice API, linking the carrier session to an Intercom conversation.
Real-time runtime:
Speech -> STT -> LLM + RAG -> TTS -> Speech. Intercom initially used a real-time API to test quickly and retained it after evolving the stack. The chained design exposed text and retrieval for grounding and debugging; direct speech-to-speech offered more natural audio but less control.Knowledge and actions: RAG retrieved approved help content. Current documentation also describes closed-beta Voice Procedures for API actions such as refunds or subscription changes; this was not part of the original 2025 disclosure.
Workflow and handoff: Rollout percentage, office hours, customer attributes, call history, and IVR branches determined which calls reached Fin. Unresolved calls transferred with a summary, transcript, and intent.
State and evaluation: Intercom stored recordings, live transcripts, summaries, outcomes, routing state, and call duration. Internal tools joined this evidence with logs for troubleshooting and evaluation.
The architecture distributed risk across the full call path. Carrier, transcription, retrieval, model, action, speech, and transfer failures could each affect the caller’s outcome.
Voice is not chat with sound
A chatbot can pause or return several paragraphs. On a phone call, silence feels broken and long answers are difficult to remember.
Figure 3: Voice requires different latency, answer length, and interaction patterns.
Intercom changed three behaviors:
Hide unavoidable latency: Simple answers arrived in about one second. For requests taking three or four seconds, the agent acknowledged the caller while working.
Break up long answers: Troubleshooting steps were delivered in short chunks with confirmation between steps.
Teach natural conversation: Callers often began with IVR-style keywords. Natural responses encouraged them to speak in complete sentences.
The LLMOps loop
Intercom delivered a browser voice playground within roughly four weeks. Support managers could test Fin against their own knowledge base before connecting a live number.
Figure 4: Test, deploy, observe, evaluate, and improve every major change.
The operating loop worked as follows:
Representative conversations were tested in the playground.
Changes reached after-hours or percentage-based production traffic.
The team reviewed recordings, transcripts, logs, handoffs, and outcomes.
Failures were traced to prompts, knowledge, routing, or runtime components.
Evaluations ran again before traffic increased.
The primary outcome metric was resolution rate: calls completed without human help. This included explicit confirmation and assumed resolution when a caller disconnected after an answer and did not call again within 24 hours.
Intercom started with manual spreadsheet evaluations and automated more of the process over time. An LLM judge helped review transcripts, but human review and deterministic checks still mattered.
Challenges and responses
ChallengeWhat Intercom didRisky first deploymentStarted after hours and increased traffic gradually.Slow complex requestsPlayed a short acknowledgement instead of silence.Long spoken instructionsSplit answers into steps and asked for confirmation.AI could not resolve the callEscalated to the correct team with a transcript summary.Hard-to-debug failuresConnected recordings, transcripts, logs, outcomes, and evaluations.
What the case reveals for AI Platform Engineers
Platform reuse created the schedule advantage. RAG, telephony, data, and the text agent already existed.
The model was one runtime component. Testing, deployment, tracing, evaluation, handoff, and rollback surrounded inference.
Quality existed at call level. STT, retrieval, generation, TTS, routing, and audio quality all affected the outcome.
Handoff was part of the architecture. Context and ownership had to survive the transfer.
AI behavior followed progressive delivery. Exposure moved from playground tests to after-hours calls and then production percentages.
Business metrics differed from model metrics. Resolution, escalation, repeat calls, and cost per outcome mattered more than tokens alone.
The public material does not describe every internal control. In a comparable production system, the remaining platform scope would normally include latency SLOs, end-to-end tracing, safe retries, provider fallback, PII controls, prompt-injection defenses, versioned prompts and knowledge, representative evaluation sets, and rollout stop conditions.
Bottom line
Fin Voice was a production system rather than a model endpoint. Intercom’s delivery speed came from existing platform capabilities; its production adoption came from workflow integration, controlled exposure, call-level evidence, and human handoff.
Sources
Peter Bar, Shipping an Enterprise Voice AI Agent in 100 Days, AI Engineer, July 2025.
Intercom, Deploy Fin Voice.
Intercom, Integrating Fin Voice using call forwarding.
Intercom, Use Fin Voice in phone workflows.
Intercom, Fin Voice FAQs.
Accuracy note
This article uses the public talk and Intercom documentation. Wider Fin metrics are not presented as Fin Voice traffic. The architecture is a teaching reconstruction, not a complete view of Intercom’s internal implementation.