The First Five Helpdesk Processes

Ticket 31 was closed by e-mail. Ticket 32 was closed by phone, and the phone call is not on the ticket. Ticket 33 was closed by walking over, and the ticket still says Open, because the walk-over was quicker than the typing. It is the end of week two. The desk has fifty tickets, and it has invented a process for each one of them. None of the processes is written down, two of them contradict each other, and most of them were invented by whoever was nearest.

The first fifty tickets always arrive before any process does. That is not a failure. It is the order things happen in. The only question is whether the desk writes the process down in week three or keeps inventing it in month six. This article is part of our Helpdesk From Scratch series. It is about the five processes a new desk needs, each on one page, each producing one thing.

It covers why five and why these. It covers each process with what it is, the one-page version, the template, and the failure it prevents. Then come one ticket at Bluewater Bank running through all five, with times, and the five on a single page to copy. It covers what happened at Meridian Parts when close turned out to be the one that paid. It ends with what process six should be and when. The one-page shape each process should take once it is written down is in The Help Desk SOP.

Why Five, and Why These

A process, for a help desk, is a written answer to "what do we do when", short enough that someone does the same thing without asking. The first five are intake, triage, escalation, close and the weekly review, and they are the smallest set that makes a loop. A request becomes a ticket. A human decides what it is and who owns it. The owner gets help when stuck, and the ticket ends with the requester's agreement. Once a week the desk looks at what happened and changes one thing. Every desk runs a version of this. The five pages make it the same version on Tuesday as on Monday.

These five and not others because each one produces an artifact the next one needs. Intake produces a numbered ticket with a receipt. Triage produces an owner, a priority and an acknowledgment. Escalation produces a four-line handoff to a named person. Close produces a resolution note and a confirmation. The weekly review produces three numbers and one change, and the change feeds back into intake. A process that produces nothing a later process consumes is a meeting.

This is the six-stage support loop from our fundamentals series cut down to what a desk can run in month one. Helpdesk Fundamentals describes the full loop, with knowledge and feedback as stages of their own. Here knowledge is folded into close, as the resolution note, and feedback is folded into the weekly review. You will unfold them later. In month one they fit on five pages, and five pages get read.

Each section below has the same shape: what the process is, the one-page version, the template, and the failure it prevents. One ticket at Bluewater Bank runs through all five. Lena, in the Harbor Street branch, e-mails the desk at 08:52 on a Tuesday: the back-office document scanner says "cover open" and the cover is not open. Marcus runs the desk; Sam is the second technician.

Process One: Intake

Intake is the rule that every request becomes a ticket, and the requester gets a receipt within the hour. A receipt is the automatic message with the ticket number, the address to reply to, and when a human will look. Intake does not solve anything. It gives the request an identity. It is the only process that runs on every single request, including the ones that arrive by phone, chat, or someone leaning on your desk.

The one-page version is four lines. Every request becomes a ticket, by every route. Phone calls and walk-ups are opened by the technician while the person is still there, with the person's name as requester, not the technician's. The receipt goes out automatically within the hour, and if the tool cannot send one, the technician sends it. Nothing is worked on that is not a ticket. The last line is the one people argue with, and the one that keeps the count honest.

The receipt template fits in three sentences: "We have your request as ticket 74. Reply to this message to add anything; keep the ticket number in the subject. A technician will look at it by 09:30 or 14:30, whichever comes first." The times are your triage times. A receipt that names a time is a promise. One that says "we will get back to you shortly" is a hope with a stamp on it.

Intake prevents work with no record. Without it the desk does things nobody can count, the requester has no number to quote, and the history of a problem lives in whichever mailbox received it. The second time the scanner fails, the first fix is in a personal folder belonging to someone on leave.

At Bluewater Bank, Lena's e-mail became ticket 74 at 08:52 and the receipt reached her at 08:53, naming 09:30. Nothing else happened. That is intake working.

Process Two: Triage

Triage is the first human look at every new ticket, at fixed times, twice a day. It answers three questions: what is this (category), how urgent is it compared with everything else (priority), and who owns it (one name). It ends with an acknowledgment that names the next update. Priority is decided by two things only: how many people are affected, and how soon it hurts. Everything else is a detail of those two.

The one-page version: triage runs at 09:30 and 14:30, takes under five minutes per ticket, and is done by whoever owns the desk that day. Each ticket leaves triage with a category (one of your three), a priority, and an owner. The priority is Urgent if many people or a deadline today, Normal otherwise, Low if the requester says it can wait. Every new ticket gets the acknowledgment, even the ones you will fix in the next ten minutes. The acknowledgment is how the requester learns the desk is real.

The acknowledgment template is one sentence with a name and a time: "Thanks, I have this. I'll update you by 11:00 either way. Sam." The time is when the requester next hears from you, not when the problem will be fixed. "Either way" means the update arrives whether or not there is news. Pick a time you can keep. Then keep it, which is the part that builds trust and the part that gets skipped.

Triage prevents the queue sorting itself. An untriaged queue sorts by age, so the urgent ticket waits behind the old one. Two technicians open the same ticket from opposite ends, and the requester chases because silence is the only update they have received. It also prevents the quieter failure: tickets that nobody owns because everybody saw them.

Marcus triaged at 09:30. Ticket 74 became Equipment, priority Normal (one person affected, with a second scanner twenty paces away), owner Sam. At 09:34 Sam sent the acknowledgment, naming 11:00.

Process Three: Escalation

Escalation is asking for help on a ticket in a way that gives the helper everything they need and keeps the ticket yours until they accept it. On a desk with no second tier, the helper is a senior colleague, a vendor, or the person who owns the system. The ticket does not change hands by being forwarded. It changes hands when the other person says so, and until then the owner is still the owner.

The one-page version answers three questions, when, to whom, and with what. When: thirty minutes with no progress, or the fix is outside what you are allowed to touch, or more than ten people are affected. To whom: a named person or group for each category, written on the page, with the route (a ticket note, a call, the vendor's portal). With what: four lines, in the ticket, every time. Tiers and the boundaries between them have their own pillar at Designing Support Tiers; on a new desk the whole of escalation is the four lines and the names.

The four lines are: what the requester sees, what I tried, what I think it is, and what I need from you. "Scanner on BR-HS-02 reports cover open with cover closed. Tried: power cycle, reseated the cover, checked the driver. I think: a stuck sensor, since the error appears with the lid held down. I need: do we open these or call the maintenance contract?" Four lines take two minutes to write and save the helper twenty, because the helper's first three questions are already answered.

Escalation prevents the stuck ticket and the dropped one. Without the when, a ticket sits with one person for a day because nobody said when to ask. Without the to whom, the ticket is forwarded to "someone in infrastructure", which is nobody. Without the four lines, the helper starts from zero and asks the requester the same questions again. The requester then concludes the desk does not talk to itself.

Sam worked the scanner remotely from 09:40, reached thirty minutes with no progress at 10:10, and wrote the four lines to Marcus at 10:12. Marcus replied in the ticket at 10:25: open it, there is a label that peels onto the lid sensor on that model. Sam kept the ticket. The update to Lena went at 10:58, before 11:00, saying a visit was booked for 13:30.

Process Four: Close

Close is the desk's claim that the problem is gone, and the requester's agreement, or their silence after a stated number of days. It has three parts: a resolution note that says what was wrong and what was done, and a confirmation request. The final part is a reopen path the requester can use without effort. A ticket is resolved when the technician believes it is fixed and closed when the requester agrees or the waiting period ends.

The one-page version: every close gets a resolution reply with the three sentences and the confirmation request. The status goes to Resolved, not Closed. After five working days of silence it closes on its own. A reply from the requester at any point reopens the same ticket, not a new one. Count the reopens. They are the desk's honest measure of whether "fixed" meant fixed.

The resolution template is three sentences and a request: "The scanner's lid sensor had a label stuck over it, which made it report the cover open. I removed the label and cleaned the sensor; it has scanned twenty pages without the error. If it comes back, press the lid down firmly before scanning and reply to this message. If you are happy it is fixed, no reply is needed; this ticket will close on Tuesday." The last sentence is the reopen path and the deadline in one. It means the requester never has to find a form to say "it's not fixed".

Close prevents the silent close and its consequence, the invisible reopen. Without a confirmation step, tickets are marked done because the technician stopped working on them. The requester discovers this on their own, and their reply arrives as a new ticket with a sharper tone and no history. The desk's reopen rate then reads zero, which is not the same as being zero. A tool should make the reopen path automatic. In QuerySolv a requester's reply on a resolved or closed ticket reopens it by any channel and the reopen is counted. Whatever tool you have, that is the behavior to want.

Sam removed the label at 13:50, sent the resolution reply at 14:02, and Lena replied "Confirmed, thanks" at 14:20. Ticket 74 closed at 14:20 with its resolution note, which is now the first search result for "cover open".

Process Five: The Weekly Review

The weekly review is fifteen minutes, once a week, in which the desk reads three numbers and decides one change. The three numbers are tickets this week by category, the age of the oldest open ticket, and reopens this week. The one change is anything the numbers suggest: a category added, a triage time moved, an article written, a question added to the form. One change, written down, checked next week. Why these three numbers and not thirty is the subject of The First Three Helpdesk Metrics.

The one-page version: same day, same time, every week, whoever runs the desk, fifteen minutes by the clock. Read the three numbers, write them on the page under last week's, pick one change, name who does it and by when. If the numbers suggest three changes, pick the cheapest. If they suggest none, write "none" and go home early, which will happen less often than you hope.

The template is the four lines of the review note: "Week 7: 41 tickets (Access 18, Equipment 14, Software 9). Oldest open: 9 days, ticket 52, waiting on purchasing. Reopens: 3, all on password resets. Change: add the 'did you restart first' line to the reset article; Sam, by Friday." That note, kept weekly, becomes the desk's history of itself and the thing you hand to whoever asks how the desk is going.

The weekly review prevents the desk working hard without knowing whether it is working. Without it the queue grows an old-tickets layer nobody looks at, and the same reopen happens every week. The first signal that something is wrong is a department that has stopped sending tickets. The review is the one process that makes the other four better. It is the first one dropped when the week is busy, which is the week it is needed.

Bluewater's review was Friday at 16:00. Week seven's note is the one above. The change took Sam ten minutes on Monday, and the following week's reopens on resets went from three to one.

The Five on One Page

Below are the five processes as a single page, with blanks where your desk's names and times go. Print it, fill it in, and put it where the queue is worked. It replaces nothing you have written already and everything you have not.

THE FIRST FIVE PROCESSES ON ONE PAGE
Desk: ______________   Owner: ____________   Review day and time: ________

1. INTAKE                              produces: a ticket with a receipt
   Every request becomes a ticket: e-mail, form, phone, walk-up.
   Phone and walk-up: the technician opens it while the person is there,
   with the person as requester. Receipt within the hour, with the ticket
   number, the reply address and the next triage time.
   Nothing is worked on that is not a ticket.

2. TRIAGE                       produces: owner, priority, acknowledgment
   Twice a day at ____ and ____, under five minutes per ticket.
   Each ticket leaves with a category (one of three), a priority (how
   many people, how soon it hurts) and one owner by name.
   Acknowledgment: "Thanks, I have this. I'll update you by ____ either
   way." The time is kept, with or without news.

3. ESCALATION                             produces: a four-line handoff
   When: thirty minutes with no progress, or outside what you may touch,
   or more than ten people affected.
   To whom: Access ____________  Equipment ____________  Software ________
   The four lines, in the ticket: what the requester sees / what I tried /
   what I think it is / what I need from you.
   The ticket stays with its owner until the helper accepts it.

4. CLOSE                          produces: resolution note + confirmation
   Resolution reply: what was wrong, what was done, what to do if it
   returns, "reply to this message if it is not fixed."
   Status Resolved; closes after ____ working days of silence.
   A reply from the requester reopens the same ticket. Reopens are counted.

5. WEEKLY REVIEW                       produces: three numbers, one change
   Every ______ at ____, fifteen minutes, whoever runs the desk.
   Numbers: tickets this week by category / oldest open ticket in days /
   reopens this week. Written under last week's.
   One change, with a name and a date: _______________________________
   Checked at next week's review: [ ] done  [ ] not yet

Write the page in the order the tickets meet it, and resist adding a sixth block today. The page is short because short gets read. A twelve-page process document is a place where processes go to be safe from use.

A Short War Story: An Afternoon at Meridian Parts

Priya set up the Meridian Parts desk and wrote the five pages in one afternoon in week three, after two weeks of inventing a process per ticket. She expected intake or triage to make the first visible difference. The one that paid first was close. Until then, resolved tickets had been marked Closed on the spot. When a fix had not held, the requester's reply arrived as a brand-new ticket. So the desk's reopen count had been zero for two weeks while the real figure, counted by hand from the new tickets, was eleven. Once the resolution reply and the reopen path were in place, the reopens appeared where they belonged. Eight of the eleven then turned out to be one printer driver, and the driver got fixed properly in week four. Nobody had done anything wrong. The process had been hiding the count, and the page stopped it.

I have watched the same thing on my own desk, and I did not enjoy it either. A reopen rate of zero is never good news. It is a reopen path nobody can find.

Process Six, and When

Process six is whichever one the weekly review keeps asking for, and it is not written before month two. The five pages need four or five weekly reviews behind them before you know which of their failures is yours. A desk drowning in password resets needs a knowledge process. A desk with twenty "can I have" tickets a week needs a request form. A desk whose escalations all go to the same overworked person needs a boundary. Writing process six in week one means guessing which of those you will be. The review tells you, for free, by week six.

The usual candidates are four. A knowledge process: every fix that took more than twenty minutes becomes an article the same day, in under a hundred and fifty words. A request process: a form for the things people ask for rather than report, with the approvals written down. A known-error list: the problems you cannot fix yet, with the workaround, so triage stops re-diagnosing them. A change freeze: the days nothing is touched because payroll runs or the quarter closes. Pick the one the review named. The other three can wait for the review to name them too.

The ninety-day shape of all this, with the week each process lands in, is in The Greenfield Playbook: Ninety Days on One Page. The six things the desk needed before any of these processes are in Day Zero: What You Need Before the First Ticket. For now, the five pages are enough. Ticket 51 will arrive tomorrow, and for the first time the desk will not need to invent anything to deal with it.

Frequently Asked Questions