What a Help Desk Should Actually Do

A help desk has three jobs. Get you working again. Find out why it broke. Stop it breaking again for everybody else. The first is the one that gets measured, so the other two are the ones that quietly go missing.

You can tell which sort of desk you have by looking at last year. If the volume of tickets is roughly what it was, and the same words keep appearing in them, the desk is doing job one properly and nothing else. That is not laziness. Job one is urgent and somebody is waiting, so jobs two and three lose every time unless somebody deliberately protects them.

A setup that has been looked after for a year should generate fewer interruptions than it did at the start, because the causes underneath the interruptions have been dealt with one at a time. Quieter is the point. If your desk is not getting quieter, ask why.

Before anybody touches anything, four questions get answered. Is this one person or is it everybody. Is it new, or has this been raised before. Did anything change recently. And is anything else broken at the same time, which is the question that most often turns three separate tickets into one incident.

Whether anyone else has it is the most useful of the four and the one most often skipped. One person who cannot open a file is a permissions problem. Four people who cannot open a file is a storage problem, and treating it as four permissions problems will burn most of a day before somebody notices.

You should come out of those ten minutes with a name. Not a queue, a person. Somebody who owns the thing until it is finished or until they hand it to a named someone else. A ticket with no owner sits in a shared inbox that everybody can see and nobody feels responsible for, and it will still be sitting there on Friday.

Here is the pattern that costs you the most and shows up on no report. The label printer in dispatch drops off the network most Monday mornings. Somebody rings, an engineer reconnects it, the ticket closes in minutes, everyone is happy. That has now happened many times and the underlying cause has never been looked at once, because each individual instance was too small to be worth investigating.

A ticket system that closes fast and never groups is an extremely effective machine for hiding a problem like that. The fix is boring. Search the closed tickets for the same symptom before starting work, and tag by cause rather than by symptom. Printer offline is a symptom. A switch port that resets when the machine beside it powers up is a cause, and you only find it if somebody is looking across tickets rather than down at one.

Then somebody makes a pass over the top repeats each month. Not a report generated automatically and filed. A person, reading the list, asking which of these we are going to stop. Two or three a month is a realistic pace and it adds up faster than anyone expects.

If you have never had that conversation with your desk, ask for the list. If they cannot produce one, you have learned something useful about how your tickets are being handled.

This is the part nobody says out loud. Reconnecting the printer takes minutes. Replacing the switch, rerunning the cable, or getting a vendor to admit their firmware is at fault takes days and sometimes money. The desk cannot authorise that. All it can do is make the case and put it in front of somebody who can.

A good case is short and specific. This has happened this many times since the spring. Each time it stops dispatch for a while. Here is what we think the cause is, and here is the part we are not yet sure about. Fixing it involves this work, roughly this cost, and here is what happens if we do nothing. No drama, no scare tactics, the trade laid out so that a business owner can decide.

If your provider never brings you cases like that, one of two things is true. Either your setup genuinely has no recurring problems, which does happen and is worth confirming, or nobody is looking. Ask which. A good desk will not be offended by the question.

The worst close on a ticket is the silent one. Status changed to resolved, no note, no explanation. It might have been fixed. It might have been fixed by the user restarting the machine before anybody got there. It might come back on Thursday. You cannot tell, and neither can the engineer who picks it up next time.

A close should say what was wrong in words a non technical person can read, what was done about it, and whether it can happen again. Three lines will do. It takes a minute to write and it saves an hour the next time somebody searches for the same symptom, which they will.

The other half of telling somebody is telling them before rather than after. The certificate that expires next week. The disk filling up on the server. The software version losing support in the spring. Warnings like those are cheap to send and they are the clearest sign that somebody is watching rather than waiting.

You can make your own answers faster, and this is the practical part. A ticket that says it is broken produces a reply asking what is broken. You are in a meeting. You answer at five. We answer the next morning. The fault has now taken a day and nobody has done anything wrong.

Give us these and most tickets skip that round trip entirely. What you were doing when it happened. What you expected and what happened instead. The exact words of any error message, typed out or photographed, and a photo of the whole screen rather than a crop, because the useful detail is usually the bit that got cropped out. When it started. Whether anybody else has the same thing. Whether anything changed recently, including things that feel unrelated.

Then tell us honestly how urgent it is. Not how urgent it feels at the moment you are annoyed, but whether you are stopped, slowed, or merely irritated. People who mark everything urgent get treated as though nothing is, eventually and without anybody deciding to do it. People whose urgent genuinely means urgent get a very fast response, because the desk has learned to believe them.

One more thing. If you found a workaround, say what it was. It often tells us more about the cause than the description of the fault does.

There is a real difference between an engineer who knows the machine in dispatch prints the delivery labels and one who sees a printer ticket. The first understands that vans are waiting. The second is being perfectly reasonable and is about to schedule it for tomorrow.

That knowledge does not arrive on its own. It comes from the same people seeing your account regularly, from documentation that says what each system is for in business words, and from somebody having walked around your premises at least once. A desk that has never seen where your equipment lives will keep making small, sensible, wrong decisions about priority.

It also comes from you. Tell your provider your calendar. Month end, the busy season, the day the auditors arrive, the week the factory shuts. A desk that knows a stocktake is happening on Saturday plans its Friday afternoon differently.

A large share of any desk's volume is the same handful of questions. How do I get on the network from home. Why does this document open read only. Where has the shared folder gone. Each is quick to answer and each costs somebody an interruption and somebody else a quarter of an hour of waiting.

The answer is usually not a portal. Most self service portals get built, get announced, and then get used by nobody, because searching them is worse than emailing a person who will definitely reply. What works is smaller. Fix the cause where there is one. Change the process where there is not. Put the short answer where people already look, which is normally their email or wherever your company keeps its notices.

Keep a count of these and treat a rising one as a signal about something else. A sudden run of tickets about the same document library usually means a change was made and not communicated. A steady trickle of the same question from new staff means the induction is missing a page, and fixing the page is cheaper than answering the tickets.