A custom IVR (interactive voice response) system is your customers’ first contact with your organization by phone. Done poorly, it’s a maze of menus that makes people hang up. Done well, it recognizes the caller, understands what they need and routes them to the right resource, or simply gives them the answer. Voxivra designs dynamic IVR systems powered by your data and built on open technologies such as Asterisk.
What sets a dynamic IVR apart from a traditional one
| Traditional IVR | Dynamic custom IVR |
|---|---|
| Same menu tree for everyone | Flow adapted to the caller and their history |
| Keypad only | DTMF and speech recognition combined |
| Static routing | Data-driven routing (customer status, open case, language, priority) |
| Changes are slow and costly | Hours, prompts and rules easy to adjust |
| Little visibility | Per-step stats, hang-ups, transfers |
A concrete example: a customer with an order in progress hears its status right away; a patient with an appointment tomorrow is offered to confirm it; a priority caller goes straight to a dedicated team without navigating menus.
Use cases
- Multi-site front door: routing by region, language or location, with each site’s own hours.
- Identification and authentication: account number entry, PIN or code verification before transfer or self-service.
- Self-service: balances, order status, hours, outage updates.
- Payments by phone: DTMF entry kept away from the agent to limit exposure of card data. Our secure payment voicebot case study shows this kind of flow.
- Emergency handling: incident messages that can be switched on in seconds, exception routing.
The public sector and contact centers are among the environments where a dynamic IVR makes the biggest difference, given the volume and variety of requests.
How Voxivra builds an IVR
Asterisk, AGI and ARI
We’ve been building on Asterisk (standalone or with FreePBX) since its early days. IVR logic lives in the dialplan, extended with AGI scripts for decisions that need external data: a CRM lookup, a business-hours check, a priority score. For richer or asynchronous flows, we use ARI, which gives an application full control over the call. See our Asterisk AGI expertise page.
DTMF and speech recognition
DTMF is handled natively by Asterisk. For speech, we integrate a speech-to-text (STT) engine and, where needed, a natural language understanding (NLU) layer so callers can answer naturally instead of matching strict keywords. Prompts can be studio-recorded or generated with neural text-to-speech, which makes updates and dynamic data (amounts, dates) much easier.
Data and routing
The IVR queries your systems in real time through APIs or databases: CRM, ERP, scheduling, ticketing. The result determines the flow and the destination. On transfer, the information already collected is passed to the agent (customer record, call reason), so callers aren’t asked twice.
Reliability
An IVR is a critical service: we design fallback behavior for when an API doesn’t respond, call monitoring and, where needed, a redundant architecture.
IVR design principles we apply
Technology rarely makes or breaks an IVR; call flow design does. A few rules we follow on every project:
- Keep it shallow. Two levels of menus at most for the common paths, with the most frequent requests offered first, based on real call data rather than the org chart.
- Say the action, then the key. “To check an order, press 1” is easier to follow than the reverse.
- Recognize before asking. If the calling number matches a customer, skip the questions you can already answer.
- Make the human option visible. Hiding the operator option increases frustration and repeat calls; offering it clearly, with an estimated wait time, often reduces them.
- Handle silence and errors. No input, invalid input and timeouts each have a short, helpful reprompt before a fallback.
- Write prompts for the ear. Short sentences, consistent wording, no marketing message before the menu.
- Measure every node. Per-step drop-offs and transfers show exactly where callers get stuck.
When an existing IVR is the problem, a redesign often starts by mapping the current tree against actual call reasons. Our guide to modernizing a legacy IVR walks through that process.
How a project runs
- Audit: review of the current IVR, call statistics, drop-off points and the systems to integrate.
- Design: simplified call flow, prompt scripts, routing rules, error handling, DTMF or speech at each step.
- Build: dialplan, AGI scripts or ARI application, integrations, prompts.
- Test and monitor: every path tested, load testing, a planned zero-downtime cutover, then tracking of hang-ups and transfers per step.
What to expect and prerequisites
A new IVR usually reduces misrouted calls and unnecessary transfers, but the gain depends mostly on design quality: fewer levels, clear choices and smart use of available data. If you’re replacing an existing system, a phased migration keeps risk low.
Useful prerequisites:
- statistics or logs from your current IVR;
- access to your PBX or SIP trunks;
- APIs or data access needed for routing;
- an up-to-date list of teams, queues and hours.