7.1 Service Request Management and the Service Desk
Key Takeaways
- Service request management's purpose is to support the agreed quality of a service by handling all pre-defined, user-initiated service requests effectively and in a user-friendly manner
- A service request is normal and pre-planned; an incident is an unplanned interruption or quality reduction — knowing the difference is heavily tested
- Standardization and automation of request models are essential to fulfil requests at the speed and scale users expect
- The service desk's purpose is to capture demand for incident resolution and service requests and to be the single point of contact between the provider and all users
- Modern service desks are omnichannel and increasingly automated, but still depend on empathy, emotional intelligence, and communication skills
Service Request Management: Purpose
The purpose of the service request management practice is "to support the agreed quality of a service by handling all pre-defined, user-initiated service requests in an effective and user-friendly manner." Memorize that wording — examiners quote it directly. Two phrases carry the marks: pre-defined (the request type is already understood and agreed) and user-friendly (the experience matters as much as the outcome).
What a service request is
A service request is a request from a user, or a user's authorized representative, that initiates a service action which has been agreed as a normal part of service delivery. Common examples:
- A request for a service delivery action (e.g., provide a report, replace a toner cartridge)
- A request for information (e.g., how do I book a meeting room?)
- A request for provision of a resource (e.g., a new laptop, a software licence)
- A request for access to a resource (e.g., access to a shared folder)
- Feedback, compliments, and complaints
Because they are normal and pre-planned, service requests can be standardized and automated to a large degree.
Service Request vs Incident (heavily tested)
This distinction appears on almost every ITIL 4 Foundation exam. The trap is that both arrive through the same channels and may be logged on the same tool — but they are different concepts.
| Aspect | Service request | Incident |
|---|---|---|
| Nature | Normal, expected, pre-defined | Unplanned interruption or reduction in quality |
| Trigger | A user wants something delivered | Something has broken or degraded |
| Mindset | "Give me something" | "Fix something" |
| Predictability | Known, repeatable, planned | Unexpected |
| Example | Request a new phone, reset a password (as a normal action) | Email is down; the website is returning errors |
If a question describes something planned and routine, it is a service request. If it describes an unplanned failure or quality drop, it is an incident — handled by the incident management practice, not service request management.
Standardization, automation, and request models
Because requests are pre-defined, service request management thrives on standardization. Each type of request should follow a documented, repeatable request model — a defined procedure for handling a particular kind of request, specifying the steps, approvals, and fulfilment teams involved.
Key points the exam expects:
- Requests and their fulfilment should be standardized and automated as much as possible.
- Policies should define which requests are fulfilled with limited or no additional approvals to streamline delivery.
- The expectations of users regarding fulfilment times should be clearly set, based on what the organization can realistically deliver.
- Opportunities for improvement should be identified to make fulfilment faster and take advantage of automation.
Some requests need authorization (financial, security, or compliance), so request models often include approval steps — but well-designed models keep approvals minimal where risk is low.
Why standardization matters so much
Users today expect the same fast, self-service experience they get from consumer apps. ITIL 4 stresses that fulfilment procedures should be optimized, and that users should be given a single, easy way to request and receive standard services. When each request is standardized into a model, the organization can predict its workload, set sensible fulfilment targets, route work to the right team automatically, and steadily move repetitive requests to self-service and automation.
The practice therefore depends heavily on good design: every new request type should be reviewed to see whether it can be simplified, automated, or removed entirely. Requests should also be tracked so the organization can report on volumes, fulfilment times, and satisfaction, feeding continual improvement.
The Service Desk: Purpose
The purpose of the service desk practice is "to capture demand for incident resolution and service requests." The service desk is the single point of contact (SPOC) between the service provider and all of its users. Two things are tested here: the desk handles both incidents and requests, and it serves users (people who use the service day-to-day), not necessarily customers (who define requirements and authorize budgets).
A practical, not just technical, function
A major message in ITIL 4 is that the service desk has a huge influence on user experience and on how the provider is perceived. Even when technical issues are resolved elsewhere, a positive, empathetic interaction with the desk shapes satisfaction. So the desk needs strong practical skills, not only technical ones.
Channels and the shift to omnichannel
Users reach the service desk through many channels:
- Phone calls (including specialized technology such as interactive voice response)
- Service portals and mobile applications
- Live chat and chatbots
- Walk-in desks (still useful in some contexts)
- Public and corporate social media and discussion forums
ITIL 4 highlights the move toward an omnichannel experience, where a user can move between channels and the desk retains context. The desk is increasingly supported by automation — self-service portals, AI chatbots, knowledge bases, and robotic process automation reduce simple, repetitive contacts.
Skills and centralization
Even with heavy automation, ITIL 4 stresses that service desk staff need empathy, emotional intelligence, business understanding, and excellent communication skills to handle the human side of incidents and requests. Service desks can be centralized (one team for the whole organization), local/distributed, virtual (staff working from many locations with shared tools), or follow-the-sun (handing off across time zones for 24/7 coverage).
Automation does not remove the human need
ITIL 4 is explicit that as technology improves, the service desk becomes more automated — but it does not become less human. The remaining human contacts tend to be the complex, sensitive, or emotional ones, exactly where empathy and communication matter most. So the service desk balances two things at once: efficient, automated handling of routine, high-volume contacts, and skilled, empathetic people for the contacts that need judgement. The desk should also understand the wider business context so it can recognize the impact of an issue on the user and escalate appropriately.
In short, automation handles scale; people handle experience — and the exam expects you to recognize that both are required, not one instead of the other.
Which statement best captures the purpose of the service request management practice?
A user emails the service desk because the company's customer portal is suddenly returning errors and they cannot log in. How should this be classified?
Which phrase best describes the role of the service desk in ITIL 4?