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.

1. Guidelines to update a ticket
By
Prasad Deshpande
6 June 2013

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. Questions
 Why to update ticket?
 What can be updated?
 How can we update?
 Who can update?

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. 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. 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. 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.  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. 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. 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. Thank You!