Home › Topics › The Internet Is Slow › Reducing Them

Reducing 'The Internet Is Slow' Tickets Before They Arrive

Friday, 15:30, at Acme. Rosa runs the desk of four and is doing the quarterly numbers for Monday's meeting with the operations manager. The manager has one question written on a sticky note: "why is the internet always slow?" Rosa's export says thirty-eight tickets in the quarter with "slow" and "internet" or "Wi-Fi" in the subject. Each was closed by a different technician in a different way, most of them with "restarted, user says better". She reads the first ten. Four are from the same two corners of the second floor. Two are from the large meeting room on a Tuesday. One is a man in finance who sends a ledger extract the size of a film to the auditors every month and has raised the same ticket every month. The internet at Acme, she realises, is not always slow. The same six things are always slow, and the desk has been fixing them one ticket at a time for a year.

Reducing slow-internet tickets means finding the handful of standing causes behind the category and fixing each one once. The fix is a map, a cable, a room setting, an article or a conversation, so that the tickets stop arriving rather than keep being closed. It is problem work rather than ticket work, and it pays back in technician hours within a quarter at most desks that try it. This article is part of our The Internet Is Slow series and is the last in it. The first five articles are about the ticket in front of you: the isolation frame, the Wi-Fi causes, the one-site case, the measurements and the home network. This one is about the next quarter's tickets, and how to make sure fewer of them exist.

It covers counting the category by branch before spending anything, then the coverage map. Next come the meeting-room capacity question, the wired option at the desk, and the self-check article visible to everyone. It covers expectation setting for the big-file people, then when to raise the sizing question about the line itself. It ends with measuring the category over time, a short war story, and the self-check article outline to copy, in that order.

Count the Category by Branch Before Spending Anything

The first job is to find out what the slow-internet tickets actually were, because the category name hides six different problems and the fixes for them have nothing in common. Export a quarter of tickets with "slow", "internet", "Wi-Fi" or "connection" in the subject. Read them, all of them, with a column for the branch and a column for the location. The branch is the one from the isolation frame: user, device, network wireless, network wired or line, one service, expectation, home. The location is the floor and corner, or the room, or "home". If the desk has been writing the branch into the ticket note as the first article asks, this is a filter. If it has not, it is an afternoon's reading, and it is the best afternoon the desk will spend this quarter.

Rosa's thirty-eight came out like this, and the shape is the usual one for an office of her size, give or take a column. Sixteen were wireless, and twelve of those were from two corners of the second floor and the large meeting room. Nine were the device, mostly the oldest laptops in the fleet, and two were docks. Six were expectation, four of them the man in finance and his ledger. Four were one service slow at the far end on two separate days. Three were home. The thirty-eight tickets had taken about fifty technician hours between them, at a rough hour and a quarter each. More than half of those hours had been spent on three places in the building and one person's monthly file. Nobody had restarted anything that was the cause of any of it.

The method of cutting a category by place, time and thing, and of deciding which cut is worth acting on, is the subject of Finding Hotspots in the Ticket Data. The way to read a category's count across months without fooling yourself is in Volume by Category Over Time. This article leans on both rather than repeating them. What it adds is the list of standing fixes for this particular category, in the order most desks should try them. The count comes first because the fixes cost money, time or someone else's goodwill. And a count is the only thing that tells you which of them to spend. A desk that buys a faster line because the internet is "always slow" has bought a solution to the one branch it did not count.

The Coverage Map

The coverage map is a floor plan with the wireless signal marked on it. It is made by walking the building with the known-good device on a quiet morning. During the walk, the signal and a repeatable test are noted at every desk cluster, corridor and room. The plan is then coloured: good, marginal, dead. It takes about an hour per floor for an ordinary office. It needs no equipment the desk does not already own. And most desks have never made one, which is why the same two corners generate tickets for years. The walk-test from the Wi-Fi complaints article is the method; the map is the walk-test done everywhere at once and written down.

Mark three things on the map besides the colour. Mark the access points, where they actually are rather than where the plan says. Mark the obstacles, meaning the kitchen, the lift shaft, the metal cabinets and the glass office with the film. And mark the ticket count by corner from the quarter's reading. That distinguishes the dead corners with tickets from the dead corners nobody sits in. A dead corner with no desks is a fact. A dead corner with four desks and six tickets is a project. The map is the one page that turns it from a complaint into a drawing the network owner can act on.

The fixes for the marked corners are the network owner's and come in three sizes. One is a cable to each desk in the corner, which the desk can often arrange itself. The others are an access point moved or an access point added. Give the network owner the map, the ticket counts and the hours, and let them choose. Then walk the corner again after the change and update the map, because a map that is not updated after changes becomes a historical document within a year. (Keep the old version. Someone will ask whether the second floor was always like that.) The map lives in the knowledge base for technicians, with the date of the last walk on it. It is re-walked after any move of desks, walls or access points, and once a year regardless.

The Meeting-Room Capacity Question

Meeting rooms generate slow-internet tickets in bursts, on the days the big meetings happen. The cause is nearly always that the room's wireless was sized for the room's furniture rather than for the number of people who actually use it. The capacity question is simple to ask and rarely asked. How many people and devices is this room's access point expected to carry at once, and how many does it carry on review day? The answer to the first is usually "nobody decided". The answer to the second is in the tickets, if the desk noted the headcount on each one, and in the calendar if it did not.

Keep a one-page capacity file for the rooms. Record the room and the access point serving it (shared with a neighbouring room or its own). Record the headcount at which complaints start, and the wired ports available in the room. The headcount comes from the tickets over a quarter, not from a figure anyone found elsewhere, because rooms differ and so does what people do in them. Twenty people reading a deck is not twenty people on a video call. Once the file shows that the boardroom fails at eighteen and holds twenty-four, the network owner has a sizing problem with a number on it. That is the only kind they can fix.

Half the fix for rooms is not radio at all, and it is the desk's to make. The room's own screen and call equipment go on a cable, so the heaviest traffic in the room is not in the air. The presenter's position has a wired port and a cable on the table. And the room guide says to use it. The deck is shared before the meeting rather than downloaded by twenty-two people during it. Standardising the rooms so that each one has the same ports, the same cable and the same guide is the subject of Standardising Rooms to Cut Tickets. The wireless capacity is one line in that standard. The remote half of a hybrid meeting has its own complaints, and most of them begin with the room's call going out over a crowded access point.

The Wired Option at the Desk

A cable at the desk removes that desk from the wireless argument entirely, and the standing fix for several branches is simply to decide which desks get one. Three groups qualify at nearly every desk I have seen. These include the desks in the marginal and dead corners on the map and the desks of the people who move large files. The last group is any desk where the dock already carries a wired port and nobody plugged it in. The third group is the cheapest project in this article. An audit of the docks on one floor, with a cable from each dock to the nearest wall port, has at some desks halved the floor's wireless tickets in a month. The cost was the cables and a morning.

Make the wired desk a standard rather than a favour, so that the desk does not have to decide each time. The standard says who gets a wired port without asking (the corners, the heavy movers, every dock). It says how a person asks for one if they think they qualify, and who runs the cable. The standards that stop the desk relitigating equipment for every requester are in the peripherals series. And the docks and cables that fail in the gap between the laptop and the wall are in Docks, Cables and the Things That Break. The wired desk is the same idea applied to the network. A person at a wired desk still has the wireless for the laptop they carry to meetings. They have simply stopped using it for the thing that was slow.

The Self-Check Article Visible to Everyone

The self-check article is a short knowledge base page that anyone in the organisation can read. It walks a person through the five-minute checks that sort most slow complaints. It tells them what to put in the ticket if the checks do not fix it. It is the single highest-return piece of writing in this series. It moves the first ten minutes of every slow-internet ticket from the technician to the requester. And the requester is already at the slow desk with the slow laptop. The outline at the end of this article is the page. The article is written in the voice the knowledge base uses for everyone, with one action per step and nothing a person would need the desk to explain.

Put it where the person is when they are about to raise the ticket, not only in the knowledge base's index. The link goes on the ticket form beside the subject field and in the automatic reply the desk sends when a ticket arrives. It also goes in the reply template the desk uses to close a slow ticket, so that the next time the person reads it before they write. The principle of answering the question at the point of submission, before the ticket exists, is the subject of Deflection at the Point of Submission. And the self-check article is that principle applied to one category. If you run QuerySolv, the page is a knowledge base article visible to everyone rather than to agents only, which is the whole point of it. In any tool, the test is that a person at a slow desk can find it in one click without signing in to anything new.

Expect the article to change the tickets as much as it reduces them. The ones that still arrive will say "I did the self-check; the phone is fine on mobile and slow on the office wireless; it is worse after ten". That is a ticket already in the network branch with its first evidence attached, and a technician can act on it without a visit. The ones that do not arrive include the clinging laptops and the paused syncs, which the self-check fixes at the desk. They include the one-service cases, where the article's "check whether a second site is also slow" step sends the person to the status page instead of the queue. Keep the article short. It will be read by someone who is already irritated, and the guidance for that reader is in the knowledge base series.

Expectation Setting for the Big-File People

Every organisation has a few people whose job involves moving files that the connection was not sized for. They raise the same ticket on a schedule: the finance extract to the auditors, the designer's artwork, the engineer's model, the video for the monthly all-hands. The ticket is in the expectation branch, nothing is broken, and closing it with "restarted, user says better" has taught the person that the desk fixes it for an hour. The standing fix is a conversation, once, with each of them, and it has three parts. It covers what the connection can do for a file that size at that hour. It covers the wired desk or the off-peak slot that makes it faster. And it includes the honest statement that a shared office line will never make a forty-gigabyte transfer instant.

Find them from the count, because they are a short list and they repeat. Rosa's man in finance had raised four tickets in the quarter, on the third working day of each month. The fix was a wired port at his desk and a scheduled transfer. The transfer started when he left on the second working day and finished before he arrived on the third. He has not raised the ticket since. And he sends the desk a cheerful note each month instead, which is the only thing about the category that has got worse. The way to say "it is working correctly" so that it lands as help rather than refusal is in Setting Expectations at the Desk Level. Here it is enough to say that the conversation happens once, with a wired port and a slot in hand, rather than once a month with a restart.

When to Raise the Sizing Question

The line itself is the last standing cause, not the first, and it is raised on evidence. The evidence is the wired reading at the wall from the measuring article, taken at the busy hour over months rather than days. The question it answers is whether the pipe is full when the building is full. If the 11:00 reading at the wall sits at the contract figure while the corners and rooms complain, the line is fine and the money belongs in access points and cables. The 11:00 reading may have fallen as the headcount has grown. Or the upload may be flat at its ceiling every morning while remote workers on the VPN complain. In either case, the line is the limit, and the sizing conversation with whoever pays for it is due.

Make the case in hours, not adjectives, because hours are the currency a manager can weigh. "Slow-internet tickets cost the desk about fifty technician hours last quarter; sixteen of the thirty-eight were wireless and are being fixed with cables and one access point; the remaining line-bound tickets, and the remote team's VPN complaints at ten each morning, trace to the office upload sitting at its ceiling from nine to eleven on three days in five, measured at the wall over two months" is a paragraph that gets a line upgraded, or a clear no with a reason. The one-page format for taking such a case upward is in The Monthly Report They Will Actually Read. The slow-internet line in it is one line, with the count, the hours and the fix beside it.

Standing cause (from the count)The fix, onceWho does itEffort at a fictional desk of four (hours)What it prevents
Two dead corners on one floorCoverage map; cables to the corner desks; one access point moved or addedDesk for the map and cables; network owner for the access pointMap 2 to 4; cables 1 to 2; access point the owner'sThe corner's tickets, usually several a quarter, for good
Large meeting room fails when fullCapacity file; room screen and presenter on cables; deck shared beforehandDesk; network owner for capacityCapacity file 1; cabling 1 to 2 per roomThe burst of tickets on review days
Docks with unused wired portsDock audit; cable from every dock to the wallDeskHalf a day per floorA share of the floor's wireless tickets and the clinging-laptop cases
Old laptops with elderly wireless driversDriver and update pass on the oldest models; refresh listDeskA quarter of an hour per machineThe device-branch tickets from those models
The same person's monthly big fileOne conversation; wired port; scheduled transferDesk1 per person, onceA ticket a month per person, indefinitely
People raising tickets before checking anythingSelf-check article visible to everyone, linked from the form and the auto-replyDesk2 to 3 to write; a quarter of an hour a quarter to reviewThe first ten minutes of every slow ticket, and some tickets entirely
The line at its ceiling at busy hoursThe sizing case, in hours, with wall readings over monthsDesk makes the case; the organisation decides2 to 4 to assembleThe line-bound tickets and the VPN peak, if the case is accepted

Remember: count the category by branch and location before spending anything. The same few corners, rooms, docks and people generate most slow-internet tickets, and each is fixed once with a map, a cable, a setting, an article or a conversation. The line itself is sized last, on wall readings over months, in hours.

Measuring the Category Over Time

The measure of this work is the category's count, by branch, month by month, and the hours beside it. Keep the quarterly reading going after the fixes, with the same branch and location columns. That lets the second quarter be set against the first. Rosa's next quarter came in at eleven slow-internet tickets. One was from a corner that had been cabled and turned out to have a second dead desk behind a cabinet. Two were from meeting rooms on days the capacity file had not predicted. There were four device, one home, three one-service on a single bad afternoon at the far end, and none at all from the man in finance. The hours fell from about fifty to about fourteen, and the difference, thirty-odd technician hours a quarter, is the number that went on Monday's page.

Read the count with care, because small numbers move for reasons that are not yours. A quarter with one far-end outage can double the one-service column without anything in the building changing. And a quiet quarter can flatter a desk that has fixed nothing. Report the branches separately, report the count beside the hours, and give the trend three quarters before calling it a trend. The volume series explains why a month is noise and a quarter is a reading. Where the count stops falling, go back to the reading of the tickets and look for the next standing cause, because there is always one more corner. The category never reaches zero. It reaches the point where every ticket in it is a new problem rather than an old one. And that is the point to stop fixing and start maintaining.

A Short War Story: The Faster Line at Oakfield College

At Oakfield College, the desk lead, a man called Tobias, was asked by the bursar to end the constant complaints that the internet was slow. He did what the complaints suggested. He worked with the network contractor to upgrade the college's connection to the fastest line the budget would bear. The project took a term, a procurement, and most of his spare attention. The next term's slow-internet tickets came in at almost exactly the previous term's number. When a new technician called Imani read the two terms' tickets side by side, two thirds of them were from the same three places. At the far end of the humanities block, two seminar rooms sat beyond a stairwell with no access point of their own. Then there was the main lecture theatre on the mornings it held two hundred students on one access point built for a seminar room. The new line was faster. The signal in the seminar rooms was exactly as absent as before, and the lecture theatre's access point was exactly as full. Two access points and a cabled lectern fixed the three places in a fortnight for a small fraction of what the line had cost. The tickets fell by more than half the following term. The cost was a term of the desk lead's attention and a procurement that would have been needed eventually but not then. The lesson Tobias put in his own notes was that "the internet is slow" is a category and not a cause. A faster line fixes only the tickets that were ever about the line.

The Self-Check Article Outline

The outline below is the knowledge base article, visible to everyone, in the order the person should do the checks. It is written to be followed by someone who is already annoyed and has never heard of an access point. So the steps name what to do and not why, and each one either fixes the problem or rules something out for the next. The desk fills in the two blanks that are local, the name of the status page list and where the wired ports are, and leaves the rest. Review it once a quarter against the tickets that still arrive. If a step is never the fix, cut it. If the tickets keep arriving with the same evidence missing, add the step that collects it.

IS THE INTERNET SLOW? — FIVE-MINUTE SELF-CHECK (knowledge base article, visible to everyone)

1. IS IT ONE THING OR EVERYTHING?
   Open a different, plain website you do not normally use.
   [ ] It loads normally  -> only one site or system is slow. Check its status page: ______________
       If the status page shows a problem, there is nothing to fix here; try again later.
   [ ] It is also slow    -> carry on to step 2.

2. IS IT JUST YOUR DEVICE?
   Ask the nearest colleague whether theirs is slow too.
   [ ] Theirs is fine     -> it is probably your device. Turn its wireless off and on, wait ten
       seconds, and try again. Close downloads, syncs and video that are running in the background.
   [ ] Theirs is slow too -> carry on to step 3.

3. ARE YOU ON WIRELESS?
   If there is a network cable at your desk or on your dock, plug it in and try again.
   [ ] Fine on the cable  -> use the cable at this desk; tell the desk so the corner can be mapped.
   [ ] No cable here      -> carry on to step 4.   Wired ports on this floor: ______________

4. IS IT THE ROOM OR THE TIME?
   Is the room full, or is it a busy time (first thing, mid-morning)?
   [ ] Yes                -> it is sharing. Try again from another room or in twenty minutes.
   [ ] No                 -> carry on to step 5.

5. RAISE A TICKET WITH THESE FIVE LINES
   What exactly is slow: ______________        Since when: ________
   Where you are (floor, room, desk): ______________   Wireless or cable: ______________
   What steps 1 to 4 showed: ______________
   The desk will take it from here. Please do not restart any shared equipment.

Rosa's page for Monday was one paragraph and one table. It showed thirty-eight tickets, fifty hours, six standing causes, four of them fixed or in hand, and one access point requested with a map attached. It had a sentence saying the line was fine at the wall and would be measured for two more months before anyone discussed replacing it. The operations manager read it, asked whether the second floor corners could be done by the end of the month, and took the sticky note off his monitor. The internet at Acme is still slow in one corner behind a cabinet. The desk knows exactly which one.

Frequently Asked Questions

We never wrote the branch into our tickets. Is the quarter's reading still worth doing?
Yes, and it is the only way to start. Read the quarter's slow tickets with two columns, branch and location, and fill them from the notes and the requester's words. Most tickets give enough to place them even when the note says only "restarted". From that quarter on, write the branch as the first word of the internal note, and the next reading is a filter rather than an afternoon.
Who should make the coverage map if we do not own the wireless network?
The desk can, with the known-good device and a floor plan. The map records what people experience at desks rather than how the equipment is configured, and that is the desk's knowledge. Give the finished map and the ticket counts to the network owner or contractor as the basis for changes. Walk the marked corners again after they have made them. A contractor given a map acts in one visit; one given "the second floor is bad" uses the visit to make the map.
How do we know whether the self-check article is working?
There are two signs. The count of slow tickets that arrive with the five lines from step 5 already filled in should rise. The count of tickets closed on the first reply without a visit should rise with it. Most knowledge bases also show how often an article is viewed; a view count that climbs while the category falls is the pattern you want. Review the article against the tickets that still arrive once a quarter and cut or add steps accordingly.
Is it reasonable to ask the big-file people to schedule their transfers?
It is, if the desk gives them something real in exchange. That means a wired port and a scheduled transfer that runs after hours and is checked in the morning. It means a clear statement of what the connection can do during the day. Most people who move large files are happy to send them overnight once someone explains why it is faster and sets it up for them. What is not reasonable is closing their monthly ticket with a restart and letting them discover the limit again each time.
Should the self-check tell users to restart their laptop?
Turning the wireless off and on is cheaper and more often the fix, so the self-check leads with that. A full restart is a reasonable second step for a device that stays slow after the wireless and background checks, and the article can say so. The self-check must say plainly that shared equipment, meaning anything in a cupboard or on the ceiling, is never restarted by the person. Restarting that equipment takes everyone else off the network.
How long before we can tell the fixes worked?
Compare whole quarters, not months. A single far-end outage or a quiet holiday month can move a small count either way for reasons that have nothing to do with the building. The corner and room fixes show within a quarter in their own columns. The self-check and expectation work take two quarters to settle as people learn the habit. Report the branches separately with the hours beside them so that a rise in the one-service column is not read as the corners coming back.

From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.