IT Service Management and Service Levels

I-T service management and service levels. Domain four is about running I-T well day to day, and it starts where the business meets I-T: the service desk, and how it decides what to work first.

Picture a service desk queue worked strictly in the order calls arrive. This morning a request for a spare monitor is being handled ahead of a report that the payment system is down for the whole finance team, because the monitor request was logged first. Nobody set out to prioritise a monitor over payroll. The process just never distinguished them.

So start with what the service desk actually is: the single point of contact between users and I-T. Its value is not that it personally fixes everything, it cannot, but that every contact goes through one place that logs it, categorises it, sets a priority, and coordinates its resolution, escalating what it cannot resolve at first line.

And that single door is what makes the rest of operations measurable. Because every incident and request is recorded in one place, I-T can see what is breaking, how long things take, and whether service levels are being met. A user who phones a developer directly bypasses all of it, and the work becomes invisible.

Now the distinction the exam leans on. An incident is an unplanned interruption to a service, or a drop in its quality: the email server is down, a login fails. Something that was working is not. A service request is a standard, expected request for something: a new laptop, access to a system, a password reset. Nothing is broken; the user wants a routine service delivered.

They are handled by different processes, incident management to restore service, request fulfilment to deliver the item, so misclassifying one as the other routes it wrongly. Requesting a new laptop for a starter interrupts no running service. It is a service request, not an incident.

How is priority set, then. Not first come first served, and not by the rank of the caller, but by two things combined. First, impact: how much of the business is affected, and how badly, one user or the whole finance department.

And second, urgency: how quickly it must be resolved before the impact grows. Impact and urgency together give the priority.

So it is not arrival order, and not the caller’s seniority. A payroll outage affecting a whole team on payday is high impact and high urgency, and it outranks a spare-monitor request logged an hour earlier. A junior reporting a payroll failure outranks an executive’s minor query.

And that is what fixes the queue. Set priority by impact and urgency, and the payment outage jumps ahead of the monitor request automatically. That is precisely what stops the desk from serving a spare monitor while finance sits idle.

So the point of the service desk is not that it fixes everything itself. It is the single, recorded point of contact that triages by impact and urgency and coordinates resolution, and that coordination is what makes the whole of operations visible and measurable.

So carry this away. A request for something new is a service request, not an incident, and the distinction decides how it is handled. And priority is impact combined with urgency, never first come, first served.