Incidents

An Incident is any technical event which disrupts, or which could disrupt, a service, including those reported directly by users, reported and/or logged by technical staff, detected by Event Management, or reported and/or logged by a vendor.  Assume all phone calls start as an Incident until the lack of a technical issue has been identified.

Identification

Incidents may be identified by many sources:  Users, Service Providers, monitoring of key IT services and Service components.  Ideally, incidents should be identified and resolved before they have an impact on users.

Logging

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

• Unique reference number
  • Issue Number
• Date/time recorded
• Submission Method
• 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 work is being performed on.
• Description of symptoms
  • 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 troubleshooting steps the CSC takes, any information confirmed with the customer, exact text of error messages, or instructions or questions to Tier 2 teams.
• Activities undertaken to resolve the incident
  • Tech Notes should capture the resolution of the case for future reference.  Example: If an individual is having a problem with Outlook, and the CSC is able to resolve, the Tech Note should describe in detail the steps taken to fix the problem.  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 issues, each issue 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

Incidents 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 and matching incidents to Problems, Known Errors and validated workarounds.  Incidents are prioritized by assessing impact and urgency.  Priority is used to determine how the incident is managed by staff and support tools.

Fields should reflect current understanding of the issue.  Should be reviewed and updated at resolution to make sure it’s accurate.  These can and should change as the case progresses.

• URGENCY
  Work Stopped - The customer cannot perform their major job function.
  Work Impaired - The customer can perform their major job function, however, there is a severe impact to functionality or performance.
  Working Normally - The customer can perform their major job function without impairment.
  
  IMPACT
  Widespread - 50 or more people. 1 or more major systems. 3 or more minor systems or services. This is (can) trigger the Major Incident Management process.
  Moderate - 10-50 people. No major system. 2 or fewer minor systems.
  Minimal - 0-10 people. No major system. No minor systems. Individual issues.

Diagnosis

The initial ticket owner performs initial diagnosis for any incidents for which the users have contacted them.  This is typically done while the user is still on the phone, and, ideally, the incident can be successfully resolved and closed.  Screenshots and error message should be captured and recorded in the incident record.  If the contact is via email, communication with the customer is required.

Escalation

As soon as it becomes clear that the initial ticket owner is unable to resolve the incident, it must be escalated to the appropriate second-level support team.  For incidents that have been received via a phone call, calls should be warm-transferred to the appropriate second-level support and the ticket then assigned to the corresponding team.  Contact information can be found here.

• 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 incidents may need to be escalated to management, even if just for notification purposes.  Incidents may also be escalated to management if they are taking too long to resolve or if management authorization is needed to resolve the incident.  This step should also include communication with the customer.

Investigation & Diagnosis

Investigation and diagnosis is first done by the initial ticket owner where analysts delve into the incident to determine solutions and next steps.  Investigation and diagnosis may become an iterative process, starting with a different support group and following elimination of a previous possible cause.  It may involve multi-site support groups and support staff from different vendors.  It may continue overnight with a new shift of support staff taking over the next day.  This requires a rigorous, disciplined approach and a comprehensive record of actions taken, with corresponding results.

Resolution & Recovery

After successful execution of the resolution or some circumvention activity (workaround), service recovery actions can be carried out, often by specialist staff (second- or third-level support).  All events and actions during the resolution and recovery activity should be documented in the incident record so that a full history is maintained.

The ticket owner should ensure that:

• Details of the actions taken to resolve the incident are concise and readable
• Classification is complete and accurate according to root cause
• Resolution/action is agreed with the customer – verbally or, preferably, by email or in writing
• All details applicable to this phase of the incident control are recorded, such that:
  • The customer is satisfied
  • The time spent on the incident is recorded
  • The person, date and time of closure are recorded

If the incident was resolved on first contact, document it as such using the drop-down option in the ticket.  For phone calls and chats, first contact resolution is defined as the customer's incident has been resolved prior to disconnecting the call.  If the call is warm transferred to a second-level support team and they are able to resolve the incident, this would still be considered first contact resolution.  Calls or chats that require a customer callback, or cannot be warm transferred, do not qualify for first contact resolution.  For e-mails, the standard is that resolution within the first correspondence with the customer FCR.

Ownership, Monitoring, Tracking, and Communication

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

• Regularly monitoring open incidents for status and progress towards resolution
• Giving priority to monitoring high-impact incidents
• Noting incidents that move between different specialist support groups, as this may be indicative of uncertainty and, possibly, a dispute between support staff.  In excessive cases, incidents may be referred to as Problem Management
• Checking for similar incidents

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.