Evaluating Technical Support Models: Tiered Support vs. Swarming, Part 1

Today more than ever, businesses of all types are dependent on technology to reach their business outcomes, whether it’s a manufacturing company producing automobiles, a hospital caring for patients, or a restaurant serving food to a couple on their night out. Gone are the days when, if the technology had a problem, employees could fall back to a manual paper and pencil backup process. If the register stops, or the supply line to the production line stops, or the feed to our trading desk is interrupted, we have no recourse; we look to IT to respond, respond quickly, and address the issue.

We look to IT to respond, respond quickly, and address the issue.

Because businesses are so dependent on IT services, downtime is increasingly unacceptable. Businesses are increasingly raising the bar for IT when it comes to the availability of it services, and IT must respond with more robust, higher availability services. In addition, the demand for higher quality in the services provided is becoming apparent. Any defects or disruptions in IT services—whether that be a service that helps assemble a car or dishwasher, a website that helps market and sell a product, or a restaurant system that enables a chef to prepare a meal to order—will impact quality from the customer’s viewpoint. At the same time, businesses are looking to provide their products/services to customers at a competitive price point, which means that supporting IT services must be delivered to the business at an acceptable cost.

The Challenge for IT Service Providers

Given this changing business and technology landscape, IT service providers must respond to survive and thrive, whether they are an internal service provider to a business and its employees or an external service provider offering IT services in the marketplace. IT service providers must:

• Maintain good on-going relationships with customers, so they can understand the nature of their customer’s products/services and their desired outcomes or business results. Staying in touch with the business and customers on a regular basis can inform IT about the demand for new functionality and how often changes/improvements are required.
• Understand which business processes are mission critical and which are less so, so that they can design IT services with the proper level of availability, resilience, and cost-effectiveness.
• Work with the business and customers to agree on the frequency and packaging of new features and performance in IT services, so that improvements can be introduced in line with business requirements, while minimizing risk of downtime. In general, businesses are demanding more frequent releases of small improvements in functionality/performance, rather than waiting for improvements to be bundled up into a major change introduced once/twice a year. The reason?  Big changes normally mean higher risk of unintended side effects and downtime to address problems, both of which the business and customers want to avoid.
• Find ways to improve the quality of their customer-facing and supporting IT services. Due to the increasingly competitive landscape, customers are no longer tolerating defects in IT services. Once the service is in production, it is expected to work well and continuously. When it doesn’t, customers want the issue responded to quickly and resolved fast.

IT Service Management and ITIL to the Rescue

IT service management arrived as an emerging best-practice in the 1980s to improve IT services to businesses and organizations. ITIL^®, the framework delivering on the promise of IT service management, has since been adopted by thousands of organizations around the world, enabling IT service providers to:   

• Devise and maintain a successful long-term strategy
• Understand the desired outcomes or results customers want to achieve
• Design, develop, and maintain quality services that help the business and customers achieve their desired outcomes
• Provide services that include the desired features, along with acceptable levels of availability and performance
• Introduce IT service changes and releases on a regular basis, with minimal disruption
• Provide IT services to the business and customers at an affordable cost, or price-point
• Deliver quality, on-going support for live operational services, responding quickly to any outages or degradations, and restoring services as quickly as possible to minimize any downtime

ITIL also provides guidance for how IT service providers organize their resources (people, money, tools, hardware and software, etc.), and develop their capabilities (their ability to deliver). ITIL recognizes that most IT organizations have their teams organized around technology or activities, and so the framework defines four functions that carry out processes:

1. The service desk, or support center, (the single point of contact for user assistance)
2. Technical management (such as the database team, network team, server, etc.)
3. Application management (responsible for the design, development, and support of applications)
4. IT operations management (the function that uses monitoring tools to help ensure a stable production environment)

When services are live in operation, these functions are intended to work together to carry out processes that keep services up and available, minimizing downtime to the business. The service desk, as the single point of contact for users, is responsible (along with the support of other groups) for receiving reports of issues from users and resolving as many as possible in a timely fashion.  In the event the service desk is not able to resolve the issue, or needs further assistance, it ought to have a process and agreement in place to escalate the issue to another IT support group who can help resolve the issue as quickly as possible.

For another perspective on swarming, read Gregg Gregory’s blog Swarm to Serve: Team vs Tier-Based Service for Support Centers.

The Tiered Support Model

The tiered support model is included in the ITIL framework as a proven good practice for responding to and resolving issues from users in a timely fashion.

Tier 1 – The Service Desk. The service desk is tier 1, or first line support for users, expected to take ownership of the issue and resolve a significant percentage (usually around 70%) without escalation to other IT groups. The service desk is staffed with generalists, who have broad technical and applications knowledge, to a limited depth. Based on target timeframes in place, they are given a limited amount of time to resolve most of the issues reported. If the issue is not resolvable, they escalate it to a tier 2 group.

Tier 2 – Technical or Application Management Teams. Tier 2 is made of the technical and application management teams, who have people with more specialized knowledge and skills and can take more time to resolve the issue. Tier 2 typically resolves about 20% of the issues reported, due to their higher level of expertise. Upon resolution at tier 2, the service desk is notified and contacts the user to close the ticket. Should the tier 2 function not be able to resolve the issue, they escalate the issue to tier 3, a group that has even more in-depth knowledge and skills to apply to the issue.

Tier 3 – Developer or Vendor Support. Tier 3, third line support (usually a development team or a vendor), accepts any incoming escalation from tier 2 and assigns a resource to resolve the issue. Once the issue is resolved, tier 2 is notified, as well as the service desk, who closes the ticket with the customer. Tier 3 support resources are reserved for resolving only the most complex issues, since they are a very expensive resource. A ticket reaching this level of support is many times more expensive than a ticket resolved at tier 1.

Advantages of Tiered Support

The tiered support model has been around for more than 30 years, having been an integral part of the early versions of ITIL. It has been adopted globally by thousands of organizations of all types and has proven its basic value. It’s also supported by the current version of ITIL and most vendor support tools. Other reasons for its widespread popularity include:

• It works well when a large percentage of the issues are relatively simple, such that they can be resolved by a generalist tier 1 support function.
• Tiered support also works well where there is not a high frequency of changes and deployment of new releases to the live environment. When the support environment is relatively stable, with only one or two major releases per year and minor interim functionality releases, the tiered model can work quite well, resolving most of the issues quickly at tier 1 and with only a small percentage of issues requiring tier 2 or 3 support.
• Its compatible with the traditional structure of most IT organizations: staff that are organized into support groups around technology and applications.
• It positions a dedicated function as the single point of contact for users that is optimized for handling user interaction effectively and efficiently. The service desk function specializes in communication skills and user relationship management (leaving the technical and app functions insulated from interaction with users). Thus, specialized technical and application resources don’t have to concern themselves with optimizing customer service skills.
• Generalist support knowledge and skills is cheaper and easier to deploy at tier 1 than more specialized technical and application resources.
• It is well documented and relatively straightforward to implement, as the structure of the service desk and other support functions have been included in official best-practice publications such as ITIL.
• Training material and courses have also been in place for years, equipping tier 1 and 2 with knowledge about their roles and providing training in the relevant soft and technical skills.

Because of these factors, it is clear to existing adopters as well as those who are considering tiered support, that it generally works and provides a viable approach to handling reported issues from users. However, the business and technology landscape is changing. Adopters of the tiered support model are already facing increasing challenges due to the nature of the changing landscape.

Challenges to Tiered Support

The pace of business and technology change has resulted in an increasing demand for continuous rollout of new functionality and IT service improvements in many organizations. This leads to more frequent changes and releases introduced into the live environment, which generally affects stability, and triggers a higher level of events and incidents for the support organization to respond to quickly and resolve. The tier 1 support staff in such support centers struggle with the increasing volume of tickets due to a larger volume of more frequent changes and releases being produced.

Other environments that have been looking for an alternative to tiered support include organizations that have adopted DevOPs, an emerging best-practice focused on increasing the collaboration between development and operations teams. The DevOps approach seeks to find ways to increase business value by more directly involving development teams in live support operations while 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 as they sometimes become, in organizations. DevOps also includes the concept of applying automation to speed process execution.

Another factor that is driving change in the support model is the increasing adoption of self-service. Organizations that have been successful in deploying self-service are equipping users with the knowledge to resolve a higher percentage of the simpler issues themselves, leaving more complex issues to be reported to and addressed by the service desk/support center. Unless they have deployed a successful knowledge management process, along with mature processes and good working relationships between support teams, such support centers often find themselves ill-equipped to deal with a growing percentage of complex issues. Strange as it seems, effective self-service can result in an increasing number of issues escalated to tier 2 and 3 technical and application teams, rather than fewer issues.

Where Tiered Support Falls Short

The tiered support model is essentially linear in nature, with one tier escalating issues to the next tier, with the expectation that they will be able to resolve the issue. Due to its structure, the reliance on separate functional teams and the escalation process, the tiered support model is falling short in helping organizations effectively address the challenges just mentioned.

Fails to encourage collaboration and knowledge sharing. The tiered model assumes the services provider is organized around separate, self-contained functions: the service desk, technology and applications groups, and IT operations. Unless clear shared policies and SOPs are put in place, along with supporting agreements and good quality knowledge management, getting support groups to effectively work together to solve escalated issues is a challenge with this model. Knowledge originates and tends to stay in specialized groups, unless measures are taken to circumvent natural barriers between groups. Front-line staff are insulated from other tiers and do not have the opportunity to collaborate with other functions to grow their skills and knowledge.

Assumes correct classification of complex issues at tier 1 to route properly. Due to a lack of specialized knowledge, and quite often a less-than-perfect categorization scheme and process, tier 1 support is not always effective at classifying incidents and requests. As mentioned earlier, good knowledge management and an effective classification scheme can help address this shortfall. Otherwise, improper classification due to lack of knowledge can lead to incorrect escalation, and case bouncing back and forth between tiers. This results in increased mean time to resolution, higher user dissatisfaction, and higher average cost per issue handled.

Self-service is resulting in a greater percentage of issues being complex. As self-service continues to be more widely adopted, an increasing number of simpler issues are being handled by the end user at “tier 0,” never reaching the service desk. The service desk is facing an increasing number of complex issues, calling for more in-depth knowledge and expertise at tier 1. Yet the tiered support model fails to encourage the continuous knowledge transfer that is called for. As a result, the tiered model is driving more escalations over time, not fewer.

The trend toward continuous deployment of new functionality. Agile development practices, along with the trend toward adoption of DevOps, mandates that development resources take ownership of code and actively participate with operations teams in the resolution of any issues discovered during live operation. Yet the tiered support model provides no guidance for technical and application specialist groups participate in front line support; instead, the model calls for an escalation and filtering of issues to tier 2 and 3.

Tiered support results in queues, work in progress, and backlog. With tiered support, queues are established for each tier 2 and 3 specialist resources to support the escalation of issues to these groups. The result? Work in progress, and some number of issues backlogged, awaiting attention by groups also tasked with design and transition activities. Work in progress creates delay by its very nature, increasing average resolution time, especially as a larger percentage of issues become more complex issues. Queued work and backlog also drives costs up, due to multiple parties being involved and more time required to resolve the issue.

Recognizing this, DevOps practices are seeking ways to minimize or eliminate queuing and the work in progress that results. Examples include getting development more directly involved in front-line support, while encouraging operations teams to play a greater role in design, development, and test activity. Yet queuing, and the work in progress that results, is inherent in the design of the tiered support model. Customer wait time increases with each escalation, impacting average resolution time, and customer satisfaction levels

Hero culture vs. a collaborative culture. A tiered support model naturally results in the creation and maintenance of a fire-fighting and hero culture, where the heroes are the tier 2 or 3 experts who are called on to resolve the most difficult issues. Meanwhile, tier 1 support resources are rarely recognized, handle only repetitive routine issues, starve for lack of new knowledge and skill development, and tend to burn out more quickly (increasing turnover and costs). Support staff satisfaction suffers, as they do not feel they are learning and growing by acquiring new knowledge and skills. As a result, turnover rises, along with support costs.

The Changing Landscape

The business and technology landscape is changing. With the shift to smaller, portable apps, increasing competition, and the increasing trend in new technology developments, more and more businesses are looking for their IT service providers to introduce more frequent functional and performance updates that add value, with few if any defects, at an affordable cost.

To continue to be relevant and a valued business partner, IT must respond to the changes in the business landscape, and to the business and customers they serve. It absolutely makes good business sense to use proven IT best-practices such as ITIL, for general guidance. It’s also important that IT service providers recognize that ITIL is intended to be an adaptable, flexible framework and non-prescriptive.

With this in mind, we ought to examine the tiered support model and determine where it makes sense and where, given the dramatic trends in business and technology, perhaps an alternative model would be preferable. Although there are many advantages of the tiered support model, there are also some challenges. To deal with the increasing complexity of issues, we must have a model that breaks down barriers, encourages collaboration and knowledge sharing, ensures fast response and resolution of issues, and results in in all teams being treated with high value. In the next edition of this two-part series, we will look at an emerging alternative: the swarming support model.

ITIL® is a registered trademark of AXELOS, Limited.  All rights reserved.

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.