Bandwidth and Capacity Planning for Hybrid Work

The traffic map changed, and most circuits were sized for the old one

The bandwidth plan that served an office of 300 people in 2019 assumed a shape of traffic that no longer exists. Back then, the heavy flows were internal — file shares, a data-center-hosted ERP, email that lived on a server down the hall. The internet circuit was for browsing and the occasional download, and it was sized accordingly.

Hybrid work inverted that. The applications moved to SaaS and public cloud, the people moved partly home, and real-time video became the default meeting format. Traffic that used to stay inside the building now leaves it, and traffic that used to be a nice-to-have — a clean video call — is now the thing users notice first when it degrades. Capacity planning has to be rebuilt around that new shape, not patched onto the old assumptions.

What actually consumes the circuit now

Three categories dominate hybrid-era demand, and each behaves differently:

• Real-time media (video and voice). A single one-to-one HD video call runs roughly 1.5 to 3 Mbps in each direction; large gallery-view meetings and screen share push higher. This traffic is bidirectional, latency-sensitive, and unforgiving — it is the workload that exposes an undersized or poorly prioritized link before anything else does.
• SaaS and cloud applications. Productivity suites, CRM, collaboration platforms, and virtual desktops generate steady, chatty, mostly interactive traffic. Individually small; in aggregate, constant.
• Cloud backup and sync. Endpoint backup, file sync, and software distribution create bursty, upstream-heavy flows that can saturate an asymmetric link at exactly the wrong moment.

The pattern that trips up old designs is upstream demand. Consumer-grade and legacy business circuits were provisioned asymmetric — lots of download, little upload — because that matched web browsing. Video calls and cloud backup are upstream-hungry. A link that shows plenty of headroom on the download graph can be completely saturated on upload, and users experience that as frozen video and failed syncs while the "bandwidth is fine" dashboard stays green.

Sizing per-user bandwidth without guessing

Resist the temptation to buy a round number and hope. Build the estimate from the workload up.

1. Start with a real-time baseline per concurrent user. Budget roughly 2 to 4 Mbps of committed, prioritized capacity for each user who may be on a video call at the same time — not each employee, but each concurrent caller.
2. Apply a concurrency factor. Not everyone is on a call at once. In a typical knowledge-work site, peak concurrent video sits somewhere around 30 to 50 percent of headcount. Measure it if you can; assume the higher end if you cannot.
3. Add the SaaS and interactive layer. Allow another 1 to 2 Mbps per active user for cloud applications, browsing, and virtual desktop sessions running alongside the call.
4. Reserve for bursty background traffic. Backup, sync, patching, and OS updates need their own slice — enough to make progress without starving real-time flows. Rate-limiting these is often smarter than buying capacity for their peaks.
5. Add headroom, then plan the growth curve. Size for the busy-hour peak plus about 30 percent, and track the trend so you upgrade before saturation, not after users complain.

A worked example: a 200-person site with 40 percent peak concurrency is planning for roughly 80 simultaneous callers. At 3 Mbps each that is about 240 Mbps of prioritized real-time capacity, before SaaS, background traffic, and headroom. A 500 Mbps symmetric circuit is a defensible target; the old 100 Mbps asymmetric line is not.

Quality of Service: bandwidth is necessary, priority is decisive

More bandwidth alone does not fix bad calls. When a link congests — and every link congests at its busy hour — what matters is which packets wait and which go first. That is Quality of Service, and for hybrid work it is not optional.

• Classify and mark traffic at the edge. Tag real-time voice and video into a priority class so the network can honor it end to end rather than treating a backup stream and a live call as equals.
• Protect real-time flows with a priority queue. Give latency-sensitive media a low-latency queue with a bounded share of the link so it is served first but cannot starve everything else.
• Police the greedy, protect the fragile. Rate-limit bulk transfers so a large upload cannot crowd out a call. The goal is not maximum throughput for one flow; it is predictable experience for the flows humans are watching in real time.
• Watch jitter and loss, not just utilization. Real-time media tolerates surprisingly little. Loss above roughly one percent, or jitter climbing into the tens of milliseconds, is audible and visible long before a raw bandwidth graph looks alarming.

Direct internet breakout versus backhaul

The single biggest architectural lever in hybrid-era networking is where branch traffic reaches the internet. Two models:

• Backhaul (hub-and-spoke). Every site tunnels its traffic back to a central data center or hub, out to the internet there, and back again. It was built for centralized security inspection and internal-app access. For a video call to a cloud service, it means the media travels a long, congested horseshoe — adding latency, consuming expensive private-WAN capacity, and turning the hub into a chokepoint the day everyone works from a branch.
• Direct internet breakout (local). The branch sends SaaS and cloud traffic straight out its local internet circuit, keeping only what truly needs the data center on the private path. Shorter path, lower latency, no hub bottleneck — and the private WAN is freed for the traffic that actually belongs on it.

For SaaS-heavy hybrid work, local breakout wins on performance almost every time. The historic objection was security: breaking out locally meant losing centralized inspection. A modern SD-WAN fabric resolves that tension by steering each application to the right path per policy while enforcing consistent security at the edge, and by pairing with cloud-delivered security so breakout traffic is still inspected. When those sites span regions, the same policies and performance guarantees have to hold across global networks, not just within one country.

Capacity planning is a data problem, not a guess

Every recommendation above depends on knowing what your traffic actually does — and most organizations are flying on vendor defaults and anecdote. You cannot plan capacity you do not measure.

• Baseline the busy hour, not the daily average. Averages hide the peaks that break experience. Sizing to a 24-hour mean guarantees congestion when it matters.
• Track per-application and per-direction utilization. Aggregate throughput tells you nothing about the upstream video problem. Break traffic down by application and by direction to see the flows that actually hurt.
• Trend over months to catch the growth curve. Adoption of a new collaboration tool or a return-to-office shift moves demand steadily. Trending lets you upgrade a circuit on a purchase-order timeline instead of an emergency one.
• Alert on saturation and quality, not just outages. A link that is up but running at 95 percent during every meeting block is failing users while reporting healthy. Continuous infrastructure monitoring turns that slow degradation into an early signal instead of a helpdesk surge.

The reward for this discipline is the end of oversubscription surprises — the sudden, unexplained slowdown that turns out to be a circuit that quietly outgrew its size months ago. Capacity planning done from real data replaces that fire drill with a boring, predictable upgrade cadence, which is exactly what you want.

Plan capacity before your users report it

Hybrid work did not just add users to the network — it changed what the network is for. Real-time media, SaaS everywhere, and upstream-heavy cloud traffic reward teams that size per-user demand deliberately, prioritize the flows humans watch, break out locally where it helps, and plan from measured data instead of a round number and a hope. intSignal designs, sizes, and monitors networks built for how work actually happens now. Talk to our network team to baseline your traffic, right-size your circuits, and give real-time work the priority it needs.