TL;DR: Call queue software holds inbound callers in line and hands them to the next available agent, but the number it shows you is not the demand you faced. Teletraffic standards draw the line precisely. Traffic carried is the traffic served by a pool of resources. Traffic offered is the traffic that would be carried by an infinitely large pool of resources. Your queue report is carried traffic by construction, and it is wrong in both directions at once. It is inflated by repeat attempts, because one frustrated caller who redials four times looks like four callers. It is deflated by suppressed traffic, the demand that disappears after days of congestion because people stop trying, and the ITU says outright that no accepted method for estimating it exists. So when you add two agents and call volume rises, that is not growth. That is demand that was always there. The same standards split a blocked call attempt, rejected for lack of resources, from an abandoned call attempt, aborted by the calling user, and real queue software keeps those apart in the data. Asterisk, the open-source reference implementation, ends a queued call with one of TIMEOUT, FULL, JOINEMPTY, LEAVEEMPTY, JOINUNAVAIL, LEAVEUNAVAIL, CONTINUE or WITHDRAW, sets ABANDONED separately, and records QUEUEWAIT in seconds and milliseconds. A dashboard that rolls all of that into one “missed calls” tile cannot tell you whether you are short staffed or misconfigured. Size on peak days, not averages. The ITU method records a daily peak, then defines normal load as the fourth highest daily peak of the month and high load as the second highest. Kixie’s inbound call queues announce queue position and estimated wait time, offer voicemail or a callback instead of holding, and expose an Outside Queue Hours Action for calls that arrive after hours, with no cap on how many queues, IVRs, or ring groups an account runs.
Here is the usual sequence. Call volume climbs, people complain about hold times, someone buys call queue software, and the hold music problem goes away. Six weeks later the complaints are back in a different shape, and now the report says abandons are up while average wait looks perfectly fine. How are both of those true at the same time?
Both are true because the queue did its job, which was to take an unmanaged pile of inbound calls and turn it into an ordered line with a clock running on every caller standing in it. That is a measuring instrument. It is not extra capacity.
The instrument is also biased, and the bias is documented. Telephone traffic has been measured and dimensioned under published international recommendations for decades, and those recommendations are blunt about what a carried-traffic measurement can and cannot tell you. Most buyer guides for this category never mention it, which is the gap this one covers, because it changes which number you put on the wall and which day you staff against.
What Call Queue Software Actually Does
Call queue software does three jobs. It holds a caller when nobody is free. It decides which agent gets the call when somebody frees up. It writes down what happened.
The first job is the one buyers shop for. The second is the one vendors demo. The third is the one that determines whether you can run the team six months later, and it is almost never tested before purchase.
Mechanically the path is short. A call arrives at a business number or drops out of a menu, a routing rule puts it into a specific queue, and the queue holds the caller while it plays something and offers a way out if the wait runs long. When an agent becomes available, the distribution logic picks who gets the call. Kixie’s inbound call queues distribute queued calls to the next available agent in the order received, announce queue position and estimated wait time, and let the caller leave a voicemail or request a callback instead of holding.
So what can a queue not do? It cannot answer a call. Only a staffed agent does that, which means every queue feature is a way of managing the gap between arrival and answer rather than a way of closing it.
So what are you actually buying? You are not buying a fix for too many calls. You are buying ordering, visibility, and a set of escape hatches, plus a record of what the line actually looked like. Decide what you need from the record first. The rest of the feature list follows from that.
Why the Queue Report Undercounts Real Demand
Start with vocabulary, because the industry uses two words loosely and the standards do not.

The ITU-T recommendation on terms and definitions of traffic engineering defines traffic carried as the traffic served by a pool of resources, and it defines traffic offered as the traffic that would be carried by an infinitely large pool of resources. Read that second definition again. Offered traffic is a counterfactual, which is to say it is the volume you would have handled if you had unlimited agents and nobody ever waited.
Your queue software measures what it served. By definition it cannot measure what an infinite team would have served, so everything on the dashboard is carried traffic plus whatever lost attempts the system happened to witness.
That gap has a name. The ITU-T recommendation on estimating traffic offered in the network addresses it directly in its opening clause. When high levels of congestion persist for a lengthy period of many days, some customers avoid calling during the congested period of each day. The recommendation calls that missing component suppressed traffic. It says suppressed traffic should be taken into account in planning, because offered traffic will increase once the equipment is augmented. Then it adds the sentence that matters most: at present, suitable algorithms for estimating suppressed traffic have not been defined.
An international standards body, working on the best measured telephone network data available, says there is no accepted way to count the people who gave up on you. Your contact center dashboard is not going to manage it either.
This has a direct operational consequence, and it is the one managers get wrong. You add two agents in March. April volume is up eleven percent. The quarterly review calls that demand growth, and the team gets staffed against a trend that does not exist. So what actually changed in March? The queue stopped punishing callers, and the people who had quietly stopped calling came back. That is suppressed traffic returning, exactly as the recommendation predicts when capacity is augmented.
So what do you do with a number you cannot compute? You stop treating the absence of calls as the absence of demand. Two practical moves. First, watch volume for two full measurement cycles after any capacity change and refuse to label the first rise as growth. Second, find the demand signal that lives outside the queue. Web sessions on the contact page, inbound texts, form fills, and repeat callers in the CRM are all evidence of people who wanted you and did not get through. Those are imperfect. They are still better than a number that is structurally incapable of seeing the problem.
Why the Same Queue Report Also Overcounts It
Now the other direction, which is less intuitive and easier to fix.
The same recommendation on estimating offered traffic warns that congestion measurements are distorted by the customer’s repeat attempts, and by automatic repeat attempts generated by other components in the network. Its traffic model is explicit about the loop. First attempts split into calls that are carried and calls that are lost, and lost calls split again into attempts that are repeated and attempts that are abandoned. Ineffective calls split the same way.
Translate that to a Tuesday morning. A caller waits ninety seconds, hangs up, redials, waits again, hangs up again, then calls back after lunch and gets through. Your queue logs four arrivals, three abandons, and one answered call. One person. One unmet need.
Every one of those numbers is defensible and together they tell the wrong story. Arrivals look like demand and are not. The abandon rate looks like three failures and is one. Worse, retriers cluster right after a bad stretch, so your arrival curve shows a spike exactly where the real problem was a capacity trough twenty minutes earlier.
So what do you do about it? The fix is boring and it works. Count unique callers per window, not call legs. Any queue platform that writes caller ID into the record can do this, and most reporting layers will group by number if you ask them to. Run both series side by side for a month. The gap between arrivals and unique callers is your retry load, and it is the cleanest congestion signal you own, because it rises before service level falls.
One caveat worth keeping. Unique callers undercounts genuine repeat business, so do not use it for revenue questions, and use it for capacity questions only. That is the distinction that keeps the number honest.
Size the Call Queue on Peak Days Not Monthly Averages
Here is where the standards stop describing your problem and start handing you a rule.
The ITU-T recommendation on traffic intensity measurement principles covers, in its own words, traffic systems with and without waiting room, which is to say queueing. It describes how to measure load and how to turn that measurement into a dimensioning number, and two parts of it apply directly to a call queue.
The first is the read-out period, which is simply the window you average over, and the recommendation sets up a genuine tension inside that choice. Longer windows converge on the true average and give you a narrow confidence interval. But a window that is too long stops being approximately stationary, and a measurement that spans a quiet morning and a brutal afternoon describes neither.
So why does your report say average wait is fine while your callers insist it is not? Most queue dashboards default to a daily or weekly roll-up, and that is the long end of this tension. Pick an interval short enough that load inside it is roughly flat. Fifteen or thirty minutes usually holds for an inbound sales line. Then look at the distribution across intervals, never the single daily number.
The second part is the dimensioning rule, and it is refreshingly concrete. The recommended daily method is the Daily Peak Period approach: measure traffic intensity across consecutive read-out periods all day, and record the single highest one as that day’s peak. Do that every day for a month. Then order the chosen days from lowest to highest daily peak.
Normal load is the day with the fourth highest daily peak. High load is the day with the second highest.
That is the whole rule, and it is a better staffing target than anything your queue vendor will hand you. It throws away the single worst day, which is usually an outage or a product launch and should not drive permanent headcount, and it also throws away the entire bottom of the month, which is what a monthly average quietly staffs you for. You size for the fourth worst day and you check yourself against the second worst.
The recommendation also lets you narrow the day set to working days only, but it attaches a condition: do that only when you already know weekend load is lower. Measure before you assume. A support line for a consumer product often does not behave that way.
If you run this once, you will almost certainly find your coverage is built around a mean that no actual day resembles, so fix the schedule against the fourth highest peak and then watch the abandon split rather than the abandon rate. More on why that split is the real metric below.
How a Call Queue Differs From ACD, IVR, and Ring Groups
Four terms get used as if they were one product, when they are four different parts of the path, and buyers who blur them end up paying for a capability they already have.
A queue is the waiting room, which means it is the holding structure plus the rules for what happens while the caller waits and how they get out of the line.
Automatic call distribution is the decision logic that empties the waiting room. It answers one question. When an agent frees up, which waiting call goes to them, and which agent gets the next one? Longest idle, round robin, simultaneous ring, fixed order, and skills matching are all ACD strategies, not queue features. If you want the longer treatment, the breakdown of how ACD works in a contact center covers the distribution side on its own.
An IVR auto attendant sits in front of all of it, and it is the menu that decides which queue a caller belongs in. An IVR cannot hold anybody and does not distribute anything. It sorts.
Ring groups are the one people confuse with queues, and the difference is sharp. A ring group rings a set of phones, either together or in order, and if nobody picks up the call falls through to whatever you configured next. There is no waiting room. Nobody is held, nobody has a position, and there is no line to report on.
So which do you need? If calls arrive faster than your team answers them, and callers are willing to wait, you need a queue. If calls are sparse and the goal is just making sure somebody picks up, a ring group is simpler and you should not pay for queue reporting you will never open. Small teams with low volume usually need the second and buy the first.
Every Way a Call Queue Can End a Call
This is the section that changes how you read your own reports, and it needs a concrete implementation rather than a vendor brochure.

Asterisk is the open-source telephony platform that a large part of the industry has built on, and its queue application is documented down to the variable. When a call leaves a queue, it sets a status of TIMEOUT, FULL, JOINEMPTY, LEAVEEMPTY, JOINUNAVAIL, LEAVEUNAVAIL, CONTINUE, or WITHDRAW. It sets ABANDONED separately, as its own true-or-false flag, when no agent answered. It records QUEUEWAIT, the total seconds the caller spent waiting before reaching an agent, alongside a millisecond version, and it records ANSWEREDTIME, which is zero when the call was never answered.
Eight exit reasons, and they are not variations on a theme. What does each one actually tell you? Walk them.
- TIMEOUT means the caller waited the full configured time and the queue gave up on their behalf. That is a staffing result.
- FULL means the queue hit its configured capacity and refused entry. That is a limit you set, and it is usually set by accident.
- JOINEMPTY means the caller could not even enter, because no agents were in the queue when they arrived. Nobody was logged in. That is a schedule or adherence failure, not a volume failure.
- LEAVEEMPTY means the caller got in, then the last agent left and the system ejected them mid-wait.
- JOINUNAVAIL and LEAVEUNAVAIL are the same two cases where agents exist but none are reachable, which usually means devices are offline.
- CONTINUE means the caller pressed a key and chose to go somewhere else, typically voicemail or a callback.
- WITHDRAW means something pulled the call out deliberately.
The standards vocabulary separates these too. A blocked call attempt is defined as one rejected owing to a lack of resources, and an abandoned call attempt is defined as one aborted by the calling user. Those are two different definitions because they are two different failures with two different owners.
Now look at your dashboard. If it shows one tile called missed calls, it has collapsed a staffing problem, a capacity misconfiguration, a schedule gap, an offline device, and a caller who chose the callback option into a single number. Every one of those has a different fix and three of them are free to fix.
JOINEMPTY is the one worth hunting first. A caller who never entered the queue frequently does not appear in queue reports at all, because from the queue’s point of view there was no queued call. Teams find out when someone calls the main line at 8:05 in the morning, hears a hang-up, and mentions it in passing three weeks later.
So the buying question is not how many reports a platform ships. It is whether the platform preserves the exit reason per call and will show it to you split out rather than rolled into a single total. Ask that in the demo. Ask them to produce a report of calls that failed to enter a queue. If they cannot, you will be flying blind on the cheapest problem you have.
One more number from that same documentation deserves attention. The wait timer is recorded in both seconds and milliseconds, and it records the wait before connection. Average that across a day and it tells you almost nothing. Look at the distribution instead, and especially at the long tail, because the callers who abandon are concentrated there and they are invisible in a mean.
Call Queue Software Features That Change Rep Behavior
Feature lists in this category are long and mostly interchangeable. A shorter test: does the feature change what a caller does, what a rep does, or what a manager can inspect? If it changes none of those, it is decoration.
Position and estimated wait announcements. These change caller behavior, which is the point. A caller told they are fourth in line with a four minute wait makes a decision instead of guessing. Kixie’s inbound call queues announce both. Watch what happens to your abandon curve after you turn them on, because abandons often rise and that is not a failure, it is callers leaving earlier and on purpose rather than burning six minutes first.
Callback instead of hold. The strongest escape hatch in the category. It converts a wait into a scheduled outbound call and hands the time back to the caller, and Kixie lets a queued caller request a callback or leave a voicemail rather than holding. So what is the catch? A callback is a promise, and an unworked callback queue is worse than a long hold. Assign an owner before you enable it.
An explicit after-hours path. Calls arriving outside staffed hours are the most common source of silent failures, because they often never enter a queue and never show up in queue reporting. Kixie exposes an Outside Queue Hours Action that determines how those calls are handled, including sending them to voicemail or to a specific agent, and queue hours can be configured separately from general business hours. Set it deliberately. Then call your own main line at seven in the morning and at nine at night and listen to what happens.
Overflow and timeout rules. These decide what the queue does when it loses. A timeout with no defined destination is a hang-up, so define where a timed-out call lands and make it somewhere a human reviews every day.
Priority and queue position control. Real queue implementations let you insert a call at a specific position rather than the back of the line, which is how you give a renewal call or an enterprise account precedence without building a separate phone tree. Ask whether priority is per queue, per caller, or per routing rule, because those are very different capabilities sold under one word.
Agent availability controls. If a rep cannot go unavailable cleanly, they will solve it by not answering, and your JOINEMPTY and timeout counts will climb for reasons no report explains. Pausing should be one action and it should be visible to a manager.
Write-back to the CRM. This is the one that decides whether the queue is manageable six months out. If the queued call, its wait, its exit reason, and its outcome do not land on the customer record automatically, then every question about follow-up becomes an archaeology project. A queue that holds callers perfectly and records nothing has moved your problem rather than solved it.
Account structure matters less than vendors imply, but it has a floor. Kixie does not cap how many call queues, IVRs, or ring groups an account can run, which matters when you work out in month two that one queue was always three queues wearing a trench coat.
What to Ask Before You Buy Call Queue Software
Demos are built to show the happy path. A caller waits briefly, an agent answers, everyone nods. Ask for the unhappy ones instead.
- Show me a report of calls that never entered a queue because no agent was available. If that report does not exist, say so now.
- Can I see the exit reason per call, split out, rather than a single missed-calls total?
- Is the wait time stored per call, and can I see the distribution rather than the average?
- What happens to a call that arrives when every agent is logged out, and where does the record of it live?
- Can I set queue hours separately from business hours, and what is the configured action outside them?
- When a caller requests a callback, what creates the task, who owns it, and what happens if nobody works it?
- Does the queue write the call, its wait, its exit reason, and its outcome to the CRM record without a rep doing anything?
- Is queue capability included in the plan quoted, an add-on, or dependent on a separate service?
- How many queues, IVRs, and ring groups can the account run, and does that change by plan?
- Can I insert a call at a chosen position for priority accounts, and is that per queue or per rule?
Use your own call path as the demo script, not theirs. Hand them your actual menu, your actual hours, and your actual overflow rule, and ask them to build it live, because the gap between what they show and what you asked for is the real answer.
A Call Queue Rollout Checklist That Survives Week One
Most queue rollouts fail on configuration, not on product. So where do you start? Work in this order.
- Map the current path first. Write down every number that rings, where it goes, and what happens if nobody answers. Do this before you touch the new system. Teams routinely turn up a forwarding rule nobody remembers setting.
- Name an owner per queue. One person who is accountable for its staffing and its numbers. A queue without an owner drifts within a month.
- Set hours and the outside-hours action explicitly. Do not accept a default here.
- Define the timeout destination. Decide where a caller goes when the queue runs out of patience, and make sure a human sees that destination daily.
- Keep announcements short. Position and estimated wait, then music. Long recordings increase abandons without adding information.
- Test the failures, not the success. Call with every agent logged out. Call at 2 a.m. Call and wait past the timeout. Call and request the callback, then confirm the task appeared and somebody worked it.
- Validate the reports against a known call. Place a test call, note the exact time and what you did, then find it in the report. If the exit reason is wrong or missing, fix that before rollout, not after.
- Baseline for a month before you judge anything. You need a month of daily peaks before the dimensioning rule means anything.
- Train on the unavailable control. Reps need a clean way to step away. If they do not have one, they will create one.
Queue Metrics Worth Putting on a Dashboard
Most queue dashboards ship with eight tiles and three of them are actionable. So which ones belong on the wall? Here is the short set, with what each one should change.
- Unique callers per interval, next to call legs. The gap is your retry load. It rises before service level falls, so treat a widening gap as an early warning rather than a reporting artifact.
- Exit reason split, not a missed-calls total. Changes which problem you work. A timeout spike is staffing. A JOINEMPTY spike is scheduling. Those get fixed by different people.
- Wait time distribution with the long tail visible. Changes your timeout setting and tells you where abandons actually live.
- Fourth highest daily peak for the month. This is the staffing target. Put it on the wall and update it monthly.
- Second highest daily peak. This is the stress check. If your coverage cannot survive it, you know your exposure in advance.
- Calls arriving outside staffed hours. Usually ignored, frequently a meaningful share of demand, and cheap to serve with a callback path.
- Callback requests created against callback requests worked. If these diverge, the escape hatch has become a second, invisible queue.
Track those and you can answer the question a manager actually has on Monday, which is not how many calls came in. It is which broken thing to fix first.
Call Queue Questions Buyers Ask
What is a call queue?
A call queue places incoming calls in line to be answered while agents are busy with other calls, then distributes them to the next available agent in the order received. Queued callers can be told their position and estimated wait, and a queue can offer voicemail or a callback so the caller does not have to hold.
How is a call queue different from a ring group?
A ring group rings a set of phones together or in sequence and falls through if nobody answers, which means there is no waiting room, no position, and no line to report on. A queue holds callers, orders them, and produces a record of the wait. Use a ring group when calls are sparse and somebody just needs to pick up. Use a queue when calls arrive faster than the team can answer them.
Does call queue software reduce hold times?
Not by itself. A queue cannot answer a call, so it cannot add capacity. What it does is order the line, tell callers where they stand, give them a way out, and record what happened. Hold times fall when staffing matches the peak load or when enough callers take the callback path, and the queue is how you find out which of those two is missing.
Why did abandons go up after we turned on wait announcements?
Because callers started making an informed decision instead of guessing. Somebody told they are ninth in line often leaves at twenty seconds rather than at five minutes, so the abandon count rises while wasted caller time falls. Judge the change by where abandons happen in the wait distribution, not by the raw rate.
How many agents does a call queue need?
Size against the peak, not the average. Measure the highest-load interval of each day for a month, order those daily peaks, and staff against the fourth highest, then check your coverage against the second highest to understand your exposure on a bad day. A monthly average will consistently understaff you, because no real day looks like the mean.
What happens to calls that arrive after hours?
That depends entirely on how it is configured, which is why it is the most common silent failure. In Kixie, an Outside Queue Hours Action determines how a call arriving outside queue hours is handled, including routing it to voicemail or to a specific agent, and queue hours can be set separately from general business hours. Whatever platform you use, set it deliberately and then call the line yourself outside hours to hear the result.
Is abandon rate the right measure of queue health?
On its own, no. Traffic engineering definitions separate a blocked call attempt, rejected because resources were lacking, from an abandoned call attempt, aborted by the caller. A dashboard that merges them hides the difference between understaffing, a capacity cap, an empty queue, and offline devices, so split the exit reasons and the abandon rate becomes useful again.
Can one account run more than one call queue?
On Kixie there is no limit to the number of call queues, IVRs, or ring groups an account can configure, while on other platforms this often varies by plan, so confirm it against the plan being quoted rather than the feature page.
Sources
- ITU-T Recommendation E.600 (03/93), Terms and definitions of traffic engineering, definitions of traffic carried, traffic offered, blocked call attempt and abandoned call attempt. Reviewed November 11, 2026.
- ITU-T Recommendation E.501 (05/97), Estimation of traffic offered in the network, clause 1 on repeat attempts and suppressed traffic. Reviewed November 11, 2026.
- ITU-T Recommendation E.500 (11/98), Traffic intensity measurement principles, on read-out periods, the Daily Peak Period method and normal and high load traffic intensities. Reviewed November 11, 2026.
- Asterisk Documentation, Queue dialplan application, QUEUESTATUS values and the QUEUEWAIT, ANSWEREDTIME and ABANDONED channel variables, generated from Asterisk branch 23. Reviewed November 11, 2026.
- Kixie, Inbound Call Queues. Reviewed November 11, 2026.
- Kixie, Automatic Call Distribution. Reviewed November 11, 2026.
Sources verified and content reviewed by the Kixie Research Team on November 11, 2026.

















