Let me start this post with the fact that I am going to be discussing three different perspectives on the concept of Tiers as it applies to issue escalation. The first perspective is ITIL’s. The second is a business/cost perspective and how IT models itself on this practice. The last perspective is mine.

ITIL’s Perspective
ITIL v2 had a paragraph (and a pretty graphic ->) explaining the concept of functional escalation to various internal and external support groups. It showed escalation from the First-line Support, to Second-line Support, to Third-line Support, to Nth-line Support. The concept here is that tickets are escalated between various functional groups within IT or externally until the issue comes to resolution.

ITIL v2 only had one definition for the various levels of support. The First-level Support group is the Service Desk. Other than that, everything else was open for interpretation.

ITIL v3 2011 has dropped all mention of “line of support” and Tiers from the functional escalation section of the Incident Management process. I guess the whole subject of Tiers got too controversial for them to handle.

The Business Perspective
Let me begin by asking you a question. Have you ever had an issue with a piece of technology used in your home (cable modem, WiFi router, coffee maker) and called for technical support? I have, and coming from a technical background, I have always found the process painful. It is very typical to reach a support person who is obviously reading a script of potential solutions (applicable or not) to repair the device. I quite often find myself schooling the person I’m speaking to regarding the technology in question.

This is common for savvy users when they reach First-line Support. We, of course, want our issue to instantly be escalated to the most knowledgeable support representatives. So why do we have to wade through this pool of incompetence?

It is because just about every organization uses a Tiered Support structure.  The business justification behind Tiers is that the cost to resolve an issue doubles at each level of escalation up the Tier chain.

Example:

The cost of an issue that can be resolved at Tier 1 = $50
The cost of an issue that can be resolved at Tier 2 = $100
The cost of an issue that can be resolved at Tier 3 = $200
The cost of an issue that can be resolved at Tier 4 = $400

Yes, I want my calls to be instantly escalated to Tier 2 (or maybe even to Tier 3!), but the company wants my issue resolved at Tier 1, so I must break through that Tier 1 barrier before I can talk to the true experts.

IT’s Perspective
Most internal IT support structures follow this model. Hopefully we have put in place the tools and resources to allow the Service Desk (Tier 1 according to ITIL v2) to resolve 70%-80% of all requests. The remaining 20%-30% of issues will have to be escalated to a different Tier.

My Perspective
Here is where I am going to climb on a soapbox. I don’t care which internal group the Service Desk transfers the request to, they are all Tier 2.

In my book, I define IT Tiers this way:

Tier 1 = Service Desk
Tier 2 = Any other internal IT support group
Tier 3 = External vendor’s support

The reason I define it like this is twofold:

• I am trying to align my Tiers to the business perspective of cost reduction
• I am trying to set a specific tone in IT

The cost to resolve an issue at the Service Desk vs. the cost to engage any other IT specialist group (like the Server Team) is dramatically different. Maybe not double, but quite a bit more.

Any time I have to engage vendor support, it is ridiculously expensive. Not only am I using man-hours of one (or more) of my IT specialist’s time, I am probably paying a premium for the vendor’s support.

Interestingly, the cost to resolve an issue at the various IT specialist groups (like the DBA group, Server group, Network group, etc.) isn’t that significantly different. Yes, the Systems Engineers may be a bit more expensive than the Systems Analysts, but it’s nothing compared to the cost difference to resolve an Incident at the Service Desk vs. escalating the issue to any other team.

But the main reason I don’t ever use the term Tier 3 for internal support groups is because of human nature. Let’s face it, people who are titled Tier 3 will always (if secretly) feel superior to employees identified as Tier 2 and Tier 1. This sets a specific tone in IT that I want to avoid at all costs. What’s more, the perceived elevation of self-importance with increased Tier level isn’t true. The various IT specialist groups are just that, employees who have decided to take their careers into a specific area of IT specialization. Is the Network team superior to the Server team? No. Are the DBAs superior to Desktop team? No. Are the App/Dev teams better than the Email team? No.

Since ITIL defines Tier 1 as Service Desk, and since there is a significant cost difference between issues resolved at the Service Desk and issues resolved at other IT specialist groups’ levels, we should accept this label. All the other internal IT groups should be on an equal playing field of Tier 2, with Tier 3 reserved for the times we have to involve our external vendors.

The benefits of this model are:

• I can quickly metric items like first call resolve %, vendor engagement, and ballpark resolution cost based on the resolution Tier
• There won’t be perceived superiority/inferiority complexes between the internal IT staff

It’s a win-win solution.