How do I make my AI phone agent handle an emergency call differently from a quote request?

This page may contain affiliate links from which Blur Studio earns commissions.

A single linear script treats every caller the same, which is fine until it isn't. The moment you have callers with genuinely different urgency or needs, you need the call itself to branch, not just the agent's tone.

What are Agent Workflows?

Agent Workflows is ElevenLabs' visual builder for branching conversations. Instead of one script, you build a flow out of nodes (each a specific point in the conversation, sometimes called a subagent, which can change how the agent behaves at that step or override its configuration entirely) connected by edges, which are the rules that decide which node a call moves to next. The dashboard's visual graph editor is the recommended way to build this. Under the hood, the whole flow is stored as part of the agent's configuration, and can be pulled, edited and pushed as structured data through ElevenLabs' CLI or SDK, which matters if you want to version-control your call flow the way you would code, rather than only editing it by hand in the dashboard.

How do I set this up for emergency vs quote?

1. List your actual caller types honestly. For most trades businesses this is 3 or 4, not 10: an emergency, a quote request, an existing-job question, and everything else. A ready-made version for trades is described in AI receptionist for plumbers, HVAC and electricians.
2. Write a short, specific first question that reliably sorts a caller into one of those types ("is this an emergency, or can it wait for a scheduled visit?" works better than something vague). The same idea is used in how to qualify a lead with AI before it reaches your team.
3. Build one node per path in the Workflow tab, and connect them with edges keyed off the caller's answer to that first question.
4. Make the emergency path short: collect the minimum (name, address, nature of the emergency) and transfer fast, rather than asking everything you'd ask a quote caller. For overnight calls, see how to take messages and sort urgent calls overnight.
5. Test each path separately with a real call, not just by reading the flow in the dashboard. After launch, you can see where callers drop off in the flow.

A sorting question that actually works

"Is this an emergency?" sounds clear but isn't, because plenty of callers aren't sure how to classify their own situation and will say no to avoid sounding dramatic. A more reliable opener describes the actual consequence: "is water actively leaking right now, or can this wait for a scheduled visit?" gives the caller something concrete to answer rather than asking them to self-diagnose urgency. Write your sorting question around the specific, visible signs of your real emergencies, not the word "emergency" itself.

A second example: HVAC, no-heat emergency vs routine maintenance

A plumbing burst-pipe split is the easy case because the urgency is visually obvious. HVAC is trickier because "no heat" can mean anything from a genuine emergency (an elderly resident, freezing temperatures, pipes at risk) to a mildly annoying but survivable inconvenience (a mild day, a backup space heater on hand). A workable sorting question for this business: "is anyone in the home elderly, very young, or medically vulnerable, and is it currently below freezing where you are?" Either a yes to the first part or a genuinely low outdoor temperature routes to the fast emergency path; everything else goes to a scheduling path that still books within 24 to 48 hours but doesn't jump the queue. The point of the second example is that your sorting question has to match your actual risk profile, not just copy a template from a different trade. A roofing company's version of this split might hinge on active water intrusion versus a cosmetic issue; a locksmith's might hinge on whether the caller is locked out right now versus planning ahead for a future rekey. Write the question around what actually makes a call urgent for your specific business, not a generic severity scale.

What happens when more than one emergency calls at once

Routing solves which path a caller takes, not what happens if your emergency path is already handling someone else when a second urgent call comes in. ElevenLabs added call queueing with custom hold audio to the platform in mid-September 2026, which is the piece that actually matters here: a second emergency caller doesn't get a busy signal or dumped straight to voicemail, they get held with audio you've chosen (ideally something that says plainly that they're in a queue and roughly how long the wait is, not generic hold music) while the first call finishes or gets transferred. Without this, a genuinely good routing setup can still fail at the one moment it matters most, a bad night with two burst pipes at once, because the system was only ever tested with one caller in mind.

The mistake worth avoiding

The natural temptation once you have a visual flow builder is to keep adding branches: a path for every edge case you can think of. Don't. A deep, complicated tree is exactly what makes callers hang up on traditional phone menus, and a voice agent isn't immune to the same problem if you give it too many forks. Three or four clear paths, each short, beats ten narrow ones that take longer to navigate than just talking to a person would.

Workflows vs a traditional "press 1 for..." phone menu

It's worth being honest about what's actually new here versus what a touch-tone IVR already did decades ago: splitting callers into a few paths based on an early answer isn't new. What's different is the sorting mechanism itself. A phone tree makes the caller translate their actual problem into a menu option that may not match it ("press 1 for billing, press 2 for support" forces a burst pipe into whichever option sounds closest), while a spoken sorting question lets the caller describe the actual situation in their own words and the agent interprets it. The tradeoff: a touch-tone menu is trivially predictable and never misclassifies based on how someone phrases something, while a voice agent's interpretation can occasionally get a genuinely ambiguous answer wrong, which is exactly why testing each path with real, slightly awkward phrasings (not just the clean example in your head) matters before you rely on this for something as consequential as an emergency.

Tracking which path calls actually took

Once routing is live, you want to know whether it's actually working, not just assume it is because it tested fine once. Agent Workflows stores which node a call passed through as part of that call's record, so you can pull a report of how many calls went down the emergency path versus the quote path versus anything-else, and spot-check a sample of each. This is also where ElevenLabs' broader platform changes from October 2026 are worth knowing about: structured procedures (the underlying definitions a workflow runs on) now compile automatically every time you save a change in the dashboard, and deployment history became queryable, meaning you can see exactly what the routing logic looked like at any point in the past, not just what it looks like today. If a routing change you made last month is suddenly sending more calls down the wrong path than it used to, that history is how you'd actually find the specific change that caused it, rather than guessing.

Who this is worth building for

If you genuinely get a mix of urgent and non-urgent calls and currently treat them the same, this is worth the setup time, since misrouting an emergency has a real cost, both in lost trust and, in trades like plumbing or HVAC, in actual property damage from a delayed response. If almost every call you take is the same type of request, a single well-written agent without branching logic is simpler to build and maintain, and you don't need Workflows yet. There's also a middle case worth naming honestly: a business that gets occasional emergencies, maybe one or two a month, where the setup and testing time for a dedicated branch may cost more in your attention than it saves, versus just training staff to listen for the handful of phrases that mean "this is urgent" and handle it manually when it comes up. Routing earns its complexity at volume, not at the first emergency call you ever get.

How I'd approach this

Designing the branching logic itself is usually straightforward once the caller types are clearly named. Where it gets harder is making each path actually do something useful once it's been chosen, like booking directly into your calendar or transferring cleanly to a person, which is where I come in if you want this built properly rather than left as a flowchart that doesn't connect to anything real. See ElevenLabs' agent plans to start building.

Need help finishing or building this?

If you've sketched the flow but it isn't connected to your calendar, CRM or phone system yet, or you want the whole thing built and tested properly, I can take it from there.