Lately there’s been a barrage of new services popping up that promise to enable you to communicate with your users and customers from the comfort of a Slack channel.
Sounds great, right?
On the surface, this sounds fantastic, but when you dive a bit deeper, it turns out Slack is not the place you want to be communicating with your users.
Disclaimer – we love Slack
We’re huge fans of Slack here at GoSquared. We jumped on the beta back before we were fully ready to stop using Campfire. Needless to say, we’ve never looked back.
It seems the excitement around Slack’s ecosystem is greater than ever, and there’s no sign of the hype train slowing down.
Slack now have a fund to invest in exciting new integrations and bots for the popular team communication service. Who wouldn’t want a slice of $80m?
But there’s one trend that I’m skeptical about – dealing with customer support conversations through Slack.
Why customer service doesn’t belong in Slack
The messages themselves – queries and feedback from customers – there’s nothing wrong with those getting sent to Slack as a notification to the team. Especially if they’re filtered before hitting Slack so you don’t get junk clogging up your Slack channels.
The problem is in dealing with your incoming support requests – the process of subsequently responding to the questions, comments and feedback from your customers – within Slack.
Slack’s interface just isn’t designed around handling customer interactions. It’s designed to be brilliant for communicating with your team, not your customers.
Slack’s brilliant for communicating with your team of 5, 10, 50 colleagues who you know and have existing relationships with.
- You can quickly see the profile for any one of your team mates by hovering over their name.
- You can have direct messages with any team mate instantly.
- You know they’ll receive the message in the same format you sent it – because both ends of the conversation are happening within Slack.
But for communicating with your customers – hundreds, or thousands of loosely tied connections that you don’t personally know – Slack is not an optimal interface for this task.
Where Slack falls down for talking to customers
Talking to your users should feel natural
There’s a divide between talking to your users and talking to your team. Getting mixed up between the two can be dangerous, and Slack as a tool is purpose built for team communication, so tools that enable you to use Slack to communicate with your users have to treat customer communication as a secondary function.
Can you really have a natural conversation with someone if you have to pre-pend a slash command before every message you write?
You need deep context about your users and customers
Most of the tools that bring your customer service into Slack seem to offer a short Slack snippet of info about the user – things like their device, perhaps their current lifetime value, and maybe the time they were last online.
This info is handy, but it’s just a tiny fraction of the full info you might need to get back to a customer with a personal, helpful, and fast response.
Who is this customer? How long have they been with us? Are they paying us? How much? Are they technical? When were they last online? How long were they online for? What device were they on? What language do they speak? Are they part of a team?
That’s just a few questions you could have about any customer sending a message. If you put all that information into Slack for every time a customer gets in touch, you’re going to be doing a lot of scrolling, and a lot of combing through information presented in a sub-optimal format.
You need to refer back to feedback and conversations at a later date
Having a definitive place for seeing the full conversation history with a customer is only occasionally needed, but when it’s needed it’s damn helpful. If your discussion is spread between Slack and another support tool then it’s challenging to piece the conversation history together.
Ideally, any comments in Slack around a support ticket would be tied to the customer conversation in whatever tool you’re using, so when you look back the messages sent to a customer, you can see the reasons and internal chatter around them in the same place.
You often have multiple conversations with multiple customers happening parallel
When using a single Slack channel for your customer service (#support for example) things can get hectic pretty fast.
Because conversations in Slack are linear, when you have a high volume of support conversations coming in, you very quickly lose track of who and what you’re responding to.
On top of this, when you’re dealing with support conversations as a team, it can be very hard for each of the team to know who’s responding to which customer and which question.
How we handle customer support without replying via Slack
While we haven’t yet found the answers to all these problems, our current workflow involves Slack, Desk.com, People CRM and a lot of love.
New support conversations come into Desk and immediately get fired into our Slack #support channel. This alerts the team, but we then head to Desk to handle the specific query, with the deep context of the customer provided by GoSquared embedded in the Desk agent console.
What does your support process look like? Have you found a way of making Slack replies work for you? It’d be great to hear your success (and horror) stories in the comments.
