ITSM, or IT service management, means treating what IT delivers as a service: with a catalogue, defined processes, agreed response times and named owners. It is neither a tool nor a certification — it is a way of organising work. The tooling and the framework come afterwards, to sustain and standardise the operation.
The distinction matters because most ITSM conversations start in the wrong place. A team evaluating a service desk platform, or a manager asked to approve one, tends to focus on features and price before agreeing on what problem is being solved. ITSM is the answer to a management question, not a technology question: how does IT commit to a level of service, measure whether it delivers it, and improve when it does not?
This post defines the three terms that come up in every ITSM conversation — ITSM, ITIL and ITOM — maps four observable levels of operational maturity, and describes a starting point that does not require freezing the operation while the team restructures.
ITSM, ITIL and ITOM: what each one is
The three terms appear together constantly and are used interchangeably often enough to cause real confusion in procurement conversations and implementation projects. They are related but not the same thing.
| Term | Full name | What it covers |
|---|---|---|
| ITSM | IT Service Management | The practice of organising how IT delivers services to users: catalogue, processes, SLAs, owners. A way of working, not a specific tool or framework. |
| ITIL | IT Infrastructure Library | The most widely used body of guidance for structuring ITSM. Describes practices (incident, change, problem…). ITIL 4 is the current version. Adopting ITIL is optional; most teams take the concepts without following the full framework. |
| ITOM | IT Operations Management | Covers the infrastructure layer: monitoring servers, networks, cloud resources and application availability. ITOM keeps the lights on; ITSM handles what users experience when a light goes out. |
The relationship in practice: ITOM keeps infrastructure running; ITSM manages what users receive from that infrastructure; ITIL provides the vocabulary and practice descriptions that make ITSM teams speak a common language.
Why the distinction matters for decisions: a team that confuses ITSM with ITIL may invest in certification before building a working catalogue. A team that confuses ITSM with ITOM may buy monitoring tools when what the operation needs is a ticketing process. And a manager who equates ITSM with a specific platform may change tools without changing the underlying practice — and find that the new platform produces the same results as the old one.
The practices that show up first in real life
ITIL 4 defines 34 management practices. In practice, three appear in almost every ITSM implementation before the others, because they address the highest-frequency friction in any IT operation.
Incident management covers everything that interrupts a service: a system down, an account locked, a printer offline. The goal is restoration — returning the service to normal operation as quickly as possible. Incident management is the practice that most IT teams have in some form before they formalise anything else, because users report outages regardless of whether a process exists to receive them.
Service request management covers the predictable, pre-approved things users ask for: a new laptop, a software installation, access to a shared drive. Separating requests from incidents is the first structural decision most teams make when moving from reactive to organised. Requests have predictable effort; they should not queue behind incidents of unknown severity.
Change enablement covers modifications to the infrastructure or systems that could affect service: a server update, a configuration change, a new deployment. The practice exists not to slow changes down, but to ensure that changes are reviewed, authorised and communicated before they are made — so that when something breaks after a change, the team knows what changed and can reverse it.
These three practices together create the foundation on which everything else in ITSM is built. A team that has functional incident, request and change processes — with a catalogue, a queue and defined SLAs — has more operational maturity than a team with an enterprise ITSM platform and no process discipline.
Four levels of maturity
The maturity scale below is not a certification framework. It is a practical tool for locating where an IT operation currently sits and identifying the specific signal that indicates readiness to move to the next level. Each level is defined by an observable characteristic, not by the tools in use.
| Level | Label | Observable signal |
|---|---|---|
| Level 1 | Reactive | No catalogue, no queue. Work arrives by chat, call or corridor. Everything is urgent because there is no triage. The team knows who knows things; no one else does. |
| Level 2 | Organised | A single intake channel exists. Requests are logged. There is a rough catalogue and first response times are tracked, even if not always met. The team can report volume. |
| Level 3 | Process-led | Incident, request and change are separate flows with defined owners. SLAs are published and reviewed. Problems generate known-error records. A knowledge base exists and is used. |
| Level 4 | Value-focused | Metrics drive decisions. Continual improvement reviews are scheduled. Users interact through self-service. IT proposes changes before problems surface. Compliance evidence is generated automatically. |
Most IT teams in organisations of 50–500 people operate between Level 1 and Level 2. Moving from Level 1 to Level 2 requires one decision and one tool, not a restructure. Moving from Level 2 to Level 3 requires process discipline — which a platform can support but not replace.
The maturity level is not determined by the size of the team or the complexity of the infrastructure. A ten-person IT team serving a 300-person company can operate at Level 3 with a simple platform and clear process ownership. A 40-person team in a 5,000-person company can operate at Level 1 if requests arrive through informal channels and there is no catalogue or queue.
Starting without stopping the operation
The most common reason ITSM implementations stall is scope. A team that tries to define a complete service catalogue, implement all ITIL practices and migrate historical data before going live will not go live. The operation does not stop while the project runs.
A starting sequence that works in practice has four steps, each of which produces a visible result before the next begins.
Step 1 — Define a minimal service catalogue. List the ten or fifteen services that account for 80% of requests. Do not aim for completeness. The catalogue exists to give users a shared vocabulary for what IT delivers and to give IT a way to categorise work. It can be expanded after it is in use.
Step 2 — Create a single intake channel. Email, a web form, or a ticketing portal — one channel that becomes the official way to submit a request or report an incident. The channel does not need to be sophisticated. It needs to exist and to be communicated. Requests that arrive through other channels are redirected, not handled informally.
Step 3 — Define response and resolution targets for the highest-volume categories. Not for every category — for the top five. Publish them to users. This is the first SLA commitment, and it creates accountability where there was none. Teams that skip this step often find that the catalogue and the channel produce data without producing improvement.
Step 4 — Review the data after 30 days. Volume by category, first response time, resolution time, unresolved tickets older than the target. This review is not a performance evaluation — it is the first iteration of a continuous improvement cycle. The output is a short list of adjustments to the catalogue, the targets or the process.
At the end of this sequence, the operation has moved from Level 1 to Level 2. The team has a catalogue, a queue, SLAs and data. That is the foundation for everything that follows — change management, problem management, knowledge management — without having restructured the entire operation before knowing whether the foundation works.
ITSM implementation with Aufiero Informatica
Aufiero Informatica is the official distributor of OTRS and EasyVista for Latin America — two platforms designed for organisations at different points in the maturity scale. OTRS covers the full ITSM practice set with a high degree of configurability, suitable for teams moving from Level 2 to Level 3 or beyond. EasyVista addresses more complex environments with enterprise integration requirements.
If your team is evaluating which platform fits the current maturity level and the next step, or if the first implementation did not produce the expected results, Aufiero can help structure the conversation around process before platform. Teams working towards ISO/IEC 20000-1 certification can use the maturity scale above as a starting self-assessment.
Frequently asked questions about ITSM
What is ITSM?
IT service management: running what IT delivers as a service, with a catalogue, process, agreed times and owners.
What is the difference between ITSM and ITIL?
ITSM is the practice of managing services; ITIL is the most widely used body of guidance for structuring it. ITSM can be practised without following ITIL; ITIL provides vocabulary and practice descriptions that help teams align.
What is the difference between ITSM and ITOM?
ITSM covers the services delivered to users; ITOM covers the operation of the infrastructure beneath them. ITOM keeps systems running; ITSM manages what users experience when something goes wrong.
Do I need ITIL certification to implement ITSM?
No. Certification helps align vocabulary across a team, but the operation starts with a catalogue, queues and SLAs — none of which require certification. Many effective ITSM implementations are built by teams with no formal ITIL training.
What is the first step?
Define a minimal service catalogue and a single intake channel for requests. Those two elements are sufficient to move from reactive operation to organised operation — the first structural shift in the maturity scale.
