Help Desk SOP: Standard Operating Procedures for a Small Desk, With a Template

Wednesday, 13:20, at Kestrel Insurance. Omar, who runs the three-person desk, is at the dentist, and a claims handler has just reported that the document scanner is not scanning. Lena, six weeks in, knows that Omar "does something" when this happens, and that it involves the scanner's web page and a password she has never been told. She tries three things, none of them that one, and after forty minutes raises it to the supplier, whose hold music she listens to until Omar returns at 14:30 and fixes it in ninety seconds by restarting a service. Nothing failed except the thing nobody had written down. The desk had a procedure for the scanner. It lived in Omar.

A standard operating procedure is the written way a desk does one of its own recurring jobs: the steps, who does them, when they are triggered, and what is recorded. It is not a policy, which says what must be true, and it is not a runbook, which is the steps for one technical fix like the scanner restart, although a good SOP points at runbooks. A help desk SOP exists so that the job is done the same way by whoever is on the desk, including the person who started six weeks ago and the person covering for the dentist. This article is part of our Helpdesk From Scratch series, and it is the written-down form of The First Five Processes.

It covers what an SOP is for on a desk this size and the two ways the word is misused. Then come the eight procedures every desk writes first, with the trigger and the owner of each. It covers the shape of a single procedure that people actually follow, how to write the set in an afternoon from what the desk already does, and how to keep it alive without a documentation day. There is a short war story. It ends with the template, with the slots marked, and one procedure filled in as an example.

What an SOP Is For on a Small Desk

On a desk of twenty, procedures exist to make twenty people consistent. On a desk of three, they exist for two other reasons. The first is cover: holidays, the dentist, the day someone leaves. A desk whose procedures live in one person has a single point of failure with a pulse. The second is onboarding: the new technician's first month is spent either reading what the desk does or guessing it, and guessing produces the forty minutes on hold. A written procedure turns the first month into the first week.

The word is misused in two directions. One is the policy dressed as a procedure: "all tickets must be acknowledged within one hour" is a rule, and a rule with no steps is not followed, it is obeyed or not. The other is the runbook dressed as a procedure: forty pages of how to restart every service on every server. That is valuable, and it is not an SOP, because it describes systems rather than the desk's own work. The desk's own work is the handful of jobs it does every day whatever is broken: taking tickets in, deciding their order, telling people what is happening, passing hard ones on, closing them, and the few request types that arrive every week. Those are the SOPs.

Each one should fit on a page. A procedure that needs two is two procedures or a runbook. The test of a good one is that a competent person who has never done the job can do it from the page without asking, and that the person who wrote it recognizes the result as right. The second half of that test is the one desks skip; a procedure the author would not follow is a procedure nobody follows.

The Eight Procedures Every Desk Writes First

These are the eight that cover a small desk's recurring work, in the order they are met on a ticket's journey, with the trigger and the natural owner of each. A desk may need a ninth; it rarely needs the first eight to be different.

1. Intake and triage. Trigger: a new ticket, from any channel. The steps: confirm it is complete, classify it as incident or request, set the priority from the matrix, assign an owner, send the acknowledgement. Owner: whoever is on triage that day, which on a three-person desk is a rota. The detail is in Ticket Intake and Triage, and the acknowledgement templates are in Ticket Acknowledgement Templates.

2. Prioritization. Trigger: every new ticket, and any ticket whose situation changes. The steps are the matrix: how many people, how important the service, how soon. Owner: the person triaging, with the rule that priority is changed in the ticket with a note, never silently. Prioritization Frameworks has the matrix and the exceptions.

3. Updates and expectations. Trigger: the time promised in the last message, whether or not anything has changed. The steps: what was done since, what happens next, the next time. Owner: the ticket's assignee. This is the procedure most desks do not have, and it is the one that stops the chasing. Managing Expectations is the series.

4. Escalation. Trigger: the assignee cannot resolve it with the skill or authority they have, or a time limit at a tier has passed. The steps: who gets it, what they are told, what the requester is told, and when the desk checks back. Owner: the assignee escalates; the desk lead owns the path. Escalation Done Right covers paths that hold.

5. Resolution and closing. Trigger: the assignee believes it is fixed. The steps: the resolving reply with what was wrong and what was done, the confirmation request with a date, two nudges, the close on notice, the resolution note. Owner: the assignee. Closing Tickets Properly is the series, and the no-response templates are in User Confirmation Without Chasing Forever.

6. Password and account requests. Trigger: a reset, an unlock, a new account. The steps: how identity is verified (and it must be written down, because this is the procedure a social engineer tests), what is done, what is recorded. Owner: anyone on the desk, which is why it must be exact. Password and Lockout Tickets has the verification question.

7. New starter and leaver. Trigger: HR says someone is joining or leaving, with a date. The steps are a checklist per role: accounts, devices, access, and on the way out the reverse, with a time limit on the leaver's access. Owner: the desk, with HR as the trigger. The two series are Employee Onboarding and Employee Offboarding.

8. Outage communication. Trigger: a service is down for more than a few people. The steps: the first notice within a fixed number of minutes, the update interval, who sends them, the all-clear, and the follow-up. Owner: the desk lead or whoever is senior on the day. Outage Communication is the series, and the first notice is template eighteen in The Twenty Templates.

Notice what is not on the list. There is no change management procedure, because a three-person desk does change management by the lightweight method in Lightweight Change Management and writes it down when it needs to. There is no problem management procedure, for the same reason. There is no procedure for the scanner, because that is a runbook, and runbooks are the subject of Scripted Fixes and One-Click Remediations. The eight are the desk's work; the runbooks are the systems' work.

The Shape of a Procedure People Follow

A procedure that is followed has seven parts, and the order matters because it is the order in which the reader needs them. Purpose, in one sentence: what this procedure is for and what goes wrong without it. Trigger: the exact moment it starts, written as something observable ("a ticket is set to Resolved"), not a feeling ("when it seems fixed"). Owner: the role, not the name, that does it, and the role that owns the procedure's text. Steps: numbered, each one an action with a verb, each one checkable, none of them "use judgment". Exceptions: the two or three cases where the steps do not apply and what to do instead, because a procedure with no exceptions is a procedure people stop trusting the first time it is wrong. Record: what is written in the ticket or the log when the procedure has run, so that the monthly review can see it ran. Review: the date it is next checked and who checks it.

Two things keep it to a page. The steps say what, not why; the why is one sentence in the purpose. And the steps point at runbooks and templates rather than containing them: "send the acknowledgement (template 02)" rather than the text of the acknowledgement. A procedure that embeds its templates goes stale the day a template changes.

The language is plain and in the imperative. "Set the priority using the matrix" rather than "the priority should be set in accordance with the prioritization matrix". The reader is standing at the desk with a ticket open and a requester waiting; the sentence has to be understood on the first read. If a procedure needs a diagram, the diagram is the procedure and the text is its caption.

The Table: Eight Procedures, One Page

Writing the Set in an Afternoon

Do not start from a blank page and do not start from a framework. Start from what the desk already does, because the desk already has procedures; they are just unwritten and slightly different per person. For each of the eight, take the last five tickets where it ran, read what was actually done, and write that down as numbered steps. Where two technicians did it differently, pick one way in the room with both of them and write the chosen way. Most of the disagreement will be about step order and about what gets recorded, and both are settled in minutes once they are visible.

Write the trigger first, because it is the part people get wrong. "When a ticket needs escalating" is not a trigger; "when the assignee has spent the tier's time limit, or needs an access they do not have" is. Then the steps, then the exceptions, which come from asking "when did this go wrong last year?". The purpose sentence is written last, because by then you know what the procedure is for. Intake, closing and password requests are the three to write first; they are most of a day's work and the ones a new technician meets on day one.

An afternoon is enough for the first four if two people do it together, one reading tickets and one typing. The other four follow over the next two weeks as their triggers come up, which they will. Put the set where the desk already looks: the internal knowledge base, as eight articles with the same name shape ("SOP 05 Resolution and closing"), visible to agents only. A procedure in a shared drive folder is a procedure in a drawer.

Keeping It Alive

A procedure is wrong the first time the tool changes, the supplier changes or the desk learns something, and a wrong procedure is worse than none because it is trusted. Three habits keep the set honest. Each procedure has a review date and a named reviewer, in the template, and the review is fifteen minutes with the last ten tickets: did the steps run as written? Each procedure has a "last changed" line and a one-line reason, so that the technician reading it knows whether it is current. And any ticket where the procedure did not fit gets a note that says so, which the quarterly review collects as the next set of exceptions. The method is the same one that keeps a template library trustworthy, in Keeping the Template Library Alive and Trusted, and it survives the lack of a documentation day for the same reason: the work is attached to tickets, which the desk already touches.

The desk lead owns the set, which means approving changes, not writing them. The person who found the procedure wrong writes the correction; the lead reads it and dates it. A set that only the lead may edit stops being edited the week the lead is busy, and the lead is always busy.

A Short War Story: The Verification Question at Kestrel Insurance

Kestrel's password procedure, before it was written, was "check it's really them". Each of the three technicians checked differently: Omar asked for the employee number, Lena asked for the manager's name, and the third technician, Sam, recognized voices. In March a caller who knew the manager's name and sounded confident got a reset on a claims handler's account; the caller was a claims handler, as it happened, resetting a colleague's password "to help", and the colleague was on leave and found her mailbox read. No harm was done beyond a difficult conversation, and the auditor, when told, asked for the procedure. There was none to show. The one Omar wrote that week fitted on a page: trigger, the two verification methods allowed (a callback to the number on file, or the manager confirming in a ticket of their own), the one exception (a locked-out executive, who gets the callback and nothing else), and the record, which is the method used, written in the ticket. Sam stopped recognizing voices. The next audit took four minutes on that point, and Lena, covering the desk alone in July, reset eleven passwords the written way without asking anyone. The scanner, incidentally, got a runbook the same week, three lines long, with the password in the internal article where it belonged.

The Template, and One Procedure Filled In

The template is the seven parts on one page with the slots marked. Below it is procedure 5, resolution and closing, filled in as the desk at Kestrel wrote it, so that the shape is visible with real words in it. Copy the blank one into your internal knowledge base eight times, number them, and fill each from the last five tickets where it ran.

SOP [NUMBER]: [NAME OF THE PROCEDURE]
Desk: ______________   Owner of this text: [ROLE]   Last changed: [DATE], because [ONE LINE]
Next review: [DATE] by [ROLE]

PURPOSE   One sentence: what this procedure is for, and what goes wrong without it.
TRIGGER   The observable moment it starts: "[WHAT YOU CAN SEE IN THE TICKET OR THE QUEUE]".
OWNER     The role that runs it: [ROLE]. Covered by [ROLE] when absent.

STEPS
  1. [VERB] [WHAT] [WHERE]. (points at template / runbook: [REFERENCE])
  2. ...
  3. ...
  4. ...
  5. ...

EXCEPTIONS
  - If [CASE], then [WHAT INSTEAD].
  - If [CASE], then [WHAT INSTEAD].

RECORD    What is written in the ticket when this has run: [FIELDS / NOTE].
CHECK     The monthly review reads [N] tickets and confirms the record is present.

----------------------------------------------------------------------------------------

SOP 05: RESOLUTION AND CLOSING                                    (Kestrel Insurance, as written)
Owner of this text: desk lead   Last changed: 14 Apr, because the auto-close moved to day 7
Next review: 14 Jul by desk lead

PURPOSE   So that a ticket is closed with the requester told what was done and able to reopen
          it, and never closed by a status change alone.
TRIGGER   The assignee has tested a fix and is about to set the ticket to Resolved.
OWNER     The assignee. Covered by the triage rota if the assignee is absent for 2+ days.

STEPS
  1. Write the resolving reply: what was wrong, what was done, in the requester's words
     (template 09). End with the confirmation request: a specific test, a date, and that
     silence means closed on that date.
  2. Set the status to Resolved. Do not set Closed.
  3. Two working days later with no reply: send the first nudge (template 11a).
  4. Two working days after that: send the second nudge (template 11b).
  5. Day 7 with no reply: send the close reply (template 11c), set Closed, and write the
     note "closed on notice; not confirmed" with the nudge dates.
  6. On any reply saying it is fixed: set Closed and send "closed, thanks" (template 12).
  7. On any reply saying it is not: the ticket reopens; reply within the response time.

EXCEPTIONS
  - An out-of-office reply names a return date: skip the first nudge and close on notice
    the working day after their return, with the close reply.
  - A shared resource (printer, room): confirm with the people who use it, not the requester.
  - Never a third nudge; never a close without the day-7 reply.

RECORD    The resolving reply, each nudge, and the close note are on the ticket.
CHECK     The monthly close review reads 10 closed tickets and confirms all three are present.

Omar's set reached eight procedures by the end of May. Lena's second month was quieter than her first for a reason she could name: the pages. When Sam left in August the handover was the set and a day of questions, and the new technician reset her first password the written way on her second morning, without asking, which is what the pages were for.

Frequently Asked Questions