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.
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