Skip to content

info@dotslash.co.uk  ·  LinkedIn

New: The Service Operations Framework, Second Edition.  Read it →

IT Service Operations · IT Service Management

Service Management, Executed.

IT Service Management is where decisions become work, and work becomes knowledge.

Detection finds the signal. Observability explains it. AIOps decides what matters. None of it counts until something gets done, and somebody learns from it.

That is IT Service Management: the act and learn stages of the operations loop. Incidents resolved at speed. Major incidents run with calm and command. Problems solved at the root. Change made safe enough to move fast.

Hero Visual Options-selectionv3

Process First

A Tool Is Not a Strategy.

You can tell the difference by the numbers. Green dashboards over red services. SLAs met while customers suffer. Incident counts driven down by reclassification rather than improvement.

We measure what is real. Time to restore. Repeat incidents. The percentage of work that leads to action. Honest numbers are sometimes uncomfortable, and they are the only kind that make anything better..

Almost every enterprise owns an ITSM platform. Far fewer practise IT Service Management.

“Honest numbers are sometimes uncomfortable. They are the only kind that make anything better.”

Core Practices

Return to Discipline.

Getting to those honest numbers requires more than just turning on a new platform. It demands a return to the core disciplines of IT Service Management. We break this down into four non-negotiable practices: how you respond to an everyday break, how you command a critical outage, how you learn from a failure to prevent its return, and how you ship safely to keep moving fast. When these four elements are engineered to work in harmony, the tool finally serves the operation.

Incident Management

Logged. Owned. Restored.

When a service breaks, speed is the headline. Discipline is what makes speed possible.

Fast restoration is built on unglamorous habits. Every incident logged against a configuration item in the CMDB, so impact is known before triage begins. Priority set by what the business is losing, not by who shouts loudest. A clear owner from the first minute to the last.

It sounds basic. It still isn't standard. We walk into enterprises every month where "affected system" is a free-text field and priority is a matter of opinion. Fix the discipline and the speed follows.

And the fastest responder isn't a person. Triage, enrichment, escalation and safe first response can all run automatically, in the first fifteen minutes, before anyone is paged. But automation only acts on what it can trust: a machine cannot prioritise an incident logged against a free-text field.

Major Incident Management

The 3am Test.

A major incident isn’t declared because a server is down. It’s declared because the business is down.

Is it the payments platform, or the contact-us page on the website? Only the Service Operations answers that question, and at 3am you need the answer in seconds. Without it, every loud incident becomes a major one, and the word 'Major' stops meaning anything.

Every minute of a major incident carries a price tag, so we rehearse for it the way other professions rehearse for fire.

Problem Management

Never Twice.

Incident management restores the service. Problem management makes sure you stop having to.

This is the learn stage, and it is the one most companies skip. Reviews happen, documents get written, nothing changes, and the same outage returns wearing a different timestamp.

Done properly, problem management is ruthless about cause and honest about recurrence. Every review ends in an action that someone owns. Repeat-incident rate becomes a number leadership actually sees. The measure of a good operation isn’t how well it handles the same failure. It’s how rarely it has to.

Change Management

Where Most Incidents Begin.

Most incidents aren’t bad luck. They start with a change.

That makes change the cheapest place to prevent them. Prevention doesn't mean slowing everything down: an approval board that rubber-stamps a hundred changes a week protects nobody. It means knowing the risk of every change before it ships.And risk is a question of dependencies. You cannot judge what a change might break without a current map of what depends on what. That map is the CMDB, and it is a discipline in its own right.

Get the assessment right and a useful thing happens. Routine change flows without friction, risky change gets real scrutiny, and the business stops choosing between moving fast and staying up.

This is no longer a manual discipline. Change risk can now be assessed automatically, against real operational context rather than a checklist: low-risk changes approved without delay, high-risk ones flagged with recommended actions before they ship. Incidents prevented before they exist.

The Front Door

The Front Door.

The other half of service management is how your business consumes IT every single day. A truly quiet operation starts by removing friction at the very first touchpoint.

REQUEST

Requests fulfilled without friction.

PORTAL

A portal people use because it works, not because they’re told to.

SERVICE STATUS

Proactive service status that answers the question before it ever becomes a ticket.

Make It Stick.

Process your teams ignore is worse than no process at all. We build IT Service Management your teams actually use.

dotslash works across the whole Service Operations loop, so your service management isn’t a silo with a ticket queue. It is wired to your monitoring, your observability and your AIOps, fed by clean signal and feeding back what it learns. 
Get it right and it compounds: fewer repeat incidents, faster change, an operation that learns its way out of firefighting. We make the discipline work, on the tools you have or the tools you choose.