The short answer
There is no single "business speed" — the right plan is the sum of what runs at the same time during your busy hour, not a number keyed to headcount. Add up the concurrent load of each activity: budget roughly 3-4 Mbps in each direction per person actively on an HD video call, about 0.1 Mbps per concurrent VoIP call, 2-4 Mbps of continuous upload per 1080p cloud camera, ~5 Mbps of download per HD video stream, and a variable burst for cloud file sync and backup. A mixed office of 15 where six people are on Zoom, eight cameras stream to the cloud, and a dozen phones are live is pulling on the order of 40-60 Mbps of upload and a similar or larger download at peak — and that is before anyone opens a streaming site in the break room.
The number almost everyone gets wrong is upload. Consumer-grade and even "business" cable plans are deeply asymmetric — a headline "gigabit" package is usually 1000 down / 35 up — while modern work is upload-heavy: your camera feed, your voice, your screen share, your cloud backups and your surveillance footage all leave the building. The same 15-person office above blows past a 1000/35 cable plan's 35 Mbps upstream while barely touching the download, and once the uplink saturates, latency balloons and every call and download degrades at once. Size the upload first, treat always-on loads such as cameras and backup as fixed around the clock demand, add 20-30% headroom, and let the calculator on this page do the arithmetic.
Download vs upload, and which one binds first
Every internet plan has two numbers — the rate at which data comes in (download) and the rate at which it leaves (upload) — and they are rarely equal. Cable/DOCSIS service is asymmetric by design: the coax spectrum is split heavily toward the downstream, so even a "gigabit" cable tier typically offers only 20-50 Mbps upstream. Fiber, by contrast, is usually symmetric — 500/500 or 1000/1000 — because the medium has no comparable spectrum constraint.
For most of the internet's history that asymmetry matched reality: people downloaded far more than they uploaded. Business traffic has since flipped. Video calls send your camera and microphone out, VoIP sends your voice out, screen sharing sends your desktop out, cloud cameras push footage out continuously, and cloud backup and file sync move gigabytes out on a schedule. The upstream, not the downstream, is now the scarce resource in a typical office.
A connection is only as good as the direction that saturates first. You can have 900 Mbps of download sitting idle and still have frozen calls and stalled backups because the 35 Mbps uplink is full. When you size a plan, evaluate each direction independently and assume the upstream is the constraint until the numbers prove otherwise.
- Cable/DOCSIS is asymmetric by design: downstream gets most of the spectrum, so upstream caps at ~20-50 Mbps even on "gigabit" tiers.
- Fiber (GPON/XGS-PON, active Ethernet) is typically symmetric: 500/500, 1000/1000.
- Upload carries everything you send: camera streams, VoIP audio, screen shares, cloud backup, file sync, surveillance footage.
- A link is only as good as the direction that saturates first — for most offices that is the upstream.
- DOCSIS 4.0 narrows the gap with higher upstream, but most installed plant is still 3.1 with a low upstream cap.
What each activity actually consumes
Video conferencing is the load people underestimate because every seat is bidirectional. A 1080p call runs roughly 2-4 Mbps up and down per active participant — your upload carries your own camera, your download carries everyone else's — and gallery view or a screen share pushes the high end. Six people on separate HD calls is not 4 Mbps of demand; it is closer to 20-24 Mbps in each direction.
VoIP is the opposite profile: tiny but unforgiving. A G.711 call is about 85-100 kbps each way once IP/UDP/RTP headers are counted, or roughly 30 kbps on G.729, so even 20 concurrent calls is only ~2 Mbps. The bandwidth is trivial; what matters is latency under 150 ms, jitter under 30 ms, and packet loss under 1%, which is a QoS problem, not a capacity one. Cloud cameras are the sustained upstream hog: a 1080p H.264 stream is ~2-4 Mbps of continuous upload (about half that on H.265), 4K is 8-16 Mbps, and unlike people it runs around the clock — eight 1080p cameras is a standing 16-32 Mbps upstream load.
The rest is mostly download or bursty. HD video streaming is ~5 Mbps per stream and 4K is 15-25 Mbps, all downstream. SaaS apps — email, CRM, docs — sip bandwidth in steady state but are latency-sensitive. Cloud backup and large-file sync are upload-heavy and can saturate the uplink outright, but they are usually schedulable to off-peak windows so they don't collide with the business day.
- HD video call: ~2-4 Mbps up and down per active 1080p participant; gallery view and screen share push the high end.
- VoIP call: ~85-100 kbps each way with G.711 headers, ~30 kbps with G.729 — tiny bandwidth, but needs <150 ms latency, <30 ms jitter, <1% loss.
- Cloud camera: ~2-4 Mbps continuous upload per 1080p H.264 stream (about half on H.265), 8-16 Mbps for 4K — running around the clock regardless of staff.
- Video streaming: ~5 Mbps per HD stream, 15-25 Mbps per 4K stream, download only.
- Cloud backup and large-file sync: bursty and upload-heavy; can saturate the uplink but are usually schedulable off-peak.
- SaaS (email, CRM, docs): low steady-state bandwidth but sensitive to latency, not throughput.
Size by simultaneous use, not headcount
Headcount overstates demand because people don't all peak at once. The right unit is concurrent users per activity at the busy hour: a 40-person office rarely has 40 simultaneous video calls, and a realistic figure might be a third of staff on bandwidth-heavy tasks at any given moment. Estimate that concurrency for each activity, then convert it to Mbps using the per-activity figures.
The exception is always-on load. Cloud cameras and scheduled backups consume the same upstream whether the office is full or empty, so treat them as a fixed baseline that sits underneath everything else. The method is: sum concurrent upstream demand and concurrent downstream demand separately, add the fixed around the clock loads, then require the plan to satisfy the larger figure in each direction. Add 20-30% headroom and avoid sustaining any link past roughly 70% of capacity — the last slice of a link is exactly where latency starts spiking.
Finally, remember that a circuit is aggregate, not per-device, bandwidth. A 1 Gbps plan does not give every workstation a gigabit; it is a shared pool, and without QoS a single large upload or backup can starve every other user on the link. Sizing the pipe correctly and shaping traffic on it are two separate jobs.
- Estimate concurrent users per activity at the busy hour, not total headcount — a 40-person office rarely has 40 simultaneous calls.
- Treat cameras and cloud backup as fixed around the clock load: they consume the same upstream whether the office is full or empty.
- Sum upstream and downstream demand separately; the plan must satisfy the larger of the two in each direction.
- Add 20-30% headroom and avoid sustaining a link past ~70% of capacity — the last slice is where latency spikes.
- A shared circuit is not per-device bandwidth: without QoS, one backup or upload can starve everyone else.
Why upload is the number plans skimp on
Marketing leads with the download number because it is the big one and the one consumers historically cared about. The upstream is an afterthought on cable: "gigabit" almost always means ~1000/35, and that 35 Mbps is what a handful of video calls plus a bank of cloud cameras will exhaust while the download sits nearly idle. The plan looks enormous and still feels broken.
The reason it feels broken is bufferbloat. When you saturate the uplink, packets queue in the modem's buffer instead of dropping, and latency climbs from ~20 ms to several hundred milliseconds. TCP acknowledgements for your downloads are stuck in that same queue, so your downloads stall too — a full uplink degrades both directions at once. This is why an office can "have gigabit" and still watch calls freeze and pages hang whenever someone kicks off a backup.
The fix, when the send side is genuinely heavy, is symmetric service. Fiber at 500/500 or 1000/1000 removes the upstream bottleneck for camera-, backup- and video-heavy sites. For operations that cannot tolerate downtime, Dedicated Internet Access (DIA) adds a guaranteed rate and a service-level agreement rather than the best-effort "up to" speeds of a shared plan. If your calls and cloud apps degrade at random times, suspect a saturated or contended uplink long before you blame the download tier.
- "Gigabit" on cable usually means ~1000/35 — plenty of download, an upstream a few calls plus cameras can exhaust.
- Saturating the uplink triggers bufferbloat: latency jumps from ~20 ms to hundreds of ms, and delayed ACKs stall downloads too.
- Symmetric fiber (500/500, 1000/1000) removes the upstream bottleneck for camera-, backup- and video-heavy sites.
- Dedicated Internet Access (DIA) adds a guaranteed rate and an SLA, versus best-effort "up to" shared plans.
- If calls and cloud apps degrade at random times, suspect a saturated or contended uplink before blaming the download tier.
Speed isn't everything: latency, jitter, and the WiFi trap
Real-time applications care far more about timing than about raw throughput. Voice and video want one-way latency under ~150 ms, jitter under ~30 ms, and packet loss under 1%; a fast link that delivers packets erratically still drops calls. Buying more Mbps does nothing for a latency or jitter problem — that is a queueing and prioritization issue.
The tool for it is QoS, specifically smart queue management such as fq_codel or CAKE, which keeps real-time traffic ahead of bulk transfers and holds bufferbloat in check even when the link is under load. Prioritizing voice and video, and shaping backups and sync, often does more for perceived quality than doubling the plan.
And frequently the WAN isn't the bottleneck at all. A 500 Mbps circuit means nothing to a laptop stuck on aging WiFi, a congested 2.4 GHz channel, an undersized switch uplink, or a marginal Cat5e run — any of those can cap a device far below the plan. Always test at the client and again at the router: a large gap points at the internal network, not the ISP. More bandwidth cannot fix latency, jitter, or a WiFi problem; those take QoS, RF design, and cabling.
- Real-time targets: <150 ms one-way latency, <30 ms jitter, <1% packet loss — a fast link with high jitter still drops calls.
- QoS / smart queue management (fq_codel, CAKE) prioritizes voice and video and keeps bufferbloat in check under load.
- The WAN is often not the bottleneck: aging WiFi, a crowded 2.4 GHz band, or an undersized switch uplink can cap a device far below the circuit.
- Test at the client and at the router — a big gap points to the internal network, not the ISP plan.
- More Mbps cannot fix latency, jitter, or a WiFi problem; those need QoS, RF design, and cabling, not a bigger plan.
Common sizing mistakes
Most bad plans come from a small set of repeated errors. The biggest is buying on the download headline and never reading the upstream number, followed closely by sizing to employee count instead of busy-hour concurrent activity. Both produce a plan that looks generous on paper and fails the moment real work happens.
The rest are about what people forget. Always-on loads — cloud cameras and backups — run around the clock and get left out of a headcount-based estimate entirely. Leaving zero headroom means normal bursts saturate the link and inflate latency for everyone. A business that cannot afford an outage runs a single circuit with no failover. And confusing the WiFi speed a phone displays with the internet plan sends people chasing a bigger tier when the fix is on the LAN.
- Buying on the download headline and never checking the upstream number.
- Sizing by employee count instead of busy-hour concurrent activity.
- Forgetting always-on loads — cloud cameras and backups run around the clock whether staff are present or not.
- Leaving zero headroom, so normal bursts saturate the link and inflate latency.
- No second circuit or failover for a business that can't afford an outage.
- Assuming the WiFi speed a phone shows equals the internet plan — the two are measured at different points.
Frequently asked questions
Is a gigabit plan enough for my business?
For download, almost always — but gigabit on cable is typically ~1000/35, and that 35 Mbps upstream is what runs out first. A dozen video calls, a bank of cloud cameras, and a nightly backup can exhaust 35 Mbps up while the 1000 Mbps down sits nearly idle. Check the upload figure and match it to your concurrent send-side load; if it's short, symmetric fiber is the fix, not a higher download tier.
Why do my video calls freeze when the speed test says I have plenty of bandwidth?
A speed test measures peak throughput on an idle link; it doesn't show what happens when your uplink is full. When upload saturates — cameras, a backup, several simultaneous calls — the modem's buffer fills and latency jumps from ~20 ms to several hundred, which is bufferbloat. Real-time media can't tolerate that, so calls stutter even though the "bandwidth" is technically there. QoS/SQM plus enough upstream headroom fixes it.
Do I need symmetric fiber, or is cable fine?
Cable is fine when your traffic is mostly download — web, SaaS, streaming — and your upload demand is light. Go symmetric when you send a lot of data continuously: multiple cloud cameras, cloud backup, frequent large-file uploads, hosted services, or many concurrent video calls. The tell is whether your busy-hour upstream demand exceeds what a cable plan's upload (often 20-50 Mbps) can carry.
How much upload do cloud security cameras use?
Roughly 2-4 Mbps of continuous upload per 1080p camera on H.264, about half that with H.265, and 8-16 Mbps for 4K. The key word is continuous: unlike people, cameras stream around the clock, so eight 1080p cameras is a standing ~16-32 Mbps upstream load before a single employee logs in. This is the single most common reason an office outgrows its cable plan's upload.
How many Mbps per employee should I budget?
As a rough planning figure, 2-5 Mbps of download per knowledge worker covers typical mixed use — but the honest answer is to budget by activity and concurrency, not per head. One employee on a 4K screen share plus cloud backup outweighs ten people reading email. Use headcount only to estimate how many people will be doing bandwidth-heavy things at the same time, then size to that peak.
