Tiered Support Explained

The term tiered support refers to the way that a support center is organized, in order to handle incoming support issues in the most effective and efficient way possible. The tiered support structure has been around for more than 30 years and has been applied in internal support centers (help/service desks) as well as externally facing customer support centers (serving customers that buy an organization’s products/services). HDI courses teach on tiered support, and you can find good documentation and guidance on this in the ITIL^® Service Operation manual and training in the ITIL Foundation and Service Operation courses.

It’s important to note that ALL support tiers should abide by and support a common support center vision, mission, and goals and conduct their activities in a coordinated fashion—in line with an agreed set of policies and procedures (SOPs). Note also that the number of tiers, and who the teams report to, can vary depending on the organization, its management style, and its culture. No one scheme need fit every support center; the structure should be tailored to fit and work with your particular organization.

All support tiers should conduct their activities in a coordinated fashion with an agreed set of SOPs.

Why Use a Tiered Support Structure?

The rationale for implementing a tiered structure to the way you organize your teams is based on the notion that it makes sense to “filter” issues coming into your support center, so that the bulk of the issues, which are typically common, repetitive in nature, and simple to solve, are dealt with by automation (Tier 0), or less costly generalist resources (Tier 1), while the minority of issues—which tend to be more complex, difficult to solve, and require more costly expert resources—are filtered and then passed to more specialized functions (Tier 2, or if need be, Tier 3).

When structured properly, with the right level of staffing, automation tools, and support systems, tiered support will result in a significant number of benefits to the support organization:

• Handle and resolve a majority of issues through automated self-service or first-line support, resulting in optimized resolution times
• Minimize overall cost of support by resolving most issues with less costly resources and automation and filtering only the more complex issues to more expensive, less available support resources
• Optimize performance with respect to achieving KPIs (average response time, resolution time, user satisfaction level, average cost per incident/request, etc.)
• Maximize customer and user satisfaction levels through self-service, faster average response, and faster resolution time performance

The Tiered Support Structure

Here is what a typical tiered support structure looks like.

Tier 0: Typically an automated self-service capability. The Tier 0 capability is typically a web self-service portal (although it could be a voice-based system), designed to be extremely easy to use and available round-the-clock. The purpose of such a portal is two-fold:

1. To empower users to serve themselves with answers to the most common questions and solutions.
2. To act as a filter so that these simple issues do not have to be reported to and handled by the Tier 1 support staff.

The goal is to resolve a majority of issues at Tier 0 through the use of self-service automation, along with chat bots that engage a user upon log-in to diagnose and suggest a solution. Tier 0 is the least costly level of support, where a significant percentage of issues (say 10–30%) should be resolved. Examples include FAQs and password reset requests. Those issues that fail to be dealt with here are filtered on to Tier 1, which is typically the first line support team. Special considerations include the following:

• It is vital that a Tier 0 web support portal is well integrated with other supporting systems, such as your ticketing system, knowledge base, monitoring, communication, and reporting systems.
• The self-service system must have a well-designed user interface and be very easy to use.
• New technology, in the form of AI tools and chat bots are further improving the capabilities of Tier 0 in many organizations. For example, a chat bot will pop-up on the self-service portal and invite the user to interact in a diagnostic session. The chat bot acts as a friendly interface between the user and the center’s knowledge base and very often is able to suggest a solution or provide an answer.
• The system must be monitored in terms of its level of usage and effectiveness with appropriate KPIs, along with reporting.

Tier 1: The front-line support team. Typically composed of technical generalists, a Tier 1 team is able to resolve the most common incidents and requests that are not handled by the Tier 0 self-service system. This level 1 team is responsible for resolving a significant percent of issues without escalation to other support groups and is typically measured by KPIs such as First Contact Resolution rate (FCR), percentage of issues resolved at level 1, average response time, and customer satisfaction.

At Tier 1, the costs per issue handled are much higher than Tier 0, but given that the staff is properly trained and equipped with remote access tools and an effective knowledge base, a significant percentage of issues (40–60%) will be resolved here (this is also measured with KPIs such as FCR). This leaves about 30% of the issues still to be dealt with by Tier 2 or 3. Special considerations for this tier include the following:

• Tier 1 is typically your largest team, consisting of generalists who are good at resolving most technical support issues. Optimized staffing and scheduling is essential.
• They should have the strongest communications skills and great troubleshooting and customer service skills.
• Your first line team must be supported by effective remote access tools, a knowledge base that provides information on common solutions and workarounds, and collaboration capabilities with other support groups.
• As with Tier 0, many level 1 teams are now benefiting from new AI tools and chat bots, further improving the level 1 performance capabilities. For example, a chat bot might suggest to the first line support person a better category for classifying the incident, based on previous incidents of that same nature; or, while diagnosing the issue, the chat bot might suggest a solution or an answer that has a high likelihood of fitting the given situation.
• The HDI Support Center Analyst (SCA) course is geared for Tier 1 analysts to become effective in their role.

Tier 2: The back-line support team to intercept and handle any escalations. In most cases Tier 2 is a back-line senior analyst team within the support center; in other cases, it may be a separate support team or teams outside of but supporting the front-line support team. The Tier 2 team is typically staffed with a smaller number of senior support technicians. The goal of this smaller team is to resolve as many of the remaining issues (about 30%) as possible, before they need to be escalated to a Tier 3 specialized technical or applications support group. Key metrics include number and percentage of issues resolved within the support center without escalation to other groups, average resolution time, and user satisfaction.

In the event Tier 2 can’t resolve the issue, they see to it that the issue is categorized properly and passed to the proper Tier 3 support group for in-depth investigation, diagnosis, and resolution. Special considerations for this tier include the following:

• Smaller in size than Tier 1, usually staffed with senior analysts with considerable knowledge and expertise.
• Excellent troubleshooting, communication, and customer service skills.
• Good collaboration with Tier 3 technical and application support specialists.
• The HDI SCA course is a must for this more senior group, but they may also take advantage of the HDI Technical Support Professional (TSP) course.

Tier 3: Typically technical and application support teams. These are the more specialized support groups, typically residing outside the domain of the support center. They are composed of multiple teams, usually organized along the lines of technology and applications: technical teams (for example, the network team, database team, web team, etc.) and application teams (the HR apps team, Financial apps team, Office apps team, etc.). The staff on these teams are composed of very specialized SMEs, technical or application experts in each domain area. These teams usually report to separate IT managers reporting up to a senior manager of infrastructure/applications. Staff are typically involved in a host of other activities in addition to handling escalated incidents/request (infrastructure design projects, new application development projects, etc.). Nevertheless, they are responsible for responding to any escalated incidents/requests, assigning the issue to the appropriate member of the team, and resolving the issue as expediently as possible.

Like the other tiers, Tier 3 must also be monitored and reported in terms of KPI performance. Examples include number of incidents/requests escalated per period, average response time, and average resolution time. Special considerations for this level include the following:

• The Tier 3 teams must use the same ticketing system with which to record and track their work, to ensure all support groups have all “work in progress” visible to them and can coordinate support activities effectively.
• To facilitate coordination of activities, the support center should put in place with these managers an agreed set of policies and procedures (SOP) for how support activities are to be conducted.
• A supporting Operational Level Agreement (OLA) should also be put in place between the support center and the technical and application teams, so that all teams have a common understanding of expectations and work well together.
• It is also essential that escalated issues to these groups be well documented and accurate! Otherwise there is a chance of having the escalation "bounce back" to the support center for proper classification and re-escalation (see my HDI article on Improving Your Ticket Categorization Scheme).
• The HDI Technical Support Professional (TSP) course is appropriate for SMEs in these groups, so they are adept at handling escalated issues in the most effective and quickest way possible.

An Emerging Trend Affecting the Tiered Model: DevOps

Over the past several years the IT industry has seen an emerging best practice known as DevOps, an abbreviation for “development” and “operations.” The DevOps movement is focused on increasing the collaboration between development and operations teams, so that quality may be improved, defects in applications reduced, and performance optimized. To facilitate the achievement of these goals, the DevOps approach seeks to find ways to increase business value by more directly involving development teams in live support operations, while at the same time including operational support teams in early design and development activity.

Collaboration, rather than escalation, is emphasized in DevOps, finding ways to break down barriers between functional teams or silos in organizations. Essentially DevOps seeks to minimize escalation to Tier 3 groups by proactively involving development teams in resolving issues as soon as they become evident in the support center.

Organizations that adopt a DevOps approach seek ways to: 

• Improve overall quality of services and applications, minimizing defects, and optimizing customer and user satisfaction.
• Reduce “handoffs” of work from one group to another, as well as “work in process,” such as incidents/requests that are escalated to Tier 3 groups, waiting for assignment and action to resolve.
• Improve communication and collaboration between Tier 3 groups and Tier 1 and 2 groups in an effort to magnify the capabilities of front-line support.
• Obtain feedback from customers, users, and front-line support, in order to react quickly and optimize quality.
• Proactively involve Tier 3 technical and application groups in monitoring incoming issues, rather than wait for an escalation to be brought to their attention.
• Immediately apply their knowledge and skills to resolve the issue while still in the support center (thereby pre-empting the need for escalation).

The DevOps movement is becoming increasingly popular across IT organizations, and support center managers are looking for ways to integrate DevOps concepts into their support organizations, including the way in which they organize their teams and handle issues and escalations.

Can Tiered Support Be Combined with Intelligent Swarming?

In an effort to address some of the shortcomings of the tiered support model (handoffs, queued work in process, and resultant slower overall resolution times), a new support model, known as swarming or the collaborative support model, has emerged. The Consortium for Service Innovation, which pioneered applying knowledge management in a support center with Knowledge Centered Service (KCS), has done quite a bit of work in leading the development of a new support model, Intelligent Swarming. In its purest form of implementation, this approach results in a support structure in which:

• There are no tiered support groups (swarming is a collaboration-based process).
• There is no escalation of the issue from one group to another.
• The person who first takes the issue owns it through to resolution.
• The issue should be initially routed to the person most able to solve the issue.

It’s easy to see that a swarming model is quite a departure for a tiered support structure. Although many support organizations might like to adopt this approach in an effort to support the DevOps approach being taken by their development organization, how is a support center able to make the radical transition from an existing tiered support structure to swarming? Is there a way to integrate aspects of a swarming model into a traditional support structure? Would that make sense?

The good news is, in many cases, yes! In fact, the latest evidence being shared by HDI Connect members is that both models can be combined into a hybrid tiered-swarming model, with significant performance improvements. In one instance reported by an HDI Connect member, the support center realized the following gains in the first three months of implementing the new hybrid model:

• An improvement in FCR from 60% to 90%
• Mean time to resolution (MTTR) dropped from 4.2 days to 1.2 days

In this tiered/swarming approach, the basic workflow is as follows:

• The same tiered structure can remain is in place, providing the basic framework for handling issues
• Shared policies and procedures are revised to reflect a new set of working priorities: that handoffs, escalations, and work-in-process are to be minimized, first contact ownership is to be preserved, quality and performance maximized, and collaboration an imperative.
• All support groups are to use the same service management (ticketing) system to facilitate communication and collaboration.
• Issues are not escalated outside the support center to Tier 3 groups. Instead, details are posted to a collaboration tool that supports teamwork across all the groups. The front-line analyst retains ownership while the issue is in process of being resolved.
• Tier 3 teams monitor the teamwork system and receive visibility to all new and existing issues. If an issue resides within their domain, they are notified and may “opt in” and assist the front-line analyst with resolving the issue.
• The issue is then resolved from within the domain of the support center, the user is updated with the status, and the solution/workaround is documented in the system.
• A by-product of the resolution is an update to/a submittal to the shared knowledge base, ratified by the Tier 3 team, so that any similar issues in the future may be expedited.
• If the issue has an unknown cause, a report is filed with problem management to investigate the root cause and effect a change to prevent similar incidents in the future.

It is clear then that tiered support and swarming need not be mutually exclusive support models. Indeed, the two may be integrated with impressive results. For more on how tiered support can work with intelligent swarming, please see my two-part series on Evaluating Technical Support Models: Tiered Support vs Swarming.

Paul is the president and principal consultant of Optimal Connections LLC. With more than 30 years of experience in planning and managing technology services, Paul has held numerous positions in both support and management for companies such as Motorola, FileNet, and QAD. He is also experienced in service desk infrastructure development, support center consolidation, deployment of web portals and knowledge management systems, as well as service marketing strategy and activities. Currently Paul delivers a variety of services to IT organizations, including Support Center Analyst and Manager training, ITIL Foundation and Intermediate level training, Best-Practice Assessments, Support Center Audits, and general IT consulting. His degrees include a BA and an MBA. Paul is certified in most ITIL Intermediate levels and is a certified ITIL Expert. He is also on the HDI Faculty and trains for ITpreneurs, Global Knowledge, Phoenix TS, and other training organizations. For more about Paul, please visit www.optimalconnections.com.