How We Provide Real-Time Customer Service Through Slack
At Taplytics, we have always tried to make great customer experience a part of our differentiation strategy. Because of this, we recently made the decision run all of our customer support through Slack. We’ve been testing this for the past six months, and have found both great results and interesting challenges. Now that we’ve had a bit of experience with this channel, we’d like to share some of the things we have learned along the way.
Great Email Support
The transition to real-time support through Slack didn’t happen immediately. At first we didn’t even think of it as an option. When we started our company, we thought the best, most differentiated support we could offer was just to make the individuals at our company directly available via phone and email. We achieved this by posting real phone numbers and email addresses prominently on our website. (It’s amazing how many companies don’t even have a central line posted to their sites.) We also posted support@, help@ and contact@ email addresses, but instituted response time limits and would quickly respond to customers that reached out, using our personal email accounts.
Problems Under the Surface
We received amazing feedback early on about our support. People really appreciated the responsiveness of everyone on the team and how they could get direct access to relevant developers. Even though we were getting great feedback, we noticed something that we didn’t like; people wouldn’t email us until they had been trying to troubleshoot an issue on their own for a while.
This brought something to our attention; email is a surprisingly high friction method of communication. Even though email is extremely prevalent, it takes a lot for someone to decide to engage over email. Despite our best efforts to offer exceptional customer service, there were probably customers slipping through the cracks just because they didn’t feel like their problems were big enough to email or call us.
The Search for Lower Friction Communication
As we searched for lower friction methods of communication we settled on web-based chat for prospective and current customers through Olark and Intercom. We thought that providing our users with an on-site and in-app way to connect with us, exactly at the time they ran into a roadblock, would be extremely helpful. Truthfully we saw these channels as a way to augment email and phone support, because not everyone thinks to hit the chat box on a website. These methods helped us in a lot of ways, but we never felt like they did everything we wanted them to.
When Slack came out we tried it within our organization. And right away it reduced our internal email drastically. More importantly was that communication was sped up, was generally more fluid and had far less friction. Questions within our team got answered more quickly and our team was working better together. We soon thought, if what we’re trying to do is make support and customer success frictionless, why not support people through this medium that we’re having such success with internally?
All-In or Nothing
When people talk about Slack or chat applications as a support channel, they typically look at it as an open support forum. I have spoken with some companies that do real-time support in this way. They tend to do this because customers can interact with each other and issues become searchable so that the same questions don’t need to be asked/answered multiple times. This type of channel is also geared toward openness around feature requests and new feature development. If an open forum is created and discussions of feature requests are encouraged, you can start to get a consensus through customer discussions about what features are truly important to the greatest number of users.
As a team we decided to take a different approach, we decided to put our customers into private channels that included relevant users from each of our teams. After 6 months of using slack as a support channel, we still do not have an open forum where customers can communicate with each other, just the private support channels for each client. Our reasoning behind this is that when we were setting up the channels, our primary concern was with the connection to the individual users at our client companies. Our hypothesis was this; people you have developed a relationship with and who have a real-time channel for communication don’t think twice about reaching out with the smallest of issues.
The Value of Open/Direct Communication
The real value of a real-time Slack channel is that it removes most of the friction of communication. Even though we think of email as a non-invasive, simple form of communication, there is still a cognitive load needed to start an email thread. So if a developer runs into even a small issue with our SDK, if the main channel for communication is email, they will need to face a major blockage before engaging. Because real-time channels are lower friction, at any sign of issue, a developer will just throw out a quick message to see if there is something simple they’re missing.
This is great because our real-life experience shows it is generally the case that most problems start small and just need a bit of extra guidance to be solved expediently. And when that’s not the case and it happens to be a bug, this means that we find out sooner and can turn a fix around quicker. In both cases, the real-time channel provides a significantly better experience than email.
Another important value is comfort. Specifically the comfort of knowing that someone is there for you. I think we have all run into a scenario, either as a customer or as the vendor, where a small issue is blown out of proportion because for some reason we can’t achieve what we want to. The friction of email and the fact that most emails are not responded to immediately means that if a customer can’t achieve what they want to, they may become unnecessarily concerned. With real-time support, you can get a solution to them quickly, or just the reassurance that you will solve a problem as soon as possible. This goes a long way toward maintaining confidence and, at the end of the day, a customer’s confidence in your product and service is the most important thing. You lose that and you’ve lost a customer.
The Challenges & Risks of Being Open to Real-time Support
The major concern that keeps most people from using real-time channels for support is that they believe there will be an expectation for immediate response. This is a very real and very valid concern because real-time channels will just amplify your current support structure in a customer’s eyes. If on one hand you are set up and willing to react quickly to support requests in all scenarios, real-time channels will make this clear to your users and will delight them. If on the other hand you are only set up to respond to support requests within 24–48 hours, setting up real-time channels will only amplify a feeling that it takes forever to get a response to a support request.
The other serious challenge is that real-time support requires a greater dedication to process. Because the conversations are ad-hoc and untracked in the traditional support ticketing sense, you need to be prepared to fill the gap with manual processes. At Taplytics we use a combination of Slack, Zendesk and Pivotal Tracker to ensure that all of the right people know what issues are outstanding, what the priorities are, who is responsible for what, and which customers require attention.
Real-time Support is Not for Everyone
This overview should make it apparent that real-time support is not for everyone. You need to have the right processes and resources in place to handle the system at your current scale while accounting for future growth. If you can make it work for you, the rewards are amazing. You get the opportunity to create truly personal relationships with your customers. You get a much better understanding of how your customers use your products day-to-day, what issues they are running into and what is truly important to them.
From our team’s perspective we love providing support this way and are only going to dive deeper. We are looking for ways to get more deeply connected with our customers and create the structure so we can manage these personal real-time connections on a massive scale.
Taplytics is a fully integrated mobile A/B testing, push notification, and analytics platform providing the tools you need to optimize your mobile app.