# Sizing a multi-site WAN for cloud, backups and voice WAN sizing starts with simultaneous work, not employee headcount or the largest speed available. A useful model explains normal demand, busy periods and the minimum service required when a link or location is unavailable. 3 September 2026 [Connectivity & WAN](https://netavo.com/insights) ## Model concurrent work in both directions Begin with a site-by-site application inventory. Record where each application runs, which direction its traffic travels and whether demand is continuous, interactive or scheduled. Separate public cloud access from traffic between branches and central systems. If many sites share an exit or application location, include the aggregate demand there as well as the branch connections. Use measured busy periods wherever possible. Average utilisation over a day can hide a short but disruptive burst, while employee count says little about how many people are simultaneously in calls or moving files. Record the assumptions behind any estimate so that the model can be updated after deployment. Consider a hypothetical branch with twelve simultaneous video sessions budgeted at 3 Mbps each in each direction, plus 20 Mbps of other active application traffic in each direction. Its planning allowance is 56 Mbps each way before backup traffic and headroom. These are invented modelling inputs, not claims about a particular conferencing platform or a recommended allowance for every business. The calculation's value is transparency. Change the concurrency or per-session assumption and the result changes visibly. Validate those assumptions with the application supplier and representative measurements. Include guest use, updates and large uploads explicitly instead of assuming they disappear inside an unexplained margin. ## Give backups and degraded operation their own budgets Suppose the same hypothetical branch must upload 120 GB in an eight-hour overnight window. Using decimal units, 120 GB contains 960 gigabits. Dividing by 28,800 seconds gives approximately 33.3 Mbps of payload throughput. Protocol overhead, retransmissions and other activity mean the connection needs more capacity than that arithmetic minimum to finish reliably. If the backup overlaps the illustrative 56 Mbps working demand, the combined payload budget becomes roughly 89.3 Mbps before those allowances. A nominal 100 Mbps service would leave little room for variation under these assumptions. Moving the backup window or controlling its transfer rate may be as important as buying a larger circuit. Do the same exercise for central locations. Ten branches starting a transfer together can overload a shared destination even when every branch circuit is adequately sized. Check storage and application throughput too, since a slow receiving system cannot be fixed with more WAN capacity. Agree which jobs can be staggered and who controls their schedules. Then model degraded operation separately. Decide whether backup jobs pause, guest access is restricted or only essential transactions and calls continue after a failure. Size the surviving path for that agreed mode and test the transition. Netavo provides [Ethernet access from 100M to 10G and private WAN](https://netavo.com/services/connectivity); the appropriate service rate follows from this demand model rather than replacing it. ## Investigate the path before buying more bandwidth More capacity helps when a link is genuinely congested. It does not automatically fix delay, packet loss, unstable wireless coverage or an overloaded endpoint. For voice in particular, packets arriving late or irregularly can damage a conversation even when average utilisation looks modest. Measure at useful boundaries. Compare a wired endpoint with wireless use, observe the access link during the complaint and identify any simultaneous upload or backup. Look at short intervals as well as longer averages. A brief queue can affect an interactive application without producing an obvious daily utilisation peak. Plan traffic treatment at the deployment level and verify that the devices involved implement the intended policy. Prioritisation can help important traffic when a local queue forms, but it cannot create bandwidth or correct an unrelated fault farther along the path. Netavo provides [hosted telephony and SIP trunking](https://netavo.com/services/voice), making voice demand a relevant part of the overall connectivity discussion. For [retail and multi-site estates](https://netavo.com/sectors/retail-and-multi-site), acceptance should use representative business activity at several locations together. Test cloud access, inter-site applications, calls and scheduled transfers, then repeat the essential workload under the agreed degraded conditions. Keep the model and measurements as a baseline. Review them when applications, staff patterns or backup volumes change, so upgrades respond to evidence rather than the first report that the network feels slow. ## Common questions ### Can we size the WAN from the number of staff? Headcount is only a starting point. Concurrent applications, traffic direction, shared destinations and scheduled transfers produce a more useful demand model. ### Why can backups affect calls? A backup can fill a shared link or local queue, delaying other traffic. Confirm the actual bottleneck and review scheduling, capacity and deployment-level traffic treatment. ### Should the backup connection match the primary speed? That depends on the required degraded operation. Define the work that must continue, estimate its concurrent demand and test that the surviving path can support it. ## Related services and sectors ### [Connectivity & WAN](https://netavo.com/services/connectivity) Fibre and Ethernet access, private WAN and resilient connectivity, from a single site to a national estate. ### [Cloud Voice & Numbering](https://netavo.com/services/voice) Hosted telephony, SIP trunking and numbering on our own platform, for a single user or a contact centre. ### [Retail & Multi-site Estates](https://netavo.com/sectors/retail-and-multi-site) Fibre, Ethernet and private networking for branches and head offices, with mobile failover and estate telephony. ## Build a capacity plan around your applications Share your site list, application mix, busy periods and backup windows. We can discuss Ethernet and private WAN capacity against normal and degraded operation. [Work with us](https://netavo.com/work-with-us) Source: https://netavo.com/insights/sizing-a-multi-site-wan