ITSM is not the same thing as a helpdesk

A helpdesk receives tickets. ITSM covers the entire delivery: how services are defined, how changes are approved, how assets are documented, and how work is improved over time.

The difference is most apparent when something goes wrong. A helpdesk can tell you who reported the error. An ITSM organization can tell you what caused it, which services were affected, and what has been done to prevent it from happening again. We explore how this function is built under service desk and helpdesk.

Why ITSM matters

Most IT departments start with a shared inbox. It works – until it doesn't.

You don't know what you're doing. Without structured logging, it's impossible to see how many tickets are coming in, which ones are recurring, or where time is being spent. Prioritization becomes a matter of guesswork.

Quality varies by person. The same question gets different answers depending on who happens to respond. Users notice this long before it shows up in the statistics.

Knowledge is trapped in people's heads. When someone leaves, that knowledge disappears. Onboarding new employees becomes a long process that depends on someone else having the time to help.

Changes happen without traceability. No one knows for sure what was changed, by whom, or why – which becomes a problem during both troubleshooting and audits.

IT fails to demonstrate its value. Without follow-up, IT becomes a budget expense rather than a function that delivers measurable value.

ITIL processes in practice

Incident management

Incident management is the process of restoring normal operations as quickly as possible when something breaks.

The word restore is key. The goal is not to find the root cause, but to get the business up and running again. A temporary fix that allows thirty people to work is the right decision, even if the underlying fault remains. The root cause is handled separately, in problem management.

Prioritization is determined by impact and urgency, not by who is calling. A manager with a broken keyboard is low priority. A financial system that is down the day before month-end closing is high. Upholding that principle is one of the most difficult and valuable things a service desk does.

Major disruptions are handled as major incidents with their own routine: a designated incident manager, ongoing communication to the business, and a documented timeline. What separates a well-managed major incident from a chaotic one is rarely the technology, but rather who is in charge and who is communicating.

The most telling key performance indicator is the percentage of tickets resolved at the first line. If it drops, it is a sign that the knowledge base is not keeping up.

Request fulfillment

Request fulfillment covers inquiries that are not faults: permissions, software, new equipment, and accounts.

These are handled through a service catalog where each service has a predetermined workflow: who is authorized to order, who approves, what happens next, and how long it should take.

The difference compared to incidents is that these are planned and repetitive. This makes them the best place to start automating – a new account created using the same steps every time rarely requires human intervention.

Keep the catalog short at the start. A service catalog with sixty items that no one maintains is worse than ten that are accurate.

Problem management

Problem management is about finding the root cause behind recurring incidents.

While incident management puts out fires, problem management looks for the cause of the fire. This work can be reactive, triggered by a disruption that has already occurred, or proactive, where you analyze patterns in ticket data to identify what is about to go wrong.

Known errors are documented along with the workaround. This prevents the service desk from investigating the same issue twice and dramatically reduces resolution times for recurring incidents.

This is the process most often skipped because no one is calling to remind you about it. It is also the one that provides the most value over time: every root cause addressed eliminates a stream of recurring tickets for good.

A practical way to get started: look at the five most common ticket categories from the last quarter and ask why they keep recurring. You don't need a formal process to begin.

Change management

Change management is the process of implementing changes with controlled risk.

The reality is uncomfortable: a large proportion of all serious operational disruptions are not caused by attacks or hardware failures, but by something someone just changed. An update rolled out on a Friday. A firewall rule that was supposed to be temporary. A certificate that no one knew was expiring.

Three types of changes are handled differently, and confusing them is the most common reason why the process is perceived as bureaucracy.

Standard changes are pre-approved and low risk: a new user, a routine patch run, replacing a client device. They should not go through a change advisory board. They should be logged and executed.

Normal changes require assessment: a version upgrade, a new integration, a reconfiguration of something business-critical. These are risk-assessed and approved before they are implemented.

Emergency changes are implemented to resolve an ongoing disruption. They can take precedence, but they must be documented afterward – otherwise, the exception will become the rule within six months.

A change advisory board, or CAB, reviews normal changes. The board doesn't need to be large or meet often, but it must have a mandate and representation from the business. A CAB consisting solely of technicians consistently misses business risks.

Four things every change should describe: what is to be done, which services are affected, how the change will be rolled back if things go wrong, and how you know it succeeded. The third point is the one most often missing and the one that costs the most when it is needed.

A change calendar shows what is planned and when. It serves two purposes: it prevents two teams from making changes in the same environment simultaneously, and it allows for the implementation of blackout periods when the business cannot tolerate disruptions—such as during financial closing, payroll processing, or peak season.

The connection to CMDB is what makes risk assessment meaningful. Without a register of dependencies, the assessment relies on someone remembering correctly.

For organizations subject to audit requirements, ISO certification, or NIS2, this is the process that makes ITSM indispensable. The requirement is rarely phrased as ITIL, but what is being requested—traceability of who changed what, when, and with whose approval—is exactly what change management provides.

A piece of advice: start simpler than you think you need to. A process perceived as an obstacle will be bypassed, and a bypassed process provides less traceability than no process at all.

Knowledge management

Knowledge management involves documenting solutions so they can be reused.

Resolved tickets become articles. Articles lead to fewer tickets—partly because agents find answers faster, and partly because users resolve issues themselves in the self-service portal. More on how to build this structure can be found under IT documentation.

Asset management and CMDB

A CMDB, or Configuration Management Database, is a register of the components in your IT environment and how they are interconnected.

Servers, applications, licenses, and services with their respective dependencies. The value becomes clear in two scenarios: when you are planning a change and want to know what will be affected, and when something is down and you need to know which services are impacted. Read more about CMDB and asset management.

SLA management

An SLA is a commitment regarding response and resolution times for a defined service.

In an ITSM system, SLAs are linked to ticket type, priority, and service, with automatic escalation before time runs out. Follow-up happens continuously rather than in retrospect.

Automation

Automation within ITSM means that recurring tasks are performed without manual intervention.

The most common examples are assignment, escalation, approval workflows, and account provisioning. User onboarding and offboarding are usually the first processes to be automated, as they are repetitive, error-prone, and frequent. See IT automation.

Reporting and improvement

Follow-up is what makes the difference between having a system and having a process.

Ticket volume over time, first-line resolution rate, SLA compliance, recurring issue types, and the percentage of changes that caused an incident. The latter is the most honest metric of whether your change management is working.

How to choose an ITSM system

Seven questions that matter more than the feature list.

How complex is your delivery, really? Do you need full ITIL coverage, or is structured ticketing enough? Buying too much costs both money and implementation time.

Who will manage the system? Some platforms can be configured by your own administrators, while others require a consultant for every change. This determines the cost of ownership over five years.

What is included in the price? Modular pricing looks cheap at sign-up but becomes expensive as you mature. Ask specifically what costs extra.

Where can the data be stored? The public sector, healthcare, and regulated industries often have requirements for data storage within the EU or on-premise operations.

What does it need to integrate with? Microsoft 365, Entra ID, monitoring, financial systems. Check that there are ready-made integrations, not just an API.

What does the migration process look like? Ticket history, assets, and knowledge base articles need to be included. Ask who is responsible for the work.

Who do you contact when something goes wrong? Time zone, language, and escalation paths. These matter less until the first time they matter a lot.

We intentionally deploy multiple ITSM platforms

A single-brand distributor can only recommend that one brand. We, on the other hand, can base our recommendations on what your business actually looks like—and advise against what you don't need.

In the ITSM space, we are the largest and most experienced distributor and implementation partner for HaloITSM in the Nordics.

If you instead provide IT services to external customers who pay via invoice, it is a PSA system you should be looking at.