The Help Desk Glossary: ITSM, ITIL, SLA, Ticket and Forty Other Terms in Plain Words

Tuesday, 10:15, at Larkspur Logistics. Dana has been running the support desk for three weeks and is in a meeting with the operations director, who has just said that the desk "needs proper ITSM with ITIL-aligned SLAs and a CMDB before the audit". Dana writes down four acronyms, nods, and spends the afternoon discovering that the first one is a field, the second is a book, the third is a promise and the fourth is a database the company does not own. None of this was in the job description. The queue, meanwhile, has thirty-one tickets in it, and seven of them are "incidents" according to the tool and "requests" according to the people who raised them.

A glossary is the smallest set of definitions a person needs to follow a conversation about support without stopping it to ask. The terms below are the ones that come up on a help desk of one to twenty people, in the meetings about it, and in the tools that run it. Each is defined in plain words first, with the way it is most often misused second, and a pointer to the article in this library that treats it properly. This article is part of our Helpdesk Fundamentals series. It is written so that a very junior administrator can read it from the top, and so that Dana can read it in the ten minutes before the next meeting.

It covers the desk itself and the names it goes by: help desk, service desk, desktop support, ITSM and ITIL. Then come the ticket and its parts, the four work types that ITIL separates, and the clocks and promises around a ticket. Next are the measures, the people and the tiers, and the knowledge and self-service terms. It ends with the words that belong to the larger platforms, a table of the pairs people confuse, a short war story, and a one-page card of the dozen terms a new technician should know by Friday.

The Desk and Its Names

Help desk. The function, the team and the place where people in an organization go when something they rely on is broken, missing or confusing. It takes the request, owns it, and either fixes it or gets it to someone who can. A help desk is not a tool and not a phone number, although it has both. The first article in this series, What Good Support Actually Looks Like, is about the function; Support Is a System, Not a Person is about why it is more than whoever is nearest.

IT help desk. The same thing, with "IT" added because the help desk in most organizations supports computers, accounts, printers and the network. The term distinguishes it from an HR help desk, a facilities desk or a customer-facing support desk. The work is the same shape in all of them: a request arrives, becomes a ticket, is owned, worked and closed.

Service desk. A help desk that has taken on a wider job: it is the single point of contact for everything IT provides, it handles requests for new things as well as broken things, and it keeps a record of what it supports and at what level. In practice the two terms are used for the same team, and the difference is mostly whether anyone has written down the list of services. Helpdesk vs Service Desk vs Desktop Support is the series on what the names mean and when a rename is worth it.

Desktop support. The hands-on part of support: the technician who comes to the desk, replaces the keyboard, re-images the laptop. Some organizations run it as a separate team behind the help desk; small ones run it as the same people with a different hat on. It is a function, not a tier.

ITSM, IT service management. The idea that IT is a set of services delivered to people, and that each service can be defined, requested, supported, measured and improved. The term covers the whole discipline, not a product, although "an ITSM tool" means software that implements it: tickets plus a service catalog, assets, changes and the rest. A help desk is the part of ITSM most organizations have; ITSM is what the help desk grows into when it starts counting the services it supports. The honest small-team version is in Pragmatic ITIL for a Small Team.

ITIL. A library of good practice for ITSM, published as a set of books and a certification scheme, revised several times since the 1980s. It names the processes (incident, problem, change, request, and so on), defines the words in this glossary, and describes how a large IT organization might run them. It is a reference, not a law. The useful parts for a desk of five are in The Five ITIL Ideas Worth Stealing; the parts that drown a small team are in the article after it.

ESM, enterprise service management. The same ticketing, catalog and service-level ideas applied to HR, facilities, finance and legal, usually in the same tool, so that an employee has one place to ask for anything. On a small scale this is simply a help desk with more than one department in it.

MSP, managed service provider. An outside company that runs some or all of an organization's IT, help desk included, under a contract. "Co-managed" means the organization keeps a desk and the MSP backs it. Internal vs Outsourced vs Co-Managed Support is the series on the three models.

The Ticket and Its Parts

Ticket. The record of one request from one person: what was asked, who owns it, what was done, when, and whether the person was told. It is both a promise to the requester and a record for the organization, which is why it has the fields it has. The Anatomy of a Ticket takes one apart.

Ticketing system, help desk software. The tool that holds the tickets, routes them, counts the clocks and keeps the history. Whether it is called a ticketing system, a help desk system, a trouble ticket system or an issue tracker depends on the decade it was named in; the parts are the same. The series on picking one without regret is Choosing a Ticketing System.

Trouble ticket. An older name for a ticket, from the telephone companies, still common in network and telecom teams. A "trouble ticket system" is a ticketing system.

Requester, end user, customer. The person the ticket is for. "Requester" is the neutral word, because the person might be a colleague, a student, a customer or a supplier. A ticket raised on behalf of someone else should name the person who has the problem, or the replies go to the wrong inbox.

Assignee, owner. The one person responsible for the ticket right now. A ticket with no assignee is nobody's; a ticket with two is also nobody's. Ownership can move, and the history should show when it did.

Status. Where the ticket is in its life: new, open, in progress, awaiting reply, on hold, resolved, closed, with names that vary by tool. The two that matter most are the ones that stop the clock in your tool and the one that means "we think it is fixed, please confirm". Ticket Workflow and Status Design is the series on choosing them.

Priority, impact, urgency. Priority is the order the desk works things in. ITIL derives it from impact (how many people or how important a service) and urgency (how soon it must be fixed), so that a printer outage for one person and a payroll outage for everyone do not both arrive as "high". Severity is a cousin used by software teams for how badly something is broken. Prioritization Frameworks covers the matrix and when to ignore it.

Category, taxonomy. The labels that say what kind of thing the ticket is about, so that the desk can count, route and learn. A taxonomy is the agreed list of categories. Too few and the reports say nothing; too many and nobody picks the right one. Ticket Categorization and Taxonomy is the series.

Queue. The list of tickets waiting for a team or a person, in the order they should be worked. A desk may have one queue or one per department. Queues and Routing covers who gets which ticket and why.

Backlog. The tickets that are open and older than they should be. A backlog is a fact, not a failure, until it stops shrinking. Backlog Recovery is the series on digging out.

Aging. How long a ticket has been open, usually reported in bands: under a day, under a week, over a month. A ticket aging report is the simplest early warning a desk has. See Ticket Aging and Follow-Up.

Reopen. A closed or resolved ticket that comes back because the fix did not hold or the requester replied. A reopen is information, not an insult; a desk that punishes reopens gets silent closes instead. Reopened Tickets is the series.

Merge, link, parent and child. Merging joins two tickets about the same request from the same person into one record. Linking connects tickets that share a cause but have different requesters. A parent ticket with children is the usual way to run an outage: one record for the cause, one per person affected, so that each person keeps their own promise.

Internal note vs reply. A reply goes to the requester. An internal note stays in the ticket for the desk: working theories, vendor case numbers, who was phoned. Getting the two confused is how a requester learns what the technician really thinks of them.

The Four Kinds of Work

ITIL separates four things that all arrive as tickets, and the separation is the single most useful idea in it for a small desk, because each kind has a different clock and a different ending. Incidents, Requests, Problems and Changes is the series on running all four in an ordinary help desk tool.

Incident. Something that was working and is not, or is working worse than it should. The job is to restore the service, by any honest means, as fast as the priority says. A workaround that gets the person going counts as resolving the incident; fixing the cause is a different ticket.

Service request. Something a person wants that is not broken: an account, access, a new laptop, a software install, a question. The job is to deliver or decline it, usually with an approval in the middle. Requests have predictable steps and longer, calmer clocks than incidents, and most of a desk's volume is requests, not incidents.

Problem. The cause behind one or more incidents, worked separately so that the incidents stop recurring. A problem ticket stays open while the incidents it explains are closed with workarounds. Problem Management covers the practice on a desk that does not have a problem manager.

Change. A deliberate alteration to something in production: a patch, a new server, a configuration edit. Change management is the habit of writing down what will be done, when, by whom and how it is undone, before doing it. Lightweight Change Management is the small-team version.

Known error and workaround. A known error is a problem whose cause is understood but not yet fixed. A workaround is the documented way to get past it meanwhile. The pair is what lets the desk answer the third report of the same thing in a minute instead of an hour. See Known Errors and Workarounds.

Major incident. An incident large enough to need its own way of working: one coordinator, one channel for updates, a timeline, and a review afterwards. The size that counts as "major" is decided in advance, not during. Major Incident Management is the series.

Clocks and Promises

SLA, service level agreement. A written promise about how quickly the desk will respond to and resolve a ticket, by priority, measured in the desk's working hours. "Respond" means a person has looked at it and said so; "resolve" means the request is dealt with. An SLA that nobody can meet is not a promise, it is a complaint waiting to be filed. SLA Design is the series on what to promise and what never to.

OLA, operational level agreement. The same kind of promise made inside IT, between the desk and the teams it escalates to: the network team will pick up an escalated ticket within two hours. Without OLAs, the desk owns an SLA it cannot keep because the people it depends on have made no promise at all.

Response time and resolution time. The two clocks in most SLAs. Response time runs from the ticket's creation to the first human reply. Resolution time runs to the moment the ticket is resolved. Time to resolution is the resolution clock averaged across tickets, and Time to Resolution is the series on measuring it honestly.

Breach. An SLA clock that has run out. A breach is recorded on the ticket and, in most tools, e-mailed to the assignee. Some tools pause the clock while a ticket waits on the requester; some, QuerySolv among them, do not, and the agreements must be designed with that in mind.

Working hours, business hours. The hours the SLA clock runs. A four-hour response promised at 16:30 on Friday is due at 11:30 on Monday if the desk works nine to five, and at 20:30 on Friday if nobody wrote the hours down. Holidays belong in the same calendar.

Escalation. Moving a ticket to someone with more skill (functional escalation) or more authority (hierarchical escalation). An escalation path is the written list of who gets what and by when, so that "I have escalated this" means something. Escalation Done Right is the series.

Triage. The first look at a new ticket: is it complete, what kind is it, what priority, whose is it. Triage is the ten seconds that decide whether the ticket is worked today or found in a month. Ticket Intake and Triage covers it.

On-call, after hours. The arrangement for support outside working hours: who is reachable, for what, and how they are paid for it. After-Hours and On-Call Support is the series.

The Measures

FCR, first contact resolution. The share of tickets resolved in the first reply, without an escalation, a callback or a second ticket. High FCR is a sign the desk knows its common problems; chasing it too hard produces quick wrong answers. First Contact Resolution is the series.

MTTR, mean time to resolve. The average time from a ticket's creation to its resolution, usually by priority or category. The mean is pulled around by a few old tickets, which is why the median is often the more honest number. (The same letters are used elsewhere for mean time to repair and mean time to recover; on a help desk they mean resolve.)

CSAT, customer satisfaction. A score the requester gives after a ticket is resolved, on whatever scale the tool uses. A response rate below a fifth means the score reports the people who felt strongly. Measuring Satisfaction and Experience Over Metrics are the series on what the number does and does not say.

NPS, net promoter score. The "would you recommend us" question, scored from minus one hundred to plus one hundred. It belongs to customer-facing support and marketing; on an internal desk it measures whether people would recommend a department they cannot choose, which is why most internal desks use CSAT instead.

Ticket volume. How many tickets arrive per day, week or month, by category and by channel. Volume is the number that justifies a hire, an article or a fix. Ticket Volume Analysis and Hotspot Analysis cover reading it.

Deflection. A request answered without a ticket, because the requester found the article or the password portal first. Deflection is counted, not observed, and Ticket Deflection Strategy is the series on counting it honestly.

Dashboard. The screen that shows the live state of the desk: what is waiting, what is late, what is due soon. A dashboard is for the next hour; a report is for the last month. Team Dashboards is the series.

People and Tiers

Agent, technician, analyst. The person who works tickets. Tools say "agent", IT departments say "technician" or "analyst", and the licensing of most help desk software counts them, which is why the word matters at renewal time.

Tier 1, tier 2, tier 3, L1 to L3. Layers of support by depth of skill: tier 1 takes everything and fixes the common things, tier 2 takes what tier 1 could not, tier 3 is the specialist or the vendor. The tiers are an escalation path, not a career ladder, and a three-person desk may have all three in one chair. Designing Support Tiers is the series.

Swarming. The alternative to tiers: whoever is free and able picks up the ticket, and hard ones are worked by several people at once rather than passed up a ladder. It suits small desks with broad skills. See Tierless Swarming.

Shift-left. Moving work to a cheaper, earlier place: from tier 2 to tier 1 by writing the fix down, from tier 1 to the requester by publishing it, from the requester to nobody by preventing it. Shift-Left Strategy is the series.

Walk-up, drive-by. The request that arrives in person, at the desk or in the corridor, and never becomes a ticket unless the technician makes it one. The untracked walk-up is one of the seven quiet failures. The Walk-Up and Drive-By Culture is the series on it.

VIP support. A faster or more personal service for named people, usually executives. It is best done as a service level and a note on the ticket rather than a separate desk. VIP and Executive Support covers the trade-offs.

Knowledge and Self-Service

Knowledge base. The collection of written answers the desk keeps: how to connect to the Wi-Fi, how to reset a password, what to do when the label printer pauses. Public articles are for requesters; internal articles are for the desk and may contain the step with the admin password in it. Knowledge Base Fundamentals is the series on building one that is used.

KCS, knowledge-centered service. The practice of writing the knowledge article while solving the ticket, not afterwards, so that the second person with the same problem reads the answer the first person's technician wrote. Capture Knowledge While Solving is the series.

Self-service portal. The web page where requesters raise, follow and sometimes solve their own tickets without talking to the desk. Its adoption depends on whether it is easier than e-mailing the one person they know. Self-Service Portal Adoption is the series.

Canned response, predefined reply, template. A saved message with slots in it, inserted by the technician and filled in for the ticket. The twenty every desk needs are listed in The Twenty Templates Every Help Desk Needs.

Runbook, SOP. A runbook is the written steps for one technical task; a standard operating procedure is the written way the desk does one of its own jobs, like triage or closing. Both exist so that the task is done the same way by whoever is on the desk. Scripted Fixes and One-Click Remediations covers turning a runbook into a button.

Root cause, RCA, post-mortem. The real reason something failed, the analysis that finds it, and the written review after a major incident that records what happened and what changes. A post-mortem is blameless by design, because a blamed technician stops reporting.

Words From the Larger Platforms

Service catalog. The published list of what IT provides, what each thing includes, how to ask for it and how long it takes. A catalog can be a page on the portal; it does not need a platform. Defining What IT Supports is the series on writing one without buying one.

CMDB, configuration management database. A database of the things IT runs, the configuration items, and how they connect: this server runs that application which these people use. It is the heart of a full ITSM suite and the part most small organizations never finish populating. Asset Data Inside Tickets covers how far a help desk gets with an asset tag in a form field instead.

Asset management, inventory. Knowing what hardware and software you own, where it is and who has it. Related to the CMDB but simpler: a list, not a map of dependencies. Some help desks include it; QuerySolv does not, which is on its limits page.

Automation, workflow. Rules in the tool that do things without a person: route by category, set a priority from a form field, close a ticket after a confirmation, send the second nudge. Ticket Workflow Automation is the series on doing this without losing judgment.

Integration, API, webhook. Ways the ticketing system talks to other systems. An API lets another program create and read tickets; a webhook is the ticketing system calling out when something happens. Monitoring alerts that open their own tickets are the usual first integration; Monitoring to Ticket Integration is the series.

AI assistant, copilot. Software that drafts replies, summarizes long tickets or suggests an article, with a person reviewing before anything is sent. The useful and the dangerous parts are separated in AI Assistants in Support.

The Pairs People Confuse

The table is the dozen pairs that cause most of the ten-minute detours in meetings. The right-hand column is the one-line test that tells them apart.

A Short War Story: The Word "Incident" at Larkspur Logistics

Larkspur's warehouse team raised everything as an incident, because the form's default was "incident" and nobody had changed it. The desk's report therefore said that the organization suffered three hundred and forty incidents a month, which the operations director took to a board meeting as evidence that the systems were failing. In fact two hundred and ninety of them were requests: new scanner batteries, access to the shipping portal for a new starter, a question about a report. Dana spent an hour re-categorizing one month of tickets by hand and brought the real numbers to the next meeting: fifty-one incidents, mostly the label printers, and two hundred and ninety requests, mostly new-starter access that took four days because it waited for an approval nobody had been told to give. The board stopped worrying about the systems and started asking why onboarding took four days. The form's default was changed to "request", the approval was written down with a name and a deadline, and the incident count fell to fifty, which was the true number all along. Nothing in the warehouse changed; only the word did. The lesson was that a report is only as honest as the vocabulary behind it, and the vocabulary is set by a default on a form.

The Dozen Terms to Know by Friday

The card is the twelve terms a new technician will hear in their first week, in one sentence each, in the order they will meet them. Print it, or pin it on the desk's internal knowledge base, which is itself the first term on the list.

THE DOZEN — FIRST-WEEK VOCABULARY FOR THE DESK
Desk: ______________________   Tool: ______________________

 01 Ticket            One request, one record: what, who, done, when, told.
 02 Requester         The person it is for. Replies go to them, not to the sender.
 03 Assignee          The one person who owns it right now. Never two, never none.
 04 Status            Where it is in its life. Know which statuses stop the clock here.
 05 Priority          The order we work in. Impact × urgency, not how loud the request.
 06 Incident          It worked, now it doesn't. Restore first, cause later.
 07 Request           They want something new. Deliver or decline, with an approval.
 08 SLA               Our written promise: respond in ___, resolve in ___, in working hours.
 09 Escalation        Passing it to more skill or more authority, with a named person and a time.
 10 Internal note     For us. A reply is for them. Check the box before you type.
 11 Knowledge base    Write the answer once, point to it forever. Public vs internal.
 12 Resolved / Closed Resolved is our opinion; closed is after they agreed, or the notice ran out.

Dana laminated the card and left it at the desk. The operations director's next request was for "proper ITSM", again, and this time Dana could answer in a sentence: the desk already had incidents, requests and service levels, in a help desk tool, measured in working hours; what it did not have was a CMDB, and the audit, when the auditor was asked, did not require one. The meeting took six minutes. The thirty-one tickets were twenty-two by the end of the day, which is the number that matters.

Frequently Asked Questions