Request Fulfillment Practice
A Service Request is defined as an End User request for information, for advice, for a Standard Change, or for access to an IT service. Service Requests are usually small, predefined, repeatable, frequent, pre-approved, and procedural requests. These requests may also include small, low-risk standard changes (Request for Change).
The primary goal and objective of Request Fulfillment is to provide a channel for End Users to request and receive standard services for which a pre-defined approval and qualification practice exists. Other objectives are to:
- Provide information to End Users and customers about the availability of services and the supporting procedures to obtain these services.
- Assist with general information, complaints, or comments.
RACI Matrix
A RACI Matrix, also known as Responsibility Assignment Matrix (RAM), clarifies to all involved with a practice which activities each person, group, or team is expected to fulfill. It is also helpful in clarifying the staffing model necessary for operation and improvement.
The RACI model specifies that only one role is accountable for an activity, although several people may be responsible, consulted, and informed for parts of the activity.
The RACI model stands for 4 main practice activity roles as follows:
RACI | Description |
---|---|
A = Accountable | The single owner who is accountable for the final outcome of the activity. |
R = Responsible | The executor(s) of the activity step. |
C = Consulted | The expert(s) providing information for the activity step. |
I = Informed | The stakeholder(s) who must be notified of the activity step. |
RACI Matrix for Request Fulfillment Practice
Practice Roles Described
A Practice Role is defined as a set of responsibilities, activities and authorities granted to a person or team. One person or team may have multiple roles, and may have different roles and responsibilities at different times due to involvement with separate practices one after the other.
Role | Description |
---|---|
Request Owner | The Request Owner is responsible for ensuring that all activities defined within the practice are undertaken and that the practice achieves its goals and objectives. |
Request Manager | The Request Manager is responsible for the Request procedure, for work instruction design, and for the day to day management of the overall procedure. The manager has authority to manage all aspects of Requests fulfilment. |
Request Analyst | The Request Analyst is responsible for designing and implementing the Request Procedure as defined by the Request Manager, and to be a point of contact for escalated issues, questions, or concerns. |
IT Support Staff | IT Support Staff are the individuals, teams, and groups who are assigned responsibility to fulfill Requests. This may include divisions of the Service Desk and/or Third-Party companies. |
Customer | The Customer is the business – a person or department – who is paying for an IT Service to be available for use by their End Users. This role is responsible to report all Service Level complaints and complements to the Customer Relationship Manager role of Service Level Management. |
End User | The End User is the person using an IT resource. This role is responsible to report all Incidents and make all IT requests and contacts through the Service Desk. |
Service Desk Manager | The Service Desk Manager is responsible for the day to day management of the Service Desk function and assisting with all management escalated issues. |
Service Desk Analyst | The Service Desk Analyst is responsible for the day to day communication with all End Users and to facilitate the resolution and fulfillment of Incidents and Requests.· The Service Desk Analyst and the Service Desk function form Level 1 Support. |
Incident Owner | The Incident Owner is responsible for ensuring that all activities defined within the practice are undertaken and that the practice achieves its goals and objectives. |
Incident Manager | The Incident Manager is responsible for practice design and for the day to day management of the practice. The manager has authority to manage Incidents effectively through First, Second, Third Level Support. |
Incident Analyst | The Incident Analyst is responsible for implementing and executing the Incident practice as defined by the Incident Owner/Manager, and to be a point of contact for escalated issues, questions, or concerns. |
Support Level 2/3 | Level 2 Support is responsible to handle Incidents that Level 1 Support could not resolve. These group(s) will have general technical support skills, but with greater skill level than Level 1 Support. These groups are separated from “End User first point of contact” responsibility and typically have longer timescales to perform incident diagnosis and resolution tasks.Level 3 Support is responsible to handle Incidents that require specialized and in-depth technical skills. Escalation to these groups may be direct from Level 1 Support or from Level 2 Support based on the Priority and Complexity of the issue. |
Service Desk | The Service Desk organization and functional role. |
Incident Management | The Incident Management practice role. |
Request Fulfilment | The Request Fulfilment practice role. |
Problem Management | The Problem Management practice role. |
Change Management | The Change Management practice role. |
Service Level Management | The Service Level Management practice role. |
Request Fulfillment Practice RACI Chart Example
Practice Steps Described
Request from Incident Management Practice
All calls to the Service Desk are assumed to be Incidents unless categorized otherwise (as Requests).
1.0 New Request?
- Objective: To avoid duplication of Records and work effort.
- Policy: All Requests will be validated against existing Open Requests for the End User.
- Input(s): End User Description, Request Records
- Output(s): New Request, Update to Existing Request
- Status: None
- Description:
- (A,R) The Service Desk Analyst is Accountable and Responsible for confirming a New Request with the End User and against open Request Records for the same End User.
- (C,I) All End Users are Consulted and Informed of the validation of a new Service Request or update to an existing Service Request..
2.0 Review and Update Request
- Objective: To fully document all Request Records, including repeated contacts with the Service Desk.
- Policy: All Existing Requests will be reviewed and updated with new End User information as well as the time and date of each End User contact.
- Input(s): End User Description, Existing Request Record
- Output(s): Updated Request Record
- Status: No Change
- Description:
- (A,R) The Service Desk Analyst is Accountable and Responsible for updating the Existing Request with new End User information as well as the time and date of each End User contact (even if there is no new information, but the End User is checking on Request status).
- (C,I) All End Users and IT Support Staff are Consulted and Informed of the Service Request update.
3.0 Authenticate End User and Requested Service
- Objective: To provide authorized Request services to End Users.
- Policy: All Requests for IT Service will only be provided to valid employees and only where the IT Service has been approved through the Authorized Request List of the Service Catalog.
- Input(s): New Request, End User Identification, Service Catalog, Authorized Request List, Request Procedure
- Output(s): Authentication of End User and Request
- Status: Open
- Description: The scope of Service Request issues that are handled include requests for IT Services identified in the Service Catalog, and include questions, advice, comments and complaints. Request issues may also include Facilities issues.
- (A,R) The Service Desk Analyst is Accountable and Responsible for:
- Validating the End User as a valid employee.
- Validating the Service Request against the Authorized Request List.
- Following the appropriate Request Procedure.
- Recording Service Request details.
- (C,I) All End Users are Consulted for Request details and Informed of next steps.
- (A,R) The Service Desk Analyst is Accountable and Responsible for:
4.0 Request out of Scope?
- Objective: To identify and manage undocumented Request.
- Policy: All Requests that are NOT approved through the Authorized Request List of the Service Catalog will NOT be fulfilled.
- Input(s): Authentication of End User and Request
- Output(s): Acceptance of Request, Rejection of Request
- Status: None
- Description
- (A,R) The Service Desk Analyst is Accountable and Responsible for denying all requests where either the End User or the Requested Service is not Authenticated against the Authorized Request List of the Service Catalog.
- (R) The Service Desk Analyst is Responsible to inform all End Users where the request is out of scope.
- The Analyst is Responsible to create a Request record in all cases of in scope or out of scope Requests.
- (I) All End Users are Informed of authentication and next steps.
5.0 Hierarchic Escalation?
- Objective: To manage End User Request escalations requiring management involvement.
- Policy: All Requests where the situation or the End User requires management involvement will be managed at the Service Desk.
- Input(s): End User Demand for Escalation, Situation Assessment by Service Desk Analyst
- Output(s): Hierarchic Escalation
- Status: Open, Escalated
- Description:
- (A,R) The Service Desk Analyst is Accountable and Responsible for escalating End User demands or situational requirements for non-standard Service Requests.
- (R,I) The Service Desk Manager is Informed of and is Responsible for managing Service Desk Analyst escalated End User demands or situational escalations.
- (I) All End Users are Informed of next steps.
6.0 Management Escalation
- Objective: To manage Request and End User escalations requiring management involvement.
- Policy: All escalated Requests will be assessed and managed in a timely manner.
- Input(s): Situation Assessment by Service Desk Manager
- Output(s): Management Escalation
- Status: Open, Escalated
- Description:
- (A,R) The Service Desk Manager or (delegate Service Desk Analyst) is Accountable and Responsible for managing the Request, further escalating to the Request Manager if necessary, and for ensuring there is a response to the escalation.
- (R,C,I) The Request Manager is Responsible, Consulted, and Informed when assisting the Service Desk Manager with escalated Request issues that require further escalation.
- (R,C,I) The Service Desk Analyst is Responsible, Consulted, and Informed of decisions and next steps, for consulting for End User details, and providing information to End Users.
- (I) All End Users are Informed of next steps.
7.0 New Service Request?
- Objective: To manage Request and End User escalations that may require a new Request Service to be added to the Service Catalog.
- Policy: Escalated Requests to management where the Request has not been previously recognized will be assessed for inclusion as a standard Authorized Request of the Service Catalog.
- Input(s): Situation Assessment by Request Manager
- Output(s): Service Level Management initiation
- Status: Open, Escalated
- Description:
- (A,R,I) The Request Manager is Accountable, Responsible and Informed for assessing non-standard Requests for inclusion as a standard Authorized Request List of the Service Catalog.
- This assessment is collaborative and triggers the Service Level Management practice.
- This assessment should NOT delay managing the current Request escalation.
- (C,I) The Service Desk Manager will be Consulted and Informed of next steps and decisions made.
- (R,I) The Service Level Management practice may be Informed and Responsible where new Requests may be assessed for addition to the Authorized Request List of the Service Catalog.
- (A,R,I) The Request Manager is Accountable, Responsible and Informed for assessing non-standard Requests for inclusion as a standard Authorized Request List of the Service Catalog.
8.0 Escalation Denied?
- Objective: To manage Request and End User escalations.
- Policy: Decisions for Escalated Requests will be documented and communicated to End Users.
- Input(s): Management Decisions
- Output(s): Denial of Escalation, Acceptance of Escalation
- Status: Open, Escalated
- Description:
- (A,R) The Service Desk Manager is Accountable and Responsible for managing escalated Request issues.
- (C) The Request Manager is Consulted for decisions made through Management Escalation.
- (R,I) The Service Desk Analyst is Informed and Responsible to communicate management decisions with the End User.
- (I) The End User is Informed of escalation decisions and next steps.
9.0 Request Categorization and Prioritization
- Objective: To categorize Requests for assignment to the appropriate fulfillment team(s), for later reporting, and for priority scheduling and handling purposes.
- Policy: All Service Requests are Categorized and Prioritized using appropriate Categorization and Prioritization models.
- Input(s): Categorization Model, Prioritization Model, Request Procedure
- Output(s): Categorized and Prioritized Request
- Status: Open, Assessed
- Description:
- (A,R) The Service Desk Analyst is Accountable and Responsible for Categorizing and Prioritizing the Request.
- The Service Desk Analyst will review the Request procedure to determine the pre-assigned Category and Impact, and will determine the Urgency with the End User.
- (I) The End User is Informed and Consulted at all stages of documenting the Record.
- (A,R) The Service Desk Analyst is Accountable and Responsible for Categorizing and Prioritizing the Request.
10.0 Functional Escalation
- Objective: To assign Service Requests to the appropriate fulfillment team(s).
- Policy: All Service Requests are assigned to the appropriate fulfillment team(s) as indicated by the SLA and supporting OLA/UC.
- Input(s): Categorized and Prioritized Request, Request Procedure, SLA and supporting OLA/UC
- Output(s): Assigned Request
- Status: Open, Assigned
- Description:
- (A,R) The Service Desk Analyst is Accountable and Responsible for assigning the Request to the appropriate fulfillment team(s) as indicated in the SLA and supporting OLA/UC.
- (C,I) IT Support Staff assigned to fulfill the Request are Consulted and Informed by the Service Desk Analyst.
- (I) The End User is Informed at all stages of documenting the Record.
11.0 Follow Work Instructions
- Objective: To deliver Requests with consistency and efficiency.
- Policy: All Service Requests are fulfilled by following pre-defined work instructions as part of the Request Procedure.
- Input(s): Request Procedure, SLA and supporting OLA/UC
- Output(s): Assigned Request
- Status: Open, In Progress
- Description:
- (A) The Service Desk Analyst is Accountable to ensure that the Request is being processed as assigned.
- (R,C,I) IT Support Staff assigned the Request are Responsible for and Consulted about the Request fulfillment progress and delivery, and are Informed by the Service Desk Analyst of any new information.
- (I) The End User is Informed as needed.
12.0 Notify End User of Fulfillment
- Objective: To deliver Requests with consistency and efficiency.
- Policy: All Service Requests are fulfilled by following pre-defined work instructions as part of the Request Procedure.
- Input(s): Request Procedure, SLA and supporting OLA/UC
- Output(s): Assigned Request
- Status: Fulfilled
- Description:
- (A,R) The Service Desk Analyst is Accountable and Responsible to contact the End User once the Request has been fulfilled, and to ensure that there are no issues, concerns or complaints from the End User.
- (C,I) IT Support Staff assigned the Request are Informed and Consulted by the Service Desk Analyst regarding any final issues.
- (C,I) The End User is Informed of the Request fulfillment and Consulted for issues, concerns or complaints.
13.0 Request Closure
- Objective: To close the Request Record.
- Policy: All Request Records are closed following the Request Fulfillment practice.
- Input(s): Request Record
- Output(s): Closed Request Record
- Status: Closed
- Description:
- (A,R) The Service Desk Analyst is Accountable and Responsible to end the Request and close the Request record with complete documentation.
- (C,I) IT Support Staff who fulfilled the Request are Consulted for all final information, documentation, and advice; and are Informed of the close of the Request.
14.0 Request Ownership, Monitoring, Tracking, and Communication
The Service Desk shall own all non-Major Incident Records from open to closed status, and acts as a Single Point of Communication (SPOC) to all End User / IT staff of IT, and to ensure that the Service Desk acts as a Single Point of Coordination (SPOC) to all IT escalations during the Incident practice.
- Objective: To ensure that there is a single source of information for all Incidents; that this information is of the highest quality and integrity; and that the Service Desk is the owner of all Request Records.
- Policy: The Service Desk shall own all Request Records from open to closed status, and acts as a Single Point of Communication (SPOC) to all End User / IT staff, and to ensure that the Service Desk acts as a Single Point of Coordination (SPOC) to all IT escalations during the Request practice.
- Input(s):
- Request Records
- Status: Updates
- Incident Documentation
- Output(s):
- Communication
- Updated Request Records
- Status: NA
- Description:
- (A,R) The Service Desk will be Accountable and Responsible for creating, updating, and documenting the Request Record as the definitive source of all information and status; and also for all communications with the End User.
- (R,C,I) All roles involved with a Request Record are Responsible to provide complete and accurate updates and information to the Service Desk, to be Consulted at any time for information related to the Request Record, and to be Informed of all status changes and information changes related to the Request Record.
- (I) All Practices are Informed and provided with data and information to support operational reporting.
Terms & Definitions
- Escalation
- An activity that obtains additional resources when needed. It is most commonly associated with Incident Management or Problem Management. There are two escalation types: Functional and Hierarchical.
- Facilities
- The physical environment where corporate staff work.
- Functional Escalation
- Transferring an Incident, Problem or Change to a technical team with a higher level of expertise to assist in an escalation.
- Hierarchical Escalation
- Informing or involving more senior levels of management to assist in an escalation.
- Impact
- A measure of the effect of an Incident, Problem or Change on business processes. Impact is often based on how service levels will be affected. Impact and urgency are used to assign priority.
- Incident
- An unplanned interruption to an IT service, or a reduction in the quality of an IT service, or a failure of a CI that has not yet impacted a service (for example, failure of one disk from a mirror set).
- Level 1 Support
- The first level in a hierarchy of Support Groups involved in the resolution of Incidents and Requests. Each level contains more specialist skills or has more time or other resources.
- Level 2 Support
- The Second Level in a hierarchy of Support Groups involved in the resolution of Incidents and Requests, and investigation of Problems. Each level contains more specialist skills or has more time or other resources.
- Level 3 Support
- The third level in a hierarchy of Support Groups involved in the resolution of Incidents and Requests, and investigation of Problems. Each level contains more specialist skills or has more time or other resources.
- Major Incident
- The highest category of impact for an Incident. A Major Incident results in significant disruption to the business.
- Mean Time To Restore Service (MTRS)
- The average time taken to restore a CI or IT service after a failure. MTRS is measured from when the CI or IT service fails until it is fully restored and delivering its normal functionality.
- Normal Service
- Normal service is defined as Service Operations within the Service Level Agreement as negotiated with the business.
- Operating Level Agreement (OLA)
- An agreement between an IT Service Provider and another part of the same organization. An OLA supports the IT Service Provider’s delivery of IT services to customers. The OLA defines the goods or services to be provided and the responsibilities of both parties.
- Priority
- A category used to identify the relative importance of an Incident, Problem or Change. Priority is based on impact and urgency, and is used to identify required times and sequence for actions to be taken. For example, the SLA may state that Priority 2 Incidents must be resolved within 12 hours.
- Procedures
- Procedures used by IT Staff. Often referred to as Standard Operating Procedures (SOPs).
- Recovery
- Returning a CI or an IT service to a working state. Recovery of an IT service often includes recovering data to a known consistent state. After recovery, further steps may be needed before the IT service can be made available to the End Users (restoration).
- Resolution
- Action taken to repair the root cause of an Incident or Problem, or to implement a workaround. (In ISO/IEC 20000, Resolution Processes is the process group that includes Incident and Problem Management).
- Service Level Agreement (SLA)
- Written agreement between a Service Provider and the customer(s) that documents agreed service levels for a service.
- Service Request
- A request from an End User for information, for advice, for a Standard Change or for access to an IT service. Service Requests are usually handled by a Service Desk and do not require an RFC to be submitted. See Request Fulfillment.
- Support Group
- A group of people with technical skills. Support Groups provide the technical support needed by all of the IT Service Management processes.
- Underpinning Contract (UC)
- A contract between an IT Service Provider and a third-party. The third-party provides goods or services that support delivery of an IT service to a customer. The UC defines targets and responsibilities that are required to meet agreed service target levels in an SLA.
- Urgency
- A measure of how long it will be until an Incident, Problem or change has a significant impact on the business. For example, a high-impact Incident may have low urgency if the impact will not affect the business until the end of the financial year. Impact and urgency are used to assign priority.
Download Request Fulfillment Practice Activity Design Document.