An Effecient Self-Regulating Escalation Model

Many IT support organizations follow a tiered support system, whereby new issues start at Tier 1 and are escalated to higher levels as needed. I have had some brilliant conversations about effective escalation models and procedures for IT support managers to implement, and I thought it would be a good idea to record some of my ideas here. We’ll just talk about escalation from Tier 1 to Tier 2, but similar patterns apply for higher level escalations.

First, a quick diagram of the tiered support model:

escalation model

If we consider the hypothetical scenario where all tickets are automatically escalated up, nothing would be resolved. This is true because higher tiers are usually filled with fewer (albeit more trained) people, meaning there are significantly less human hours available. Conversely, in a scenario where no tickets are escalated would result in complicated and urgent issues never being resolved satisfactorily. It is obvious that the best model lies somewhere between these two extremes, where escalations are minimized to only what is necessary so as to minimize cost without sacrificing support and service.

Considering these two worlds, we can summarize some of the pros and cons of escalating a ticket.

Benefits of a Ticket Escalation

  • The individual ticket may be resolved faster
  • The resolution may be more in line with best practices
  • The resolution may be more reliable
  • An otherwise stagnated ticket may get resolved
  • A difficult interpersonal situation may be better addressed
  • Employees at higher tiers may have contacts in other departments or organizations that may help

Drawbacks of a Ticket Escalation

  • The escalator may not learn the details of the resolution, and may instead learn to escalate similar tickets in the future.
  • The higher tier may be forced to delay more urgent tickets to address the new ticket
  • Frequent escalations may not look the best if one is working for a promotion into the next tier
  • As more tickets are escalated, the need for a lower tier diminishes
  • If a client sees a low tier usually escalates tickets anyway, they may begin skipping the lower tier in the first place
  • The average ticket resolution cost at higher tiers is usually higher

One of the methods I have found to be helpful in minimizing escalations from Tier 1 to Tier 2 is the implementation of a secure knowledge base that can be updated by all members of every support tier. If a Tier 1 Technician encounters a ticket they otherwise couldn’t resolve, they have a knowledge base to go. If the issue can’t be resolved after exploring the knowledge base, it is then usually escalated up to Tier 2.

There is an added level of benefit based on this policy. Tier 2 technicians have a natural tendency to avoid repetitive tickets. When a Tier 2 Technician starts seeing tickets with similar issues and resolutions, they habitually tend to take it upon themselves to add resolution steps to the knowledge base so as to minimize future such ticket escalations. This keeps the knowledge base growing and up to date, and maximizes ticket resolutions at Tier 1 so as to keep costs down. Carefully implemented, this model allows maximally efficient ticket escalation with minimal supervisory overhead.