What is an IT help desk? Tiers, tickets, ITIL basics and metrics

What an IT help desk handles

ITIL, the IT service management framework, describes the service desk as the central point of contact between a service provider and its users. Behind that front door, nearly everything that arrives is one of two kinds of work. An incident is something that stopped working or got worse. A service request is something a person asks for that the desk already knows how to deliver. The same area of IT produces both:

Questions ("how do I share my calendar?") are a third, smaller stream. They are cheap to answer once and expensive to answer over and over, which is why the knowledge base below matters.

Access work deserves more care than the table suggests, because a password or MFA reset is the most valuable thing an attacker can get from a help desk. CISA's advisory on the Scattered Spider group (November 2023, updated July 2025) describes attackers phoning IT help desks, including contracted ones, and persuading staff to reset passwords or transfer an employee's MFA to a device the attacker controls.

Help desk or service desk?

The two names describe the same function. Some organizations keep "help desk" for break-fix work and "service desk" for a wider front door that also takes requests and feeds change and problem management. In a small business the same people do both, and this guide uses the names interchangeably. It is not where projects happen (a tenant migration, an office move), and removing root causes belongs to problem management, covered below, rather than to the desk alone.

Help desk tiers: level 0 to level 3, and the vendor

Most help desks split the work into levels, also called tiers or lines, so that frequent, simple contacts are handled quickly and specialists spend their time on what only they can fix. The numbering varies between organizations; the logic does not.

A few examples show where the boundaries sit in practice:

• Level 0. Microsoft Entra self-service password reset lets people change or reset their own password with no administrator or help desk involvement, and Microsoft presents it as a way to cut help desk calls. The Intune Company Portal does the same for devices and software: users enrol devices, install apps and find how to reach IT there.
• Level 1. First-line staff need enough rights to reset, and no more. In Microsoft Entra ID the built-in role for this is Helpdesk Administrator, which Microsoft marks as privileged: it can change passwords for non-administrators and other Helpdesk Administrators, invalidate refresh tokens to force a new sign-in, and open support requests with Microsoft.
• Level 2. A laptop with a corrupted profile or a string of failed fixes gets reset remotely rather than rebuilt on a bench. Windows Autopilot Reset removes personal files, apps and settings and returns the device to a business-ready state.
• Vendor. Escalating to Microsoft is an admin task. Microsoft's support page for Microsoft 365 says these support methods require an admin of a business subscription, suggests checking the Service health dashboard first, and sends customers who bought every subscription through a partner to that partner.

Escalation comes in two kinds. Functional escalation moves a ticket to someone with more skill or access. Hierarchical escalation brings in a manager when a target is at risk or the damage to the business is growing. Either way, the ticket moves with its history: what the person reported in their own words, what was checked and what was tried. A second-line technician who has to phone the user and start again has turned one contact into two.

In a small business, level 1 and level 2 are often the same one or two people, and level 3 is a provider or a contractor. The tiers still work as a sequence: the known fix, then the deeper one, then the specialist, then the vendor, with each step written down. What each tier's job involves, and the skills and certifications it takes, is in our guide to the IT support specialist role.

Tiers are not the only model. Intelligent Swarming, developed by members of the Consortium for Service Innovation, removes tiers of support: it routes work directly to the people best placed to solve it and makes it easy for them to pull in colleagues when they need help. A small desk often works this way already without using the name, and the model suits a team too small to staff separate lines.

The life of a ticket, step by step

Help desk tools give the statuses different names, but the lifecycle underneath is the same:

1. Log. Every contact becomes a ticket, whether it arrives by phone, email, chat, the portal or a monitoring alert. The person gets a ticket number to quote, and the ticket records who is affected, the device or service involved, and the problem in the person's own words.
2. Verify. Anything that touches access waits until the caller's identity is confirmed, as in the warning above.
3. Categorize. Decide whether it is an incident or a service request, and which service or device it concerns. Categories are what later reveal patterns, so keep the list short enough that people pick the right one.
4. Prioritize. Rate impact and urgency (below). The priority sets the target for a response and a fix.
5. Assign. Level 1 tries first, unless the category routes the ticket straight to a specialist queue. Requests that need approval, such as access to finance data or a paid licence, wait for the approver named in the request's definition.
6. Work and update. Diagnose, fix or escalate, and tell the person what is happening. While the desk waits for the user or a vendor, the ticket goes on hold.
7. Resolve. Service is back, through a fix or a workaround. The technician records what was done and links or writes a knowledge article.
8. Close. The person confirms the fix, or the ticket closes automatically after an agreed number of days without a reply. A short satisfaction survey goes out at closure.
9. Review. Tickets are also read in aggregate. The same incident on the same service, again and again, becomes a problem record.

Setting priority from impact and urgency

Impact is how much of the business is affected: one person, a team, or everyone. Urgency is how fast the effect becomes serious: work has stopped, work is slowed, or it can wait until a planned time. Rating both keeps priority from depending on who complains loudest or who is most senior. A common scheme:

Write your own examples into each cell. One payroll clerk who cannot reach the payroll system on pay day is a single person, but the urgency belongs to the whole business, so it is reasonable to let a named deadline raise urgency by a level. Service requests usually sit at the bottom of the scale and are measured against the date promised rather than against an incident clock.

Incidents, requests, problems and changes: the ITIL basics

ITIL is a framework for running IT as a service. PeopleCert, which certifies ITIL, describes ITIL 4 on its practice pages as the world's most used IT service management framework. Four of its terms do most of the work on a small help desk:

In PeopleCert's descriptions of the practices, incident management is about restoring normal service operations swiftly after a disruption. Service request management handles predefined, user-initiated requests for services, information and access. Problem management identifies and manages the root causes of incidents to prevent them recurring, and manages workarounds and known errors along the way. Change enablement aims to maximize the number of successful changes by assessing risk, authorizing changes and managing the change schedule.

Why the distinctions matter to a business with a small IT team:

• Different clocks. An incident target is about getting people working again. A request target is about delivering on the promised date. Measuring a laptop order against an incident target makes the desk look slow and teaches it to rush the wrong things.
• A workaround closes the incident, not the problem. "Restart and it works" logged week after week is a problem record waiting to be opened. A problem with a documented cause or workaround becomes a known error, which the desk applies at once while someone removes the cause.
• A fix pushed to every laptop is a change. A small business does not need a formal change board, but it needs a second person to look at risky changes, a planned time, and a way back if it goes wrong.

The knowledge base and self-service

A knowledge base is the help desk's memory. It holds two kinds of article: instructions people follow themselves (connecting to the office Wi-Fi, setting up MFA on a new phone) and internal articles for technicians (how a printer's driver is deployed, the workaround for a known error).

Most knowledge bases fail the same way: someone writes articles in a burst, nobody updates them, and technicians stop trusting them. Knowledge-Centered Service (KCS), maintained by the Consortium for Service Innovation, which now calls it Knowledge-Centered Success, turns that around by making knowledge a by-product of the work. Its Solve Loop has four practices:

1. Capture in the workflow. Write the article while working the ticket, using the requester's own words and phrases, so the next person's search finds it.
2. Structure for reuse. Use one simple template and a crisp style, so articles are quick to scan.
3. Reuse. Search the knowledge base early and often, before solving from scratch; the words people searched with become the start of a new article when nothing matches.
4. Improve. Whoever uses an article takes responsibility for fixing it, so every reuse is also a review.

Self-service is level 0 built on the same content: a portal where people search articles, order from a catalogue of standard requests, and fix common issues without a ticket. Password reset and app installs, covered in the tiers above, are the usual first two, because they are frequent and follow the same steps every time.

Help desk metrics worth tracking

Targets come from the service level agreement, and ITIL's service level management practice is about setting clear, business-based targets. The measurements below show whether the desk meets them, and whether people are actually better off:

Each metric can be gamed on its own, which is why they come in pairs. A resolution-time target alone rewards closing tickets early; the reopen rate exposes it. FCR alone rewards rushing people off the phone; satisfaction exposes that. Four habits keep the numbers honest:

• An automatic acknowledgement is not a response. First response means a person has read the ticket and started work.
• Decide when the clock may pause. In Jira Service Management, for example, an SLA starts, pauses and stops on conditions you define and follows a calendar, so it can stop while the office is closed for a public holiday. Agree which on-hold reasons pause it (waiting for the user, waiting for a vendor), or on hold becomes a place to hide slow work.
• Count FCR only where it is possible. A password reset can be solved on the first contact; a new laptop cannot. Measure FCR on the categories where it applies.
• Look at the slowest tickets, not just the average. A good average hides the handful of week-old tickets nobody owns, and the people behind them are the ones who remember the service.

How to turn these measures into an agreement with a provider is covered in the help desk outsourcing guide.

When a business outsources the help desk

The mechanics above stay the same whoever runs them. Outsourcing moves some or all of the work to a provider, under a contract that fixes the hours, the priorities and the targets. The common arrangements:

• The whole desk, level 1 to level 3, for a business with no in-house IT.
• First line and after-hours cover, with an internal IT lead taking escalations.
• Escalations, overflow and projects behind an in-house first line, often called co-managed support.

What does not move: decisions about your systems, ownership of the tenant and the admin accounts, which should stay in your name, and accountability for the result. Whether outsourcing makes sense, how it is priced and how to write the service level agreement are in IT helpdesk outsourcing: benefits and best practices. Supporting remote and hybrid staff is in outsourced help desk support for remote teams, and the tools a remote desk runs on (remote access, RMM, ticketing, device management) are compared in remote IT support tools.

If you want this run for you, our IT support service provides a help desk with one email queue, answered by engineers during business hours and, where the agreement includes it, outside them, with every request written down in plain language. Priority is set by impact and urgency: by default an engineer replies to a P1 request within 1 hour, P2 within 4 hours, P3 within 8 business hours and P4 within 24 hours, and the agreement can tighten these. Recurring issues are traced to their cause and fixed at the root, and fixes go into a knowledge base. It can also work alongside your own IT team: your team keeps day-to-day ownership, and we take escalations, overflow and projects. More guides on running IT for a small team are in the IT support topic.