Incident Management Best Practice

[Juan Osorio]

Sharing some Incident Management Best Practices...

Resolution

• The team\group that resolved the incident owns resolution. Regardless of if they do not directly manage the technology or service. If you fixed it you own it. Resolution is not about blame.
• Resolution notes should include all steps leading to the resolution (summary of what was done). No single word resolutions like “Fixed” or “Resolved” that is not good enough for problem Mgmt to investigate if they need to , nor does is suffice for audit requirements (depending on your company)

Priority

• The priority is to be kept at what it was at its worst point in time.
• You do not lower the priority because its now “resolved”.
  • Lowering the priority is a disservice to the end user and skews reporting.
  • You do not seek permission to lower the priority from the user reporting the incident.
  • You only lower if it was incorrect to begin with or the impact\urgency was found to be less during triage. (Needs good justification)

SLA’s

• Tickets that have been passed around multiple teams but with the same vendor should calculate the sum of all the time spent in the vendors hands. Regardless of how many groups the ticket went through. 
• If an SLA pauses because run conditions are not met, then start again the SLA must account for time passed for the durations of time it spent with the same company\group\vendor the very SLAs are measured against. Mishandling of ticket where it leaves the resolution team then comeback is not a justified reason to restart the SLA.
• SLAs are an agreement between two entities not internal teams.

E.g.

SLA	15 hrs.
Entity	A	B	A
Time passed	10 hrs.	4 hrs.	1 hr.
SLA Percentage	66.66%	93.33%	100.66%
Activity	Ticket held then reassigned	Ticket held then reassigned	Ticket reassigned then resolved

SLA violations

• Includes pausing an SLA longer than the allotted SLA time.
• Pausing the SLA for unjustified reasons or violations of the SLA duration.
• Violation retroactive rules or pausing for the duration of the ticket until the end
• Do not keep ticket on hold\pending up until you need to mark the ticket as resolved. This pauses SLAs and skirts the system to work around breaching SLAs.
• The only reason to truly place a ticket on hold\pending is if work can not continue and all other options have been exhausted and you are dependent on the end user to move forward.
  • Unjustified hold\pending reasons
    • Waiting on internal team (Should be baked into your SLA time)
    • Pending vendor (Should be baked into your SLA time)
    • Pending shipping (Should be baked into your SLA time)
    • Pending change

Ticket Reassignment (Group hop counts)

• 3 or more reassignments should be considered a “mishandled” ticket.
  • 1 reassignment is ok
  • 2 is fine if it was misrouted the first time
  • 3 means teams are playing ping pong or the ticket is lost and need to be followed up on

[NDizzy]

Some very good reminders! I have shared this with my itil users!

[Vivek Kumar1]

Perfectly described thanks

[Juan Osorio]

#Update - #Duplicate Tickets

There is no such thing as a duplicate ticket, only more occurrences (child tickets). You don't cancel a ticket because someone else reported the same thing. You don't cancel a ticket because a problem was open before it was resolved. You only truly cancel a "duplicate" if the same thing was reported by the same person more than once the same day. Otherwise, they should have time to re-open the incident if it was not fixed and their ticket was resolved but not closed yet.   

[c8h9js]

This is straight to the point - great suggestion!