Capacity Planning and Scaling

The MSP's Guide to VoIP: Part 13 of 20

Nobody calls their MSP to say "things are working great, but I think we might be approaching the limits of our voice infrastructure and should plan for growth." What actually happens is the system hits a wall. Calls fail, quality degrades, trunks busy out. Now you are firefighting a problem that was predictable and preventable.

Capacity planning is one of those areas that separates MSPs running a voice business from MSPs running a voice sideline. It is not technically difficult. It requires no specialized tools beyond what you should already have from monitoring. What it requires is the discipline to track the right metrics over time and the confidence to have the growth conversation with the client before they experience a failure.

This post covers what to watch, how to interpret the trends, and how to present upgrades as competent management rather than an upsell.

The three capacity constraints

Every voice environment has three resources that can become bottlenecks: trunk capacity, bandwidth, and platform resources. Each one has different symptoms when exhausted and different lead times for resolution.

Trunk capacity

Trunks determine how many simultaneous external calls the system can handle. Clients often still talk about this in terms of "lines," but lines don't exist anymore — the real constraint is concurrent call capacity. Whether you are running SIP trunks to an ITSP or channels on a hosted platform, there is a hard limit on concurrent calls to and from the PSTN. When every available trunk is in use and another call tries to go out (or come in), it fails.

The failure mode depends on the direction. Outbound calls get a fast busy or a "all circuits are busy" recording. Inbound calls get a busy signal at the carrier level, which means the caller hears busy and the client never even knows the call was attempted. This is the worst outcome because the client is losing calls they do not know about. Their customer calls, gets busy, and calls a competitor instead.

What to monitor: Peak concurrent calls versus total trunk capacity. Most PBX platforms and hosted providers report concurrent call counts in their dashboards or CDRs. Track the daily maximum, not the average. You care about the peak because that is when the system is closest to its limit.

Healthy headroom: A system should routinely have at least 20-30% of its trunk capacity unused during peak hours. If a client has 20 SIP trunk channels and regularly hits 16 concurrent calls, they are at 80% utilization and one busy day away from dropped inbound calls. That is the time to act, not when they hit 20 and start missing calls.

Growth trajectory: Plot peak concurrent calls by week or month. If the peak is climbing steadily, extrapolate when it will hit the trunk limit. This gives you a timeline for the capacity conversation. "Your peak call volume has been growing about two concurrent calls per quarter. At this rate, you will hit your trunk limit in six months. We should add capacity now so we are ahead of it."

Seasonal patterns: Some businesses have predictable spikes: accounting firms during tax season, retail during holidays, landscapers in spring. If you know the client's business, you can anticipate the spike and add temporary or permanent capacity before it hits. This is the kind of proactive management that clients remember.

Bandwidth

Every concurrent VoIP call consumes a predictable amount of bandwidth. G.711 uses approximately 85-90 kbps per direction (including overhead). G.729 uses about 30-35 kbps. Opus varies but typically 30-80 kbps depending on configuration. This is per call, in each direction. A Bandwidth Calculator can help you model these numbers against a client's actual call volume and codec choices.

The math seems straightforward: 20 G.711 calls consume about 1.8 Mbps of upload bandwidth and 1.8 Mbps of download. That is a tiny fraction of most modern internet connections. So bandwidth should never be a problem for voice alone, right?

Wrong, because voice does not exist in a vacuum. It shares the internet connection with everything else the office does. And the issue is not total bandwidth. It is momentary congestion and the absence of QoS prioritization on most connections.

A 100 Mbps upload link that averages 40% utilization can still have microsecond-level bursts that hit 100%. During those bursts, if voice packets are queued behind a large data transfer, they arrive late or not at all. This is why monitoring average bandwidth utilization is necessary but not sufficient. You need to monitor peak utilization and, ideally, utilization in the priority queue if you have QoS configured.

What to monitor: Upload and download utilization on the WAN link, tracked over time. Focus on business hours. Track the 95th percentile utilization (the level that utilization stays below 95% of the time) rather than just the average, because the 95th percentile captures the bursts that affect voice quality.

Healthy headroom: If 95th percentile upload utilization during business hours is above 70% of the link capacity, voice quality is at risk during peak moments. If it is above 85%, you are probably already experiencing intermittent quality issues during the busiest periods, even if the client has not connected the dots yet. Check your monitoring data for MOS trends that correlate with bandwidth peaks.

Growth factors: Bandwidth consumption grows for reasons that have nothing to do with voice. A client that adopts a new cloud CRM, starts using video conferencing heavily, moves their file server to SharePoint, or hires five new employees is consuming more bandwidth even if their call volume stays flat. Track total bandwidth trends, not just voice bandwidth, because voice quality is affected by all traffic on the link.

The upgrade conversation: Bandwidth upgrades are one of the easier capacity conversations because the data tells a clear story. "Your internet connection is running at 85% capacity during your busiest hours, and that is when your calls sound the worst. Here is the quality data showing the correlation. Upgrading to a faster connection, or adding a second connection with SD-WAN, would give you headroom for growth and eliminate the quality issues."

If the client is on a shared connection like cable and the quality issues are not just about capacity but about the inherent variability of shared infrastructure, this might also be the time to discuss moving to DIA for voice traffic.

Platform resources

This applies primarily to on-premises or self-hosted PBX deployments, though hosted platforms have their own limits that manifest differently.

An on-premises PBX (whether it is FreePBX on a physical server, 3CX on a VM, or any other self-hosted platform) has finite CPU, memory, and I/O capacity. As call volume grows, the PBX consumes more of each. The symptoms of a PBX approaching its resource limits are subtle at first and dramatic later.

Early signs:

• Call setup latency increases. The time between dialing and hearing ringback gets slightly longer. This is the PBX taking more time to process the INVITE because it is busy handling other calls.
• Transcoding quality degrades. If the PBX is converting between codecs (for example, G.729 on the trunk side and G.711 on the extension side), transcoding is CPU-intensive. Under load, the PBX may start producing degraded audio on transcoded calls while non-transcoded calls sound fine.
• Registration delays. Phones take longer to register or re-register. During a power outage recovery, when all phones try to register simultaneously, the PBX struggles to handle the flood and phones sit unregistered for minutes.
• Voicemail processing slows down. Messages take longer to appear in email, or voicemail-to-text transcription falls behind.

Late signs:

• Calls fail with SIP 500 or 503 responses. The PBX is too overloaded to process new calls.
• Audio glitches that correlate with call volume peaks. The PBX cannot process media fast enough and starts dropping RTP packets.
• The system becomes unresponsive. The web interface hangs, SSH sessions timeout, and management operations fail.

What to monitor: CPU utilization, memory utilization, and disk I/O on the PBX during peak call periods. Track concurrent calls versus the platform's rated capacity (which the vendor should document). If you are running the PBX as a VM, also monitor the hypervisor's resource allocation. A VM that is competing with other VMs for CPU cycles will show voice quality degradation under load even if the guest OS metrics look acceptable.

Hosted platform limits: If you are reselling a hosted platform, the capacity constraints are the provider's problem to manage, but the limits still exist. They manifest differently: the provider might throttle new registrations, rate-limit API calls, or experience degraded call quality across their platform during peak hours. Platform-wide degradation that follows peak hours is often a sign of overbooked capacity on the provider's side. You have less visibility into these limits, which is why the vendor relationship and the quality of their platform monitoring matters.

Anticipating growth

The best capacity planning is not reactive to trends. It is informed by business context. You know things about the client's business that a monitoring dashboard cannot tell you.

Hiring plans. If a client tells you they are hiring ten people next quarter, that is ten more phones, ten more concurrent call slots needed, and proportionally more bandwidth consumed. Don't wait for those people to start and then discover the trunks are maxed out. Add the capacity before the new hires arrive. This is basic managed services discipline applied to voice.

Office changes. A client opening a second location, consolidating two offices, or moving to a larger space all have voice capacity implications. New locations need their own internet connections and network infrastructure assessed and prepared. Consolidations might temporarily double the call volume on a single system. Moves are covered in detail in the office move series, but the capacity implications are worth flagging here.

Business growth. A client whose revenue is growing is almost certainly generating more phone calls. Sales teams call more prospects. Support teams handle more customer calls. Seasonal businesses have predictable spikes. Understanding the client's business cycle helps you anticipate capacity needs before the metrics show them.

Technology changes. A client that adopts video conferencing, moves to cloud-based applications, or starts supporting remote workers is changing their bandwidth profile. A client deploying AI voice agents is an even sharper example: automated agents can spike from idle to hundreds of concurrent calls in seconds, a pattern that traditional capacity models do not anticipate. These changes affect voice capacity indirectly but meaningfully. The network preparation work you did before the initial deployment may need revisiting as the client's technology stack evolves.

When to add what

Knowing that capacity needs to increase is the first step. Knowing which resource to increase, and how, is the second.

Adding trunk capacity

This is usually the simplest capacity change. Adding SIP trunk channels with most ITSPs is an account change. You request additional concurrent call capacity, and it is activated within hours or days. Some providers charge per channel, some include a pool of channels in their pricing, and some scale automatically. Know your provider's model so you can quote the cost quickly when the need arises.

For hosted platforms, adding trunk capacity might mean upgrading the client's plan tier or adding a trunk group. Check the provider's pricing and any minimum commitment requirements.

The lead time for trunk capacity changes is usually short (days), so you can be somewhat reactive here. But "somewhat reactive" means adding capacity when you see the trend approaching the limit, not when the client reports that calls are failing.

Upgrading internet

This has a longer lead time and is more disruptive, so plan further ahead. Upgrading from a 100 Mbps cable connection to a 500 Mbps connection might take a few days if the ISP can provision it on the existing infrastructure. Moving from cable to DIA might take 30 to 90 days depending on whether the circuit needs to be built. Adding a second connection for redundancy or SD-WAN involves procurement, installation, and configuration.

Start the bandwidth upgrade conversation when 95th percentile utilization consistently exceeds 70% during business hours and the trend is upward. This gives you time to evaluate options, get quotes, and implement the upgrade before utilization reaches the point where quality degrades.

Scaling the platform

For on-premises PBX systems, scaling might mean adding CPU and memory to a VM, migrating to a larger server, or moving to a clustered deployment. These changes involve downtime for the voice system, which means scheduling a maintenance window, communicating with the client, and having a rollback plan.

For hosted platforms, scaling might mean moving to a higher tier, migrating to a different platform entirely, or splitting the client across multiple instances. The lead time and complexity depend entirely on the provider.

The decision to scale the platform versus migrate to a different platform is a judgment call that depends on cost, capability, and the client's trajectory. A platform that serves a 30-person office well might not be the right platform for the same company when they reach 150. This is a larger conversation that involves evaluating the platform's roadmap, pricing at scale, and whether the features the client needs at that size are available. Platform selection criteria are covered in post 5.

Presenting upgrades proactively

This is where many MSPs struggle, not because the technical analysis is hard, but because they are uncomfortable having cost conversations. It feels like upselling. It feels like asking the client to spend more money.

Reframe it. You are not selling them something. You are managing their infrastructure. Part of managing infrastructure is anticipating when it needs to grow and presenting that information with enough lead time that the client can budget and plan, rather than making emergency purchases under duress.

The formula is:

Here is what the data shows. "Your peak concurrent calls have been growing steadily and you are now routinely using 85% of your trunk capacity during your busiest hours."

Here is what happens if we do nothing. "When you hit 100%, inbound callers will get a busy signal instead of reaching your team. You won't know the call was attempted."

Here is what I recommend. "We add ten trunk channels, which gives you headroom for the next 12-18 months based on your current growth rate. The cost is $X per month."

Here is the timeline. "I'd like to make this change within the next 30 days, before the busy season."

This positions you as the professional who is watching their systems and planning ahead. The client does not feel sold to; they feel managed. There is a significant difference, and it is the difference between a client who sees your fee as a cost and a client who sees it as a value.

If you have been delivering quality reports as described in the monitoring post, the capacity data is already part of the conversation. The upgrade recommendation is a natural extension of the data you have been presenting, not a surprise upsell dropped into a random meeting.

The cost of not planning

When capacity is not planned, it is reacted to. And reactive capacity changes are universally more expensive, more disruptive, and more damaging to the client relationship.

A trunk capacity shortage that causes missed inbound calls for a day costs the client real business. An internet connection that is saturated to the point of unusable voice quality for a week costs them patience and confidence in your management. A PBX that crashes under load during a Monday morning call spike costs them a morning of productivity and costs you a weekend of emergency work.

Beyond the direct cost, reactive capacity management undermines the managed services value proposition. The whole point of managed services is that someone is watching, planning, and preventing problems. If every capacity issue is a surprise, the client starts to wonder what they are paying for.

Proactive capacity planning, by contrast, reinforces the value proposition every time you have the conversation. "We've been tracking this, we saw it coming, here's the plan" is the most powerful statement an MSP can make. It demonstrates competence, builds trust, and creates the kind of long-term partnership that drives retention and referrals.

A simple capacity planning checklist

For each voice client, review these metrics quarterly (monthly for fast-growing clients):

• Peak concurrent calls versus trunk capacity. Flag if above 75%.
• 95th percentile bandwidth utilization during business hours. Flag if above 70%.
• PBX CPU utilization during peak call periods (on-prem only). Flag if above 70%.
• PBX memory utilization (on-prem only). Flag if above 80%.
• Average call setup time. Flag if increasing trend.
• Registration success rate during high-load periods. Flag if below 99%.
• Client headcount changes (planned or actual).
• New applications or services consuming bandwidth.

Each flagged item gets a recommendation: add capacity, optimize configuration, or monitor closely for another quarter. Document the review and include it in your quality report.

The entire review takes 15 to 20 minutes per client if your monitoring is set up correctly. That is a trivial time investment compared to the cost of a capacity-related outage, and it is the kind of disciplined operational practice that builds a genuinely sustainable voice business.

Next up: Vendor Relationships: Working With Hosted Providers and Trunk Carriers, on being an effective client advocate when the problem is on the provider's side.