Your First Week Running a Helpdesk

Monday, 08:40. The queue has 140 tickets in it. The oldest was opened before you joined, by someone who has since changed departments, about a printer that has since been replaced. It is still open. Someone is standing at your desk, and they have just a quick one.

This article is for the administrator who was handed the support queue on Friday and is looking at it properly for the first time. It walks through the first five working days in order. We start with what to leave alone, the census on day one, and the ten habits on day two. Then we cover the daily and weekly cadence, the five conversations worth having, and the three numbers worth counting. It ends with a one-page operating rhythm to copy and a look at week two. It is part of our Helpdesk Fundamentals series, which covers what a desk is for and why support is a system rather than a person.

Nothing here depends on which tool you inherited. If it has a queue, a status field and somewhere to leave a note, it will do for a week. The queue, meanwhile, is not going anywhere. It will be there at 08:40 tomorrow, and it will have opinions.

Do Not Fix Everything in Week One

The first instinct on inheriting a queue is to rebuild it, and the instinct is wrong. The category list is a mess, every ticket is "High", and three of the nine statuses mean "waiting". You will want all of it fixed by Wednesday. Do not. You do not yet know which parts of the mess are decay and which are load-bearing.

Leave the categories, priorities, statuses, forms and automation rules alone for a month. Each encodes a decision somebody made for a reason, and the reason is usually not written down. A category called "Legacy Billing" looks like clutter until you learn it routes to the one person who still understands the invoice export. Change it in week one and you have broken something you cannot yet see.

I rebuilt a category tree in my first week once, because it offended me. The facilities tickets stopped arriving. It took three weeks to notice, because they were arriving by phone instead, at my desk, one at a time.

What you may change in week one is your own behavior. That means how you acknowledge, how you triage, what you write in a ticket, and when you look at the queue. None of that needs permission or an announcement. It is also, it turns out, most of the job.

Day One: Read, Do Not Act

Spend the first day counting, not fixing. A queue census is a count of what is in the queue, how old it is, what it is about and who owns it. It takes two hours with the export button and a spreadsheet. And it tells you what kind of desk you have inherited, which is not always the kind you were told about.

Count four things. Start with open tickets and their age, with the oldest and the share older than thirty days. Next come the top five categories, or subject lines if the categories are unusable. Finally, count tickets with no assignee, which is the number nobody is going to work on.

Here is the census Dana took on her first Monday at Meridian Parts, finished by 11:30.

Read the census as a story, not a scorecard. Fifty-two unowned tickets means nobody sorts the incoming work. Forty-one in "Other" means the categories were built for a different desk. Thirty-one older than a month are not being worked, and their requesters know it better than you do. None of this is a judgment on whoever ran the desk before you. It describes the system they were running inside.

Do not act on any of it today. Write the numbers down with the date, because in a month they are your before picture. A before picture is the only argument for change a manager accepts without a meeting. Then read the twenty oldest tickets end to end, replies included. You are not looking for what broke. You are looking for how the desk talks to people.

Day one ends with a list and no changes. That will feel like a wasted day. It is the only day this week you will get to think.

Day Two: The Ten Habits

On day two you start the ten habits, all at once, on your own tickets only. A habit here is a thing you do on every ticket without deciding to. The ten cost nothing, need no configuration, and together they are most of what separates a desk people trust from a desk people route around. Start today, because the sooner they are boring, the sooner they are real.

1. Acknowledge within the hour. "I have this and will look at it by three" is worth more to the requester than a silent fix at five. Why acknowledgment beats speed is covered in what good support actually looks like.
2. Triage twice a day. Triage is the sort: read each new ticket and give it a category, a priority and an owner. Do it at two fixed times, not continuously.
3. One owner per ticket. A ticket with two owners has none. Assign to a person by name and let the person reassign.
4. Write the next action in every ticket. The next action is what happens next, who does it and by when: "waiting on the replacement drive, due Thursday, Marcus to chase."
5. Close with a note. What was wrong, what you did, how to tell if it comes back. Three sentences; the next person with this problem will search for it.
6. No ticket, no work. If it is not in the queue it cannot be counted, handed over or found again. Open the ticket yourself if the requester did not.
7. Say what you will do and when. Every reply ends with a time. Keep it, or write again before it passes to say why not.
8. Ask the user to confirm. Before you mark anything resolved, ask "does that fix it for you?" and wait a working day.
9. Log the walk-ups. Every hallway request, phone call and shoulder tap becomes a ticket, even a one-line one, even after the fact.
10. End the day with an empty "new" column. Everything that arrived today has been read, categorized and owned by the time you leave. Not solved. Owned.

Four of the ten are about writing things down, and that is not an accident. A ticket is both a promise to the requester and a record of what was done. And the record is the half that outlives you, the requester and the printer. The fields that carry it are walked through in the anatomy of a ticket. This week, the next action and the closing note are the two that matter.

Expect the habits to feel slow for about a week. Writing a next action takes thirty seconds, and on day two you will be sure that is the difference between keeping up and drowning. It is not. The time comes back on day four, the first time you open a ticket and know what to do without re-reading it.

The hallway, you will notice, keeps no records at all. It has never been asked to.

Day Three: The Daily and Weekly Cadence

A cadence is a fixed set of times at which you look at the queue. That way, the queue stops deciding when you look at it. Without one, the queue gets looked at whenever it is loudest, which rewards the loud. With one, every ticket is seen at least twice a day whether or not anyone shouted. The table is the whole of it.

The times are examples; the fixedness is not. Put the daily slots in your calendar as meetings with yourself. Treat them as you would a meeting with your manager. That is to say you will move them sometimes and feel bad about it. A slot that moves is still a cadence. A slot that is skipped is the queue deciding for you again.

The midday sweep is the one people drop, and it is the one that catches broken promises. Only the midday sweep looks at what you promised by noon and have not done, while there is still an afternoon left. Drop it and the first a requester hears about a slipped promise is from you, the next morning, apologizing.

The Friday review is where the desk improves rather than merely survives. It is the feedback stage of the loop in support is a system, not a person. It is also the stage small desks lose first because it produces nothing a requester can see. Hold it anyway. Friday at three is the quietest the queue gets. It is saving itself for Monday.

Day Four: Meet the People

On day four, leave the queue for five conversations. Each takes twenty minutes and has one question. Each tells you something the census cannot, because the census only shows you the people who use the queue.

• Your manager. "What does a good week on the desk look like to you?" You are listening for the measure they already use, whether or not it has been said aloud. If it is "fewer complaints", acknowledgment matters more than resolution time.
• Whoever ran the queue before you, if reachable. "What breaks if nobody does it?" This is where you learn about the monthly export, the certificate that expires in spring and the requester who only ever phones.
• The loudest department. "Walk me through the last time you needed IT." Listen for how they reached you, not what was wrong. "I messaged Marcus" means you have found a shadow channel, one of the failures in the seven ways support quietly fails.
• The quietest department. "When did you last raise a ticket?" A department that cannot remember has either no problems or another route. It is almost always the route.
• Whoever handles what the desk does not: facilities, the finance system owner, the outside vendor. "What reaches you that should come to me, and the reverse?" Draw the line in writing before someone falls over it.

Record each conversation in the queue the same day, as a ticket or a note. In a month you will not remember who said the certificate expires in spring, and the certificate will. The queue is a partial map of the organization; these five people hold the rest of it.

If you are the only person on the desk, day four still happens. It is the day the organization learns there is a desk, and that it has a name.

Day Five: The First Numbers

On Friday you count three things and nothing else. Volume is tickets opened and closed this week. Age is the oldest open ticket and the number older than thirty days. Reopen rate is the share of tickets closed in the last month that a requester reopened. The requester did so by replying to say it was not fixed. Three numbers, one line, dated.

Volume tells you whether you are gaining or losing ground. Age tells you whether anything is rotting. Reopen rate tells you whether "closed" means fixed. Between them they describe a desk well enough to see it change from week to week. A manager accepts them without an argument about method.

Do not count first-response time, resolution time, satisfaction scores or anything per technician or category. Not yet. Each is a real measure, and measuring a desk properly is a later subject in this library. In week one, more numbers mean less attention per number.

Dana's Friday line at Meridian Parts read: "opened 61, closed 44, open now 157, oldest 98 days, over thirty days 33, reopened 6 of the 44 closed." The queue grew by seventeen, which is normal in a first week. It grew because she was triaging everything and closing only what she had confirmed. The reopen rate, roughly one in seven, told her where to look next: all six reopened tickets had been closed without a note.

Take the numbers from wherever is least work. If the tool reports over seven, thirty and ninety days and counts reopens for you, as QuerySolv does, read them off the screen. If not, the export and a spreadsheet are fine for a month. A dashboard that is green because nothing is measured is a very restful dashboard. Three honest numbers beat a restful one.

The Operating Rhythm on One Page

The operating rhythm is the cadence, the habits and the numbers on a single page. It is pinned where you can see it from your chair. The page exists so the desk runs the same way on a bad day as on a good one. Whoever covers for you can run it from the page. Copy it, change the times, print it. A printed page cannot be minimized.

OPERATING RHYTHM: SUPPORT DESK        Owner: ________      Started: ________

DAILY
  08:45  Morning triage   Read every new ticket. Category, priority, owner.
                          Acknowledge anything older than one hour.
                          List what is due today.
  13:30  Midday sweep     New tickets. Requester replies. Anything past
                          its promised time: act on it or write again.
  16:45  End of day       "New" column empty. Every ticket I touched has a
                          next action and a date. Tomorrow's due list written.

WEEKLY  (Friday 15:00)
  Count   opened ____   closed ____   open now ____
          oldest ____ days   older than 30 days ____
          reopened ____ of ____ closed in the last month
  Read    the ten oldest tickets, end to end
  Pick    one thing to change next week: ______________________________

ON EVERY TICKET
  [ ] Acknowledged within the hour, with a time I will come back
  [ ] One owner, by name
  [ ] Next action written: what, who, by when
  [ ] Requester asked to confirm before I resolve
  [ ] Closed with a note: what was wrong, what I did, how to tell if it returns

NOT WORK UNTIL IT IS A TICKET
  Walk-up, phone call, chat message, hallway: log it, even afterwards.

LEAVE ALONE UNTIL ________ (one month from the start date)
  Categories, priorities, statuses, forms, automation rules.

Everything on the page is something you do, not something you believe, and each line can be checked by someone other than you. If you add a line, remove one. The rhythm that fits on one page is the rhythm that survives a bad week.

A Short War Story: Two Mondays at Acme

Acme handed over two support queues in the same quarter, one at the warehouse and one at the main office, to two new administrators. Tomas, at the warehouse, declared ticket bankruptcy on his first Wednesday. He closed all 180 old tickets in an afternoon with a one-line notice. His theory was that anything still broken would come back. Forty did, within two weeks, as new tickets with no history. Some requesters did not come back at all, having concluded that the queue was where requests went to be closed. Lena, at the main office, read her 120 old tickets first, then closed the stale ones over two weeks. Her message said what she thought had happened and asked for a reply if it had not. She left each ticket where a reply would reopen it. Eleven people replied, and those became her first eleven solved tickets, history intact. Both queues were healthy within six months, but the main office trusted its desk much sooner, and Tomas said so himself at the review.

The reopen path matters more than the wording. A kind closing message with no way back is a locked door with a nice sign on it. A requester's reply to a resolved or closed ticket may reopen it with its history. QuerySolv does this from any channel and counts it. Where replies reopen tickets with their history, the kind close costs nothing and the reopens become a number you can watch. If your tool treats closed as final, leave stale tickets resolved rather than closed. In that case, say in the message that a reply brings the ticket back.

What Week Two Looks Like

Week two is week one with fewer surprises. The habits are two days from boring. The cadence has held for five days and slipped twice, which is normal. You know what is in the queue, which is more than could be said on Monday.

In week two you start on the stale tickets, ten a day, oldest first, with the kind close and the reopen path. Ten a day is slow enough to read each one and fast enough that the thirty-one are gone by Thursday. Each reply that comes back is a real ticket with a real requester, and it joins the ordinary cadence.

You will also notice, by about Tuesday, that three password tickets a day have the same answer. Write it down once, somewhere requesters can find it, and point to it. That is the start of a knowledge base, which is a later subject in this library and does not need a plan yet. It needs one article.

What you still do not do in week two is touch the configuration. The month is not up. By the end of the month you will have four Friday lines, a census, five conversations and a list of what "Other" actually contains. That is enough evidence to change the categories once, well, with reasons. Changing them now would be changing them on taste.

Monday, 08:40. There are more tickets in the queue than there were a week ago. And you know what every one of them is, who owns it and what happens next. Someone is standing at your desk with just a quick one. You open a ticket.

Frequently Asked Questions