{"id":458,"date":"2014-04-04T13:06:12","date_gmt":"2014-04-04T20:06:12","guid":{"rendered":"http:\/\/itiltopia.com\/?p=458"},"modified":"2020-06-02T08:06:37","modified_gmt":"2020-06-02T15:06:37","slug":"tyranny-of-tiers","status":"publish","type":"post","link":"http:\/\/itiltopia.com\/?p=458","title":{"rendered":"The Tyranny of Tiers"},"content":{"rendered":"

\"ITIL<\/a>
\nLet 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\u2019s. The second is a business\/cost perspective and how IT models itself on this practice. The last perspective is mine.<\/p>\n

ITIL\u2019s Perspective<\/b>
\nITIL 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.<\/p>\n

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.<\/p>\n

ITIL v3 2011 has dropped all mention of \u201cline of support\u201d 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.<\/p>\n

The Business Perspective<\/b>
\nLet 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\u2019m speaking to regarding the technology in question.<\/p>\n

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?<\/p>\n

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

Example:<\/p>\n

The cost of an issue that can be resolved at Tier 1 = $50
\nThe cost of an issue that can be resolved at Tier 2 = $100
\nThe cost of an issue that can be resolved at Tier 3 = $200
\nThe cost of an issue that can be resolved at Tier 4 = $400<\/p>\n

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.<\/p>\n

IT\u2019s Perspective<\/b>
\nMost 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.<\/p>\n

My Perspective<\/b>
\nHere is where I am going to climb on a soapbox. I don\u2019t care which internal group the Service Desk transfers the request to, they are all Tier 2.<\/p>\n

In my book, I define IT Tiers this way:<\/p>\n

Tier 1 = Service Desk
\nTier 2 = Any other internal IT support group
\nTier 3 = External vendor\u2019s support<\/p>\n

The reason I define it like this is twofold:<\/p>\n