Call queues that actually work — priority routing, agent skills, fallback destinations

Most FreePBX® call queues start as "add agents, set ring strategy, done" and become an unmaintainable knot of overflow destinations, weird priorities, and stuck calls within a year. This article covers the queue config patterns that scale — both in terms of call volume and operational sanity.

The four decisions to make first

• Ring strategy — how the queue picks which agent to ring.
• Agent membership — static (always members) vs dynamic (log in/out).
• Caller experience — music, position announcements, expected wait, opt-out paths.
• Overflow / fallback — what happens when no agent is available, when wait exceeds threshold, when the queue itself is closed.

Picking a ring strategy

FreePBX gives you ringall, leastrecent, fewestcalls, random, rrmemory, linear, wrandom. Practical recommendations:

• ringall — small teams (≤ 4 agents), no skill differentiation. Whichever phone picks up wins.
• rrmemory (round-robin with memory) — most teams. Distributes calls evenly without ringing every phone every time.
• linear — when you have a preferred "answer first" agent (a receptionist) and overflow agents below them in order.
• leastrecent / fewestcalls — equity- focused; useful for sales teams where call distribution matters for compensation.

Avoid ringall in larger teams. It increases abandoned-call rates because the call disappears as soon as one agent picks up, leaving the others wondering why their phone just stopped ringing.

Static vs dynamic agents

• Static — agents are always in the queue. Simple. Fine for small ops.
• Dynamic — agents log in/out via feature codes (default *45 to toggle queue membership). Useful when agents handle multiple queues, or when you want agents to log out for breaks without removing them from the config.

Dynamic gets unwieldy without a UCP (User Control Panel) or custom dashboard for agents to see their queue status. If you have one, dynamic is more flexible. If not, static is one less thing to forget.

The caller experience

• Music on hold — pick a category that's appropriate to the brand. Default Asterisk MoH is notoriously bland; uploading custom music takes a few minutes.
• Periodic announcements — "Your call is important to us" every 60+ seconds. Annoying if too frequent; reassuring at a sane cadence.
• Position announcement — "You are caller number 3 in queue." Tell the truth; estimated wait time is wrong about half the time and erodes trust.
• Estimated hold time — Asterisk will compute this from call history; accurate enough for general purposes. Don't combine with promises ("you'll be answered in 5 minutes" sets a target you can miss).
• Opt-out keypress — let callers press a key to leave voicemail rather than continuing to hold. Reduces abandon-and-callback churn.

Skills-based routing

FreePBX's stock queue module doesn't have first-class skills. Two ways to approximate:

• Multiple queues with different agent membership. "Sales Queue" with sales agents, "Support Queue" with support agents. IVR routes the caller to the right queue. Simple, works fine.
• Custom dialplan tagging callers. An IVR sets a channel variable (__SKILL=spanish) and the queue uses penalty rules to prefer matching agents. More flexible, more complex.

The first approach handles 90% of cases. Only use custom penalty rules when you have a genuinely matrixed team.

Overflow and fallback — the critical part

Calls that exceed the queue's wait limit, or that arrive when no agents are logged in, need somewhere to go. Patterns:

• Voicemail after N seconds — most common. FreePBX queue → Fail Destination → Voicemail. Make sure someone monitors the voicemail.
• After-hours route — different destination based on time of day. Time Conditions module → check time → route to queue or to after-hours voicemail.
• Escalation queue — primary queue overflows to a secondary queue with more agents. Use sparingly; it can hide capacity problems.
• External callback — caller's number is captured, a callback is scheduled. Requires custom scripting or a paid module.

Always set Max Wait and Service Level Threshold. Without them, calls can sit in queue forever, eating agent attention and distorting your CDR.

Common queue config mistakes

• Default Member Delay = 0. Means the queue rings agents instantly. Set to 1-2 seconds to give agents a moment to focus on the incoming pop.
• Ringall on a 12-person team. Every phone rings, customer hears one ring, conversation starts, eleven phones go quiet. Confusing for staff, slow to answer.
• No music, no announcements. Callers think they were disconnected after 30 seconds of dead air. Abandon rate spikes.
• Failure destination = "Terminate Call." You hang up on the customer. Almost always wrong; pick voicemail.
• Skip Busy Agents off. The queue rings agents who are already on a call. They hear the second call notify, get confused, miss it. Turn this on.

Monitoring queues in production

• FreePBX → Reports → Queue Stats shows per-queue metrics — calls answered, abandoned, average wait, average talk.
• For real-time monitoring, the UCP queue widget shows current calls in queue. Adequate for small ops.
• For larger ops, a dedicated wallboard (iSymphony, Queuemetrics) is worth the cost. Real-time visibility changes how agents work.

Tuning over time

After a queue is live, look at:

• Abandon rate. Above 10% means callers are leaving — usually wait time is too long, music is too unpleasant, or your IVR is misleading.
• Time to answer (TTA). Target depends on your service level. Below 30 seconds is good for most ops.
• Agent occupancy. Above 80% suggests understaffing. Below 40% suggests overstaffing or a misrouted queue.

The point is to look at metrics, not pile on configuration. Most queue problems are fixable by adjusting one or two parameters, not by adding more modules.