Traffic Forecasting and When to Expand Voice Capacity

Traffic Forecasting and When to Expand Voice Capacity

Capacity planning for voice goes wrong in a predictable direction. An organisation looks at its total call volume, notices it has doubled in two years, and concludes it needs a bigger platform. It orders capacity, installs it, and finds that the constraint was never where the volume suggested. Meanwhile a different constraint, on a different resource, continues to bind unnoticed until it causes the outage. The reason is that aggregate call volume is a poor predictor of voice resource demand. What consumes resources is the number of calls in progress during the busiest period, combined with the average length of those calls, and those two quantities have very different growth patterns.

Why Averages Understate Demand

Voice resource demand is driven by concurrency, and concurrency is not evenly distributed. An organisation may average a modest number of simultaneous calls across a day while reaching a peak several times higher during a small number of windows. Average daily figures therefore understate the true requirement, sometimes by a wide margin. Worse, the peak pattern differs between business units: a sales team concentrates calls into a few predictable windows, while a service desk spreads them across the day.

The statistically correct unit is the busy hour, which is the busiest one-hour period in a defined measurement period, expressed as a percentage of offered traffic. This is what equipment and licensing decisions should be based on. Peak load in the busiest single minute is useful for stress testing and for understanding headroom, but it is a poor basis for sizing because it overstates the sustained requirement.

Traffic in this context has two components: the number of call attempts and the average duration of those attempts. Both contribute to resource occupancy, and they often grow differently. A campaign that doubles outbound call attempts without lengthening them is a different problem from a support team whose calls take twice as long, and the second is generally the harder one to absorb because duration cannot be compressed.

Building a Demand Model

A workable model is assembled from a few simple components rather than from elaborate forecasting. It should express demand per business unit, per hour of the day, and per month, because those three dimensions capture nearly all of the variation that matters.

Two refinements make the model substantially better. First, model duration by direction and by call type, because inbound support calls and outbound sales calls behave very differently in a system with queuing. Second, apply the growth assumptions to the peak rather than to the average, and check whether the growth itself changes the peak shape, since adding staff often increases the peak rather than spreading it.

Setting an Expansion Trigger

The most useful planning artefact is not a forecast but a trigger: a stated condition, checked regularly, that starts the expansion process. Triggers work because they convert a judgement call made under pressure into a process that begins while there is still time. A trigger also removes the argument about whether an increase is significant enough to act on.

• Sustained busy-hour occupancy approaching a stated percentage of practical capacity for several consecutive periods
• Calls failing or being rejected during known peak windows, even if daily totals look normal
• Queue abandonment rising during specific periods rather than across the day as a whole
• Any single day where concurrent demand exceeds the modelled figure by a stated margin
• A planned business change that alters the model, such as a new shift pattern or a new site opening
• Headcount or customer growth that pushes the forecast beyond the current model horizon
• End-of-life notice on an element that cannot be replaced like for like, which starts the project early

Whichever trigger is chosen, it should name a threshold, a measurement source, a review frequency, and a named person who acts on it. A trigger without an owner is a data point rather than a control.

Identifying the Actual Constraint

Before ordering anything, establish what is actually constrained. In voice systems the limiting resource is frequently not the one people assume. Licensed concurrent-call entitlements, available trunk channels, media transcoding capacity for recording or codec conversion, registration capacity for endpoints, and console or user-interface capacity can all bind well before the platform as a whole is under pressure. Each has a different remedy and a different lead time, which makes early identification valuable.

The practical method is to look at where degradation first appears under load and work backwards from there. If calls fail while endpoint registration is healthy, the constraint is upstream of the endpoints. If calls connect but recording fails, transcoding or storage is the constraint. If quality degrades without any failure, the constraint is probably media capacity or network resources rather than platform resources.

Lead Times Change the Plan

Expansion decisions are constrained by procurement as much as by engineering. Lead time, licence delivery, hardware availability, and configuration effort each add to the time between recognising the trigger and having the additional capacity in service. A trigger defined too tightly leaves no room for these delays and results in a capacity problem being solved after the fact rather than before it.

This is why the trigger threshold should be set below the point of failure, and why the review frequency should be short enough that the response can complete within the available lead time. Where lead times are long, the useful response is to raise the trigger threshold and start planning earlier, rather than to reduce the lead time optimistically.

Planning for Degradation, Not Just Failure

Voice capacity does not behave like a step function. As a system approaches its limits, quality typically degrades gradually before any outright failure appears: fewer simultaneous recordings succeed, some calls experience delay, queue reports show unusual answer patterns, and a small proportion of attempts fail intermittently. Intermittent failure during peaks is frequently the first real symptom of capacity pressure, and it is easily dismissed as a provider fault.

Treat gradual degradation as the primary capacity signal rather than waiting for hard failure. It appears earlier, it gives more lead time, and it is much easier to diagnose when it is recognised for what it is.

Redstone Approach

Redstone can support voice capacity planning. Our engineers can review historical call reporting from a Redstone REX IP-PBX deployment with you, help build a demand model from busy-hour and duration data, identify which resource is actually constraining your deployment, and advise on realistic lead times and sequencing for the expansion options available to you across platform, gateway, and licence considerations. We can also review the output of your monitoring so that triggers reflect what your environment genuinely shows. We do not provide capacity figures for platforms you have not specified, because sizing depends on your configuration and licence mix.