A speed test can show a large number while your next meeting still sounds like a conversation over a walkie-talkie. The number is not necessarily wrong. It may simply answer a different question from the one you care about.
Remote work needs enough capacity in both directions, reasonably consistent delivery and a data allowance that lasts. These are separate constraints. Buying more gigabytes does not cure delay; buying a faster plan does not guarantee that a crowded guest network will remain stable.
Start with the task, not a universal speed target
Email, live conversation and uploading a project make different demands. Email can usually wait for a short interruption. A call needs packets to arrive in time to be useful. A large upload needs sustained upstream capacity and enough allowance to finish.
This is why “good internet for remote work” needs a description of the work. Two hours of editing documents and two hours of high-resolution video meetings are not equivalent. Nor is downloading a presentation equivalent to uploading a recording of the same size: the upstream and downstream rates may differ substantially.
Build your requirement around the busiest necessary overlap. A solo worker attending one call has a different need from two people making separate calls while a laptop uploads video. The second setup should be tested with that overlap, not inferred from the first person's successful browsing.
Read upload and download as a pair
Download is data arriving at your device. Upload is data leaving it. A meeting involves both, and the upload figure is easily overlooked when a provider advertises one prominent headline speed.
For a concrete reference, Zoom's Web App documentation recommends 1.2 Mbps in each direction for a 720p one-to-one video call. Its group-call guidance recommends 2.6 Mbps upload and 1.8 Mbps download for 720p. These are bandwidth planning recommendations, not promises about exact data consumption or every Zoom client and meeting layout. Zoom Web App requirements
The lesson is not that reaching one number guarantees a good call. It is that the weaker direction can be the limiting one. A connection with abundant download capacity and a heavily occupied upload may make everyone else look clear while your own video freezes for them.
Leave room for other traffic and variation rather than targeting the published requirement exactly. There is no single scientifically justified percentage of spare capacity for every venue. The practical check is whether the real task remains usable under the overlap you expect.
Mbps and gigabytes answer different questions
Mbps describes a rate: megabits per second. GB describes an amount. Using decimal units, eight bits make one byte, so a sustained combined rate of 1 Mbps for an hour transfers approximately 0.45 GB.
That conversion gives a useful planning model:
| Hypothetical sustained combined rate | One hour | Ten hours |
|---|---|---|
| 1 Mbps | 0.45 GB | 4.5 GB |
| 3 Mbps | 1.35 GB | 13.5 GB |
| 5 Mbps | 2.25 GB | 22.5 GB |
“Combined” here means upload plus download. A hypothetical 1.5 Mbps sent and 1.5 Mbps received totals 3 Mbps for this calculation. These figures are arithmetic examples, not measured meeting consumption. Real applications adapt, and background traffic and protocol overhead complicate the comparison.
Use the model to see scale, then inspect your own device's usage over a representative working period. A plan sized around maps and messaging can be inadequate once the laptop joins the hotspot. The laptop has not become unusually wasteful; you have changed the workload.
Estimate transfer time before promising a deadline
A 2 GB file contains approximately 16,000 megabits in decimal units. At a sustained 10 Mbps upload, the ideal transfer takes 1,600 seconds, or about 27 minutes. At 2 Mbps it takes 8,000 seconds, or about two hours and thirteen minutes.
Those are lower-bound calculations. They exclude overhead, interruptions and any time the receiving service spends processing the file. But they are enough to change a work decision. Starting a large upload twenty minutes before a meeting may be unrealistic even though the connection feels quick when opening web pages.
There is also a cost to overlap. If the upload consumes the available upstream capacity, the meeting has to compete with it. Pause or schedule the transfer when permitted, or send the approved smaller deliverable first. Do not solve a bandwidth problem by moving confidential work to an unapproved service.
Delay is not the same as slowness
Latency is delay; jitter is variation in delay; packet loss means some transmitted pieces do not arrive. For conversation, consistency matters because late or missing sound cannot always be repaired in time for the listener.
Microsoft's Teams quality guidance evaluates these characteristics separately from simple throughput. Its diagnostic thresholds belong to its own reporting context, so they should not be treated as universal pass/fail numbers for every network or application. Microsoft Teams quality review guidance
A useful analogy is a delivery road. Bandwidth describes how much can travel along it; latency describes how long a journey takes. More lanes do not shorten every journey, and an intermittently blocked road can remain unreliable despite having plenty of lanes.
For your working day, observe the symptoms as well as the measurement. Long conversational pauses, repeated reconnects and missing syllables matter even when a speed test looks impressive. A short test call to the actual service can reveal a problem a nearby speed-test server does not.
Test the place and time you intend to work
A result from the lobby is not a result from the desk behind a thick wall. A quiet afternoon is not the same usage condition as the evening. Treat a test as a sample, not a certificate for the building.
Try the connection where you will sit, using the laptop and required VPN you will actually use. Open the document or system needed during the call. If you normally share your screen, include that in the rehearsal. One successful test cannot guarantee tomorrow's performance, but it narrows the uncertainty more effectively than a generic “fast Wi-Fi” description.
Avoid repeatedly running large speed tests on a small cellular allowance. Measurements themselves transfer data. Test with a purpose, record the useful result, then move on to the actual work.
Decide what can be reduced when capacity falls
A fallback should preserve the important outcome, not every optional feature. Depending on the meeting and its rules, turning off video, avoiding unnecessary screen sharing or switching to an approved audio route may keep a conversation productive.
Prepare the files and details before the call so that a temporary interruption does not remove access to the agenda. Tell the other participant how you will rejoin. A known fallback channel is more useful than discovering during the outage that the meeting link was stored only in an inaccessible email.
For uploads, the equivalent fallback is a staged delivery: the smallest approved file that allows the next person to proceed, followed by the full asset when capacity permits. Discuss that arrangement before the deadline rather than inventing it under pressure.
A practical buying rule
Buy the plan that supports the workload and the failure you need to survive. If mobile data is only an emergency meeting connection, size it around those meetings plus essential communications. If it will carry the whole working month, include updates, file transfers and every connected device.
Keep the assumptions with the budget. For example, two hours of calls on each of ten workdays at an assumed combined 1 Mbps would use 9 GB before other traffic. A 10 GB package would leave only 1 GB for everything else. This is an illustrative rate, not a prediction of Zoom consumption; replace it with your own observed usage when available. Use the backup connectivity guide to reserve capacity for the work that cannot wait.
A large file transfer creates a different problem from a meeting: the connection may be fast enough for calls but too slow to finish a backup before departure. Work through the backup and file-sharing guide, then use the venue work routine to check the connection where you will actually sit.
Method: source bandwidth recommendations checked on 11 October 2026. Calculations use decimal GB and theoretical sustained rates; they are not field tests or guarantees. Network conditions and application behavior vary.
