About the Knowledge Base
Search all the Knowledge Base
Testimonial: I have found that the new HDAA Knowledge Base reduces the time it takes me to research industry stats & reliable information for the ITSM sector. It’s easy to use search functionality encompassing KCS principles, helps to filter & tailor my searches more accurately & there are numerous new services now available through the website. Every time I return to the site there is new information published. Very impressive.
Chris Powderly, Support & Services Manager, Allens
supportworld , support center , technical support , staffing , support models
No Result Found
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.
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:
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:
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:
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 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:
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:
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:
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.
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:
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:
In this tiered/swarming approach, the basic workflow is as follows:
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.
No Result Found
- Contact Us
- IT Membership
- Support Centre Association
- Comparison Guide
- Price Guide
- Membership Conditions
Training & Workshops
- Training Courses
- Recent Workshops
- Cancellation & Transfer Policy
- ITIL Training
- ITIL Foundations
- Support Centre Consulting
- Service Desk Consulting
- Help Desk Consulting
- Media Kit
- Update your details
- New account
© Copyright HDAA. All rights reserved.
HDAA - Energising the Service & Support Profession
Help Desk Association Australasia Pty Ltd trading as HDAA
T: 1300 130 447 T: +61 (0) 2 9986 1988 F: +61 (0) 2 9986 1330
E: firstname.lastname@example.org W: www.hdaa.com.au A: PO Box 303, Turramurra NSW 2074 Australia
ABN: 20 088 292 755
Our Services: ITIL | ITIL Training | ITIL Foundations | IT Membership | Service Desk Association | Support Centre Association | Support Centre Training | Service Desk Training | Help Desk Training | Support Centre Consulting | Service Desk Consulting | Help Desk Consulting
ITIL® and PRINCE2® are registered trade marks of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
RESILIA™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
The Swirl logo™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
DevOps Foundation®, is a registered mark of the DevOps Institute.
HDI® is a Registered Trade Mark. HDAA is the Australasian Gold Partner of HDI®.
KCSSM is a Service Mark of the Consortium for Service Innovation™.
Apollo 13 Insignia image by 'NASA Johnson' (copyright-free) June 2017 via https://www.hq.nasa.gov/alsj/a13/images13.html
WEB DEVELOPMENT PARTNER