When someone says “the internet is slow at the office”, they almost never actually have an internet problem. They have a symptom —the ERP that lags, the video call that drops, the files that won’t load— and a hasty conclusion. The provider gets a call, runs a test from their exchange, sees that “everything is fine” and closes the ticket. Back to square one, with the team losing hours and nobody taking the blame.
The only way out of that loop is to stop giving opinions and start measuring. With hard data you can prove in an afternoon whether the slowness is in your own network or on the provider’s line, and that same data is what makes a complaint impossible to ignore. Here’s the method we use to diagnose it without guessing.
“The internet is slow” is almost never just the internet
The slowness people suffer is almost always the sum of several bottlenecks, and the provider’s line is usually the least guilty of them. The reasoning mistake is treating the whole chain —your laptop, the Wi-Fi, the router, the line and the server at the other end— as one single thing called “the internet”. It isn’t. If you don’t separate the links, you’ll blame the wrong one.
These are the usual suspects that disguise themselves as “slow internet”, ranked by how often we run into them in a real office:
- The Wi-Fi, not the line: a saturated consumer-grade access point, channels overlapping with the neighbour’s, half the office hanging off a free router. The line can deliver 600 Mbps and only 40 reach the laptop at the far end.
- Devices and cabling: a PC with its disk at 100%, a network cable that’s been trodden on for years negotiating at 100 Mbps instead of 1000, a cheap switch that drops packets under load.
- Saturation of the line itself: it’s not that the line is “faulty”, it’s that you’re filling it up. Twenty people on video calls plus one upload to the cloud can exhaust the upstream bandwidth, which is usually far lower than the downstream.
- A backup or a sync at the wrong time: the backup that kicks off at midday, OneDrive uploading 40 GB, Windows updating thirty machines at once. Everyone notices “slow internet” and nobody knows why.
- DNS: pages take a while to “start” loading but then run fast. A slow or misconfigured DNS server adds a delay to every site you open and gets mistaken for a lack of speed.
That’s why the provider is almost always “right” when they measure: their test checks their own segment, and their segment is usually fine. The problem lives inside your office, or only shows up at certain hours. To prove it you have to measure yourself, on your own network.
How to measure properly, not with a random speed test
Mistake number one is opening a speed test on your phone over Wi-Fi, seeing an ugly number and taking it as final. That figure mixes Wi-Fi, device, time of day and line, and it’s useless for a complaint. Measuring properly means isolating variables and repeating. It takes no more than an afternoon and it completely changes the conversation.
- Measure over cable, not over Wi-Fi: plug a laptop straight into the router with a network cable. If it’s fine over cable and bad over Wi-Fi, your problem is the Wi-Fi, not the provider. It’s the most revealing test and the one almost nobody runs.
- Measure at different times: first thing in the morning, at midday and at the end of the day. If it’s only slow at 12:30, don’t look at the line: find out which process fires up at that hour (a backup, a sync, your provider’s peak hour).
- Watch latency and packet loss, not just speed: a line can deliver its megabits and still be “choppy” if it has high latency or drops packets. A sustained
pingto a stable server tells you more than any speed meter about why video calls keep breaking up. - Note the conditions: which device, over cable or Wi-Fi, at what time and against which destination. Without that record you don’t have evidence, you have an anecdote.
- Repeat before concluding: an isolated reading proves nothing; a pattern that repeats three days in a row at the same hour does.
With these five tests you now have something the provider can’t wave away with “it looks fine from here”: you have your own evidence, taken where and when the problem actually happens.
How to isolate the cause: your network or the provider’s line
Isolating the cause is a funnel: you rule out links one by one, from the device outwards, until a single culprit is left. The logic is simple. If the problem disappears when you swap a piece on your side, it was yours; if it persists all the way to the last point you control, the ball is in the provider’s court.
The path, in order: first rule out the device (does it affect one PC or all of them?). Then the Wi-Fi (is it fine over cable?). Then saturation (is it always slow or only with a lot of people or at a certain hour?). And finally the line: with a laptop cabled directly into the router and nothing else consuming bandwidth, if latency spikes or you lose packets consistently against a stable destination, then yes, you’ve reached the provider.
The provider doesn’t respond to complaints, it responds to data. “It’s slow” gets filed away; “4% packet loss over a cable direct to the router, every day from 9 to 11” doesn’t.
The step up in quality comes when you stop measuring by hand and monitor continuously. A probe that watches the line around the clock records latency, loss and real speed minute by minute, and leaves a history behind. At that point there’s no more arguing: you show a three-week chart with the daily outage, exact time and pattern. It’s the difference between “I think it fails in the afternoons” and “here it is, every day at 17:00”. That record is exactly what a 24/7 monitoring service provides.
How to complain to the provider with evidence they can’t ignore
A complaint is won or lost in its first sentence. If you open with “the internet is terrible”, the technician will run their routine test, see their segment is fine and close the ticket. If you open with concrete data, they’re no longer defending their network: they’re explaining an anomaly that you have documented.
A complaint that works carries three things: measurements over cable direct to the router (so they can’t blame your Wi-Fi), a clear time pattern (at what hours and how often) and the exact metric of the problem (latency, loss percentage, real speed versus the contracted one). With that, you demand a ticket number in writing and that they open a line fault, not a remote router reboot. Keep every reply: if the problem is recurring and they’re not delivering the contracted throughput, that documentation is your leverage.
And when do you stop complaining and switch lines? When the data proves a sustained breach and the faults get closed without being resolved, insisting costs more than acting. At that point the sensible decision is usually twofold: a second backup line from a different provider with automatic failover, so an outage doesn’t stop you, and migrating the main service. But that’s only decided well with the history in front of you: without data, changing providers is swapping one problem for another blindfolded.
How MagicBoxDesk helps you
Diagnosing a network thoroughly takes time and tools a business doesn’t always have on hand, and doing it right is the difference between solving the problem and paying months of extra fees for a line that isn’t failing. At MagicBoxDesk we do that work for you: we measure over cable and over Wi-Fi, at different times, we leave a monitoring setup watching the line to capture the pattern, and we tell you with data whether the blame lies with your Wi-Fi, a device, a poorly scheduled backup or the provider. And if it’s the provider, we handle the complaint ourselves, with the evidence on the table, until it’s resolved or it’s time to switch supplier.
It’s part of what outsourcing your IT to us means: no more losing mornings wrestling with phone support and having someone who makes sure the infrastructure just works, remotely or coming out to your office anywhere in Spain. Tell us what’s happening and at what times, and we’ll measure it. Request a no-obligation quote and we’ll tell you what you really need.
