Policy Series - 3.: Request Fulfillment Policy

INTRODUCTION:

This policy document is aligned to ISO/IEC 20000 and ITIL V3 best practices.

As per this policy Service Request is defined as end user requests that an IT organization is required to fulfill.

SCOPE:

This policy is applicable to the entire Request Fulfillment life cycle as described in Request Fulfillment process document. The scope encompasses entire ICT infrastructure of the organization. 

This policy is applicable to all permanent, temporary and contract staff.

POLICY:

• A standard Request Fulfillment process will be defined and adopted by the entire organization
• Staff should be trained to ensure that a common understanding on service request and request fulfillment prevails across the entire organization
• Roles and responsibilities shall be defined and communicated for effective Request Fulfillment
• Service desk should be the Single Point of Contact for the users; Ownership of service requests will rest with the Service Desk
• Single Request Fulfillment tool shall be used across the organization; All service requests should be recorded using this tool including:
• Call to service desk
• e-Mails to service desk
• Service desk should ensure the correct logging of service requests (incident tickets should not be logged as an service request)
• Service desk should correctly categorize all service requests
• Priority should be assigned to every service request based on the impact and urgency (Impact - urgency matrix and critical services list should be referred to)
• All service requests shall be provisioned/fulfilled only after required approvals are obtained
• All service requests that has impact on any CI should be fulfilled/provisioned post change approval; Change Management process should be followed at all times in such cases; Tagging of ticket to CI shall be done in all such cases
• Requests not auto-assigned by the tool has to be routed by the Service Desk to relevant support group
• In case the service request is assigned to a support group and not assigned to the individual support engineer, the accountability for ticket assignment lies with both the team/shift lead of that support group as well as with support engineers
• Progress of all service requests should be monitored by service desk and record updated on the progress till resolution and closure
• User should be updated regarding the progress of the service request as per the communication matrix agreed upon till closure of the ticket
• Escalation matrix should be clearly defined and followed
• All SLAs for Request Fulfillment including the ones related to service desk (average wait time, average hold time, etc.) as agreed with the customer should be adhered to
• Customer should be informed of any breach or potential breach of service levels
• Priority of service requests should be upgraded or downgraded only post approval from the concerned approval authority
• Request Fulfillment process performance shall be reported and reviewed periodically
• Continual Service Improvement initiatives should be taken up by Request Fulfillment

ACCOUNTABILITY & RESPONSIBILITY TOWARDS POLICY ADHERENCE

• Team Leads and delivery heads are responsible to ensure that their staffs are adequately trained to support this policy
• Request Fulfillment Managers, Service Desk Leads and Quality leads are responsible to drive adherence to the policy and process
• Accountability to adherence to policy and process lies with individual staff

BREACH:

Non-adherence to this policy will lead to disciplinary actions as per the organization's disciplinary policy and may even lead to termination of employment.

REFERENCES

Following documents should be referred to along with this policy document:

• Request Fulfillment process document
• Change Management policy
• Service Level Management policy

KPI: Request Fulfillment

KPI Definition	Unit of Measure	Reporting Frequency	Remarks
Number of service requests	Count	Weekly / Monthly	This KPI will be useful in reporting the load of service request that will be handled in any given week / month.  This can also be reported with further classification based on application, priority, user, etc.
Number of service request by Status	Count	Weekly / Monthly / Quarterly	This KPI will be useful in reporting service request volume based on status (Assigned, In progress, Pending, Resolved, Closed and Cancelled) priority wise.
Number of service request by Operational Categorization	Count	Monthly / Quarterly	This KPI will be useful in reporting service request volume based on operational categorization (Application, Access, Desktop or Laptop, Application access, Network, Failure, Server or Server Components, Request, Hardwar, etc.) priority wise.
Percentage service request handled within agreed response time	Percentage	Weekly / Monthly	This will be useful in reporting the response time for all service requests based on priority.
Percentage service request that breached agreed response time	Percentage	Weekly / Monthly	This will be useful in reporting the tickets that have breached the response time SLA for all service request based on priority.
Average response time	Minutes	Weekly / Monthly	This will be useful in reporting the average response time based on priority.
Percentage service request fulfilled  within agreed resolution time	Percentage	Weekly / Monthly	This will be useful in reporting the fulfillment time for all service request based on priority.
Percentage service request that breached agreed resolution time	Percentage	Weekly / Monthly	This will be useful in reporting the tickets that have breached the resolution time SLA for all service request based on priority.
Number of service requests that were wrongly	Count	Weekly / Monthly	This KPI is useful in reporting ticket hops, i.e., wrongly assigned tickets.
Percentage of service request reopened by user	Percentage	Weekly / Monthly / Quarterly	This KPI highlights the percentage of service request re-opened (along with number of tickets re-opened and total number of tickets for the mentioned period).
Backlog of unresolved service request	Days	Weekly / Monthly	This KPI highlights unresolved service request by aging for assigned resolver group typically highlighted as pending for number of days 0-3 days, 5-10 days, 10-20 days and so on; Also used to focus the top 10 pending tickets
Customer Satisfaction Survey (CSAT) of service request	Number	Daily / Weekly	This KPI provides average qualitative assessment of the end-user experience and feedback on fulfillment of service request
Percentage of incidents wrongly logged as service request	Percentage	Monthly	This KPI determines the effectiveness of service desk personnel in correctly identifying service request. Ideally this should be 0.

Request Fulfillment Ticket – Should It Be Reopened Or Incident Ticket Raised?

In my various interactions with my customers and fellow professionals, I have come across many queries where people ask me “If Request Fulfillment Ticket is not correctly fulfilled, should one reopen the ticket or raise another request fulfillment or Incident ticket?”

Service request is a request for any service or standard change. Some examples are password reset, software installation, hardware request, access/authorization requests, location movement, etc.

Let us consider some examples when service requests are inadequately or unsatisfactorily provisioned:

• Reset password does not work
• Software installation was not proper or wrong version was installed
• Hardware provided was faulty or of different configuration
• Others

Let us first understand the Ticket Closure part of Request Fulfillment process. After the ticket has been fulfilled or provisioned, the resolver group has to seek confirmation from the user before one can assign ‘Resolved’ status to the ticket. This is one of the instances where user can ask for a proper or satisfactory resolution.

In cases where due to whatever reason (e.g. 3-Contact Process), ticket has been assigned ‘Resolved’ status, user can reopen the ticket citing reasons for the same. Reopening of the ticket can happen ‘n’ number of times.

What happens when ticket is reopened?

When a ticket is reopened, the SLA clock starts ticking again. Please note that the SLA clock does not restart. Thus, the chances of SLA breach for the resolver group increases. Also, ticket is escalated after n^th time it is reopened (‘n’ depends on the process defined in an organization,).

How does ticket reopen affect the KPIs?

When a ticket is reopened, two major KPIs that would be impacted are:

• %age and number of tickets reopened (measurement of how effectively the resolver groups are able to fulfill or provision service requests)
• %age and number of tickets that breach the SLA (another measurement of effectiveness of resolver groups)

Analysis of these two KPIs and the factors that drive up the number/percentage would lead to SIPs related to ‘People’ or the ‘Process’ itself depending on the analyzed root cause.

Why not create an Incident Ticket?

Incident is defined as an unplanned interruption to IT service or degradation of the quality of IT service (or a CI).

When any request is incorrectly provisioned, it is not an instance of service disruption. The particular user does not have access to that service itself and thus needs the access to the same. This is a service request and not an incident.

Please note that when any process is defined, as part of the process definition itself measures have to be put in place to monitor and measure process performance besides the aspects that would drive continual improvement of the process.