Get started

IVR replacement

A traditional IVR asks callers to translate their problem into a menu: press one for sales, press two for support, press three for billing. That works when every request fits a stable department tree. It works less well when callers do not know who owns the issue, when the menu changes, or when several branches send people to the same queue without useful context.

An AI phone agent can replace that first menu with a conversation. The caller explains the reason for calling in ordinary words. The agent asks the minimum follow-up questions defined for that intent, answers a bounded question from approved material, or routes the call under explicit rules. The value is not that every menu disappears. It is that the business can design the call flow around the caller's goal and give the next person the context already collected.

A concrete replacement flow

Suppose a customer calls a company that previously offered separate menu branches for deliveries, invoices, and technical support.

Agent: Thank you for calling. I am an AI phone assistant. Briefly, what can I help with?

Caller: Our delivery arrived, but the invoice has a different quantity.

The caller has described two topics. The prompt tells the agent to identify which one needs action first rather than choosing a department from a single keyword.

Agent: I can record both details. Is the delivery itself complete, and are you calling to correct the invoice?

Caller: The boxes are all here. I need the invoice corrected before our payment run.

The agent collects the invoice reference, customer name, callback details, and deadline. It uses the approved billing route and attempts the designated recipient. With attended warm transfer, the caller waits while the agent privately explains that the delivery is complete and the mismatch is on the invoice. The recipient accepts and begins with the relevant facts instead of sending the caller through another menu.

If the billing team does not answer, the agent returns to the caller, explains the outcome, and creates the defined follow-up record. If the request were simply for published payment instructions, the agent could search the approved knowledge base and answer without a transfer.

How to set it up on ThunderPhone

Begin by inventorying the current menu branches. For each one, write down the caller's actual intent, the fields a recipient needs, the approved self-service answer, the destination, and the fallback. Remove branches that reflect the organization chart rather than a meaningful caller choice.

Turn that inventory into a prompt outline:

  • open with a short greeting and invite the caller to describe the request;
  • recognize the supported intents and ask only the follow-up questions attached to each;
  • clarify overlapping or multiple intents before taking an action;
  • use only approved knowledge for routine answers;
  • define urgent, restricted, and human-only paths;
  • state when to use cold transfer or attended warm transfer; and
  • preserve the collected context when a transfer fails.

Attach current hours, policies, department descriptions, and caller-safe instructions through ThunderPhone's knowledge base. Supported uploads include text, Markdown, CSV, PDF, and DOCX, with documents scoped per agent. The agent can search those sources during a call. Do not attach internal material that should never be repeated to a caller.

Connect the systems that make a route useful. HubSpot or Salesforce can hold an allowed customer or follow-up record. Slack can notify an on-call team. Google Sheets can support a simple reviewed routing log. For a custom directory, account system, or ticket queue, expose only the required lookups and actions through REST, webhooks, or an approved remote Zapier MCP server.

Choose the number and transfer behavior. Inbound demo U.S. numbers can support testing but are not production numbers. ThunderPhone supports cold transfer and attended warm transfer. Warm transfer requires an eligible production number that can place an outbound SIP leg; demo numbers and browser calls are limited to cold transfer. The warm-transfer flow privately briefs the recipient and returns to the caller if the recipient declines, does not answer, or reaches voicemail.

Test vague requests, slang, silence, multiple intents, unsupported requests, closed departments, protected accounts, urgent phrases, and unavailable recipients. Reusable scenarios, graded call logs, regression suites, and pass-rate gates can check whether a prompt change breaks a route before it reaches live traffic.

What to measure

Track whether the new conversation sends callers to a better outcome:

  • supported intents identified with all required fields;
  • routine questions answered from approved material;
  • transfers accepted by the first destination;
  • calls transferred again after an incorrect route;
  • follow-up records created after failed transfers;
  • callers sent to a human because the intent stayed ambiguous; and
  • reviewed calls with an unsupported answer or a missed escalation.

Compare those results with call screening and routing and FAQ answering. The replacement should reduce avoidable work without making human access harder.

Honest limits

Conversation does not remove the need for structure. The agent cannot verify that a caller is truthful, decide sensitive access rights, or infer a safe destination when the rules are incomplete. Keep human paths for emergencies, threats, suspected fraud, accessibility needs the flow does not serve, and requests involving protected information.

Some organizations should retain a short menu for a mandatory choice or a reliable fallback. An IVR replacement is successful when callers reach the right next step with context, not when every touch-tone option is removed.

Create your ThunderPhone account to configure and test an IVR replacement.