Skip to end of metadata
Go to start of metadata
You are viewing an old version of this content. View the current version.
Compare with Current
View Version History
Version 1
Next »
- One issue per ticket
- If a customer submits a ticket or calls with multiple issues, each issue must be captured in a single ticket with the appropriate information.
- Ticket should be open and timer running while working the issue
- Pause timer when not working the ticket
- Customer Information
- Customer name should be captured along with email address and phone number. Joe Public (jpublic) should only be used if you are unable to resolve a Purdue customer. Customer Information tab should not be left blank.
- Activity, Type, and Sub-type
- Follow Time to Deliver standards
- 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.
- Work Stopped - the customer is unable to work
- Work Impaired - the customer can work, but conditions are not ideal
- Working Normally - the customer is able to work normally
- 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
- Must contain an entry.
- Failure 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, Failure should be used.
- Service Request is to be used for any other issue, and is the majority of tickets we process. Any time someone makes a request for a new account, modification to something, etc., is a Service Request.
- No other type besides Service Request or Failure should be used without consulting management.
- Asset Information
- 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.
Add Comment