7 min read · Published August 24, 2026 · Vast Networks
Why the usual approach produces the wrong answer
The common method is to pick a speed tier that sounds adequate and see whether anyone complains. It fails for a specific reason: the number being chosen describes download capacity on an oversubscribed network, and the constraint in almost every business is upstream capacity during the working day.
Counting employees does not help much either. Fifteen people running a hosted line-of-business application, a video wall, and a camera system place very different demands from fifty people doing email and document work. The load follows the workloads, not the headcount.
Step one: list what sends data out
Hosted and cloud applications, video conferencing endpoints, off-site backup and replication, security cameras, VoIP channels, remote access sessions, and any file sharing with customers or partners. These are the flows that run concurrently and compete for the same upstream capacity.
For each, establish a realistic per-unit rate. Video conferencing runs roughly 1.5–4 Mbps per HD stream. A VoIP call consumes about 85–100 kbps with common codecs once overhead is counted. Cameras vary enormously — a 4 MP camera at 15 frames per second on H.265 might use 2–4 Mbps, and the same camera badly configured on H.264 at 30 frames per second can use three times that. Use your actual encoder settings rather than a datasheet maximum.
Step two: work out what is genuinely concurrent
Not everything peaks together. Cameras and voice run continuously; video meetings cluster in the morning; backups usually run overnight and should be scheduled to do so. The number that matters is the sum during your busiest working hour.
If backup cannot be scheduled outside business hours — increasingly common with continuous replication — it belongs in the concurrent total, and it is frequently the largest single item in it.
Step three: add headroom, then sanity-check
Add about 40% to the concurrent upstream total. Headroom absorbs growth, unexpected bursts, and the reality that estimates are estimates. A circuit running consistently above 70% utilisation will feel congested even though it is technically within capacity, because queuing delay rises sharply as a link approaches saturation.
Then sanity-check against the downstream side. Downstream demand is usually well below upstream demand in a business, so a symmetric circuit sized for upstream almost always has ample download capacity. That is the practical reason symmetric circuits at modest rates outperform much larger asymmetric plans.
A worked example
A thirty-person professional firm: a hosted practice-management platform (roughly 15 Mbps aggregate at peak), eight concurrent video meetings at 3 Mbps (24 Mbps), sixteen cameras at 3 Mbps (48 Mbps), twelve concurrent voice calls (about 1.2 Mbps), and continuous cloud backup averaging 20 Mbps. That totals roughly 108 Mbps upstream at peak.
Add 40% headroom and the requirement is about 150 Mbps symmetric. Compare that with a common business plan advertising 500 Mbps down and 25 Mbps up: the plan is nominally three times larger and provides one-sixth of what the firm actually needs in the direction it uses. This is the arithmetic behind almost every "our internet is slow but the speed test looks fine" report.
When to buy more than the calculation says
When growth is planned and a capacity change would need construction rather than provisioning — worth checking, because on an existing dedicated fiber circuit an increase is usually a configuration change. When a single event dominates the year, such as an assessment window or a seasonal production run. And when the cost difference between two rates is small enough that the headroom is cheaper than the meeting about whether to buy it.