Conversational IVR is an interactive voice response system that lets callers describe what they need in natural language. It interprets the request, asks for missing details, and either handles an allowed task or routes the call to a person. For teams with an existing phone system, the migration depends on call routing, busy handling, and human handoffs as much as the conversation.
How conversational IVR differs from phone menus
Interactive voice response (IVR) is the automated part of a phone call that collects input and guides the caller through a service or routing flow. Conversational IVR changes that input from a sequence of menu choices to a description of the caller's problem.
A caller might say, “My replacement order hasn't arrived.” The system can ask whether they need delivery information or help with a missing shipment, then follow the appropriate workflow. That workflow still needs a defined destination, an allowed action, and an exit when the system cannot help.
| Approach | Caller input | Typical flow | Main design responsibility |
|---|---|---|---|
| Keypad menu | Digits sent as dual-tone multi-frequency (DTMF) signals | Select an option at each menu level | Keep branches clear and destinations reachable |
| Constrained speech menu | A supported word or phrase, such as “billing” | Match speech to a menu choice | Define accepted phrases and recovery prompts |
| Conversational IVR | A request in the caller's own words | Interpret intent, clarify, then act or route | Bound supported requests, actions, and handoffs |
These are interaction patterns, not strict generations of technology. Older speech systems can support more than command recognition. Voice Extensible Markup Language (VoiceXML) supports speech, keypad input, and conversations in which the caller can supply several pieces of information together, as defined in the VoiceXML standard. Speech alone does not make a flow conversational.
An AI voice agent can implement the conversational layer. Whether it only routes calls or also completes tasks depends on the workflow and integrations you build. “AI IVR” does not imply unrestricted access to business systems or the replacement of your contact-center platform.
Put the agent in front of the queues you already run
A private branch exchange (PBX) is the system that manages an organization's telephone calls. A contact-center platform adds capabilities such as queues and operator workflows. A conversational front door can sit ahead of those existing destinations while the platform continues to own its routing and queue operations.
A bounded migration follows this path:
- The caller reaches the existing business number.
- Your PBX or contact-center routing selects the calls that enter the conversational flow.
- The live call connects to the voice agent.
- The agent handles an allowed request or initiates a handoff to a destination you have configured.
- Calls outside the pilot, or calls that cannot enter it, follow a defined route in your existing system.
Session Initiation Protocol (SIP) supplies signaling for connecting telephone sessions. A SIP uniform resource identifier (URI) is a call address. For a SIP-based integration, the existing platform needs a way to transfer or bridge the live call to that address. The SIP trunking guide explains the surrounding telephony architecture.
Separate the conversation's decision from the phone system's routing policy. “This caller needs billing” is an intent decision. Which billing destination is open, where overflow goes, and how the caller reaches a person are routing decisions with their own owners.
That division also makes rollback smaller. You can remove the conversational route from the selected traffic without redesigning every queue.
Define peak-load behavior before changing the entry route
A voice agent that can hold a good conversation still needs a path for calls it cannot accept. Peak planning starts with the caller's experience at that boundary.
Write a route for each distinct situation:
- The agent cannot accept the incoming call. The system that receives the call first needs an alternative destination or treatment, such as the existing menu or a staffed queue.
- The agent accepts the call but cannot complete the request. The conversation needs an explicit handoff or another defined outcome.
- The human destination is busy or does not answer. The transfer flow needs its own failure behavior and caller messaging.
These events happen at different points. Increasing agent capacity does not determine what happens when a human destination is unavailable. A transfer rule does not determine how the PBX handles a rejected incoming connection.
For each path, assign an owner, a destination, and the message the caller hears. Include after-hours routing and a destination that is itself unavailable. Avoid a loop in which the alternative route sends the caller straight back to the same agent entry point.
Treat human handoff as a call path and a context path
A warm transfer briefs the receiving person before the caller joins. A cold transfer connects directly without that spoken briefing. Warm handoffs fit requests where the person needs to understand what has already happened. Direct routing can fit a simple department selection.
Context needs a separate delivery plan. A working audio connection does not establish that an operator can see the transcript, recording, or case information.
Define a compact handoff contract:
- The caller's stated reason for calling.
- Relevant details already collected and anything still missing.
- Actions attempted and their actual results.
- The help the caller now needs.
- The destination responsible for the next step.
For example, an order-status request and a missing-order complaint may belong to different workflows. A useful briefing distinguishes them and states whether any lookup succeeded. It should not turn an unsuccessful lookup into a claim that the order was found.
A spoken briefing, a written summary, a transcript, and a recording serve different purposes. Specify which must reach the receiving person, through which integration, and at what point. Recording a transfer does not automatically deliver its context to the operator's screen.
Keep “I want to speak to a person” as an explicit route. The call escalation playbook covers the operational side of deciding when a person should take over.
Keep keypad input as an intentional route
Conversational input and keypad input can coexist. A caller may prefer digits, need to enter a long identifier, or be unable to use speech effectively in that moment.
Define what each supported key does, where keypad input is accepted, and how the caller learns about it. A familiar key has no reliable meaning unless the flow actually maps it to a destination.
Keep a recovery path for silence, an unclear request, and a request outside the supported scope. Repeating the same open-ended question indefinitely is not a recovery policy. A clarification prompt needs a defined exit to keypad input or a person.
Keypad behavior also depends on how signals travel through the call path. Our DTMF guide explains that transport separately from the conversation's routing logic.
How a Dasha integration fits this architecture
With Dasha, the existing PBX, SIP provider, or contact-center platform can receive the call first. Our integration pattern is register, receive the SIP address, then bridge the live call. The existing system must be able to transfer or bridge a live call to a SIP URI.
The call registration flow returns the SIP destination for the registered call. Registration remains valid until its deadline, with a default of 10 minutes and a maximum of 24 hours. That window is registration validity, not a promised caller waiting time.
When your organization has no free line for the call, we respond with SIP 486 Busy Here. What happens next belongs to your PBX or provider's routing. Sending that call to an existing menu or another destination requires your own route; the response does not establish a Dasha queue or automatic forwarding behavior.
Our SIP credential configuration supports User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and Transport Layer Security (TLS) transports. Transport selection and the ability to bridge the live call are separate parts of the integration.
Our human transfer options include warm, cold, and webhook-routed transfers. With webhook routing, your endpoint decides the destination at transfer time. During a warm transfer, recording can continue and speech recognition can stay active when their respective options are enabled. Those options do not by themselves send a transcript or recording into your contact-center system.
There are no per-line fees, and we increase limits at no extra cost. Calls are billed per second with no minimum call length. The pricing details belong in the operating-cost model alongside the telephony and integration work you retain.
This is an integration path for a technical team keeping its phone system. It does not make Dasha a replacement for the PBX or contact-center platform.
Roll out one call segment with explicit acceptance criteria
Start with a queue, a call reason, or a defined share of traffic. The pilot should have a clear boundary and a route back to the previous flow.
Establish the baseline and supported scope
Record the existing caller journey for the selected segment: menu steps, destinations, common reasons for transfer, and where callers abandon. Define the requests the agent may handle and those that must go to people.
For each supported request, specify the information required, the permitted outcome, and the next step when the request cannot be completed. A general invitation to “help customers” is too broad to serve as an acceptance criterion.
Cover failure paths in the acceptance run
The pre-pilot run should include an accepted call, a busy response at entry, unclear speech, keypad input, a human request, a successful handoff, and an unavailable human destination. Include calls that fall outside the selected segment so the existing route remains intact.
Acceptance means the intended caller treatment occurs on every defined path. It also means the receiving person gets the required briefing or context through the integration you chose. A successful connection alone is insufficient.
Measure the whole caller journey
Use the same definitions for the baseline and pilot:
- Requests resolved: requests with evidence of the defined completed outcome. A call ending without a transfer is not enough.
- Transfer rate: calls handed off relative to the calls entering the selected flow. Retain the reason for transfer.
- Abandonment: callers who leave before the intended service or human connection. Keep the measurement boundary consistent across both routes.
- Average wait time: time spent waiting for a person, reported alongside time spent in the conversational flow. Moving waiting into a different stage should remain visible.
The average wait time guide covers queue measurement in more detail. Segment results by call reason and destination so a changed traffic mix does not masquerade as an improvement.
Set rollback criteria before widening traffic
Define which failures stop expansion, who can restore the previous route, and how that routing change is made. Review unresolved requests and handoffs with the people receiving those calls.
Expand only when the selected segment meets its acceptance criteria. Add new call reasons deliberately, with their own allowed outcomes and exits. Keep the keypad and human routes available wherever they remain part of the service design.
Frequently asked questions
Is conversational IVR the same as an AI phone agent?
They overlap. Conversational IVR describes the natural-language service or routing flow on a phone call. An AI phone agent can provide that flow and may also complete tasks through integrations. The supported actions depend on its configured scope.
Does conversational IVR replace my existing IVR or PBX?
It can replace a menu interaction while leaving the PBX, queues, and operator environment in place. It can also cover only selected calls while the existing menu serves the rest. The integration determines which system owns each route.
Can callers still press keys?
Yes, a conversational flow can retain keypad routes. Each key needs an explicit function and a supported signal path. Natural-language routing does not automatically supply keypad behavior.
What happens when no line is free on Dasha?
We respond with SIP 486 Busy Here. Your PBX or provider controls the next action. An alternative destination must be part of your routing; do not assume the call will queue or forward automatically.
Will a person receive the conversation history after transfer?
Only through the context-delivery path you implement. A warm transfer supplies a spoken briefing. Recording and speech recognition can continue during a Dasha warm transfer when enabled, but delivering those artifacts to a contact-center interface is a separate integration responsibility.
For a PBX-first evaluation, start with our call registration flow and connect a bounded call segment to Dasha while retaining your existing routing.
