Route calls abandoned in the IVR
Some callers never get to talk to anyone. They dial in, sit through the IVR menu or a closed-message, and hang up before the call is ever routed to a queue. Left alone, these show up as calls with no agent, no reply, and nothing useful to say about what the caller wanted.
This recipe builds an automation that catches those calls the moment they close, and routes them to a dedicated team so someone can review, tag, or follow up — instead of letting them disappear into the inbox unnoticed.
What you’ll use
- Trigger:
Call abandoned in IVR— a Voice trigger that fires when a call closes after the caller hung up in the IVR/closed-message before ever reaching a queue. - Condition:
Reached a queue— a Yes/No condition you can add to any rule to filter on whether the call was routed to an agent queue.
You don’t strictly need the condition on a rule built from the Call abandoned in IVR trigger — the trigger itself only fires for calls that never reached a queue. But Reached a queue is also useful as a standalone condition on other voice-related rules, so it’s worth knowing both.
Before you start
- Admin permissions to edit automation rules
- A team set up to receive IVR-abandoned calls (for example, an “IVR” team) — see your Teams settings if you need to create one
- A read of What are Automations? if you’re new to the rule builder
Steps
-
Open the rules page. Go to Settings → Automation Rules → Manual Builder.
-
Start a new rule. Click New rule.
-
Pick the trigger. Choose Call abandoned in IVR from the trigger list (it’s grouped under Voice triggers). This fires once per call, right after the call closes, for any caller who hung up in the IVR or closed-message without being routed to a queue.
-
(Optional) Add the “Reached a queue” condition. If you want to reuse this same rule for broader voice logic, add a condition:
Field:Reached a queue
Operator:equals
Value:No
For a rule built purely on the Call abandoned in IVR trigger this is redundant — the trigger already guarantees the call never reached a queue — but it’s the condition to reach for whenever you need to branch on queue-routing outcome in other rules.
-
Add a branch. Leave the default Always branch in place — every call that fires this trigger is one you want to act on.
-
Add actions. Inside the branch, add the actions you want, for example:
Assign to team → choose your IVR team, so someone reviews the drop-off.
Add tag → apply a tag likeivr-abandonedfor reporting. -
Name and save. Give the rule a name like “Route: IVR-abandoned calls” and click Save.
-
Enable it. Toggle the rule On.
How “Reached a queue” works
Reached a queue reflects whether the current call was ever routed to an agent queue — not whether some earlier call on the same conversation reached one. A caller who calls back and reopens an existing conversation, then abandons again in the IVR, still evaluates as “No” for the new call, so the rule won’t miss repeat abandons just because the conversation has history.
This also means the condition covers a deliberately broad population by design: callers who hang up on a closed-message outside business hours, and callers who exit partway through an AI voice agent flow, both count as never having reached a queue, alongside classic “hung up in the menu” abandons.
Verify it worked
Place (or simulate) a test call that enters your IVR and hangs up before selecting a queue-routing option. Within a few seconds the call’s conversation should pick up the assignment and tag from your rule. Check the Manual Executions tab on the rules page, filtered to your rule’s name, to confirm the fire and see the actions that ran.
Troubleshooting
-
Symptom: The rule doesn’t fire at all. Fix: Confirm the rule is enabled and that the trigger is Call abandoned in IVR, not a general call-ended trigger — this trigger only fires for calls that closed without reaching a queue.
-
Symptom: A repeat caller who abandoned in the IVR again didn’t get routed. Fix: This shouldn’t happen —
Reached a queueis evaluated per call, not per conversation history. If you’re seeing it, check whether a different rule with a higher priority matched first, or check Manual Executions for the actual condition values evaluated on that run. -
Symptom: You added a
Reached a queuecondition but saving the rule is blocked. Fix: The condition requires a value (YesorNo) to be selected — the builder won’t let you save it empty.