ITSM Explained: Processes, ITIL and Tools for Small Teams

IT service management, or ITSM, is the discipline of running IT as a service. Instead of managing servers and applications as technical assets, an ITSM approach asks what the people who use them need, how reliably they receive it and how the provider improves over time. A service desk that answers requests, a process for restoring service after an outage and a method for making changes safely are all parts of ITSM.

The term is used for two things. One is the set of practices, which any team can adopt. The other is the category of software built to support them. It is useful to keep these apart, because a team can have good practices without a suite and can buy a suite without gaining the practices.

ITIL, the common reference

ITIL is a widely used framework of ITSM practices. It describes a set of practices rather than a single method, and organisations adopt as much of it as is useful. Many use its vocabulary, such as incident, problem, change, request and service level, without following the whole framework. Treat it as a reference to borrow from, not a standard that must be satisfied in full. Other frameworks and standards also exist, and software teams often draw on site reliability engineering practices alongside.

What counts as a service

The word service carries most of the weight in the discipline. A service is a means of delivering value to someone by helping them achieve an outcome, without them having to own the cost and risk of the specific technology behind it. Email is a service. Payroll processing is a service. A laptop is not a service, but the arrangement that provides, supports and replaces laptops is.

The distinction matters because it changes what you measure. A team that manages servers counts uptime of machines. A team that manages a service asks whether the people relying on it can do what they need to do. The machines can all be running while the service is failing, for example when a certificate has expired or a permission has been removed.

Two further terms recur. A customer is the party that agrees the service and its terms, such as a department head or a client. A user is the person who actually uses it. They are often different people with different needs, and a good service desk serves both.

The core practices

• Service request management: handling standard requests from users, such as access, equipment and information.
• Incident management: restoring service after an unplanned interruption. See the incident management guide.
• Problem management: finding and addressing the causes of incidents. See the problem management guide.
• Change enablement: assessing and authorising changes so that they are safe and timely. See the change management guide.
• Service desk: the single point of contact between the provider and its users. See the service desk guide.
• Knowledge management: capturing what is known so that answers are found rather than rediscovered.
• Service level management: agreeing and measuring what level of service will be provided.
• Asset and configuration management: knowing what you run and how the pieces relate.
• Continual improvement: using measures and reviews to improve the other practices.

Service levels and the agreements behind them

Service level management is the practice of agreeing what level of service will be provided and checking that it is. Three kinds of agreement are commonly distinguished. A service level agreement is between the provider and the customer. An operational level agreement is between internal teams, for example the time the network team will take to respond to a request from the service desk. An underpinning contract is with an outside supplier whose work supports the service.

The reason to separate them is that a promise to a customer can only be kept if the agreements underneath it are at least as strict. A desk that promises a one-hour response while the team it depends on promises a four-hour response has made a promise it cannot keep. See the service desk SLA guide for how to set targets, and the guide to SLI, SLO and SLA for the engineering view.

Request fulfilment and the service catalogue

A service request is a formal request from a user for something that is standard, expected and low risk to provide. Because the requests recur, they can be defined once and handled the same way each time. The list of what can be requested, with who can request it, what it costs, how long it takes and who fulfils it, is called the service catalogue.

A catalogue need not be elaborate. A page that lists the twenty most common requests, each linking to a form, is a catalogue. The discipline it imposes is valuable: each entry forces the team to decide what information it needs, who approves and how long the work should take. Standard requests that are pre-approved should flow straight to the fulfiller, while those that need a decision, such as access to sensitive data, should route to an approver first.

Atlas does not provide a service catalogue with fulfilment workflows. The nearest equivalent is a set of forms, each creating a task in a project with an owner, and an approval state on the task where a decision is needed. For a small team that is often enough. A large organisation with hundreds of request types, cost recovery and automated provisioning should look at a dedicated ITSM suite.

Distinguishing the four things people confuse

• A request asks for something that is expected and standard, such as a new account. It is not a failure.
• An incident is an unplanned interruption or degradation. Something that should work does not.
• A problem is the cause behind one or more incidents.
• A change is a deliberate modification to a service or its components.

Ownership: who is responsible for what

Practices fail when nobody owns them. Two roles are worth naming even in a small team. A service owner is accountable for a service as a whole: its quality, its cost and its improvement. A process owner is accountable for how a practice, such as incident handling or change, is designed and whether it works. One person can hold several of these roles.

Write the owners down. When a recurring problem has no owner it is an annoyance, and when it has an owner and a date it is a project. The same applies to the knowledge base, the escalation policy and the change calendar: each needs a named person who reviews it on a schedule.

ITSM, DevOps and site reliability engineering

Teams that build and run software sometimes see ITSM as a competitor to DevOps or site reliability engineering. In practice they address different parts of the same work. DevOps practices shorten the path from change to production and put the people who build a service in charge of running it. Site reliability engineering adds objectives, error budgets and a habit of automating toil. ITSM contributes the vocabulary and discipline for handling requests, incidents, problems and changes in a consistent, auditable way, and for dealing with people who are not engineers.

The friction appears when ITSM is applied as heavy approval in front of every change. A team that deploys many times a day cannot send each deployment to a weekly board. The resolution is to move control into the delivery path: peer review, automated tests, staged rollouts and recorded deployments, with a human approval kept for the changes that carry real risk. The IT change management guide describes this in more detail.

A staged path

A realistic adoption plan has stages. Each should produce a visible benefit before the next begins.

• Weeks one to four: choose the single front door for requests, publish it, and triage the queue at fixed times. Agree a one-page outage procedure and name who is on call.
• Months two and three: define severity levels, write the first runbooks for the most common failures, hold a short review after each significant incident and begin recording repeat causes as known errors. Start a change calendar.
• Months four to six: introduce standard changes for routine work, a light approval for the rest and a regular review of the oldest open requests. Begin to track a handful of measures.
• After six months: review which practices earned their keep. Remove the ones that did not, and decide whether the volume now justifies a dedicated tool.

Starting small

A team of five does not need a nine-practice programme. Begin with the practices that cause the most pain and build outward.

• Give users one place to ask for things, and make it visible. See the service desk guide.
• Agree how you will handle an outage: who is on call, how severity is set, how users are told. Write it on one page.
• Review incidents briefly, and record the repeating ones as problems with workarounds.
• Introduce a lightweight change habit: a short request, a second reviewer, a calendar, a way back.
• Keep a knowledge base of answers that were asked twice.
• Measure a few things: how long requests wait, how often incidents recur, how long recovery takes.

Where a work platform fits

Atlas is a work platform, not a full ITSM suite, and it is better to say so than to imply otherwise. It does not provide a configuration management database, a service catalogue with fulfilment workflows or dedicated request SLA timers. It does provide several of the practices directly.

• Incident management with severity levels, roles, a timeline, approved customer updates and reviews, and on-call schedules with escalation policies. These are included from the Team plan.
• Problem handling through known causes with workarounds on the incident reviews screen.
• Change enablement for software and platform changes through Release Management: scope, checklist, sign-off, freeze windows and deployment records.
• Request intake through public forms that create tasks, email-to-task addresses, and an inbox triage view for deciding on each new item.
• Automation rules that match events such as a task being created and then set fields, apply labels, notify someone or call a webhook.
• A wiki for knowledge, available from the Pro plan, and an audit log for accountability.

Knowledge management in practice

Knowledge is the practice that most reliably repays effort and is most often neglected. Its aim is simple: the second time someone asks a question, the answer already exists. The method is equally simple. When a request is resolved and the solution is reusable, the person who resolved it writes a short article while the details are fresh, in the words a user would use to search for the problem.

Give each article an owner and a review date, because an out-of-date article is worse than none. Retire articles for systems that no longer exist. Link articles from the forms and alerts where the question arises. Review search terms that returned nothing, since each is a question users have and the knowledge base cannot yet answer.

Reporting to leadership

Leaders do not need ticket counts. They need to know whether the services they depend on are reliable, whether the team is keeping up and whether risk is rising. A one-page monthly view is enough: the incidents that mattered, with their duration and the follow-up actions; request volume and wait time against the target; the changes made, how many failed and how many were emergencies; the open known errors and their age; and one or two decisions that the team needs.

Explain every number in a sentence. A figure that moves without comment invites the wrong conclusion. Where a target was missed, say why and what is being done. Reports that admit misses build the trust that lets a team ask for investment when it needs it.

Common objections

• "This is too much process." Apply only the practices that address a current pain, and keep each as light as the risk allows. A one-page procedure is process too, and it is the one that works.
• "We are an engineering team, not an IT department." The practices describe how any group runs a service for other people. Engineering teams that run production already do incident, problem and change work, whether or not they call it that.
• "We will buy a tool and the practices will follow." They do not. Agree how you will work first, then choose a tool that supports it.
• "Nobody has time." The time is spent already, in repeated incidents, rediscovered answers and unclear ownership. The practices move that time to the front, where it costs less.

Measure what matters

• Request wait time and resolution time, by type.
• Incident counts by severity, and time to acknowledge, mitigate and resolve. See the MTTR guide.
• Repeat incidents from the same cause.
• Change success rate and the share of emergency changes.
• User satisfaction, asked briefly and consistently.

Common mistakes

• Buying a suite before agreeing the practices it should support.
• Copying a framework in full and drowning the team in process.
• Measuring activity, such as ticket counts, instead of outcomes.
• Treating every request as an incident and every incident as a crisis.