Swarming and tiered support are the most popular models for customer service. But how to find out which one’s right for you
Whereas some companies adopt their own unique methods for their customer service process, there are two main established models that are widely used and compared — swarming vs tiered support.
The traditional tiered support has been around for a while but has recently been challenged by the newer concept of swarming.
We’ll get into the intricacies of both models in this post.
Increased competition in every imaginable business area means that companies have to step up their support game more than ever to stand out.
User expectations are rising, and customers expect fast resolution times along with general support quality.
But does it really matter which model of support you use, as long as issues get resolved?
Yes.
While self-support—knowledge bases, FAQ’s, etc—is on the rise as the preferred method of customers resolving their issues, spending time thinking about your direct support process is still absolutely integral.
Today, we’re going to talk about the two main models of customer support, the differences between them, and how to decide what works for you.
What’s the difference between swarming and tiered support?
Let’s look at the main characteristics of both support models.
Tiered support is the most classic and widespread support structure, and works strictly on an escalation principle.
A customer issue moves through three tiers depending on its complexity:
Tier 1 support
This is the first level of the support desk, consisting of generalists who usually don’t have in-depth technical knowledge about the product, application, or service. This is where all customer communications start.
Tier 1 deals with the most basic of issues and questions—usually the most common, recurring, easily resolved problems people have.
Tier 2 support
This is the second level in the hierarchy. It’s closely connected to tier 1, but consists of people with a little bit more technical knowledge, permissions, and skills than tier 1.
Tier 2 deals with any issues that agents in tier 1 aren’t able to handle themselves.
Tier 3 support
This is the highest level of the hierarchy and consists of people with a very high level of technical expertise, knowledge, and skills. This often includes engineers, developers, and other specialists who are working directly in building the product or service.
Tier 3 touches the most technically complicated issues that require the highest level of attention and expertise.
Think of it as a backward funnel—if an agent can’t resolve an issue, they’ll keep passing it on…
…until it reaches a tier with a person who can solve the issue.
Swarming is a much newer concept compared to tiered support.
Basically, whereas tiered support is based on one-way escalation and hierarchy, swarming is based on simultaneous collaboration.
Swarming includes no hierarchy and no escalation.
The different swarms proactively watch for incoming tickets that fall under their responsibility and work to resolve them as quickly as possible.
The number and size of your swarms depend on how many support agents you have and the type of product or service they are supporting.
In a very small company (say, 10 people), usually everyone is in a swarm together—they constantly check incoming support tickets, solve what they can, and leave what they can’t to other people in the swarm.
In slightly larger companies, there are usually a lot of swarms that all consist of a certain group of people. For example, you can have a local swarm, consisting of a front-line agent and a specialist, and a severity swarm, consisting only of specialists.
The local swarm watches your incoming tickets and picks the issues that are the easiest to solve. The severity swarm is less active but deals with the harder and more critical issues that have been left over by the local swarm.
Like we said earlier—how many swarms you have and who they consist of depends on your company and specific case.
However, the point of swarming still remains—instead of a ticket being passed on through rigid tiers and multiple queues, there is always a group of people on duty who watch for the issues they can immediately resolve, without having to wait for the ticket to be assigned to them.
Swarming has been called the new and improved support model, and has been rapidly adopted by many companies as the smarter way of organizing customer support.
At first glance, it does seem more flexible and perhaps even quicker than the traditional tiered model. However, don’t be fooled by the puppy gifs—both of these process models have their pros and cons.
The pros and cons of swarming and tiered support
Let’s tackle the traditional three-tier support model first.
Let’s take a closer look at both the pros and cons.
Pros of tiered support:
Tiered support works well if a lot of incoming issues are recurring and easy to resolve (simple questions, requests, etc)—which is the case in most companies. Lots of recurring issues mean that Tier 1 can deal with the majority of it.
This support model is pretty straightforward to implement, and since it’s a widely-known approach, it doesn’t require much training for a new support team.
Tiered support means that specialists (Tier 3) only deal with the actually complicated issues— since they have been escalated to their level for a reason—and don’t have to spend their time on basic questions and minor blips.
Generalist support agents with basic skills and knowledge (who will be dealing with the majority of incoming issues) are easier and cheaper to find, hire, and outsource.
Tiered support fits well with the structure of most companies—swarming is a relatively new concept and many traditional teams aren’t instantly compatible with it.
Especially in IT, teams (development, support, marketing, etc.) tend to work mostly separately from each other, and non-support teams prefer to spend time on support only if it’s really needed.
Cons of tiered support
Quality self-service support options are becoming more common, which means that end users can solve most of the simple issues on their own without contacting support.
This means that the majority of incoming conversations are on complicated subjects that have to be escalated immediately, which reduces the point of having Tier 1 and increases the workload for Tier 3, who are specialists and could use their time more wisely.
There is little knowledge and skill sharing involved in the hierarchy system. The tiers are siloed—unless a Tier 1 agent specifically goes and looks at how a Tier 3 agent solved an issue, they will not learn from it nor share or gain any knowledge.
Larger queues and ticket backlog—if a Tier 1 agent fails to resolve an issue, they will escalate it, which basically means it is out of their hands and up to someone else to pick it up.
If the ticket moves through multiple tiers and multiple people (with their different work hours and timelines), it means a longer waiting time for the end user to get their issue resolved.
Tiers and strict allowance areas reduce the feeling of accountability and ownership for support agents and may cultivate an attitude of getting rid of issues by just re-assigning them.
Tiered support doesn’t make much sense in very small teams. For example, if you have a team of 5 people, you most likely don’t have layers of people with very different skills, which means you don’t have tiers to put a ticket through.
Now, let’s bring in swarming.
Pros of swarming:
Faster resolution times: If an issue is swarmed by agents of differing levels of skills, it is much more likely to be picked up by someone who is qualified to immediately fix the issue—even if it is a complicated one—rather than waiting for a qualified agent to pick up an escalated issue later.
Smaller support backlog: With multiple levels of agents immediately available to solve an issue, the “work in progress” pile should be reduced by quite a bit.
A stronger feeling of collaboration and commitment: There is no passing an issue on and forgetting about it. Everyone is in it together and equally responsible for every issue.
Cons of swarming:
The swarming method is fairly unstructured (as the name suggests) and harder to coherently document.
If you’re not staffed properly, swarming may mean that highly qualified staff are being constantly distracted by very simple issues that could be solved by a support generalist.
The new(ish) method requires training and reorganization of most support teams, to ensure that the swarms on duty are empowered and qualified as a whole to deal with all levels of issues.
It doesn’t make sense in a very large team. Like we said, swarming can be fairly unruly, which usually doesn’t fly in large teams (the general case is that the bigger an organization is, the more strict structure there needs to be).
If you have a large team, you probably have a lot of support agents and a lot of specialists, which mean that it actually makes sense to have a front line that deals with all incoming, and pass more complicated issues on to higher skilled people.
Now that you know the main pros and cons of tiered support vs swarming let’s figure out…
Which method is right for you?
Ready for the best answer ever?
…
…it depends.
Mad yet?
As much as swarming is being called the new and smart way of doing support, whereas the traditional tiered support is being increasingly considered as ancient and rigid, the truth is that both of these models work.
For certain types of teams.
Generally, swarming is a better option if:
- You have a very good self-serve knowledge base in place, which means that the number of recurring, basic issues is very low, or if most of your incoming issues are more complex in nature;
- You have a small support team (under 40 people);
- You make constant and rapid developmental changes to your product (new releases and features, updates, whatever else) that might cause an influx of unexpected issues to start coming in;
- Resolution time is the most important support metric for you.
Generally, tiered support makes more sense if:
- Most of your incoming issues are recurring, known, simple ones that can be dealt with by support generalists;
- You make changes to your product or service very infrequently and your product development is stable (no big batches of unknown issues that will flood the system);
- You have a larger support team with a higher turnaround rate of new agents
- You have a more formal company structure and culture;
- You need heavy, clear, straightforward documentation of all of your support processes.
Let’s put these main points next to each other:
At the end of the day, deciding on which model you should use depends on your team, your company, your customers, and which metrics you consider most important.
Look at your team, what your incoming issues and conversations are like, how agile your company is or isn’t, what your existing support resources look like, and make a decision based on what fits best with your specific case.
Don’t worry too much about the support model
Yes, it’s important to carefully consider which support model is the best one for both your team and your customers.
Yes, it’s always good to explore other ideas and new approaches to see if they would make your life easier and your customers happier.
However, the most important thing to keep in mind is the values, goals, and existing processes of your company. Don’t fall for trends and go for a specific support model just because people are saying it’s the best or makes the most sense or is the new smart way to do things.
Look at your company, team, and customers, and make a decision based on what makes the most sense for your business.
Which support model do you use and why?
