What Good Support Actually Looks Like

"My laptop won't connect to the projector." It is 08:52, the meeting is at 09:30, and the same sentence lands on two help desks in two different buildings. At the first desk it becomes a ticket with the status New. The user hears nothing until 12:10, when a reply says an adapter is waiting at reception and the ticket is now Resolved. At the second desk a technician replies at 08:58 to say he will be in the room at 09:15 with an adapter. And he is. Both tickets close the same day. Both count as a success on the dashboard. Only one of them is support.

You have been on both ends of that ticket. Most of us have also worked the first desk, usually because the queue was long and nobody had said what the job was. This article is the first in our Helpdesk Fundamentals series. It answers the question a new desk administrator is rarely asked out loud: what does good look like? Not the tool, not the metrics, not the framework. The thing itself.

It covers the difference between answering tickets and running support, and the five properties of a desk people trust. Then we look at what "fast" means to the person waiting, and the gap between a fixed ticket and a resolved problem. We also cover what a good desk feels like from the technician's chair. It ends with a ten-question self-assessment to run on your own desk this week.

The Same Ticket, Minute by Minute

The projector ticket is worth following in detail, because the two desks did almost the same work and produced completely different mornings. The user is Dana, a sales manager at Meridian Parts, presenting to a customer in meeting room 3. The first desk has two technicians and about 180 open tickets. The second desk has two technicians and about 180 open tickets.

Both desks did the work. The first desk fixed a laptop, eventually. The second desk fixed a meeting, then fixed the room for the next person. Then it wrote down which port carries video so nobody has to discover it again. The difference was three sentences at 08:58 and one note at 09:40, and neither cost anything.

The first desk's dashboard was green all week. Nothing on it measured whether Dana got to present.

Answering Tickets Is Not Running Support

Answering tickets is a task; running support is a service. A service is a promise kept repeatedly to people who did not choose you and cannot go elsewhere. Answering a ticket means replying to what came in. Running support means owning the outcome for the person, noticing the pattern behind the ticket, and making the next one easier.

The first desk was answering tickets, and it was not lazy about it. Each ticket was a unit of work to be removed from the queue, and the queue was a pile to be made smaller. Shrinking the pile is satisfying and easy to measure. It is also the wrong goal, because the pile is a symptom. The goal is that people at Meridian Parts can do their jobs. What the desk is for beyond that has its own article, The Helpdesk Mission Beyond Closing Tickets. None of this needs a budget. It needs a decision about what the job is.

The Five Properties of a Desk People Trust

Trust is the desk's main asset. A trusted desk gets tickets early, with good descriptions, from people who expect to be helped. An untrusted desk gets them late and vague, or gets hallway visits, or gets nothing. Five properties separate the two: a trusted desk is reachable, honest, consistent, it remembers, and it improves. Each is a habit, not a feature.

Reachable

Reachable means a person can get a request to you with almost no effort, at the moment they have the problem, and know it arrived. At Northgate Retail the desk address is printed on the back-office screen in every store. The web form has three fields, and every message gets a receipt within a minute. The opposite is a portal that needs a password the user has forgotten, which is, often enough, what they wanted to ask about. A requester portal that needs no account is reachable in this sense. QuerySolv's identifies requesters by e-mail address alone and asks for no password at all.

When the desk is hard to reach, the requests do not stop. They move to the hallway, the group chat, and the technician's personal mailbox, where nothing is counted and nothing is remembered. The hallway is the oldest ticketing system there is, and the least searchable.

Honest

Honest means the desk says what it knows, what it does not know, and when it will next say something. "We don't know why the printer drops off the network yet. Dana is reading the switch logs. I'll update you by 15:00 either way." That reply contains no fix and still makes the user feel looked after, because it gives them something to plan around. The dishonest versions are silence, "we're looking into it" with no time attached, and a status that means nothing outside the tool. Pending is the ticket system's way of saying that we, too, are waiting.

Without honesty the user chases, and chasing becomes a second queue that nobody triages. Every "any update?" is a ticket about a ticket.

Consistent

Consistent means the same request gets the same answer, the same priority, and the same path, whoever picks it up and whichever week it is. On a Monday at Bluewater Bank, Marcus resets a password in five minutes over chat. On the Thursday, Sam asks the same person for a manager's approval first, because that is what he was taught. Both are defensible on their own. Together they are a lottery, and users learn to play it by asking for the technician who says yes.

Consistency comes from writing the rule down for the twenty request types that make up most of the queue. That is the subject of Support Is a System, Not a Person, the next article in this series. When the rule lives in people, the people become the queue's routing table.

It Remembers

A desk that remembers keeps the history of every request and uses it: what was tried, what was said, when, and by whom. Lena at Kestrel Payroll raises her third ticket in two months for the same laptop crash. A desk that remembers sees the pattern at triage and replaces the machine. A desk that forgets fixes it a third time, cheerfully, and will fix it a fourth. Remembering is cheap when the history is in one place; full-text search across every conversation turns "has anyone seen this before?" into a four-second question.

Where the desk does not remember, the user does the remembering for it. Eventually the user stops reporting small things because explaining them again costs more than living with them. That silence looks like a falling ticket count. It is not good news.

It Improves

A desk that improves changes because of what the tickets taught it. The change might be a two-paragraph guide, a fix at the root, a field added to the form, or a step removed. Acme logged twelve tickets in one month about the expense system's login page. The desk wrote a short guide and sent the pattern to the system's owner with the twelve ticket numbers. And the next month there were three. Improvement needs an input, which is why good desks ask the user how it went. They ask for a rating and a comment on every resolved ticket, read by a human once a week. A satisfaction page reached from the link in the agent's reply, a score from 1 to 10 and a comment box, is enough. That is what QuerySolv provides.

A desk that never improves gets the same ticket forever, and the technicians know it. They know which problem is coming back on Monday, and after a while they stop suggesting that anyone fix it. That is how a capable team becomes a tired one. And it is the earliest warning sign of the failures in The Seven Ways Support Quietly Fails.

What "Fast" Actually Means to a User

To the person waiting, fast means "I know someone has it," not "it was fixed in under four hours." An acknowledgment is a human, or a human's commitment, telling the user that the ticket has been seen. It tells them who has it and when they will hear next. The automatic receipt is not an acknowledgment; it is a receipt. It proves the message arrived at a mailbox, and users know the difference.

Waiting with information is tolerable, and waiting without it is not. A user told "we'll have it by 15:00" goes back to work. A user told nothing checks e-mail every ten minutes, then walks over. Acknowledgment within one business hour is achievable from the first day on any desk, because it is a sentence. Resolution time depends on the problem, the vendor, and the parts in the cupboard, and much of it is not yours to promise.

So measure both and promise the first. A service level agreement, or SLA, is a written promise about response and resolution times for each priority. Designing one is a later subject in this library. On day one, the only promise worth making is the one you can keep on your worst day. That means a named person, within the hour, with a time for the next update. Everything else is aspiration, and aspiration does not belong on the poster.

A Short War Story: The Four-Hour Desk

Northgate Retail ran a two-person desk for forty stores. It resolved nearly every ticket within four hours, and the store managers disliked it anyway. The desk worked the queue oldest first, in silence, and replied once, when the thing was fixed. Store staff, hearing nothing, phoned to ask whether their ticket had arrived, and the phone calls ate the time that made the four hours possible. After a survey in which "I never know if anyone has seen it" was the most common comment, the desk added one habit. It was a human acknowledgment within ten minutes during store hours, naming who had the ticket and when they would update. Resolution times did not change at all. The complaints stopped within a month, and the phone went quiet.

I ran a desk like that once. We were proud of our four hours, and we were measuring the wrong four hours. It took a store manager, very politely, to tell us that a fix nobody is told about is indistinguishable from no fix for most of the afternoon.

A Fixed Ticket Is Not a Resolved Problem

A fixed ticket means the symptom went away. A resolved problem means the person can do the thing they were trying to do, and will not be back next week for the same reason. The word resolved should mean that the user agrees it is done, not that the technician believes it is. Dana's projector was fixed when the laptop appeared on the screen. It was resolved when the loose cable was reported, the port detail was written down, and the room would work for the next person.

The gap between the two shows up as repeat tickets, and repeat tickets are expensive in a way that hides. They look like volume. Volume looks like a staffing problem, which gets argued about in a budget meeting. The real problem was a cable at a wall plate that nobody was asked to fix. Finding and removing causes, usually called problem management, belongs to a later pillar. The desk's part is smaller: notice the repeat and say so, in the ticket, where it will be found.

Make Resolved a claim the user can dispute. Ask them to confirm, and let their reply reopen the ticket if they do not agree. If the tool counts reopens, read that number monthly; it is the most honest measure of resolution quality you will get for free.

Good Support From the Technician's Chair

A good desk feels calm from the inside, and the calm is specific. You know what is yours, what is next, and what "done" means for each. Triage happens at fixed times, so a new ticket at 10:40 is not an interruption. It will be looked at at 14:00, and the user has been told so.

Interruptions are routed rather than absorbed. A walk-up gets a ticket number and a time, politely, and the technician logs it themselves if the user is in a hurry. The phrase "just a quick one" has never once preceded a quick one, and a good desk writes it down anyway. Writing things down counts as work, not as what you do after work.

You are allowed to say "I don't know yet," because honesty is the desk's policy, not your personal risk. Juniors have a lane: the written rules cover the common requests. So a technician in their first month can resolve most of a day's queue without asking anyone. The best desk I worked on had one rule above the others: nobody closes a ticket without a note the next person could use. It was irritating for about a week. Then it was the reason the week after was quiet.

A bad desk is the reverse. Every ticket is a surprise, and every day is reactive. The senior technician is the queue's single point of failure. And the good people leave first because they can. The properties users trust are the same properties technicians can stand to work inside.

The Ten-Question Self-Assessment

Run this on your own desk this week, with the last twenty resolved tickets open in front of you. Answer from the evidence in those tickets, not from what the desk intends to do, and pick the column that describes most of the twenty.

Count the Yes column. Eight or more means you run a desk people trust; keep measuring, because trust erodes quietly. Four to seven is where most desks live, and the Sometimes answers tell you where to start. Three or fewer means the users are doing the remembering, the chasing, and the quality control for you. Whatever the score, questions 1, 3 and 8 come first, because each is a sentence in a reply and costs nothing.

What to Do This Month

None of the following needs a new tool, a budget, or permission. It needs four weeks and a small thing on every ticket.

• Week one: acknowledge every ticket within one business hour, from a named person, with the time of the next update. Add "next update by" to the end of every reply.
• Week two: write the rule for the three most common requests (usually password reset, new starter, shared folder access) on one page each. Cover what we need from the user, what we check, what we do, and how long it takes.
• Week two: make the resolution reply say what was wrong and what was done, and ask the user to confirm. Make sure a reply from the user reopens the ticket.
• Week three: log every walk-up and hallway request as a ticket, after the fact if necessary. Count them at the end of the week.
• Week four: open the last thirty resolved tickets and mark the ones that came back. Pick one cause and fix it, or send it to the person who can, with the ticket numbers attached.
• End of the month: run the self-assessment again. One column moving is a good month.

Dana's meeting is at 09:30 every week, somewhere in your organization, under a different name and with a different cable. Both versions of that ticket will close. Both will be green on the dashboard. Running support is choosing, on every ticket, to be the second desk, and then building the habits that make the choice automatic. The next article is Support Is a System, Not a Person. It is about why those habits have to live somewhere other than the best technician's head.

Frequently Asked Questions