Operate
Service desk and ITSM
A service desk run to ITIL and ISO/IEC 20000 aligned processes, with the problem management most desks skip — and coverage hours you choose. Measured on the tickets it prevents as well as the ones it closes.
Duration
Transition 6–8 weeks, then continuous
Built on
ITIL 4 · ISO/IEC 20000
Who this is for
IT director
Has a team spending its week on password resets instead of the roadmap.
Operations leadership
Needs predictable response, not best efforts.
CFO
Is paying for support and cannot see what it delivers.
CISO
Knows the desk is where phishing is reported and where social engineering is attempted.
A service desk is judged on the tickets it prevents
Almost every service desk reports ticket volume and time to close. Both look like performance measures and neither is. Volume rises when the estate deteriorates and falls when users give up reporting things. Time to close improves when you get better at closing tickets, which is not the same as getting better at fixing causes — and a desk that closes the same incident forty times a month is performing well by its own numbers.
The discipline that changes this is problem management, and it is the ITIL practice most often skipped. An incident is restoring service now. A problem is the underlying cause of repeated incidents. Separating the two, and giving someone time and authority to work the second, is what makes the volume fall for the right reason.
The second missing piece is the catalogue. Where there is no agreed list of what the desk does and what it does not, everything becomes a ticket — including the things that should be self-service and the things that are somebody else's job. A catalogue is as much a boundary as a menu.
The desk is also a security control, and it is rarely resourced as one. It is where phishing gets reported, which makes it your earliest warning. It is also where an attacker will call to request a password reset for a colleague who is conveniently travelling. Identity verification at the desk is a control, and most organisations have never written theirs down.
Coverage is a window you choose — business hours, extended hours, or around the clock — priced for what you select and written into the service description.
How we do it
- 01
Intake and baseline
2 weeks
Current ticket data, the estate, the existing tooling and where the real load comes from. The pattern in twelve months of tickets tells you more about an IT estate than any audit.
- 02
Catalogue and service levels
2 weeks
What the desk handles, what it routes onward, what becomes self-service, and the response and resolution targets per category. Agreed with the business, not set by IT alone.
- 03
Workflows and tooling
2 weeks
Incident, request and problem separated properly, with escalation paths and a knowledge base that is written as work happens rather than as a project afterwards.
- 04
Transition
2–4 weeks
Runbook capture, shadowing and phased handover. Nothing transfers on a single date.
- 05
Run
continuous
Within the agreed coverage window, with named escalation contacts and reporting that shows causes as well as counts.
- 06
Continual improvement
quarterly
The problem register worked, the top recurring causes eliminated, and the catalogue revised as the estate changes.
Named artefacts
What you receive
- Service catalogue with clear boundaries
- Service level definitions per category, agreed with the business
- Incident, request and problem workflows, properly separated
- Knowledge base, maintained as part of the work
- Identity verification procedure for the desk, as a security control
- Problem register with root causes and elimination progress
- Monthly reporting on volume, performance and recurring causes
- Quarterly service review with the business
What we need from you
- Historical ticket data, if it exists. If it does not, an acceptance that the first quarter partly builds the baseline.
- Business agreement on the catalogue and the service levels. Imposed targets are ignored targets.
- Access to the estate and its documentation, and the people who hold the undocumented parts.
- Authority for problem management to change things. A problem register nobody can act on is a list of complaints.
What changes
- 01Recurring incidents reduce because their causes are worked rather than their symptoms.
- 02Users know what the desk does and how quickly, so expectations stop being a source of friction.
- 03Your internal team gets its week back for work that only they can do.
- 04Reported phishing reaches security quickly, because the desk knows what to do with it.
- 05Password reset requests are verified against a written procedure rather than against tone of voice.
What it costs
On request
All prices exclude VAT.
Questions
Do you replace our internal IT team?
Usually we take first line and the volume, so your team can do the work that needs to know your business. Full outsourcing is possible and we will say plainly when we think it is the wrong answer for you.
Which hours?
Whichever you select — business hours, extended, or around the clock. It is written into the service description and priced accordingly, rather than implied.
Will you use our ticketing tool?
Yes, where it is serviceable. Where it is not, we will say so and what replacing it would involve. Moving tooling during a transition is usually a mistake — one change at a time.
How do you measure success?
Response and resolution against agreed targets, and the reduction in recurring incidents. The second matters more, and it is the one that makes the service cheaper over time rather than more expensive.
Leave with your top three risks documented
Thirty minutes with a senior practitioner. No slideware, no sales engineer.