Service Request Management Procedure

1. Introduction

A service request is a formal request from a user for something the service provider already offers: information, access, a standard item, advice or a routine action. Requests are expected, repeatable and have a defined fulfilment path, which separates them from incidents (something is broken) and from changes (something new or non-standard is to be done to a service).

This procedure sets out how requests are offered through the request catalogue, approved where needed, fulfilled within target and closed with the requester's agreement.

2. Purpose

This procedure makes sure that every request is recorded, authorised by the right person, fulfilled by the right team, within a target that the requester knows in advance, and with evidence that it was done. It prevents requests being handled by informal favours that bypass approval, leave no trace and cannot be measured.

3. Objectives

• Offer each routine request through a catalogue entry with a clear description, form, approver, fulfilment path and target time.
• Fulfil at least [95%] of requests within their catalogue target.
• Obtain approval before fulfilment for every request that needs it, and never fulfil a request that has been refused.
• Keep the requester informed of progress and expected completion without needing to ask.
• Reduce manual effort year on year by automating the [ten] highest-volume requests.
• Reach a satisfaction score of at least [4.2 out of 5] on closed requests.

4. Scope

• In scope: all requests listed in the request catalogue, raised by employees, contractors and customer users, through the portal, email, telephone or chat.
• In scope: access requests, new starter and leaver requests, hardware and software requests, information requests, and routine service actions such as password resets or mailbox changes.
• Out of scope: faults (see the Service Incident Management Procedure), new services or non-standard changes (see the Change Management Procedure and the Service Design and Transition Procedure), and complaints.
• Applies to: the service desk, fulfilment teams, approvers, service owners and every requester.

5. Terms and definitions

6. Roles and Responsibilities

7. Request Management Process

7.1 Inputs and outputs

7.2 The request catalogue

Each request the Organisation will accept is an entry in the request catalogue. An entry is created by the catalogue manager at the request of a service owner and reviewed every [6 months]. A request that is not in the catalogue is treated as an enquiry: the analyst records it, and either finds the right route or asks the service owner whether an entry should be created.

7.3 Receiving and logging a request

1. ReceiveThe requester submits a request through the portal, which presents the catalogue form. Requests that arrive by telephone, chat or email are entered by the analyst on the same form during the contact or on first reading.
2. Check for what it isThe analyst confirms the contact is a request. A fault is opened as an incident; a new or non-standard need goes to the service owner or to the Change Management Procedure.
3. ValidateThe analyst checks that mandatory fields are complete, that the requester is entitled to ask, and that the beneficiary is identified. Incomplete requests are returned within [1 business day] with a clear list of what is missing; the clock is paused until the reply.
4. AcknowledgeThe requester receives the request number, the approvals needed and the target date within [30 minutes] of logging.

7.4 Approval

Fulfilment must not begin before the approvals shown for the request model are recorded. The approval is requested in [the ticketing tool], so the name, time and decision are held in the record. An approval by email or chat is pasted into the record by the analyst; a verbal approval is not accepted.

1. RequestThe system sends the approval to the named approver with the request details, the reason, the cost and the security effect.
2. RemindIf no decision is made in [1 business day], the analyst reminds the approver; after [2 business days] the alternate is asked.
3. DecideA refusal must carry a reason. The requester is told within [1 business day] and may resubmit with new information.
4. ExpireAn approval is valid for [30 days]. After that the request is re-approved before fulfilment.

7.5 Fulfilment

1. AssignThe analyst assigns the request to the fulfilment team named in the model. If the model has tasks for several teams, tasks are created in order and each shows its owner and due date.
2. FulfilThe team carries out the tasks as in the request model, using approved tools and not shortcuts. Access is granted by the identity team only; no requester or approver grants access.
3. VerifyThe team tests that the outcome works for the requester, or for the beneficiary, and records what was checked.
4. Update recordsWhere an asset, licence, configuration item or access right changes, the team updates the record in the same task. The configuration manager samples [10%] of fulfilled requests monthly.
5. Hand backThe team marks the task done with evidence and the analyst contacts the requester.

7.6 Targets

Each catalogue entry has a target in working hours or days, counted from the last approval to completion. The standard bands below apply where a service level agreement does not say otherwise.

A request at risk of missing its target is escalated to the process manager when [75%] of the target has elapsed. If a request cannot be done, the requester is told why and given a new date.

7.7 Closure and satisfaction

1. ConfirmThe analyst asks the requester to confirm that the request is complete. If there is no reply within [3 business days] after two reminders, the request is closed.
2. CheckBefore closing, the analyst checks that approvals, task evidence and updated records are present.
3. SurveyA short satisfaction survey is sent on closure. Scores below [3 out of 5] are followed up by the process manager within [2 business days].
4. ReopenA request may be reopened within [7 days] if the outcome does not work. A reopened request counts against first-time fulfilment.

7.8 Process flow

1. Requester submits a request from the request catalogue or contacts the service desk.
2. Analyst confirms it is a request, validates it, and logs it with the request number and target.
3. System sends approvals to the named approvers in order; fulfilment waits for every required approval.
4. Analyst assigns tasks to the fulfilment teams according to the request model.
5. Teams fulfil, verify, update records and mark tasks complete with evidence.
6. Analyst confirms with the requester and closes the request after confirmation or the waiting period.
7. Satisfaction survey is sent and the results enter the monthly report.
8. Process manager reviews performance and the catalogue owner updates the request models each quarter.

8. Interfaces with Other Processes

9. Key Performance Indicators

10. Records and Evidence

Annexure A: Service request form

Annexure B: Request catalogue entry

Annexure C: Request register

Annexure: Document history

11. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

12. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

13. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 20000-1:2018 references

Related documents

• Service Catalogue Management Procedure
• Service Incident Management Procedure
• Change Management Procedure
• User Access Management Procedure
• Service Level Management Procedure
• Configuration and Asset Management Procedure
• Service Operating Model
• Communication Procedure