Coworking Internet Bandwidth Calculator: Calls and SLAs

Executive Summary

A coworking internet bandwidth calculator should compare simultaneous endpoint demand against available upload and download separately. Microsoft Teams explicitly sizes bandwidth per endpoint, while Google's organizational method multiplies participant demand by peak concurrent participants. Counting memberships or remote meeting attendees alone misses the devices actually sharing the local connection. ^{[1] [2]}

For a transparent starting point, Zoom desktop group 720p video recommends 2.6 Mbps upload and 1.8 Mbps download per endpoint. ^[3] Teams meeting video recommends 2.5 Mbps upload and 4 Mbps download. ^[1] Google's current small-organization table lists 1080p Meet at up to 3.6 Mbps in each direction, with a separate group-meeting inbound allowance of up to 4 Mbps. These are different scenarios, rather than interchangeable definitions of a call. All were checked on October 19, 2026. ^[2]

The worksheet below adds explicitly chosen background traffic and 30% additive planning headroom, then tests each direction. In the hypothetical Zoom example, all-calling teams of 2, 5 and 12 people require respectively 9.36/11.18, 19.50/18.20 and 43.16/34.58 Mbps upload/download, including the stated background allowances. These are reproducible calculations, not vendor promises or measured workspace results. ^[3] A nominal gigabit connection supplies no member allocation by itself; TELUS, for example, qualifies maximum speeds by wired connection and optimal network conditions. ^[4]

Capacity is only the first decision. A buyer should compare call statistics, repeated tests at the intended desk, and the written service commitment. CIRA recommends direct Ethernet for accurate testing; Cloudflare distinguishes loaded from idle latency; and Wi-Fi prioritization alone does not guarantee service quality. ^{[5] [6] [7]} Resilience needs separate evidence: Bell's dedicated-service description defines a customer-facing Ethernet demarcation, and Videotron distinguishes connection backup from backup power. ^{[8] [9]} The practical outcome is an auditable choice among a desk, suite and home fallback: accept a workspace when measured busy-hour demand fits, representative calls remain usable, and recovery arrangements match the team's needs. No operator, including this report's publisher, receives a performance rating from advertised speeds.

Introduction and Background

For a Montreal freelancer, the relevant internet question is whether a client conversation remains usable from the seat they intend to buy. For a small team, it is whether that remains true when colleagues join separate meetings, share moving content and synchronize files. The useful purchase specification therefore begins with the working day rather than a building's advertised connection.

Bandwidth describes a data rate, commonly expressed in megabits per second (Mbps). Upload concerns traffic sent from the workspace; download concerns traffic arriving there. The Canadian Radio-television and Telecommunications Commission (CRTC) separates these directions and identifies 50 Mbps download and 10 Mbps upload as Canadian access targets. Those targets are not a coworking member's allocation or a video-quality guarantee. ^[10]

This report treats capacity, quality and resilience as separate decisions. Capacity asks whether simultaneous demand fits. Quality asks whether packets arrive promptly and consistently. Resilience asks what happens when the normal path becomes unavailable. Bottleneck queues can add delay, giving a technical reason to assess call quality alongside throughput. ^[11]

The intended reader is a solo remote worker or a team choosing between shared desks, a private suite and a home-office fallback. The examples are deliberately editable. A suite is not assigned a network advantage simply because it has a door, and the worksheet does not assume that unused building capacity is reserved for its occupants. Those are questions for the operator and the agreement.

Sources were checked on October 19, 2026. Vendor recommendations describe particular applications and operating conditions; this report's headroom, background allowances and decision rules are identified as planning choices. The resulting calculator is a buyer's screening method. It does not certify any building, promise uptime or replace a network assessment where the consequences of an interrupted session justify one.

Key Changes: Size the Busy Hour Instead of the Brochure

Count endpoints and choose the right scenario

An endpoint is a participating device on the connection. A person joining Teams from both a computer and a phone can represent separate endpoints. Conversely, a room of colleagues using a shared conferencing device should be entered according to its actual connected equipment. Microsoft's endpoint definition supports this distinction. ^[1]

The platform matters, but so do meeting type and quality setting. Table 1 summarizes selected official requirements verified on October 19, 2026. The Teams page displays a July 9, 2026 update; ^[1] Google's network-preparation page displays October 13, 2026 UTC. ^[2] The fetched Zoom requirements did not expose a last-updated date. Verification date and document update date serve different purposes. ^[12]

The table is an input menu, not a ranking of applications. In particular, a resolution-specific entry should not silently replace a group-meeting allowance. Different layouts, received video and meeting policies mean that equivalent-looking labels need not describe equivalent traffic. Microsoft documents that its media-bitrate policy applies to uplink and downlink media, reinforcing the need to ask about managed-client settings. ^[13]

Separate sharing, synchronization and headroom

Screen sharing is not a universal fixed increment. Zoom desktop lists 50 to 75 kbps for screen sharing without a video thumbnail, while its web-app document lists 100 to 300 kbps for 1080p sharing without a thumbnail. Choose the requirements page that matches your Zoom client and screen-sharing scenario. ^{[3] [12]} Google also distinguishes still content, which needs no further sharing bandwidth once loaded. ^[2]

For the worksheet, enter a separate sharing allowance only when it is additional to the selected scenario or a deliberately conservative reserve. Do not add every platform table row as though vendors required that total. For a presentation-heavy team, test the actual combination of camera, slides, animation and received video. Microsoft's guidance that whole-screen sharing uses more bandwidth than sharing a window supports testing the intended workflow. ^[14]

Headroom is a chosen planning margin. The calculations here multiply total estimated traffic by 1.30. That is 30% added to estimated demand; it is not a claim that 30% of the circuit remains unused, and it is not a platform requirement.

Implementation Considerations and Process Changes

Fill in a shared-network worksheet

The following inputs turn a generic video-conferencing bandwidth calculator into a workspace decision. Enter the same boundary throughout: either the team's available service or the whole site's demand and capacity. Mixing a team's calls with the building's headline speed produces an unsupported answer. The bottleneck concept concerns the limiting path, not the largest advertised link. ^[11]

• Peak on-site people: Use the busiest credible working period, including visiting colleagues.
• Concurrent endpoints: Count devices transmitting or receiving calls locally, grouped by platform and scenario. ^[1]
• Video settings: Record meeting type, intended resolution and the source row selected.
• Sharing allowance: Identify whether it is included in the scenario, separately measured or a conservative addition.
• Background upload: Include expected cloud synchronization, file delivery and backup traffic.
• Background download: Include updates, incoming files and other simultaneous work.
• Available service: Record upload and download observed at the intended seat, plus any documented allocation.
• Planning margin: Choose an explicit additive headroom percentage and explain why it suits the workload.

Google's concurrent-participant method supports summing simultaneous demand, but its large-organization averages should not silently replace small-team endpoint scenarios. This report uses a transparent sum so readers can replace each assumption. ^[2]

Use separate directional formulas

Let n_i be concurrent endpoints in scenario i; u_i and d_i their respective upload and download rates. Let B_u and B_d represent background traffic and S_u and S_d any additional sharing reserve. Let h be additive headroom, expressed as a decimal.

Planned upload = (SUM(n_i * u_i) + B_u + S_u) * (1 + h)
Planned download = (SUM(n_i * d_i) + B_d + S_d) * (1 + h)
Capacity ratio = MIN(Available upload / Planned upload,
                     Available download / Planned download)

These are this report's planning formulas. A ratio below 1 means an entered direction does not cover modeled demand; a ratio at or above 1 means the entered capacity clears this arithmetic screen. It says nothing by itself about delays, wireless contention or contractual availability.

The weaker direction is the weaker demand-adjusted ratio, not necessarily the smaller raw speed. A download-heavy workload can exhaust download first on a symmetric line. For identical endpoints, the following inverse calculation estimates a count, provided sharing reserves are included in background traffic:

Maximum endpoints = MAX(0, FLOOR(MIN(
  (Available upload / (1 + h) - B_u) / u,
  (Available download / (1 + h) - B_d) / d
)))

Spreadsheet users can replace the named inputs with cells and use SUMPRODUCT for mixed endpoint classes. Keep the vendor source, selected scenario and verification date beside each input. That makes later changes auditable without hiding assumptions inside a single recommended-speed result.

Decide what a member can establish

A member can test their laptop, intended connection and real calls. An operator can supply the wider occupancy, circuit specifications, monitoring and allocation policy. The member cannot infer building-wide spare capacity from an isolated test. CIRA itself notes that testing servers share bandwidth between simultaneous tests, another reason to treat a measurement as evidence about a particular path and moment. ^[5]

If the operator does not disclose a reserved allocation, describe the output as estimated team demand compared with observed desk throughput. Do not describe it as capacity guaranteed to the team. Repeated satisfactory results strengthen the purchase decision, while the agreement determines what the member can require later.

Connection Quality: Why a Gigabit Headline Can Still Be Insufficient

Shared capacity and wireless airtime

An access-circuit rate and a laptop's available throughput describe different points in the system. TELUS qualifies its maximum-speed language by wired access and optimal conditions. Apple explains that wider Wi-Fi channels can increase speed while increasing susceptibility to interference. These are reasons to inspect the intended connection, rather than convert a brochure rate directly into a member count. ^{[4] [15]}

Wi-Fi also needs traffic scheduling. Wi-Fi Multimedia (WMM) assigns higher priority to real-time voice and video; Apple recommends enabling it. However, Cisco explicitly cautions that the existence of priority queues alone does not guarantee quality of service (QoS). The buyer should ask how the deployment was designed and monitored, then observe its behaviour under the expected workload. ^{[16] [15] [7]}

Do not make a generic demand that every application receive the same QoS configuration. Google's Meet guidance recommends avoiding network QoS absent a compelling reason and an appropriate end-to-end model. Wireless prioritization and an Internet-wide service guarantee are different claims. The useful operator question is which policies apply to the actual traffic path. ^[2]

Delay, variation and missing packets

Latency concerns delay; jitter concerns variation in delay; packet loss is the share of transmitted packets that do not arrive. CIRA defines the latter two separately, so a fast throughput result should not be treated as their substitute. ^[17]

Thresholds require attribution and matching measurement definitions. Zoom's statistics guidance recommends latency of 150 ms or less ^[18], jitter of 40 ms or less ^[18], and packet loss of 2% or less. ^[18] Its fetched wording does not establish that its latency number is equivalent to every speed-test ping result. Google's troubleshooting guidance explicitly discusses round-trip client-to-Google delay: highest video quality below 100 ms, with reduced quality at 300 ms or more. Those are Google-specific statements, not a universal network SLA. ^[19]

Round-trip time (RTT) includes travel to a destination and back. A test against a nearby measurement server and a call to an application's media service do not necessarily exercise the same path. Cloudflare's explanation of loaded versus idle latency adds another distinction: delay measured during traffic can differ from delay measured when the connection is quiet. ^[6]

The practical test therefore combines throughput, loaded conditions and application statistics. When calls deteriorate during an upload, inspect the timing and metrics before assuming the remedy is a larger download plan. RFC 8289 explains how queues form at bottlenecks, providing a technical basis for investigating contention and delay together. ^[11]

A Repeatable On-Site Test and Evidence Log

A short visit is a screen, not a guarantee

Use the following five-minute initial protocol as an editorial planning template, then repeat it in the morning, around lunch and in late afternoon. These intervals are proposed sampling choices, not vendor certification requirements. Google's more extensive troubleshooting guidance recommends pinging its Meet media front-end for at least four hours, which makes the limitations of a short visit clear. ^[19]

1. Record the setting: Note seat, time, approximate occupancy, device, connection type and whether a virtual private network (VPN) is active.
2. Measure the access path: Run the same test service each visit; capture both directions and the quality metrics it exposes. CIRA recommends Ethernet directly to the modem or router for accurate results. ^[5]
3. Exercise the real call: Join the normal application, speak, receive video and share representative content. Zoom exposes a test-meeting option in its Statistics tab. ^[18]
4. Introduce expected work: With operator agreement, add ordinary file synchronization or the intended simultaneous team calls. Record loaded delay and observed audio/video behaviour. ^[6]
5. Compare connection options: Repeat a problematic call on permitted Ethernet, and record whether the result improves. Google specifically suggests this comparison. ^[20]

Run tests with the team's normal approved VPN route as well as any permitted diagnostic comparison. Google notes that a VPN adds another network location and may delay video. A satisfactory test with a different routing configuration should not be substituted for the configuration the employer requires. ^[20]

Keep a printable log

For each run, record the following fields. Blank or unavailable metrics should remain explicitly unknown, rather than being entered as zero.

• Context: Date, local time, desk or room, occupancy estimate, laptop and test service.
• Connection: Ethernet or Wi-Fi, network name, band if known, and VPN state.
• Throughput: Upload and download Mbps, plus whether the result was quiet or under expected work.
• Delay: Idle and loaded latency where available, with the destination or tool identified. ^[6]
• Quality: Jitter, packet loss and the application's own statistics, preserving their units and definitions. ^[17]
• Experience: Audible gaps, frozen video, sharing readability, reconnects and whether the meeting remained usable.

Test tools are not interchangeable instruments. M-Lab's Network Diagnostic Tool (NDT) is a single-stream performance measurement. Cloudflare says its speed test does not try to saturate the connection. A difference between results can therefore reflect methodology, not necessarily a change in the workspace. Use consistent tools for comparisons and retain the raw result where practical. ^{[21] [6]}

A member should not deliberately exhaust a shared network to prove a point. Arrange concurrency tests with the operator, keep the workload representative and record its scope. The evidence is strongest when the planned call pattern, actual test and worksheet assumptions describe the same working conditions.

SLA and Resilience: Audit the Commitment Behind the Connection

Calculate a hypothetical downtime allowance

For an example of the underlying arithmetic, the AWS Interconnect SLA expresses uptime as (Maximum Uptime - Downtime) / Maximum Uptime. The following worksheet applies that time-based ratio to hypothetical inputs, not to any coworking operator's offer.

Enter availability A as a percentage from 0 to 100 (for example, 99.9, not 0.999) and measurement period M in minutes. This simple example counts every minute in the entered period and assumes no exclusions.

For a period of full 24-hour days:
M = Number of days * 24 * 60
Permitted counted downtime (minutes) = M * (1 - A / 100)

Hypothetical example: At 99.9% over 30 full days, M = 43,200 minutes, so permitted counted downtime is 43,200 * (1 - 99.9 / 100) = 43.2 minutes, or 43 minutes 12 seconds. These are illustrative inputs and arithmetic, not a forecast of outages or a workspace guarantee.

Before using the worksheet for a purchase, record the actual agreement's measurement period, covered service and handoff, qualifying outage definition, exclusions (including treatment of scheduled maintenance), remedies and claim procedure. Apply its counting rules when determining eligible downtime or a remedy. Keep this contractual allowance separate from measured call quality: assess latency, jitter, packet loss and call continuity through the call log rather than inferring them from an availability percentage.

Specify the boundary and recovery process

A service-level agreement (SLA) needs a defined service boundary, measurement period and remedy. Bell's dedicated Internet description places its demarcation at a customer-facing Ethernet port. That is a useful example of why a circuit commitment should not automatically be represented as a desk-level Wi-Fi commitment. ^[8]

Dedicated and shared describe questions worth investigating, rather than sufficient purchasing answers. Beanfield describes dedicated fibre delivery for its business Internet; Cogeco advertises an SLA addressing jitter and latency for dedicated fibre. Neither description establishes that a coworking membership inherits those terms. Obtain the actual schedule and ask which provisions reach the member. ^{[22] [23]}

Resilience also has several layers. Bell lists physical redundancy separately and describes wireless backup without a minimum bandwidth guarantee. Videotron describes automatic switching to wireless, while clarifying that connection protection does not power the equipment. Those distinctions justify asking separately about path, backup capacity, switching and electricity. ^{[8] [9]}

Table 2, the primary workspace comparison, applies the same evidence standard to each arrangement. It compares purchase questions, not tested provider performance.

The publisher row states the assessment standard rather than supplying an amenity claim or score. A reader comparing a desk and a suite should insist on the same evidence boundary in both cases. A private room may solve acoustic needs while leaving connectivity questions to be answered separately.

Printable questions for a Montreal operator

• Circuit: Is the service dedicated or shared, and where does the quoted speed apply?
• Allocation: Is any bandwidth reserved for this membership or suite, and in both directions?
• Busy hour: What occupancy and call load were present during the supplied measurements?
• Wired access: Can the intended users connect by Ethernet, and is there an extra charge or configuration step?
• Isolation: How are guest, member and operational networks separated? Aruba's client-bridging command illustrates that a named setting describes a specific behaviour, not an entire security policy. ^[24]
• Traffic policy: What shaping, upload limits or application prioritization affect calls and synchronization? ^[7]
• Diversity: Who supplies each access path, and do they share entrances, ducts, equipment or last-mile facilities? Beanfield documents partner-carrier last-mile access as a possible delivery method. ^[22]
• Failover: What triggers switching, what was the observed reconnect time, and did existing meetings continue?
• Power: Which modem, router, switch and access-point equipment stays powered, and for how long? ^[9]
• Commitment: Where are measurement scope, exclusions, support hours, reporting process, repair target and member remedies written?

Data Analysis and Evidence

Worked capacity and concurrency calculations (Hypothetical Example)

Table 3 uses Zoom desktop group 720p inputs of 2.6 Mbps upload and 1.8 Mbps download per endpoint. It assumes 2 Mbps background upload, 5 Mbps background download, no separately added screen-sharing reserve and 30% additive headroom. Background allowances and headroom are illustrative choices, not measured office averages or vendor requirements. ^[3]

The first rows answer the team question; the later rows illustrate operator-level sensitivity. They do not claim that those concurrency percentages describe Montreal coworking usage. The same background allowance is held constant to isolate concurrency's effect; a real whole-site calculation must replace it with site-wide traffic. Every result follows the displayed arithmetic using the cited endpoint input. ^[3]

For another hypothetical example, enter available service of 20 Mbps upload and 200 Mbps download into the inverse formula. With the same assumptions, the upload direction allows 5 whole endpoints after rounding down. The 5-person modeled load fits at 19.50 Mbps upload, but the 12-person modeled load does not. The larger download number does not remove the upload constraint. These are calculations on assumed available service, not a judgement about any advertised plan. ^[3]

Evidence quality matters more than a precise-looking total

Sensitivity should include workload as well as occupancy. Change the selected platform row, replace background traffic, and vary headroom. Do not combine Teams' minimum rates with another platform's high-resolution setting and present the result as uniform call quality. Teams documents adaptive prioritization of audio when bandwidth is insufficient, so continuing audio is not proof that the intended video experience was maintained. ^[1]

No pooled measurement in this report establishes coworking speed across Montreal, a typical member allocation or an outage probability. The numerical evidence is vendor requirement data plus explicitly labelled calculations. CIRA, M-Lab and Cloudflare provide useful testing methods, but their results remain tied to the measured path and methodology. ^{[5] [21] [6]}

Implications and Future Directions

Use a decision rule that fits the working day

The following red, yellow and green classifications are proposed purchasing rules, not certified network grades. They combine the worksheet with observed calls and contractual evidence. These rules keep a favourable arithmetic result from substituting for call tests or a written commitment; wireless queues alone do not guarantee quality. ^[7]

• Green: The modeled demand fits in both directions, repeat calls at the intended seats are usable, and support and recovery arrangements meet the team's stated needs.
• Yellow: The arithmetic fits but peak-period evidence, wired access, allocation or backup behaviour is unknown. Seek another test or a short commitment while closing the specific gap.
• Red: The modeled demand exceeds entered available service, representative calls remain unsuitable, or the arrangement lacks a recovery option the team has declared essential.

For a solo caller, this can support choosing a desk with a repeatable test and a workable fallback. A hybrid team should model days when people overlap, rather than average attendance. A client-facing video day warrants rehearsing the actual room, presentation workflow and reconnect process. These are workload-based recommendations, not claims that any accommodation type has inherently better Internet.

Network reviews should also follow changes in devices, occupancy and conferencing settings. Microsoft's media policy can affect uplink and downlink, while an application's intended sharing workflow changes demand. Keep assumptions and test logs together so the buyer can distinguish changed requirements from changed service. ^{[13] [14]}

Cost comparisons should wait until comparable current quotes and service boundaries are available. No break-even calculation is supplied here because a nominal circuit rate, a workspace membership and a backup connection do not establish comparable delivered service. The immediate decision is whether evidence supports the required working day, followed by the commercial terms for that arrangement.

Frequently Asked Questions (FAQs)

How much bandwidth does a coworking space need?

Sum its simultaneous local endpoints in each direction, add other expected traffic and apply an explicit planning margin. Google's concurrency method supports this structure. Whole-site planning needs whole-site demand; a member's worksheet estimates only that member's or team's needs. ^[2]

What upload speed is needed for simultaneous Zoom calls?

For the group 720p scenario used here, multiply concurrent endpoints by 2.6 Mbps upload, then add background traffic and chosen headroom. The worked examples show the calculation. Different Zoom scenarios require their own inputs. ^[3]

Does dedicated Internet guarantee a call will survive failover?

The product label does not establish that outcome. Bell's documentation separates redundancy options and states that wireless backup lacks a minimum bandwidth guarantee. Request observed switching and reconnect results plus the applicable contract. ^[8]

Which terms help in a Montreal site visit?

For an English-language checklist used with a French-speaking operator, ask for upload speed, or vitesse de téléversement. ^[25] The CRTC's French terminology also uses latence for latency, gigue for jitter, and perte de paquets for packet loss. ^[25] Record each test tool's definitions alongside the terms.

Conclusion

A useful coworking internet bandwidth calculator starts with the busiest credible working period, counts local endpoints and preserves upload and download as separate constraints. It identifies the selected application scenario, adds visible allowances and headroom, and shows the arithmetic. The result is understandable enough to challenge and editable enough to update.

That calculation should lead to a purchase test rather than a performance score based on a headline speed. Bring the intended device and normal work configuration, test the actual seat, reproduce simultaneous calls where permitted and retain the results. Treat missing measurements as unknown. A successful visit is valuable evidence, while a written commitment answers a different question about ongoing service.

The reliability decision then follows the same boundary discipline. Ask what the operator monitors, what the agreement covers, which equipment remains powered and how a backup path behaves. A second connection is useful only to the extent that its operation matches the team's recovery needs.

For Montreal freelancers and small teams, the strongest choice is the arrangement with evidence that matches their working day. A desk, suite or home fallback can be assessed using the same worksheet, call log and operator questions. Keep the conclusion proportional to that evidence: modeled capacity, observed quality and documented recovery, each stated separately.