Service Requests

A Service Request is a formal request from a user for something to be provided.  For example, a request for information or advice; to reset a password; or to install a workstation for a new user.

Identification

Service Request is used as a generic description for many different types of demands that are placed upon ITaP by users.  Many of these are typically requests for small changes that are low risk, frequently performed, low cost, or may just be a request for information.  

Logging

Always make a ticket!  All relevant information relating to the nature of the Service Request must be logged so that a full historical record is maintained.  At a minimum, the following details are input during initial recording:

• Unique reference number
  • Issue Number
• Date/time recorded
• Submission Method
• Date for completion
  • Schedule Date - The date and time for when we can fulfill the request
  • Customer Requested Date - The date and time for when the customer needs the request fulfilled
• Name and/or group recording the incident
  • Team Assigned
  • Agent Assigned
• Name/department/phone/location of user
  • Contact Information tab - Customer name and alias should be captured along with email address, phone number, and office location, if applicable.  Joe Public (jpublic) should only be used if you are unable to resolve a Purdue customer.  Contact Information tab should not be left blank.
• Asset Information 
  • Must contain an entry and be accurate to the machine that the request relates too, if applicable.
• Description of request
  • The Tech Notes field should capture the technical details of the case which are usually not appropriate for the Customer Notes field.  Tech Notes should be used to record any steps the CSC takes, any information confirmed with the customer, specifics of the request, or instructions or questions to Tier 2 teams.
• Activities undertaken to fulfill the request
  • Tech Notes should capture the resolution of the case for future reference.  Example: If an individual is requesting a password reset, and the CSC is able to fulfill, the Tech Note should describe in detail the steps taken to fulfill the request.  If the customer calls back, any other employee referencing the case should be able to tell exactly what happened.

If a customer submits a ticket or calls with multiple requests, each request must be captured in a single ticket with the appropriate information.  

This step should also include communication with the customer.

• Customer Note 
  • Customer Notes field should only be used for supporter-to-customer communication – not for supporter-to-supporter (internal) communication.  Notes to other support teams and technical details of the case should be captured in Tech Notes.
  • All cases created by the CSC should have an initial Customer Note entry.  If creating a case, and immediately escalating, a simple note indicating the topic of the case and notifying the customer we’ve escalated for review is appropriate.
  • Customer Notes should be free of grammatical and spelling errors, should properly address the customer, and include the CSC standard signature.
  • When sending a KB article to a customer, the instructions should be inserted in the Customer Note, along with a brief introduction and greeting to the customer.

Categorization & Prioritization

Service Requests are categorized so the exact type of contact is recorded; follow the ticket classification standards found in KB article #791500.  This helps later with reporting, trend analysis, etc.  Service requests are always set with a Scheduled priority that has been agreed upon with the customer.  All Service Requests should be fulfilled before the Scheduled Date and Time.

Information Gathering

The initial ticket owner collects information for any Service Request for which the users have contacted them.  This is typically done while the user is still on the phone, and, ideally, the Service Request can be successfully fulfilled and closed.  Specifics related to the request should be captured and recorded in the ticket.  If the contact is via email, communication with the customer is required to confirm details of the request.

A date and time should be agreed upon with the customer for when the request will be fulfilled.  If the request can be fulfilled at the time of first contact, then the following Day should be entered in the Schedule Date field.

Escalation

As soon as it becomes clear that the initial ticket owner is unable to fulfill the request, a ticket must be escalated to the appropriate second-level support team.  

• Escalation to other tiers reflects expectations documented in the KB or internal documents, i.e. it doesn’t appear CSC staff is guessing where the case should go, resulting in a significant number of reassignments.

High impact and/or urgent Service Requests may need to be escalated to management, even if just for notification purposes.  Service Requests may also be escalated to management if they are taking too long to resolve or if management authorization is needed to fulfill the request.  This step should also include communication with the customer.

Request Fulfillment

After successful fulfillment of a request, all events and actions during fulfillment should be documented in the ticket so that a full history is maintained.

The ticket owner should ensure that:

• Details of the actions taken to fulfill the request are concise and readable
• Classification is complete and accurate according to the requested service
• Fulfillment is agreed with the customer – verbally or, preferably, by email or in writing
• All details applicable to this phase of request fulfillment are recorded, such that:
  • The customer is satisfied
  • The time spent on the Service Request is recorded
  • The person, date and time of closure are recorded

Ownership, Monitoring, Tracking, and Communication

The ticket creator, along with Tier 2 and Tier 3 analysts are responsible for:

• Regularly monitoring open Service Requests for status and progress towards fulfillment
• Giving priority to monitoring Schedule Dates 
• Noting Service Requests that move between different support groups, as this may be indicative of uncertainty and, possibly, a dispute between support staff.  In excessive cases, Service Requests may be referred to management

Communications with the customer requires the Send Email To check box on the Assignees and Notifications tab to send a message to the customer and should be checked, as appropriate.

If a ticket is returned to the CSC simply for resolution, or to avoid direct communication with the customer, it should be returned to the ticket owner with the following message in the Tech Notes:

Per the Director of IT Service Management, this ticket is being returned to the owner for follow up with the customer, further escalation, or resolution.  The ticket owner should ensure that details of the actions taken to resolve the issue are concise and readable, classification is complete and accurate according to root cause, and the resolution is agreed upon with the customer.