One request, start to finish
Who: the agent who owns the ticket.
Looks at: the user, the fault, the fix and the confirmation.
Misses: tickets nobody has picked up, clocks paused for no reason, owners who are off today.
Output: a resolved ticket.
Every agent works their own tickets. Somebody has to look after the queue as a whole. This free IT help desk daily checklist gives service desk leads, IT support teams and MSP help desks a routine for each working day: open the desk and check every intake channel, triage what arrived overnight, catch SLA breaches before they happen, chase aged and escalated tickets, watch for the cluster of calls that means a major incident, and close the day with shift notes the next shift can act on. A weekly queue review appears on the last working day. Each day leaves a dated record of the queue and who looked after it.
Working Tickets and Running the Desk Are Different Jobs
A ticket process tells an agent how to handle the request in front of them: acknowledge, diagnose, fix, confirm, close. It says nothing about the forty tickets nobody has opened yet. Queues go wrong in the gaps between tickets. A form on the portal breaks and the day looks quiet. A priority set at 07:50 by an auto-rule is never corrected. A ticket assigned to someone on annual leave waits a week. None of these shows up while you work a single ticket, and all of them show up in the monthly SLA report.
The ITIL 4 practice guides treat the service desk as the point of contact between the service provider and its users, alongside separate practices for incident management and service level management. The daily checklist sits where those three meet: it is the service desk checking, once a day and at the same times, that incidents are being picked up and that service level targets will be met.
The whole queue, every working day
Who: the desk lead for the day, which can rotate.
Looks at: intake channels, unassigned and misprioritised tickets, breaches, age, escalations and clusters.
Misses: the detail of any single fix, which stays in the ticket.
Output: a queue with an owner and a next step for every ticket, and shift notes for tomorrow.
Three things are left out on purpose. Handling a single ticket belongs to the ticket process. Restoring service in a major incident belongs to the incident process; the desk spots the pattern, raises it and keeps callers informed. Out-of-hours cover is a separate hand-off between engineers, which the desk feeds but does not run.
What the IT Help Desk Daily Checklist Covers
Phases 1 to 6 run every working day. Phase 7 appears on the last working day of the week. Two tasks appear only when they apply: one when someone on the desk is off, one when a major incident is already open at the start of the day.
- Phase 1
Phase 1: Open the Desk
5 tasksDone before the phones open. The answers recorded on the first task decide which conditional tasks appear later in the day.
- Record the desk lead for today and who is off — and whether a major incident is already open and whether this is the last working day of the week
- Read yesterday’s shift notes before touching the queue — promises made to users and tickets flagged at risk come first
- Check every intake channel is working — portal, shared mailbox, phone queue and chat; a broken form looks exactly like a quiet morning
- Check monitoring and the status page for anything already live — so the first callers hear the same message from every agent
- Check the change calendar for today — a planned outage or a new app going live tells you which calls to expect
- Phase 2
Phase 2: Triage the Queue
5 tasks- Clear the unassigned queue — every new ticket categorised, prioritised and given an owner
- Review tickets logged out of hours — after-hours emails, auto-created monitoring tickets and anything left by the on-call engineer
- Correct priorities that do not match impact and urgency — not how senior or how insistent the requester is
- Link tickets that describe the same fault — several reports of one symptom are one incident with several callers
- Chase tickets waiting on the user — apply your pending-closure rule instead of leaving them open for weeks
- Phase 3
Phase 3: SLA Breaches & At-Risk Tickets
5 tasks- List every ticket that breached its SLA since yesterday — with the reason, so the monthly report explains itself
- Pull the list of tickets due to breach before close of business — give each one a named person and a time
- Check that paused SLA clocks are paused for a valid reason — waiting on the user or a supplier, not parked to protect the figures
- Chase tickets escalated to suppliers — their contract clock and your SLA clock rarely match
- Update users on at-risk tickets before they have to chase — a proactive update turns a likely complaint into a routine call
- Phase 4
Phase 4: Aged Tickets & Escalations
5 tasksThe third task appears only when someone on the desk is off today.
- Review tickets older than your age threshold — each one needs a next action and a date, or a reason it cannot move
- Check that escalated tickets moved since yesterday — a ticket at second line with no update for two days has stalled
- Reassign tickets held by anyone off today — a ticket owned by someone on leave has no owner
- Raise tickets blocked on a decision with the team lead — approvals, purchases and access requests stall quietly
- Flag repeating faults for problem management — the same cause three times in a week is a common trigger
- Phase 5
Phase 5: Major Incident Watch
5 tasksThe first task appears only when a major incident was already open at the start of the day. The rest run every day.
- Brief the desk on the open major incident — latest update, any workaround and exactly what to tell callers
- Look for clusters of similar tickets at set times — late morning and mid-afternoon; several calls about one service within half an hour is the usual sign
- Raise a suspected major incident through the incident process — the desk spots and reports it; the incident manager runs it
- Post a known-issue message on the portal and the phone greeting — every caller who hears it is one fewer ticket to log
- Link new tickets to the parent incident — so they close together and every affected user hears when service is back
- Phase 6
Phase 6: Knowledge & Shift Notes
6 tasks- Turn today’s new fixes into knowledge articles — written while the ticket is fresh, not saved for a monthly clean-up
- Flag articles that failed an agent today — wrong steps, old screenshots or a fix that no longer works
- Record the day’s numbers — tickets opened, closed and still open, plus breaches and aged tickets
- Write the shift notes for the next shift — at-risk tickets, promises made to users, open incidents and tonight’s changes
- Pass anything that may page tonight to the on-call engineer — a known fault or a risky change should not surprise them at 2am
- Switch intake channels to out-of-hours mode — voicemail, auto-reply and the emergency number all say the same thing
- Phase 7 — Last Working Day of the Week
Phase 7: Weekly Queue Review
4 tasksAppears only when the first task records that today is the last working day of the week.
- Compare this week’s volume and backlog with last week’s — a backlog that grows by a few tickets every week is a staffing conversation
- Review the top five ticket categories — the biggest category is where a knowledge article or a fix saves the most time
- Group the week’s SLA breaches by reason — missed triage, waiting on a supplier and wrong priority need different fixes
- Check next week’s rota against planned leave and known busy days — month end, a release or a new starter intake
A Day on the Service Desk, Hour by Hour
The checks work best at fixed times, so nobody has to decide when to look at the queue in the middle of a busy morning. The times below assume an 08:30 to 17:00 desk. Treat them as a starting point and move the cluster checks to your own peaks.
| Example time | Check | Phase | Why then |
|---|---|---|---|
| 08:00 | Channels, shift notes, monitoring, change calendar | 1 | Before the first call, so problems are found by the desk and not by users |
| 08:30 | Unassigned and out-of-hours tickets, priorities | 2 | The overnight pile is largest and the day’s SLA clocks are starting |
| 10:00 | Breaches and the at-risk list | 3 | Early enough to save tickets due today |
| 11:30 and 15:00 | Cluster check | 5 | Just after the usual peaks, when a pattern has had time to form |
| 14:00 | Aged tickets, escalations, absent owners | 4 | The quieter part of the day, with time to chase other teams before they leave |
| 16:30 | Knowledge, numbers, shift notes, out-of-hours hand-off | 6 | Before the desk empties and while the day is still fresh |
| Friday 15:00 | Weekly queue review | 7 | Enough of the week has passed to see trends, with time left to fix next week’s rota |
What counts as an aged ticket is your call. Many desks start with a flat threshold, such as anything open for more than 10 working days, then set separate limits per priority once they see where tickets really stall. The number matters less than the rule behind it: every ticket past the threshold has either a dated next action or a written reason why it cannot move.
Knowledge follows the same logic. The Knowledge-Centered Service (KCS) method from the Consortium for Service Innovation has agents capture articles while solving the issue and treats each reuse of an article as a review of it. Phase 6 applies that daily: capture today’s fixes and flag the articles that failed, while the details are fresh.
Why Run the Daily Help Desk Checklist in CheckFlow?
There every morning, Monday to Friday
A recurring schedule starts the checklist each working day and assigns it to the service desk group, so whoever is leading the desk that day picks it up. Due dates on each phase follow the run’s start, and conditional logic adds the weekly review only on the last working day.
Breaches with reasons, not just counts
Breached and at-risk tickets go into tables inside the tasks, with ticket number, priority and reason. After a month you have a daily record of why SLAs were missed, which is the part a ticketing system’s breach report leaves out.
Shift notes the next shift can find
The shift notes are a field on a task in a dated run, not a message lost in a chat channel. The first task of the next day points straight at them, comments carry any follow-up, and the activity trail shows who led the desk and when each check was done.
This routine looks after the queue; the work on each ticket follows its own process. The IT Support Checklist sets up tiers, routing and SLAs for the desk, and the Support Ticket Response Checklist covers a single ticket from acknowledgement to confirmed close. When the cluster check finds a real outage, the Incident Management Checklist takes over.
At the end of the day the desk hands out-of-hours risks to whoever holds the pager. That rotation has its own routine in the On-Call Handover Checklist, run each time the pager changes hands. CheckFlow’s recurring checklist software shows how daily and weekly schedules, group assignment and reminders work across both.
Related IT Templates
Information TechnologyLive demo
IT Support Checklist
Information TechnologyLive demo
Support Ticket Response Checklist
Information TechnologyLive demo
On-Call Handover Checklist
Information TechnologyLive demo
Incident Management Checklist
Information TechnologyLive demo
IT Service Request Fulfilment Checklist
AI generator
Didn’t find what you need? Describe it.
Describe the process in a sentence and the AI checklist generator drafts the phases and tasks for you.
Frequently Asked Questions
What should an IT help desk daily checklist include?
The checks that protect the queue as a whole: that every intake channel works, that yesterday’s shift notes were read, that nothing is unassigned or wrongly prioritised, which tickets breached or are about to breach their SLA, which are old or stuck at another team, whether a cluster of calls points to a major incident, and what the next shift needs to know. Individual ticket steps belong in the ticket process, not the daily list.
How often should a service desk queue be triaged?
New tickets should be triaged continuously, within your response target, by whoever is on intake. The daily checklist adds fixed sweeps on top: a full pass through the unassigned queue at the start of the day, an SLA check mid-morning and cluster checks after the usual peaks. The sweeps catch what continuous triage misses when the desk is busy, such as a ticket categorised by an auto-rule and never looked at by a person.
When does a help desk ticket count as aged?
There is no standard figure. A common starting point is 10 working days, with shorter limits for high-priority tickets. What makes the threshold useful is the rule attached to it: an aged ticket must have a dated next action or a written reason it is blocked. Tickets that sit past the threshold with neither are the ones that turn into complaints.
What should go in help desk shift notes?
Only what the next shift has to act on. Tickets at risk of breaching and when they are due, anything promised to a user such as a call back at 09:00, any open or suspected major incident, changes scheduled overnight or first thing, and faults the on-call engineer has been warned about. A list of everything that happened today is a report, not a handover, and the useful items get lost in it.
How do you reduce SLA breaches on a help desk?
Look at breaches before they happen, not after. A daily at-risk list of tickets due before close of business, each with a named person and a time, saves more tickets than a monthly breach report. Then record the reason for every breach that does happen and group them weekly. Breaches caused by slow triage, suppliers, wrong priorities and absent owners each need a different fix, and the pattern only shows once the reasons are written down.
Is CheckFlow free for this template?
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
Give Every Ticket in the Queue an Owner and a Next Step, Every Day
Free trial — no credit card required.
14-day free trial, no credit cardFull refund in your first 30 daysUS hosting, EU on request