IT Service Management Design
Designing the processes — not running your service desk.
Service catalogue, service levels, and the incident, request, problem and change processes underneath them.
Advisory. Process design and improvement. Running the service desk is not what this is.
IT leaders and service managers, in-house teams, and organizations holding an MSP to a contract.
Everything is a priority one, changes go in unannounced and break things, or nobody can say what service levels you are actually getting.
The practice
Service catalogue
What services you actually provide, in business language, with an owner, a cost and a consumer against each one. Most estates have never had this written down.
Service levels
Targets that mean something, the operational agreements behind them, and how they line up with what your suppliers have actually committed to.
Incident and major incident
Priority that reflects business impact rather than who is asking, escalation that triggers on time, and a major incident process people have rehearsed.
Request fulfilment
A request catalogue with defined fulfilment paths and approvals, which is what moves volume off the service desk and into self-service.
Problem management
The discipline almost everyone skips: recurring incidents investigated, root causes recorded, known errors published, and fixes funded.
Change enablement
Standard, normal and emergency paths with risk-based approval, so low-risk work moves quickly and the risky change gets the scrutiny.
Configuration
A configuration model scoped to the decisions it supports — impact analysis and change risk — rather than a CMDB nobody can maintain.
Metrics and reporting
Resolution times, first-contact resolution, reopen and change failure rates, backlog age. Measures that drive behaviour, not a dashboard of green.
Roles and tooling
Who owns each process, and the configuration of the ITSM platform you already run to support it. Process first, tool second.
Designed together, or they undo each other.
Change approval that treats a password reset like a firewall rule produces the same outcome as no approval at all: people route around it.
What you provide, in business language, with an owner, a cost and a consumer against each service. Everything else references it.
- Incident and major incident
Priority by business impact, escalation that triggers on time, and a rehearsed major incident path.
- Request fulfilment
A request catalogue with defined paths and approvals, which is what makes self-service possible.
- Problem management
The one everyone skips: recurring incidents investigated, known errors published, fixes funded.
- Change enablement
Standard, normal and emergency paths, so routine work moves and the risky change gets scrutiny.
We design the service management processes: the catalogue, the service levels, and the incident, request, problem and change processes underneath them — with the roles, metrics and tool configuration to support them.
The design is where service quality is decided
Most service problems are not effort problems. They are priority schemes that reflect volume rather than impact, escalation that nobody triggers, change approval that treats a password reset like a firewall rule, and an absence of problem management that guarantees the same incident returns monthly.
Problem management is the one everyone skips
Incidents get closed, the same incident returns, and the cycle continues because nobody is funded to find out why. Standing up problem management — recurring incident analysis, a known error record, and fixes that make it into the portfolio — takes more pressure off a service desk than any tooling change.
Change enablement should speed most work up
A single approval path punishes routine work and gives the risky change the same cursory review as everything else. Risk-based paths let standard work proceed on pre-approval, and give the change that could take down the ERP the scrutiny it deserves.
Where this stops
We design and improve the processes and configure the platform you run. We do not operate your service desk. Where you have an MSP, this is the work that makes their contract measurable — and tells you whether you are getting what you are paying for.
What you keep
The code and the data·Your existing relationships·Approval and control·The ability to stop·The off switchWhat that means
IT Strategy
A technology plan tied to what the business is trying to do, and funded.
Learn more ↗Enterprise Architecture
Standards, reference models and the governance that makes them stick.
Learn more ↗AI Strategy & Enablement
The same strategy discipline, pointed entirely at AI.
Learn more ↗IT Portfolio Management
Demand, capacity and money, managed as one view instead of three arguments.
Learn more ↗IT Operating Model
How IT is organized, funded and held to account — and who decides what.
Learn more ↗Program & Project Delivery Assurance
An independent read on whether a programme is where it says it is.
Learn more ↗IT Financial Management
Knowing what technology costs, where it goes, and what it buys.
Learn more ↗Fractional CIO
Senior technology leadership, in whatever shape the situation needs.
Learn more ↗Start with a 45-minute briefing.
No pitch. We’ll map your situation against what actually works and tell you honestly where to start.