01
IT service assessment
A fixed-scope review: ITSM practice, incident and problem flow, SLAs, escalation paths, prioritisation logic and who actually owns what.
Deliverable: a prioritised improvement plan with owners, effort and expected impact.
IT SERVICE MANAGEMENT
ITSM consulting — making daily service predictable.
When incidents repeat, SLAs drift away from what the business expects and ownership disappears between teams and suppliers, the problem is rarely the tool. We clarify what is genuinely measured, where accountability vanishes, and which decision has to be made.
WHEN TO CALL
Signs that service management needs attention.
Not every problem needs a new system. Most need clarity about who owns what.
01
Incidents repeat, but the causes stay vague.
Symptoms get cleared quickly, but with no problem management practice the same failure returns a month later.
02
SLAs exist in the contract, but nobody manages them.
Metrics are calculated but disconnected from decisions: it is unclear who acts when a threshold is breached, or what changes as a result.
03
Escalation depends on specific individuals.
When one engineer is away the process stops. Knowledge lives in heads rather than runbooks.
04
Nobody in the supplier chain owns the overall result.
Each supplier delivers their part, while the service as a whole has no owner.
WHAT YOU GET
From assessment to working practice.
You can start with one stage and stop — each produces a result on its own.
02
SLA and metrics rework
We clarify what is measured and why, align the metrics with business expectations, and connect them to concrete decisions and escalation.
Deliverable: a set of SLAs both IT and the business understand, with a clear response procedure.
03
Fractional IT leadership
Acting service delivery lead for organisations that need the function but not a full-time hire — proven while running services for multiple clients.
Deliverable: the function runs day to day, the practice is built and handed over.
HOW I WORK
Four steps, with proof that it runs.
A
Map the service
Business goal, service catalogue, teams, suppliers, risks and the real constraints — without assumptions.
B
Design the path
Priorities, ownership, escalation procedure, metrics and a way back if something goes wrong.
C
Prove it works
The practice is tested against real incidents, not in a spreadsheet: we measure whether resolution time and quality actually change.
D
Hand over control
Documentation, runbooks and the knowledge your team needs to operate independently.
FAQ
Common questions about IT service management
What is ITSM, and does our company need it?
ITSM treats IT as services with clear owners, metrics and procedure, rather than as a stream of failures. Not everyone needs formal ITSM, but every organisation that depends on IT needs clarity about ownership and escalation.
Do we have to deploy a new ITSM system?
Usually not. Most problems come from unclear ownership, priorities and escalation rather than from the tool. We fix the practice first; only then is it clear whether the existing systems are genuinely insufficient.
What is the difference between incident and problem management?
Incident management restores the service as fast as possible. Problem management finds the cause so the incident stops recurring. Organisations with only the first fight the same fires for years.
How do we know whether our SLAs are meaningful?
A meaningful SLA is tied to a business consequence and has an owner who acts when it is breached. If a metric is measured but nobody changes behaviour when it fails, it is a report, not an agreement.
How long does an IT service assessment take?
A fixed-scope assessment usually runs a few weeks, depending on the number of services and how quickly people and data are available. You finish with a prioritised plan, not a general audit.
Do you work with public sector organisations?
Yes. That experience includes delivering services under formal procurement, and managing scope and budget under those conditions.
OTHER SERVICES
Often addressed together
EXAMPLES
What this looks like in practice
Concrete examples: the situation work starts from, what is done, and what it is judged by.
START HERE
Bring a situation, not a specification.
The most useful first conversation is about what is actually going wrong: repeated incidents, drifting SLAs, or ownership nobody will take.