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

In an effort to address some of the shortcomings of the tiered support model and to take advantage of new collaborative technologies now available, a new support model known as swarming or collaborative support model has been emerging over the past several years. 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 this new support model. They have coined the term Intelligent Swarming^sm for this emerging model, since in their view the swarming model should act intelligently—using a database of profiles to match the best resource/team likely to immediately resolve the issue, backed by an effective knowledge management process. In the view of the Consortium:

• There are no tiered support groups; swarming is a collaboration-based process
• No “passing off” escalation of the issue from one group to another
• The person who first takes the issue owns it through to resolution (as with ITIL, Total Contact Ownership is maintained in the swarming model as well)
• The issue should be directly routed to the person most able to solve the issue

Rather than a linear/hierarchical model as in the case with tiered support, the swarming model is a network of people, a collaborative model. Rather than impede collaboration via silos, the swarming model is compatible with the way engineers and support analysts naturally work. The goal is to get the right resources to work together to resolve the issues in the timeliest fashion possible.

Paul examines the challenges of a tiered support model in Evaluating Technical Support Models: Tiered Support vs. Swarming, Part 1.

In order to do this, silos that are characteristic of most IT organizations have to be bridged. The resources most able to address the issues must have visibility to these issues. Rather than directing issues to a specific escalation team, resources that are relevant to the issue can view the incoming issues and choose to opt in, providing a solution, workaround, or helpful tip to the case owner.

Of course, this approach requires a supporting service management tool, with the ability to maintain profiles, case visibility to those who are relevant, and chat capability to enable team members to collaborate on a solution. Early adopters of the swarming model include Cisco, BMC, Red Hat, and Allscripts. All of these organizations have experienced dramatic improvement with swarming, including increased visibility of cases across teams, improved collaboration, reduced resolution times, an increase in first contact or first day resolution, improved skills and knowledge transfer, and a decreased backlog.

Of course, it is important to point out that this is an emerging best-practice, only adopted in a small number of organizations/businesses where the is a high volume of frequent releases, an active Agile/DevOps practice, and strong management support for this new model. Swarming, as a support model, lacks the maturity and proven track record that the tiered support model has in place (such as ITIL supporting documentation, many industry case studies, and proven service management supporting tools). Nevertheless, the new model does result in dramatic improvements in some environments, based on the case studies available.

Where a Swarming Support Model Makes Sense

In some cases, the tiered support model no longer seems to be the optimal approach for the support environments. In organizations that experience frequent and rapid business change, customers demand continuous deployment of new functionality and immediate attention to any failures or degradation in performance. In these cases, tiered support falls short; the swarming model, with its emphasis on real-time handling of issues, can deliver faster and more effective response and resolution.

The growing popularity and adoption of Agile development practices and the DevOps collaboration model by development and operations groups works well with the swarming support model, as it specifically addresses the need to bridge organizational silos found in many organizations and encourages collaboration.

The increasing adoption of self-service is resulting in an increasing share of simpler issues being resolved by users and more complex issues left to be resolved by the support organization. The swarming support model answers with more effective swarm teams who can effectively deal with the increasing complexity of issues reported and yet resolve these expeditiously.

The tiered support model, by its very nature, drives costs up as an issue escalated from tier 1 to 2 to 3. Resolving issues on first contact, or at least within the support center with effective swarming teams, can help meet the need of organizations to reduce costs while increasing performance.

The tiered support model, by its very nature, drives costs up.

The collaborative/swarming support model should be reviewed and seriously considered for adoption whenever it makes sense given the support environment. This makes sense especially in environments where rapid business changes have led to the adoption of Agile and DevOps practices or when a current state assessment of the support organization shows poor performance on escalated issues; relatively long resolution times, as compared to industry averages; and low first contact resolution, with a high percentage of issues escalated to technical and application groups.

A Sample Workflow Using the Swarming Model

Let’s take a look at how an issue might be handled using the swarming/collaborative model. Assume for the purposes of this scenario that there are three swarming teams set-up in advance, with subject matter experts (SMEs) rotated in on a regular basis to help staff these swarming teams: 1) a primary of “Routine” swarm team, which would handle most issues, 2) an “Expedited” swarm team, which would handle only the top priority issues (similar in concept to the ITIL major incident team), and 3) a “Backlog” swarm team, which would proactively attack and resolve any issues not yet handled on a daily basis:

1. An incident/service request is transmitted into the support center via available channels. The submitter provides credentials and what they are contacting the support center about, establishing in your distribution system the status of the caller, any special handling that may be required, and the type of issue.
2. Your distribution system, using the profiles and the information provided by the customer, identifies the individual/team that has the best knowledge and skills to resolve the issue. If the issue is high-priority, the issue is immediately routed to the “Expedited” swarm for resolution. The Expedited swarm team resolves the issue or works in conjunctions with product engineering/development in real-time to continue to work the issue until resolved.
3. If the issue is not high-priority, the issue is routed to the “Routine” swarming team and to the best matched individual in that team for the issue. An attempt is made to resolve on first contact; the team member uses their matched skills, knowledge, and access to an integrated knowledge base to resolve the issue on first contact. Relevant solutions are presented to the team member to apply, and other team members relevant to the issue have immediate visibility to the issue (in case they are needed), due to a match of the issue to their profiles.
4. If the individual cannot resolve the issue, they signal the relevant swarm team members that they need some assistance. This may be done several ways, for example, using a chat tool to raise a virtual hand for help or posting the issue to a shared discussion board, for less urgent issues. Relevant team members opt-in and provide assistance, collaborating on a solution to the issue and speeding resolution.
5. The Routine swarm team also huddles and reviews tickets not yet resolved several times a day. Collaboration tools such as chat and discussion forums are used to brainstorm within the group and with other SMEs to identify a possible solution. They cherry pick and swarm to resolve issues, preventing as many escalations as possible. In the event the issue cannot be resolved, they validate the issue before escalating to a responsible technical/application support group.
6. A high percentage of issues are either resolved on first contact (or at least first day) by the Routine swarm team. High-priority issues are handled real-time in parallel by the Expedited swarm team until resolved. Any remaining issues are addressed by a third type of swarm team, the Backlog swarm.
7. A Backlog swarm team focuses on issues not yet resolved and swarms daily to resolve any ongoing issues. This relieves technical and application management teams from having to deal directly with escalated incidents/requests and ensures that a cross-functional team of applicable technical/application specialist resources addresses the issue in a timely manner.

Advantages of a Swarming Support Model

Given the environment and proper planning and implementation, the swarming support model can provide the following results:

• A greater sense of shared vision, mission, and purpose across all support groups that are a part of the IT service provider, since individuals no longer identify themselves by their membership in organizational/technology teams, but by their shared values, common purpose, and areas of expertise. Team measurement and metrics also take priority over individual metrics and reporting. In this model, a common set of performance goals and objectives is shared by all.
• A higher level of support center performance can also be achieved with the swarming approach, if the right prerequisites are in place (discussed later in this article) and it is deployed in answer to the needs of the business and customers. Given the enabling factors, an effective swarming methodology has been shown to result in faster first contact resolution and a higher level of issues resolved within the support center, without escalation to other support groups.
• Higher user satisfaction, due to faster average turnaround times that result with effective swarming. This leads to higher customer retention and more product/service sales. Costs are also reduced—there is a lower average cost per issue, due to fewer escalations and faster average turnaround time.
• A higher level of support staff satisfaction also follows, due to greater knowledge sharing that is part and parcel of a swarming model, and less routine work by front line support. Staff satisfaction and morale benefits. And as a result, turnover decreases, and employee retention and productivity rises.

Challenges to Implementing a Swarming Support Model

The swarming model is also flexible and adaptable and can be implemented in several ways depending on the organization and support environment. Nevertheless, there are some challenges that must be addressed in order to effectively plan and implement such a model:

• Setting up Staff Profiles is absolutely essential to effective handling of incoming issues. Documented, continuously maintained profiles of knowledge, general, and specialist skills are established for each team member and stored in a service management system and facilitate routing of the issue to the best person/group to resolve the issue.
• A knowledge management process and supporting knowledge base must be integrated into the issue handling process, such that solutions to issues are either reused or captured in the workflow—no need to take extra/separate steps.
• Effective categorization and priority schemes ensure that the issue is properly identified as to the affected service, major category, and sub-category. Priority should still be based on a combination of impact and urgency (consistent with ITL).
• Revisit and re-document your incident management and request fulfillment processes. These ITIL processes are still for the most part compatible with a swarming approach; however, the way that functional escalation is carried out changes.
• Issues are no longer “passed” to another support group tier. Instead, the ticket owner “signals” to the swarm by means of a collaboration tool that they require assistance.
• Because relevant team members of the swarm have the visibility to incoming issues, they may “opt in” and volunteer to provide the needed knowledge/skills.
• In-depth investigation and diagnosis takes place in a collaborative fashion, with SMEs participating in the resolution and skills and knowledge are transferred across functions.
• A shared supporting service management system for ticket management, along with effective collaborations tools. Tickets will still need to be identified, logged, and tracked through their life-cycle. Collaboration tools that support real-time chat and integrate with other systems and social media will provide support for real-time collaboration between groups.
• Planning and establishing your swarm teams. Each swarm is actually a small team, focused in real time on incoming issues depending on the nature and priority of the issue. There is no set rule for how you must organize your swarm support teams, but one example would be to have a swarm for normal issues, another for high-priority issues, and one focused on the backlog.
• Determine the rotation of members from technical and application groups into your swarm team(s). Rotations of SMEs from technical and application groups should be on a scheduled weekly/monthly basis to minimize interruption to other ongoing project activities.

Critical Success Factors for Either Support Model

Pay attention to the following considerations to design, implement, and maintain an effective support model, whether that be a tiered model or a swarming support model.

• Carefully assess your internal and external support environment. Using a strengths, weaknesses, opportunities, and threats (SWAT) approach, analyze the internal and external factors that affect your service and support provision:
• Connect and align with your business and customer’s strategies. Is the business in need of more frequent releases of new functionality and performance in IT services?
• Consider your internal IT strategy for the frequency of changes and releases. Are you moving in the direction of more frequent, smaller increments of changes and releases?
• Is your IT organization adopting Agile and DevOps practices? 
• What is the trend in demand for higher availability in IT services?  Is it increasing across the board?  Just for some services?
• What is the impact of self-service in your environment?  Are a higher percentage of issues becoming more complex, with more rather than fewer escalations?
• Establish a shared vision and mission for your support center across all IT service and support teams, backed by strong IT and support center leadership and management. Ensure that all teams understand what you do, why you do it, and the value all are expected to participate in delivering to customers.
• Involve your team members in designing and implementing the support model for your organization, whether that be a tiered support or swarming model. This will encourage participation in the adoption of the preferred approach.
• Establish shared goals and KPIs. In a tiered support model, a good balanced scorecard of individual, team, and process metrics should be established. In a swarming support model, team metrics should be emphasized over individual metrics.
• Create and maintain profiles. Up-to-date profiles and a matching and routing system enable your support center to route the issue directly to be most qualified person/team to resolve it. Profile records should include roles and responsibilities, skills, knowledge, and interests. Rather than manually updating records, integrate the update of these records into the process.
• Take a process approach. Although a good distribution system and service management system are essentials, don’t be tool driven. Document the policies and procedures (SOPs) for how tickets are going to be handled and routed,  whether to other functional groups in a tiered model or to a different swarm. Clear roles and responsibilities of individual team members, along with shared policies and procedures, will facilitate collaboration and teamwork.
• Emphasize Total Contact Ownership. The person that took the issue initially owns it through to resolution, whether tiered support or a swarming approach. This is a best-practice no matter which approach is taken, for good reasons: coordination, follow-through, and ultimately higher user satisfaction.
• Remain focused on key performance goals and objectives. Every issue does not need to be escalated or routed for swarming. If you can solve on first contact, then by all means do so! Clearly document and communicate to all individuals your shared goals, objectives, and KPIs. Leverage team display scoreboards to provide visibility to team performance to goals.
• Select and implement effective support tools to automate, but stay process and performance focused. You will need an effective service management tool no matter which model you adopt. You must capture profiles to automatically route to the most qualified resource to handle and resolve the issue. Pay attention to collaboration support tools that facilitate real-time chat. It’s also important to ensure your tools enable you to capture and share knowledge in the workflow, to grow the knowledge base as a by-product while handling issues.

Choose the Support Model that Makes the Most Business Sense

In the final analysis, IT service providers should be driven to be of service to the business and customers they serve. Consider your business environment, the customers your serve, and the vision and mission of your organization, to design and implement the support model that makes the most business sense. Overarching goals should include:

• Delivering quality IT services to the business and customers that represent real value, responding to changing business needs and enabling them to achieve the business results they seek
• Carrying out IT best-practices that minimize defects, disruptions, or degradations in services, resulting in quality IT services that demonstrate high availability and minimal downtime
• Organizing resources and capabilities to enable you to respond quickly and resolve issues as fast as possible to minimize the impact to the business and customers
• Implementing a support model that provides cost-effective services to IT and the business

Intelligent Swarming^sm is a service mark of the Consortium for Service Innovation^TM.

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.