Get your FREE 30-day trial.
Start by selecting a product:
The pressure on customer service teams continues to increase. Customers expect instant help — either from self-service digital resources or, with a complex problem, by talking to a person. They’re looking for support that’s both easy and expert.
However, the traditional support model of escalating difficult cases to managers or other teams doesn’t cut it anymore. In fact, 82% of customers expect to be able to solve complex problems by talking to just one person, according to Salesforce’s State of the Connected Customer report.
The old way of providing support often results in long resolution times and multiple handoffs for complex cases. That’s frustrating for the customer. It’s also inherently inefficient for the organisation.
The solution is case swarming, a collaborative service model that shares the load of solving customers’ complex problems across the organisation. At Salesforce, we’ve transformed how we provide support to our customers by adopting case swarming. We are doing this using the newest addition to Salesforce Customer 360: Slack.
Under a traditional model, customer service teams are typically grouped into tiers, based on their level of experience or expertise in a particular product. A customer with a complex problem is often passed from a Tier-1 service agent to a Tier-2 team member, then to a Tier-3 agent.
There are clear downsides to the customer experience: time to resolution is longer, and customers often have to repeat information about their issue to multiple case owners. Even with a successful resolution, this drawn-out experience reduces customer satisfaction.
A traditional, tiered model requires an overly complex structure, with multiple customer handoffs. Service agents may spend time on cases they are ill-equipped to resolve, reducing their productivity. When an agent escalates a case to the next tier, it can result in a lack of accountability and ownership. Unless they receive formal training, they’re not learning new skills or progressing their careers.
In a tiered support model, customers interact with multiple agents to resolve their issue.
Recognising these issues at Salesforce, we set about solving them by adopting a new model of intelligent case swarming. We redefined our strategy by creating swarm pods, giving customers access to more expertise from a pool of support engineers. We use Service Cloud to route the case to a swarm pod lead who brings in the necessary experts from across Salesforce.
Case swarming puts the customer at the centre of the support experience. This type of support model is designed to ensure customers only deal with one owner for each case, someone who has quick access to the expertise they need to resolve each issue quickly.
Each of our swarm pods supports a different Salesforce product, although some pods offer a specific skill set or specialty. Support engineers collaborate within their pods, and can also jump into other pods to help. There’s no need to escalate a complex issue — everyone is collaborating by default, so a case owner can quickly connect with the right person or people to resolve the issue.
We use Slack as our collaboration tool because of its flexible, feature-rich environment. It allows cross-functional teams to communicate and make decisions in real time, no matter where they are located. Because it will integrate with Service Cloud, the full case histories will be easily accessible from within those conversations, creating a simpler agent experience in a single, collaborative place.
Case swarming helps bring the right experts together to quickly resolve cases.
Slack gives our support pods the flexibility they need to work together to resolve even major issues quickly. Here’s how it works: If an engineer needs help on a case, the pod’s lead pushes a swarm request into the appropriate Slack channels, asking other pods, cross-functional subject matter experts, and managers to swarm the case.
Workflows built into Slack automate the processes service agents use to bring the right experts to the swarm pod and work through the case together. Slack bots help monitor and process channel activity, post messages in channels, react to members’ activity, and make channel messages interactive with buttons.
This approach allows our engineers to resolve customers’ problems faster, while also shielding customers from the complexity and multiple hand-offs of a traditional support model.
As a result, Salesforce has seen a 26% reduction in case resolution time since introducing a tierless support model with case swarming with Slack, despite an increase in customers and case volume over the same period.
With the swarming process, our engineers are regularly collaborating with engineers in other pods, while working closely with highly-skilled experts in their domains. They’re constantly learning from each other, accelerating their skills in their areas of expertise, and broadening their knowledge across domains.
Meanwhile, pod leads can coach and mentor their teams in a real-time, collaborative way, instead of the traditional, review-style management approach.
As a result, the company gets a more highly-skilled support team, while engineers gain more skills and more responsibility, progressing their careers.
Ultimately, case swarming has improved the dynamic between our support teams, managers, and customers. Looking ahead, we plan to standardise and scale case swarming across Salesforce.
Having seen its success in customer support, it’s not hard to see how swarming could benefit other teams. Already, for example, Slack channels provide readily available feedback loops for product teams. They can see issues as they unfold, identify trends, and come up with new ways to improve products for our customers.
We have amazing people working in security, operations, finance, sales, product development, support, and other departments. We’re already a highly-collaborative organisation, but swarming could take that to a new level, enabling our people to readily share their knowledge, experiences, and resources in real time.
This post orginally appeared on the U.S.-version of the Salesforce blog.
