Swarming vs Tiered Support Models Explained

What is Swarming Support? It’s a reaction to the perceived shortcomings of a ubiquitous ITSM practice: the tiered support model.

Perhaps the most well known organisational structure for IT Service Management is the three-tier support hierarchy. In a typical enterprise, we might find a structure which looks something like this:

• Level 1: A frontline Service Desk, directly fielding incoming customer communication (typically by answering phone calls), with a level of generalised skill intended to enable resolution of a high volume of simpler issues.
• Level 2: A second tier of support, often closely associated to the Service Desk, but with deeper general or specialist skills.
• Level 3: Specialist support teams focused on specific technologies and applications.

This structure has become entrenched in the corporate IT support world for a number of positive reasons:

• Customers are presented with a single communication channel to the IT support organisation, regardless of the nature of their issue.
• The general technical support skills needed to work in Tier 1 and Tier 2 support are easily found in the workforce. This also makes outsourcing of one or both of these layers straightforward, and as a result this is commonly seen.
• Specialist technical resources can be insulated from direct contact, ensuring that only properly triaged issues reach them.

The journey of a customer’s case through this structure may start and end at the first line (in fact, in many organizations, customers have the opportunity to resolve their issue through automated self-service — often described as “Level zero”).

There are inevitably many issues, however, which are not resolvable by Level 1 support. These progress to Levels 2 and 3 through a process of escalation:

Level 2 support agents typically handle fewer cases than their Level 1 counterparts, but these tend to be more complex, with a longer average effort on the part of the agent.

Tickets which make their way to Level 3 typically account for a small volume of the overall incoming caseload, but they are also the most complex issues, requiring the most specialist skills, and generally taking the most time to resolve.

Swarming attempts to replace this support structure with something rather different. Advocates of swarming contend that there are fundamental problems with the multi-tiered support model:

• Tiered Support can lead to cases “bouncing” from one team to another, often multiple times, as the organization attempts to find a single team which can drive the issue to resolution.
• The model is fundamentally siloed. The use of single-discipline teams reduces opportunities for knowledge dissemination.
• It leads to queues forming. Often a single issue may wait in a number of teams’ ticket queues, each adding a delay to the issue’s progress to resolution. The answer may be at level 2 or 3, but it takes time to get there, as it waits in a number of teams’ queues along the way.

“Swarming” appeared late in the last decade as a proposal for a new framework for technical support organisation. It explicitly rejects the three-tier orthodoxy, in favour of a model of networked collaboration:

A key pioneer for IT support was Cisco, who set out their new “Model for Distributed Collaboration and Decision Making” in a 2008 white paper, “Digital Swarming”. The concept was subsequently adopted by the Consortium for Service Innovation, and developed into a vision entitled “Intelligent Swarming^SM”. Some of its core principles, in direct opposition to the orthodoxy, are that:

• There should be no tiered support groups.
• There should be no escalations from one group to another.
• The case should move directly to the person most likely to be able to resolve it.
• The person who takes the case is the one who sees it through to resolution.

The intelligent part of Intelligent SwarmingSM refers to the use of individual or team “reputation” to help select the right people to bring into the Swarm.

Here at BMC, many of our customer support teams use Swarming as an alternative to tiered support. Our model consists of three different types of swarm:

1. Severity 1 Swarm
2. Local Dispatch Swarm
3. Backlog Swarm

Swarming starts as soon as any issue is not immediately resolvable at the point of customer contact. A rapid initial triage results in the distribution of case tickets to one of two “Swarms”:

Each “Swarm” is actually a small team, focused in near-real-time on the incoming flow of customer cases:

“Severity 1” Swarm

Three agents working on a scheduled weekly rotation.
Primary focus: Provide immediate response, and resolve as soon as possible.

A Severity 1 swarm is focused on a very small percentage of issues which happen to be the most critical. Appropriate people are brought into the swarm to resolve severe cases as quickly as possible. This is not something unique to Swarming, being indistinguishable from a typical “major incident war room”.

Local Dispatch Swarm

Meet every 60–90 minutes
Regional, product-line focused
Primary focus: “Cherry pickers”. What new tickets can be resolved immediately?

Secondary: Validation of tickets before assignment to product line support teams.
Dispatch Swarming addresses a key shortcoming of tiered support: many cases can be solved extremely quickly by the right expert, but there is a delay in getting to them.

The Dispatch Swarm is encouraged to “cherry pick”, disregarding anything that cannot be resolved very quickly. In doing so, they are able to dramatically shorten the time spent achieving resolution for a significant subset of escalated cases.

There are significant secondary benefits, too. The inclusion of inexperienced frontline support staff in these Swarms gives exposure to knowledge that would otherwise only start to be gained after eventual promotion to more specialist teams. Meanwhile, conversely, third-tier support agents are brought closer to the customer.

Backlog Swarm

Swarming that isn’t the result of initial triage is often called the Backlog Swarm.

Meet regularly, typically daily.
Primary focus: Address challenging tickets brought to them by product-line support teams.
Secondary: Replace the role of individual subject matter experts.

Issues which are still open after being processed by the Triage Swarm may be brought to the Backlog Swarm. This brings together groups of skilled and experience technical people, crossing boundaries such as geography and department, with the objective of focusing on the most difficult cases. Cases are referred to them by local engineering and support teams, who are no longer permitted to directly engage individual subject matter experts. They must, instead, always refer those cases to the appropriate Backlog Swarm.

The introduction of Swarming in BMC’s customer support organisation has led to a number of measured improvements across key indicators such as customer satisfaction, mean time to resolve, and backlog size. Importantly, too, we have seen tremendous improvements in skills development and knowledge sharing. As one experienced support analyst put it, “I have probably doubled my knowledge of the products in a year because of Swarming, and I have been here a long time”.

You can learn more about Swarming at the Consortium for Service Innovation’s website.

These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

See an error or have a suggestion? Please let us know by emailing blogs@bmc.com.