As last years of the last decade of the 20th century flickered to a close, a then-new way of delivering Software as a Service (SaaS), transferred power and expertise from companies to customers.
Customers could now cancel their contracts at any time, they were no longer locked into multi-year software deals. And since customers were also using the software in ways we didn’t anticipate, they too became important partners in resolving issues.
Expectations around time were reshaped. Customers wanted to use the software out of the proverbial box, without long implementation or customization times. And if they had an issue, they wanted it addressed swiftly, without being bounced around. They don’t care if it is a complex issue or not. In fact, Eighty-two percent of customers expect to solve complex problems by talking to one person.
Customer support teams respond
These customer expectations exposed fundamental limitations in the traditional tiered support model that had been in place from the early days of support. Solving complex issues required teamwork and collaboration beyond the usual tiers of service and support.
For those that aren’t familiar with it, in a traditional support model, your least technically qualified staff are ‘the face of your organization’ to your customers and partners. If they can’t resolve the customer’s issue with the existing knowledge base, they escalate and hand off the issue to a more senior tier in their group or to someone else in another group that has the knowledge or authority to resolve the issue. Escalations take time. And the backlog of cases that are ‘in process’ but not solved builds up. Each hand off is a disaster waiting to happen and dealing with backlogs are one of the most soul-sucking of experiences for a tech support person (and their managers).
The traditional tiered support model does a disservice to the customer and makes your front-line tech support person’s life miserable. Is it any wonder that as soon as they are better trained, your team members ‘escape’ to the next tier up in support so that they don’t get ‘interrupted’ by as many customer issues?
My personal introduction to this dizzying world
In 1999, at the dawn of the Internet boom, I was asked to create and build out the Tech Support team at a then-tiny company called Akamai. It was an early unicorn that was growing exponentially. Almost immediately, it became clear that everything I knew about building out a traditional support team wouldn’t work.
There had to be a better way.
We (along with others struggling with the same issue) ended up pioneering two support models at scale. One which is now called Customer Success (making sure that customers got value out of what they bought from you) and ‘Swarming’ – a route to finding the right solution for your customers. Quickly and effectively.
We called it swarming as it was inspired by nature.
We studied how ants, fish, birds and bees respond quickly to external stimuli using simple rules of thumb based on how each individual acts based on their local perception of what is needed to be done. Adapting this enabled people to solve issues in a decentralized manner in response to rapid changes, without a lot of managerial overhead.
This early version of swarming at Akamai worked because most issues were ‘hair on fire’ – urgent and time sensitive to resolve, and all groups were happy to pitch in to figure out who and what was needed to address customer issues. It’s no wonder that many smaller organizations tend to naturally swarm.
But it soon became clear that this too wouldn’t scale. Too many people were jumping in to resolve issues that could be much better handled (or were already being handled) by someone else. Swarming while getting people involved who didn’t need to be and re-inventing the wheel each time is chaos and certainly isn’t intelligent.
Since then, several companies (including many I worked with when I moved to a consulting role) have continued to evolve the swarming model.
Swarming today
While there are many variations in terms of how it is implemented, here is how swarming works in practice in many companies. If the tech support person needs help from another group, instead of handing the case off (escalating) to another group, they ask an appropriate cross-functional group for help. The request for help is typically aided by technologies that matches the request to the right group that can help resolve the issue.
A swarm ‘lead’ in the swarm group ensures that issues move along and get resolved quickly. There is no need to escalate, as the model ensures that everyone collaborates by default. Common group collaboration tools include Slack, Microsoft Teams, a forum/community software or even a simple mailing list.
Traditional Swarming has many advantages over a tiered model.
- Reduces Time to Resolve (less hand offs). Salesforce reported a 26% reduction in case resolution time since implementing a swarming model.
- Initiator learns (they keep ownership of the case and are responsible for creating or updating the knowledge outcomes)
- Less turnover (people feel supported in a learning environment)
Time for the next evolution of Swarming
While there is a lot to celebrate with the existing swarming paradigm, we think the time has come for Swarming to evolve again. We propose the following meme for Swarming which will help leaders and teams understand the key principles behind swarming.
Swarming with the KIT principle
KIT stands for Knowledge-first, Improvement and Teams.
“K” for a knowledge-first culture
So ‘K’ is to remind everyone that for swarming to succeed, you must have a knowledge-first culture. This means that leaders create the environment where people want to improve knowledge every time they touch it, leaving it in a better place for the next person. This is also a key prerequisite for swarming to work.
As more of the ‘known’ issues are captured and findable in a customer-facing knowledge base, incoming ‘new’ issues require research to resolve. Even in a traditional tiered support model, if ‘known’ issues are treated as ‘new’, it is expensive for both the customer and the teams involved in solving the issue. Given how many more people are engaged in collaboration in real time, it very quickly becomes far more expensive in a swarming model.
Wait. Isn’t it obvious that we should be knowledge-first and not case-first? Why do we need to re-iterate this? Because under pressure, we tend to revert to a case-first mentality – take care of customer issues, with knowledge as an afterthought. We tend to focus on fire-fighting and then rush off to address the next fire, saying we ‘don’t have enough time’ to look at fire-prevention.
There is another reason we often revert to a case-first culture. This is because most organizations frame the problem that they are trying to address with swarming is related to taking care of complex issues – reducing hand offs and reducing backlog. Too often victory is often prematurely declared by focusing only on the case resolution times, instead of the knowledge captured and lessons learned.
“I” for (continuous) improvement
Swarming groups are the core unit used to bring out the best of everyone during each interaction. Groups can be assembled cross-functionally and by product for easy collaboration.
This model includes a really important role – that of a swarm coach, who focuses on continuous improvement. They offer guidance and feedback to swarmers and swarm leads in real time. They look at patterns across multiple swarming groups to see, devise or refine solutions that span groups and can help everyone.
Their role would be similar to the National Safety Transportation Board (NTSB) in the United States. The NTSB has a crack team of investigators who fly to crash sites and conduct thorough investigations of the root cause and ferret out where it lies, no matter how complex. (They also investigate near accidents, to help prevent accidents from occurring in the future.)
There is yet another reason why swarm coaches are critical. At times, they will need to go toe to toe with multiple managers (remember, in a swarm group, there could be people from multiple reporting structures, each with their own group’s goals that may conflict with the swarm group’s goal) to help them see the big picture.
“T” for Teams and teams-based measures
Too often, we bring together people from disparate groups and call them a team. It’s like telling everyone who watched the same movie in a movie theater that they are a team because they shared the same (hopefully wonderful) experience.
Teams need more than lip service to thrive. They need common purpose and common measures.
In complex environments, decision making must be pushed out to the periphery. This means that people need autonomy and room to adapt based their judgment, experience, and expertise. They need simple guidelines and guardrails within which to operate.
They can and should have common goals and measures that they hold each other accountable for. Swarm groups then take collective responsibility for improving the measures. With this type of team where multiple managers from different groups are involved, it is important to know that the measures are for the team to do better, not for managers to ensure compliance.
Swarm Coaches work with managers to make sure that the managers are not enforcers, but player-coaches who promote knowledge-first among swarm group members.
Examples of measures from a recent client:
- Same Day/Next Day resolution
- Customer Effort score
- Employee Effort score
- Collaboration Effort score (how easy was it to get assistance from another group)
- Time to Proficiency
Final thoughts and next steps
We believe that swarming with KIT is not a wholesale rip and replacement for the traditional tiered support model. They may need to exist together. (But over time, swarming with KIT should replace most of traditional tiered support.)
There are incredible benefits to be gained by embracing swarming for complex cases. However swarming has limitations at scale, and a case-first approach means you may end up missing many opportunities for continual improvement across the business, not just within Support.
A client we recently did a Swarming Accelerator with surveyed their (initially skeptical) Pilot team on the results of the engagement.
With a 83% response rate:
- 92% believe/strongly believe this model (if implemented well) aligns with their North Star
- 92% believe/strongly believe this model (if implemented well) will reduce the Time to Resolve for complex issues
- 84% believe/strongly believe this model (if implemented well) will reduce Employee Effort for complex issues
And the 1.5 hour self-paced online training we created on Swarming with KIT :
88% believe/strongly believe the training content on Klever platform helped to understand the concepts well.
If you’d like to have us chat with your leadership team about swarming with the KIT principle, do reach out.
We also have a webinar coming up on it.