Design a Customer Support Voice IVR

Problem statement

Design a customer support voice IVR platform where callers dial a support number, navigate by voice or keypad, authenticate, get simple issues resolved automatically, or are transferred to a live agent with full context. The platform must terminate PSTN calls, play prompts, detect DTMF digits and streaming speech, run dialog logic, look up account data mid-call, record audio under compliance rules, route to skilled agents with queue management, and produce an auditable call record.

This is not a request/response web backend with a voice skin. A phone call is a long-lived, stateful, bidirectional real-time media session. If a web request times out, the client retries. If a media path stalls for 400 ms, the caller hears dead air, assumes the call dropped, and hangs up. If a digit is lost, the caller enters the wrong menu and the authentication flow breaks. Therefore the design separates four concerns with different failure semantics: telephony and media transport, dialog automation, contact-center routing, and integration with systems of record.

Why the problem is distinctive

A chatbot can take three seconds to answer. Voice cannot. ITU-T G.114 recommends one-way voice latency below 150 ms for acceptable conversation quality, and users tolerate only about one second of silence after speaking before they assume the system failed. Every dialog turn has a hard budget: capture audio, stream it to speech recognition, finalize the utterance, run dialog logic, perform any account lookup, synthesize or select the next prompt, and start playback, ideally within 1.5 to 2 seconds.

The second distinction is state. A call lasts minutes and crosses media servers, speech services, backend APIs, queues, and agent desktops. There is no cheap retry for a live call: you cannot replay the last 40 seconds of a conversation after a crash. The architecture must keep per-call state journalable, make degradation deterministic (speech fails, fall back to DTMF; account API fails, offer queue or callback), and treat call drops as incidents with evidence.

The third distinction is compliance and trust. Callers may enter card numbers, hear recorded consent statements, and expect that agents see only what their role permits. Payment capture through DTMF must pause recording and mask digits per PCI-DSS. Recordings have consent and retention rules that vary by jurisdiction.

Public operating baseline versus design assumptions

Public evidence establishes the category at enormous scale. Genesys reports that more than 25 billion customer interactions per year run across its CX platform; these are company-reported figures. Microsoft completed its acquisition of Nuance, a foundational speech IVR vendor, for roughly $19.7 billion in 2022, which signals how central voice self-service remains. AWS describes Amazon Connect as the same cloud contact center used by Amazon's own customer service organization. Twilio reports hundreds of thousands of active customer accounts building on its communications APIs. These provide context, not our design targets.

For capacity planning, this answer explicitly assumes a large enterprise contact center: 300,000 inbound calls per day average, a 5x storm multiplier for outages and billing events, 40% IVR containment, 4,000 agents, and a design ceiling of 30,000 concurrent calls. Unless a number is tied to a citation or a standard, it is a stated design assumption, target, or budget.

The four architectural planes

1. Telephony and media plane: carrier interconnect, session border controllers, SIP signaling, RTP media, DTMF detection, recording, codecs, and media servers.
2. Dialog automation plane: prompt selection, streaming ASR, TTS, dialog state machine, intent matching, fallback policies, and backend data dips.
3. Contact-center routing plane: authentication context, skill-based routing, queues, agent state, screen pop, warm transfer, virtual hold, and callback.
4. Data and governance plane: call detail records, transcripts, recordings, flow versions, analytics, compliance retention, and fraud signals.

A strong interview answer keeps these planes separate. The media plane can degrade a region while the routing plane re-admits calls elsewhere. The dialog plane can lose cloud speech and fall back to DTMF menus without dropping the call. The data plane can lag without affecting any live audio path.