Collaborative case swarming, or swarming collaboration, is a great way to improve the customer experience with support. At TSIA, we have seen an increasing amount of interest in the subject. During our latest conference, Marlene Summers of Salesforce, Francoise Tourniaire of FT Works, and TSIA’s Vele Galovski joined forces on a panel to discuss the topic. They received so many questions during their session that we asked them to come back and answer them in a series of blogs.In this second installment, I collaborated with Francoise and Marlene to focus on the staffing structure and metrics needed for a successful collaborative swarming model.We’ll tackle the top questions around structure and metrics, including:

• How are teams structured for swarming collaboration?
• What is the optimal size for a team?
• How do you measure individual performance and swarming collaboration’s overall success?

What is Swarming Collaboration?

The swarming support model is when a support case has one owner throughout its lifecycle, and that owner collaborates with team members to resolve the ticket. Gone are the days of tiered support, forcing customers to repeat their problems over and over again to different members of your team. We’ve seen first hand how our member companies have reaped the benefits when they adopt a single-tier support structure. This includes improvements with satisfaction and retention of their skilled employees, satisfied customers, and higher renewal rates and gross margins. If you’re new to collaborative case swarming, the first blog in our series outlines best practices for collaboration success. These come from what Francoise has learned from her years of experience helping companies implement the model.Now that we understand what collaborative swarming is, it’s time to move on to the question at hand: how do I structure my team and measure their success?

How to Implement the Swarming Support Model

When it comes to the collaborative support structure, there is a wide range of ways you can set it up within your team. Ultimately, the structure typically depends on product complexity and the charter of the support organization. The teams can be aligned by product, vertical, geography, entitlement, features, and a whole host of other classifications.

The Pod Structure

The structure most conducive to a swarming support model is a set of pods or specialty areas. Pods can be defined around products or specialties within product lines, or sometimes by product environment (e.g. AWS vs. Azure). Through working with our member companies, we have seen a shift to more product-centric pods. We believe this is due to the increasing complexity of the product portfolio and the range of knowledge needed to support the portfolio. When we look at the TSIA Benchmark data, we see that 73% of members reported having high-complexity products or portfolios. In the pod structure, Francoise sees vendors organizing their teams by geography or by customer type first, with individual contributors reporting to local managers. The pods function as a matrixed form of work organization, superimposed on the reporting structure. The pods are global in scope, even though most collaboration happens within a given region, in near real-time. In some cases, members of the engineering team also participate in the pods. Every support engineer in the organization is a member of a primary pod, with all pod members having the same manager. Most swarming requests occur within a given pod, but it is absolutely possible to request assistance from someone in a different pod. This cross-pod swarming helps to address and resolve “gray zone” cases that don’t fall neatly into a given area. When teams are assigned to specific customers, you can overlay the concept of specialty pods to encourage collaboration.

Pod Communication

At Salesforce, they use Slack to digitize the pod experience into Slack channels. To enhance the swarming support model beyond the individual product support teams, there are additional swarming channels. Support pod members can join based on their background and experience.

• Customer Centric Engineering Channel: contains members of the engineering team who are responsible for formal support investigations raised from cases.
• Product-Topic Channel: contains any employees interested in the product area, typically product, engineering, professional services, and support.
• Cross-Product Channel: used to ask for review and clarification on next steps for issues involving multiple products or when unclear
• Individual Case Channels: Should a specific issue grow into a lengthy, threaded discussion, a case-specific channel is created with appropriate swarm pod members. Others can be added as needed to focus on the particular case at hand. This is similar to how incidents are treated and can be used for escalated and hot cases.

The beauty of collaborative swarming is that it can be implemented with teams of any size and any configuration. A company like the Salesforce organization is very large and can create many specialized pods, but smaller organizations can also benefit from collaboration. The pod structure is adaptable, but does require internal leadership. This is why designating a leader is important.

Pod Structure: Start with Pod Leaders

Whether the job title is collaboration lead, swarm lead, or pod lead, having a senior subject matter expert (SME) in a leadership role is essential to the pod structure. Similar to a scrum master in agile development, the pod leader will coach team members, host daily assist with backlog, remove roadblocks, and facilitate team retrospectives.This role is a great fit for senior engineers with extensive technical experience and, ideally, the ability to lead technical discussions and mentoring sessions. These technical experts are not managers of their team, but instead provide thought leadership and guidance. The pod leaders often manage a smaller case load since they are expected to spend much of their time helping others.  In creating the swarm lead role at Salesforce, Marlene and her team were intentional about ensuring the job description and expectations were clear and consistent throughout the organization. They conducted multiple listening sessions to gather feedback from senior team members who would be applying for the positions. As part of the swarm lead application process, they identified key differences between the support manager and swarm lead roles. A swarm lead is a highly experienced technical resource while a support Manager maintains traditional management responsibilities.

Swarm Lead

• Facilitates the swarming activities within a swarm pod and coordinates swarming activities across the organization where needed
• Serves as a mentor, sharing knowledge resource, and technical escalation point
• Conducts product support troubleshooting sessions and deep-dives to foster pod knowledge
• Drives team improvements on collaborative swarming metrics and support KPIs such as Total Time to Resolution, Customer Satisfaction, and avoidable escalations to Engineering
• Takes ownership of the case or live engagement on the call as required to resolve the case

Support Manager

• Conducts periodic and regular 1:1 with team members
• Oversees performance management of support engineers
• Responsible for engineer staffing, engineer availability across shifts
• Handles critical customer and support service management escalations
• Responsible for attainment of targets for customer satisfaction, employee satisfaction, service levels, resolution time, and project deadlines

By articulating these distinctions from the start, they have not experienced any friction between swarm leads and support managers.

Pod Size: Building Collaborative Support Team Ratios

Once you’ve established a pod or swarm leader, it’s time to construct your team. But what is the size you should be aiming for?One way to define a pod size is through the pod leader to team member ratio. A lower lead-to-team-member ratio allows for purposeful collaboration on complex issues and increased time to mentor individually. This approach means that pod sizes will differ between teams and allows you to build pods with different capacities for complexity.  With this in mind, you may consider determining pod size around customer entitlements. At Salesforce, pod sizes are guided by the Salesforce Success Plan levels, their name for customer entitlement. The highest level of support offers dedicated pods with a lower swarm-lead-to-pod-member ratio, while the standard entitlement offers a higher ratio.

Salesforce Swarm Lead: Swarm Pod Members ratios

• 1:6 (Signature Entitlement)
• 1:12 (Premier Entitlement)
• 1:12 to 1:25 (Standard Entitlement)

Depending on how your own customer entitlements are set up, this is a great way to organize swarming collaboration around structures you already have in place. But remember: take the time to understand what best practices being used by other companies and how those may or may not work within your own organization.

Collaborative Swarming Metrics  

We receive two common questions from our members embarking on the journey to a single-tier model:

• How do you know if swarming is helping or harming the support team?
• How do you measure individual performance when everyone is collaborating?

Measuring Swarming Support Impact

With any organizational transformation, ensuring that the change positively affects performance metrics and team member experience is essential. It’s important to  brainstorm and pilot new metrics designed to represent the impact and health of swarming. At Salesforce, they came up with  four new metrics Marlene uses to track performance:

1. Number of Swarm Requests (SR)
2. Number of Swarm Assists
3. Percentage of Case Inflow Swarmed
4. Swarm Request Average Initial Response Time

Based on the results of their initial pilot launches, Salesforce defined assumptions and established baselines for these four metrics. For qualitative feedback, Marlene’s team holds listening sessions with current swarm leads, pod members, support managers, and cross-functional stakeholders. When introducing swarming collaboration, build in mechanisms for ongoing dialog to assess the good, better, and best ranges for collaborative swarming metrics. As you continue on this journey, use customer-centric KPIs such as Total Time to Resolve, Customer Satisfaction, and Customer Effort Score as the north star to gauge the success of collaborative swarming.

Measuring Individual Performance

Even though collaborative support is a “team sport,” Francoise stresses the importance of capturing collaboration contributions. When measuring individual success, it is essential to throw out preconceived notions about self-sufficiency as a sign of success. Oftentimes in collaborative swarming, “going solo” has a negative effect on the individual’s own contribution numbers as well as the team’s.    

Reward support engineers for contributing to resolving cases they do not own. Don’t just expect them to do it out of the goodness of their heart, without some kind of recognition. There must be a clear personal benefit for providing collaborative assistance to other members of the team.On the other hand, many customer support organizations struggle because the support engineers fail to ask for help when needed. Support engineers are quite resourceful and they may hesitate to ask for help out of pride, and sometimes because the culture frowns upon it. Position collaborative swarming as a normal part of resolving cases that is good for customers and good for self-learning. Though it might seem counterintuitive, those that request more collaboration can have higher contribution numbers than those that seek to resolve issues themselves. For Franciose, she has seen this first hand. Recently, one of her clients found that a top contributor to collaboration was also one of the top requesters for assistance.  Correlating outcomes (in particular resolution time and customer satisfaction) to when and how collaboration was requested can help define where more training is needed. Additionally, it can show you who should be collaborating more to embrace the benefits of swarming collaboration.

Industry Best Practices for Collaborative Swarming

As we wrap up these blog posts on collaborative swarming, I would like to thank Francoise and Marlene for their invaluable input. We would like to leave you with some industry best practices.

• Collaborative support is primarily about behavior, not tools. A collaboration and knowledge-sharing culture must be embedded in your organization from the top down. While there are many tools to help enable a frictionless process, they cannot ensure effective collaboration will take place.
• Take steps to formalize the collaboration process that is informally already taking place. Start small, but start now. This includes the whole ecosystem that is needed to be successful, including a solid knowledge management foundation, automated skill-based case assignments, clinics, queue reviews, and a collaborative/knowledge-sharing culture.
• All team members should clearly understand WHY the change to the swarming support model is being made and how this will make their lives better. There may be some employees that need more nurturing as the culture changes around swarming collaboration. Encourage the team members to design, own and refine the process, having managers guide the process and remove roadblocks. Performance KPIs and the hiring profile may need to change to fit the new culture.
• Clear and constant communication is essential. Not only communication to the team members but also the organization as a whole. Communicate the progress that is being made and the benefits and improvements in the KPIs.

As self-service continues to handle the easiest issues, more complex cases are coming into customer support. If your company has a high percentage of support-to-support escalations and declining customer effort scores, it may be time to start looking at a single-tier support model.