Charlotte Ward: 0:13
Hello and welcome to episode one hundred and sixty-seven of the Customer Support Leaders Podcast. I'm Charlotte Ward. The theme for this week is Slack support, so stay tuned for five leaders talking about that very topic. I'd like to welcome to the podcast today, Fletcher Richmond. Fletcher, it's lovely to have you join me this week. First things first, would you like to introduce yourself?
Fletcher Richman: 0:42
Yeah, thanks so much for having me. Um so my current role is um leading product for a product line called HALP, which is part of the Atlassian family. We were acquired about six months ago by Atlassian, and um I was previously the CEO of that company. So um now just in charge of all things product related to uh business inside of Atlassian. I recently also uh moved to Austin, Texas. So calling in from there today.
Charlotte Ward: 1:14
Awesome. That's cool. Um so I I feel like you're one of the very people I ought to be speaking to this week about Slack support. Um and I have to admit, this is one support channel that I have never really done in anger. Um like like I think a lot of people, a little bit of accidental Slack support, but not much else. So uh so I'm kind of I'm I'm gonna let you lead this. What maybe maybe we start at the beginning. Where where do we begin with Slack support?
Fletcher Richman: 1:48
Yeah, so I I think you're not alone. Um I know a lot of folks in support who they hear the those two words together, Slack and support, and I think immediately have a kind of a scary allergic reaction, which I think is actually totally reasonable. And um I think there are actually a lot of ways you can do slack support really wrong and really badly. Um, and it can be a nightmare for both sides uh of the equation. Um, but I don't think that's a good reason to just dismiss it outright and and totally say this is not something we're ever, ever going to do, because there are ways to do it well, and there are ways that if you're really thoughtful about it, um, it can be absolutely delightful, I think, actually, for for both sides, uh both the support person and the the customer. Um and that's kind of the business that we're in in the end is delighting customers.
Charlotte Ward: 2:41
So that's quite a promise. Absolutely delightful. I I hope that's where we'll get by the end of this episode is is absolute delight at Slack support. So so yeah, so so sorry, I completely interrupted you then. You I think you were about to tell me where we should all begin.
Fletcher Richman: 2:57
Yeah, so the the two specific things that I think Slack support is really good for, it depends on the the organization size that you're working at. So if you're working at a small startup, really early stage and you're you have early customers, or let's say you're working on a brand new product inside of a bigger company, but generally talking about products that are newer and don't have very many customers. Um so maybe you're the first support person, or maybe you're even just doing support as a part-time job, then uh shared shared channels in Slack. So and there's this is also a thing I'd be very specific about is the way you set it up is is important. Um, what I generally recommend is using Slack now calls this Slack Connect. It's still a relatively new Slack piece of functionality. But what you're doing is actually creating a channel that exists in two completely separate Slack workspaces. So you're taking your channel from that from your instance and you're saying, I want this channel to be available in someone else's Slack instance. So there's no new account. There's no, if if I'm logged into my Slack account and that's where I talk to all my coworkers all the time, I can now join this specific channel and talk to somebody in another organization. So what works great is if you set up these shared channels, one individual channel for each one of your early access or early adopter customers. So call it the first 20 or so roughly customers that you do this for. And what you'll find is that it really just decreases the distance between you and the customer. And so you get really quick feedback loops, they'll tell you what they like or don't like about the product, they'll ask for features, they'll um report really small bugs, really big bugs. They're really just going to build a pretty tight relationship with you, and you can throw your engineers in there and they can talk and quickly debug and fix things as well. So that's one really great um, I think, use case for Slack support. And then the other one is if you're larger and you have a ton of customers, is to specifically offer it as premium support. And I see this really as the evolution of um we instead of having a direct phone line, uh, which is the old way of doing premium support, we're now giving you a direct Slack channel. Um, and so I've seen companies charge more money for this. Um, they're actually making a profit on it because they're charging a lot of additional money for that, that is a support service specifically. Um, and they're um retaining their customers better, they're building good relationships, and the customers are willing and happy to pay for it, especially if you have a product that is a developer-focused product. So if you're selling to developers and engineers, they want to stay inside of Slack. And so um, we tend to see larger enterprise customers that um larger enterprise companies that are B2B do this uh shared Slack channel thing. That's also what I'll say is if you're a B2C company, this doesn't apply. If you're like it's a very specific set, B2B companies selling into other enterprises who are also technology focused and also use Slack. Um, so there's a pretty specific um set of cases where it makes sense. And I think a lot of people use it outside of those contexts, and then you have bad experiences.
Charlotte Ward: 6:03
I I I I love like a couple of things that you said there. And I think first of all, that that distinction you make, this isn't a transient channel, is it? That that kind of you know the the retail type of support does not sit in Slack, you know, no nobody's gonna be returning a pair of shorts in Slack, let's face it. Um but I think what what I really liked particularly about those two use cases was something you said in the first one, which is in that early stage, how it decreases the distance between you and the customer. I thought that was a really interesting way of putting it. And that actually carries through to the second use case you gave as well, doesn't it? When you've got when it's a much more premium channel and you've got these bigger customers, actually, inside these enterprise level organizations, there are teams that you want to actually develop really close bonds with, and it's great for that, right?
Fletcher Richman: 6:58
Right, exactly. And that's you need to have buy-in from the rest of the organization on that concept. Because if the whole org is just thinking, how do we decrease costs and make our support as low touch as possible and have as few tickets as possible, then this isn't for you. But if your organization is customer-centric and wants to build these great relationships with some of your best customers, this is a really good way to do it. Also, one thing I thought of that is also, I think, important in this context is depending on the complexity of tickets, this can be a much nicer way to debug more technical problems because you can share files, you can share code snippets, you can quickly jump on a call. It's it just decreases that back and forth time between responses on the customer side as well. So you're getting these fast responses from customers every time you ask a question instead of the, hey, yeah, can you send me the logs for this thing? Six days later, you get the logs back because that engineer is not checking their email ever. So um it it can actually improve your resolution times on more complex tickets as well.
Charlotte Ward: 8:00
I'm guessing it's quite transparent as well, because I think that particularly if you're if your team is very distributed and you have people based all around the world in a bunch of time zones, it's not obvious if your customer is coming in through email or through a support portal, who's going to be answering the ticket, if somebody's available to answer the ticket at that point. Um and I think that the sense I get from Slack probably is that you you get an immediate sense of who's there, if someone's there, and you get the conversation going really quickly.
Fletcher Richman: 8:36
Yeah, I think that's that's definitely true. It just feels more human too. It's it's you realize you're just two humans talking to each other. You have there's an actual face, and there's you can use emojis and you can you can express yourself, I think, a lot deeper. And that's a lot of where the the connection and the um deeper loyalty and relationship, I think, comes from is the fact that it's just so much more expressive. Uh everything from what you mentioned, just hey, is this person online or not? Well, I'm not gonna bug them if they're not online, to um using emojis, using gifts, using all the fun things that we get to use now in in the workplace, and and doing that um in those conversations feels pretty natural.
Charlotte Ward: 9:15
Operationally, then one thing that I have always felt nervous about is how we track this, how we measure it, how we proceduralize it, if that's a word. You know, from the support support perspective, from my own organization's perspective, how can I support my support folks in supporting customers through Slack?
Fletcher Richman: 9:39
Yeah, so I I would uh get a butt kicking from my marketing people if I didn't plug our our product a little bit at least here. So that is definitely a very good reason why a lot of folks choose to use the help product inside of their shared channels in Slack. Um basically you take any message in Slack, you turn it into a ticket. We can then sync that ticket with either Zendesk or GeoService Desk. Um so if a lot of our shared channel customers, I'd say, are primarily in Zendesk for the rest of their tickets. We don't want to force them to go to another place and have to manage another queue. Um and so you can just kind of easily sync all of those conversations with your existing ticketing system. So great, great reason to check out help. Um, but I think you're right that um that is really important. If we think back to our two use cases, if we're talking about the early access sort of startup, uh one, I think it's maybe a little bit less of a problem. It's it's kind of okay if maybe you're just having a lot of lightweight conversations and the ball gets dropped on a couple of them. But yeah, Slack is just not great for tracking status and following up on things, and there's threads everywhere and conversations happening and who's assigned to what. And so really, even just adding that layer of status assignment and some tracking and being able to go back and both I think for accountability purposes and reporting purposes, that that is really important and something something folks could should be considering. What I'll what I'll say as well is just generically, Slack does have an amazing app store. So there's thousands of apps in the in the Slack App Store. So um, whether it's us or or some other product, um, feel free to check out uh all the stuff in the Slack App Store. And there's lots of great products being built around this concept.
Charlotte Ward: 11:21
So uh yeah, you're right about the trackability and and everything in Slack. It's a great communication tool, but it's not necessarily a an incident management tool or or a conversation management tool in that sense, is it? Um final question I have for you, which is just kind of an extension of like how we help our support folks support people through Slack, is aside from the tooling, are there any tactics? Any is there any advice? Is there a way of doing or being on Slack as a support person, do you think that that just facilitates this whole relationship?
Fletcher Richman: 12:05
Yeah, so a couple of things I'll say. I think one thing we do is we consider this to be, I think you mentioned this, but I would just very much consider this to be its own channel. And so the same way that you're gonna have different response time expectations and SLAs for your chat versus your email channel, I wouldn't just automatically bucket this into chat because it's something a little bit different than chat, than the website chat type concept. This is an intercom, it's a different thing. And so we have different SLAs and different response time expectations for chat versus Slack versus email. Um, so I would make sure that there's alignment there around um creating accountability and metrics for what your expectations are of your support team. One thing we have noticed is sometimes it's so easy to reply in Slack that we are almost a little too trick too quick to the trigger. Um, and there is something to be said about you don't want to create the expectation for your customer that you're gonna always respond within five seconds or 10 seconds or something like that. And so they do need a little bit of time to just um report what the actual problem is. They might solve it themselves, they might have follow-up questions or things. I even find myself sometimes just being like, okay, the thing lit up. I got the pop-up Slack notification. Let's just hold on to it for a little while. Um just take a breath. Exactly. So just making sure it's clear what the expectations are at the same time in Slack. I think there is a moment, uh, if it's over 24 hours, it's kind of feels like you're ignoring somebody. And so there's gonna be a fine balance there of don't respond too quickly, but also don't keep people waiting. Um, and just make sure that you're measuring that stuff and that you're um clear with your customers. The other thing I would say is try to empower your customers to um sort of understand the protocol and context for how to how to report a ticket inside of Slack because different people use Slack in different ways. Are they supposed to use a thread? Are they not? Are they supposed to upload all the attachments there? Do they need to include more information? Like, what are you expecting from your customers when they're reporting something in these in these Slack channels? When do they get the Slack channel? Who should be in it on their side? Um, a lot of these things you can just be pretty clear with your with your customer about what your expectations are, and they don't know there, this is still a relatively new thing. And so they'll be totally willing to sort of follow your lead on that um and say, hey, we we'd like you to have three representatives from your organization in this. Here's the the different people that we expect to be in here. Um when you report an issue, we we try to respond within 30 minutes and we'll thread the issue and it'll be in this thread. And please upload any attachments inside of that thread. Just simple stuff like that, right? You can use like the um you could link to a Google Doc in the description of the channel as an example of a way to do that. Um, so yeah, just be really clear, measure what you're doing, and make sure those expectations line up with your customer.
Charlotte Ward: 15:05
That's it for today. Go to customersupportleaders.com forward slash one six seven for the show notes, and I'll see you next time.
