IVR navigation shouldn’t be the hard part

If you’ve built a voice agent that calls other businesses, you probably know the feeling. You spend weeks on the parts that matter: getting the agent to understand what it’s calling about, handle sensitive information properly, stay inside the compliance lines, and recover when the person on the other end goes off script.

Then you listen to the recordings, and a good chunk of the calls never got that far. The agent spent two minutes in a phone menu, picked the wrong option, and ended up nowhere. We ran into this constantly, so we started paying close attention to what actually goes wrong in there.

Phone trees are messier than they look

On paper a phone menu is a list: press 1 for this, press 2 for that. In practice every line has its own quirks. One opens with “In a few words, tell me why you’re calling” and won’t read you a single option until you’ve failed to answer twice. Another says “you could say something like, check my balance,” and an agent that takes that literally ends up somewhere strange.

Some levels only listen for keys and the next one only listens for speech. The department you actually need is three menus down, behind a name that has nothing to do with what you asked for. Some options quietly drop you into a general queue or ask for an account number you don’t have. And every so often the company changes the whole tree without telling anyone.

Each of these is easy to handle once you know it’s there. The hard part is knowing.

A better generic IVR node won’t save you

Most voice platforms give you some version of the same tool: an IVR node or a keypad tool, plus a prompt along the lines of “listen to the options and pick the best one.” Teams put real effort into tuning theirs. Better prompts, better models, retry logic, special cases for the numbers that caused trouble last month.

It helps for a while. The agent gets good at the lines you’ve tested. Then it calls a new one and you’re back to reading transcripts. Nobody built the node badly. A general approach is guessing at something specific, live, on every single call, and there are more strange phone trees out there than any prompt can anticipate.

What it costs when the call never starts

The frustrating thing about IVR failures is how quietly they happen. There’s no error. The call just never reaches a person, or it reaches the wrong one.

Each of those calls still costs you minutes and a retry. Worse, the work behind it doesn’t get done: the claim status nobody checked, the authorization nobody followed up on. Say your agent makes 10,000 calls a month and one in ten gets lost in a phone menu. That’s a thousand calls a month that never had a chance, before you count the engineering hours spent figuring out why.

Make the phone tree boring

Here’s what we kept coming back to: a phone tree isn’t a conversation. For any given number it has a fixed structure, with the same prompts and the same options leading to the same places. So you don’t have to figure it out on the fly. You can map it once, check it, and hand your agent the exact route before it dials: which key to press or what to say at each step, which sentence to wait for, what to try if that doesn’t work, and where the path ends up.

Same number, same route, every time. Your agent stops improvising its way through the menu and simply follows directions, which is exactly what you want from the most boring part of the call.

So your team can work on the interesting stuff

That’s what we’re building with TurnGraph. Before each call, one API request gives your agent the route for that number, either as structured steps or as plain instructions you can drop straight into a Vapi, Retell or Bland agent, or whatever you’ve built yourself. Your agent gets to the right person, and your team gets to spend its time on the conversation that happens after, which is the part your customers actually care about. See how the API works.