A service desk checklist tests the desk on real requests rather than on how it was set up. First, someone outside the desk picks ten tickets that closed recently. Then the desk lead marks four checks on what the desk recorded, while the picker asks the employee behind each ticket four short questions. Each check ends as a count out of ten. Set side by side, the two counts for each stage show whether the desk’s work on paper reached the employee. The wider work of making IT help quicker for staff is set out in a separate use case.
Last reviewed 2026-11-02 by Manish Sharma.
Service Desk Checklist: Eight Checks in Four Pairs
This Signisys checklist follows a request through four stages, and each stage gets a pair of checks. In each pair, one check comes from the desk record and the other from the employee who raised the ticket.
- The request comes in: checks 1 and 2.
- Someone takes it on: checks 3 and 4.
- It is passed to another technician: checks 5 and 6.
- It is closed: checks 7 and 8.
A help desk checklist that only the desk fills in can tell half the story. Each pair here has an employee half. Signisys wrote these eight checks for this article.
Two terms need a meaning before marking starts. To begin with, the desk record means what the technicians wrote on the ticket and in its history. Next, the picker is a person outside the desk, such as an operations head, an office manager or an HR lead. That person chooses the tickets and puts the questions to the employees.
Key Takeaway Each stage gets two witnesses, the technician’s note and the employee’s memory, and the useful reading comes from where they disagree.
Ten Closed Tickets, Picked From Outside the Desk
To begin, the picker takes the full list of tickets that closed in the four weeks before marking. That list covers each route an employee might use: email, chat, phone or a walk to the desk.
From that list, the picker chooses ten, spread across those weeks and across teams. The desk lead sees the ten only once the picker has chosen them.
There is a plain reason for this. A desk lead choosing tickets, with the best of intentions, may reach first for the ones they remember. In contrast, a picker outside the desk does not know which tickets went well.
If the firm closed fewer than ten tickets in that time, the picker takes them all. In that case, the picker writes the real number on the sheet’s first line.
The picker numbers the closed tickets in date order, divides the count by ten and takes the ticket at each step down the list. The ten reach from the first week to the last. Then the desk lead receives the ten numbers on the day of marking.
Service Desk Checklist Counts, Not Ticks
For each ticket, each check is a yes or a no. The result for the check is then the number of yes answers, written as “7 of 10”. That figure only shows the format and comes from no firm.
Checks 5 and 6 apply only to tickets that one technician passed to another. The marker writes those two counts over the passed-on tickets alone, “2 of 3” for instance. If none of the ten moved between technicians, the picker writes “none passed on” and leaves both blank.
As for who marks what, the desk lead marks the odd-numbered checks from the desk record. The picker asks the even-numbered checks of the employees, in person or by a short call, within a few days of choosing the tickets.
The two markers keep the eight counts apart, and no count has a target.
Where the employee has left or the picker does not reach them, the picker writes “no reply” for that ticket and counts the check over the tickets that have a reply. The picker does not answer on the employee’s behalf, and the desk lead does not answer for the picker.
When the Request Comes In
The first pair looks at the start of a request. Here, the desk lead compares two times, and the picker asks one question.
| Check | Where the marker looks | Counted if |
|---|---|---|
| 1. A technician logged the request on the day the employee first asked, whichever route the employee used. | The time the technician opened the ticket, beside the employee’s first email, chat message or call note. | The desk lead finds both on the same working day. |
| 2. The employee knew where to ask before raising it. | The picker asks, “When this came up, did you know where to ask IT?” | The employee names the firm’s route without a prompt. |
Check 1 looks at the employee’s first message, not at the ticket alone. A request can wait a day before anyone logs it, and the desk’s clock then starts late.
When Someone Takes It On
The second pair asks whether a person, not a queue, picked the ticket up. It also asks whether the employee knew who that person was.
| Check | Where the marker looks | Counted if |
|---|---|---|
| 3. A named technician took the ticket on the working day the desk logged it. | The ticket history. | The desk lead finds a person’s name against the ticket by the close of that day, not a team name or a queue. |
| 4. The employee knew who had the request. | The picker asks, “While it was open, did you know which person in IT had it?” | The employee names the person or recalls a message from them. |
Check 3 can count while check 4 does not. That happens when the technician took the ticket but the employee heard nothing. A later section reads that gap.
When It Is Passed to Another Technician
The third pair covers hand-overs. Both counts run over the passed-on tickets only.
| Check | Where the marker looks | Counted if |
|---|---|---|
| 5. The technician who passed the ticket on wrote why, and what they had tried. | The hand-over entry in the ticket history. | Reading that entry alone, the desk lead can say why the ticket moved and what was already done. |
| 6. The employee told IT each detail once. | The picker asks, “After you first explained it, did anyone in IT ask you for something you had already told them?” | The employee answers no. |
A hand-over within the same team also counts, as long as a different technician took over. The silence that can follow a change of technician is described in who holds a ticket and whether the employee is told.
Closed and Confirmed
The fourth pair looks at the end of a request, from both sides.
| Check | Where the marker looks | Counted if |
|---|---|---|
| 7. The technician who closed the ticket wrote what fixed it. | The closing note. | A colleague on the desk could repeat the fix from the note. |
| 8. The employee agrees IT fixed the problem when it closed the ticket. | The picker asks, “When IT closed this, was the problem fixed for you?” | The employee says yes and has not raised the same problem since. |
The same thought, about where a request really ends, appears in a public guide. In the UK Service Manual’s guide on measuring user satisfaction, the guide notes that “sometimes the end of a transaction is not the end” of a user’s experience. It also advises a means of gathering feedback once the user’s involvement has fully ended. The guide is part of the GOV.UK Service Manual. Even so, the same idea fits an internal desk, where the technician closing the ticket and the employee’s problem ending can fall on different days.
Service Desk Checklist Read Pair by Pair
Under this Signisys checklist, the desk lead and the picker then set each record count beside its employee count.
- Record count higher than the employee count: the technicians did the work on paper, but the employee did not see it. Check 3 high with check 4 low is the plainest case: someone had the ticket, and the employee did not know who.
- Employee count higher than the record count: employees were served, and the technicians did not write down how. The fix can then stay with whoever did it, and leave with them.
- Both counts low in one pair: the desk lead looks at that stage of a request first.
The counts sit beside the help desk KPIs a desk may already report, such as time to close. In other words, they test ten tickets behind those figures rather than replace them.
The counts stay unsummed, with no band or target, and no other firm’s counts sit beside them. They describe ten tickets as they closed, not each request the desk handles, and not any one technician.
Key Takeaway A gap between two halves of a pair points to a stage to look at; it says nothing about who is at fault.
Ten Tickets at a Pathology Lab Chain
Take a pathology lab chain in India, with one main lab, several sample collection centres and an IT desk of a few people at the main lab. The chain exists only in this article and is not based on any Signisys client. It has no name or city, and the counts below are invented too.
First, the office manager picks ten tickets from the four weeks before marking. Of those ten, two moved from one technician to another.
Next, the desk lead marks checks 3 and 7. Check 3 comes out at 9 of 10: a named technician had the ticket on the day the desk logged it. Check 7 comes out at 8 of 10, where the closing notes say what fixed the problem. However, the picker’s check 4 comes out at 4 of 10. On six of the ten tickets, staff at the collection centres did not name who had their request.
For the IT manager, the reading is plain. The technicians take tickets on promptly, but the people who raised them do not hear about it. What to look at next may be the message an employee gets when a technician takes a ticket on, rather than more technicians. Once the weak stage is clear, a way to act on it in a set order is laid out in where a team of a few people can begin on Monday.
Beyond Ten Tickets
The sheet does not cover how the firm staffs the desk, what tools it uses, how fast tickets close on average, or whether the desk should be run from inside the firm or by a provider. The last of those questions is compared across in-house and managed desks and a hybrid of the two.
The desk lead keeps the sheet, with the ten ticket numbers, the eight counts and the date, beside the desk’s own reports. Later, the next sample can sit next to it. Building monthly reports on desk performance is separate work.
Signisys can act as the picker for a firm that would rather have someone with no ties to its desk choose the tickets and ask the employees.
Signisys sells IT consulting and managed cloud services and an IT service management and operations automation solution, and has a commercial interest in how firms run their service desks.
Service Desk Checklist FAQ: Picking and Asking
Are ten tickets enough for the service desk checklist?
Why does someone outside the desk pick tickets for the service desk checklist?
Does the service desk checklist replace the desk’s own reports?
Does the service desk checklist work for tickets raised by phone or in person?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.