ITSM- Process-Guidelines to update a ticket

739 views

Published on

It is created when we are initially started to implement ITIL Incident Management Process. To allow a support engineer to maintain ticket record and work done on incident.

Published in: Business, Technology
  • Be the first to like this

ITSM- Process-Guidelines to update a ticket

  1. 1. Guidelines to update a ticket By Prasad Deshpande 6 June 2013
  2. 2. Background  Ticket record is a formal document of incident for customer as well as service provider  Ticket record maintenance is nothing but book keeping task.  This task is made easy using smart ticketing tools.
  3. 3. Questions  Why to update ticket?  What can be updated?  How can we update?  Who can update?
  4. 4. Purpose  Whatever work has done on the incident and ticket, is documented.  It can be provided as evidence to customer and Internal/external auditing.  Easy handover of work history to next assigned group/ individual.
  5. 5. What we can include (in work info, not compulsory)  Related to incident  Asset details  CMDB  Incident, Change, Problem, SR relations  Email communication with  User  Business  Support group  Interfacing processes  Related incidents  Essentials to proceedings  Approvals  MOMs(action points, suggestion, decisions)  Discussion history(verbal approvals, suggestions, who was involved)  Activity progress details(like backlogs, lag on DB server etc)  User input requirement form  Event confirmation email from user, support groups  Escalation history
  6. 6. Forms of work info  Tool provided input method(text pad entry)- in this we can write anything  Integrated relations Ticket(Change, Problem, SR) CMDB Component Asset Management  Attachments- File attachment (.doc,.xls,.txt,.pdf) Email attachment(Outook email, emails sent by support personal via ticketing tool) Video/Audio file of VC or Bridge call(if any) Chat history file(if any)
  7. 7. Guidelines  Does: Update should be related to incident and ticket only Must include activity approvals User input/communication details Every activity and update date and times Troubleshooting history Management decisions and customer approval Updates should be in agreed templates/formats Event history Action points Teams involved Ticket relations Last updated by <<Name>> Avoid unnecessary information
  8. 8.  Don’t : Don’t include internal strategies Don’t include disagreements Don’t include personal opinions Don’t include future ideas Don’t write detailed discussions, only highlights, keynotes.
  9. 9. Closure Statements  Must include how incident resolved/impact is reduced  What final actions taken to resolve/ workaround provided  Reason for outage(short and user understandable, if not possible- under investigation)
  10. 10. Conclusion  It is a best practice to preserve and provide evidence of work  Individual performance can be measured on this ground  Must update work info for accountability and problem investigation.  Achieve customer satisfaction
  11. 11. Thank You!

×