Ticket Handling

This article outlines the expectations for the ITaP Customer Service Center on handling tickets in BMC FootPrints.  Cases are randomly reviewed each week for accuracy and are given a score indicating the amount of errors.

• ALWAYS make a ticket; One Incident / Service Request per ticket
  • This one should be easy, but no ticket = no work.  We are at a critical time where there is more work than the team can realistically handle.  As such, we need all the data possible to prove our need for additional staffing.  If we are not making tickets, we're not showing the work that is being done.  We absolutely have to make a ticket for every encounter we have in the CSC, be it a phone call, an email, or a customer at the walk-up desk.  And with that, there should only ever be one issue per ticket, meaning if a customer calls in about BoilerKey and then needs help installing a printer as well, that should be TWO tickets.  Another example would be if a customer calls in about BoilerKey but needs their password reset as well, it's still two tickets; two distinct actions for two different service offerings.
• Ticket should be open and timer running while working the issue 
  • Pause timer when not working the ticket
• Customer Information 
  • 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.  Customer Information tab should not be left blank.
  • Tickets that are submitted by a DCL show up as 'DCL_username" in FootPrints. When you see a ticket like this, you need to remove the "DCL_" part in order to populate with a correct username. This way, the customer receives sent messages and can reply to the ticket.
• Category, Service, and Service Offering
  • Follow the ticket classification standards found in KB article #791500
• Urgency and Impact 
  • 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.
• Tech Notes 
  • 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/tier 3 teams.
  • 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.
• 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.
• Notifications 
  • The check box to send a communication to the customer should be checked, as appropriate.
• Ticket Type 
  • Incident is to be used when a customer is experiencing an error, or encountering a problem.  If something was previously working, and now isn’t, or has never worked correctly, Incident should be used.
  • Service Request is to be used any time someone ask how to do something, makes a request for a new account, modification to something, etc.
• Asset Information 
  • Must contain an entry and be accurate to the machine that work is being performed on.
• Reassignments 
  • 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.