168: Slack Support with Sean Tanos

Charlotte Ward: 0:13

Hello and welcome to episode 168 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 would like to welcome to the podcast today, Sean Tanos. Sean, it's lovely to have you join me for the first time, even though I feel like I've known you for ages because you shared your leadership story with me a long time ago, and we've inhabited some of the same Slack groups and so on for quite a significant amount of time as well. And we've crossed a lot of paths, but we've never spoken live. So here we are. Welcome. Welcome to the podcast.

Sean Tanos: 0:57

Great to be here.

Charlotte Ward: 0:58

Thank you. Would you like to introduce yourself for our listeners?

Sean Tanos: 1:01

Yeah, sure. My name is Sean Tanos. I work for a company called Kindred. We are a uh kind of a unique company in that we provide robots as a service. I think we're one of the few people in the marketplace that actually does so. Uh so we have uh robots in e-commerce facilities across uh the US, and we're going into Canada next year and potentially the UK and Europe in a few years down the road. Uh and yeah, we put robots in the facility, and then we do all of the support and all of the maintenance of those robots uh so that the customer can completely forget about them other than the bill at the end of the month or the for the use of it itself. And depending on the customer, that's either a uh monthly fee or a per item fee based on whatever sales had done that day.

Charlotte Ward: 1:52

That's awesome. So robots, um, and I gather that you use Slack to provide support not to humans. Is that right?

Sean Tanos: 2:06

Exactly, to the robots. So we have a system set up where either the person on site or the robot itself can actually alert us to uh an issue with the robot. And because we're not dealing with customers, we can do all of our support actually over Slack. So uh either a ticket gets generated, like I said, by our uh monitoring systems. There's monitors on every single part of the robot. So anything that goes wrong we're we're notified on or the on-site sees something, or uh as we also have pilots in the in the field, so someone watching over the robot may also see something, and then we'll open up a support ticket. That support ticket is then translated over to a thread and slack where we then work. So just kind of a view, we have two teams that support the robots. We have a team that sits uh remotely, uh, we call them product support team, uh, and then we have a team that sits um live in the field as well, and we call them our on-site premise managers. So we work the support teams work together via Slack to kind of solve any issues. So uh for example, well, let's say one very common thing is a gripper. So the robot itself has a hand at the end, so oftentimes that'll break off. So we'll get a notice, hey, the gripper's broken. So we then flag the on-site at blah, hey, FYI gripper on machine is broken, and then we'll chat back and forth with them until either the issue's resolved or uh we need to page up the next level. And because it's all done in Slack, when we page up the next level, they just join the Slack conversation, it just becomes part of that ongoing thread.

Charlotte Ward: 3:51

Yeah, that that's really easy, then isn't it? So so yeah, so you use threads to maintain that context. Um and your initial conversation is usually with the robot, and then you can transfer to a human or at least loop a human in at some point.

Sean Tanos: 4:07

Try to loop the human in, exactly. Yeah, so some things we can actually uh resolve without ever having uh someone on site actually touch the robot. We can just use some software support behind the scenes, reboot system A or reboot system B. But oftentimes we do need that person on site to wrench something for us or move something for us, or you know, glass gets broken, things get scratched, cameras get moved, so all of that. And then, you know, we get into a place sometimes where you know we're dealing with a complicated robot, the issue gets beyond what the on-site or the uh remote tech can do, and then we'll page in engineering. And like I said, the nice thing about that is engineering just joins the thread. They're then able to read back and say, oh, okay, this is what we've done so far, this is the point we're at. Again, because we're we're dealing remote, we can get them to take pictures and send those pictures over Slack. So then the you know, we'll take a picture of the robot or the electronic box, and the engineer will take that picture, circle some things on it, draw some arrows on it, send it back, and really get that communication back and forth to get that robot online. So we see common threads 10, 15, but we've seen Slack threads go up to 400, 500 deep uh conversation, lines deep conversation.

Charlotte Ward: 5:30

Wow, wow, scary times, scary times for me. Um so I'm super curious. I mean, this sounds like a really efficient way of doing things because you can have everything in a single place, you don't have to go out to some command line to do stuff, come back, have a conversation with a human in a different in a different tool or a different forum or whatever. Um given all that efficiency, how do you what what what's what's the tooling look like from a point of view like in terms of how how you manage things like metrics and accountability and all of those things that every other support team might talk about? How how do you manage all of that through Slack?

Sean Tanos: 6:14

So the nice thing is again, because it's on Slack, the engineers like to go back through some of the threads. If they see a thread that's three or four hundred lines deep and they don't see any engineers tagged on it, uh they have a tendency, just their own curiosity kind of takes them over. So from that point, it always allows us to improve because the engineers are always willing to provide feedback and say, hey, I saw last night, uh, just FYI. It took you guys three hours to resolve a problem. We're glad that you were able to resolve it yourselves. But just FYI, if you had done this at step two, you would have been done 15 minutes into the problem. So that's that's great. Uh, in terms of tracking the metrics, we still use a pretty standard ticketing system. We use Fresh Desk actually for all of our tickets. So all of the responses are still handled within Fresh Desk. So when the robot fires us off an alert, hey, I'm broken, uh, the person that responds or receives that communication then responds to the robot saying, okay, no problem. So then we can track how long it takes before we start. And then uh again, we track how long it takes for the ticket to close. So when we try to maintain a, you know, that's our SLA. It's how many, you know, it's the percentage of first response, the percentage of of resolution time within the the right thing, and then how long each of those are, which is it. And yeah, and then when we close the ticket, we create kind of a template, what like a basic what was done, and then we link the Slack thread. So if we ever need to go back, we can go back and see that history of everything that was done. So there's no, you know, when you do a you know, conversations over the phone, you lose, you know, what steps were done, what steps were taken. So it's never a question of what we've done. The engineers, we always know exactly what has been done and what hasn't. So we can always go back later as we refine our processes and say, hey, you know, we could have done better here. And and that's a lot of what we do is refine those processes to get better.

Charlotte Ward: 8:10

Yeah, that makes sense. It makes it really self-documenting, doesn't it? You don't have to rely on on humans to kind of come back and and have good memory and and uh yeah, yeah, yeah.

Sean Tanos: 8:21

That's that's and then if we do anything unsafe, the engineering team is right there to to be like, no, no, don't don't open that, or you know, don't go in there or stay away from that part of the robot and keep us away as well.

Charlotte Ward: 8:35

Yeah, yeah. Um now I know engineering teams. I know I know they like to do clever stuff. They sure do. What's the cleverest thing that you have um uh as part of this whole process in Slack? What's the cleverest part of the process or or tool that you've implemented? I I imagine they've been in there tweaking stuff.

Sean Tanos: 8:54

Yeah, it's it's really the alerting system that we use. I we use Datadog for our alerting system. So Datadog is constantly monitoring every single bit of that robot. So the minute something goes wrong, that's the clever bit, is we're basically the robot can tell us it's sick before we even see any other signs. It'll be like, hey, you know, air pressure's too low right now. And you know, to see that in the field, you would never see it, but there's the robot to alert you. So I think that's really the the cleverest trick that we have right now. But we're looking at always looking at more that we can do to automate the process, being an automation company ourselves. The the more you can rely on the robots to do the robotic work, and the more you can rely on people to do the creative and puzzle solving, I think, you know, you keep put best best for best, I guess.

Charlotte Ward: 9:44

Yeah, yeah, absolutely. You don't want uh you don't want to put your engineers in a position where they are effectively responding like robots, they're just doing all the things that yeah, yeah, that any any any uh any other part of the system can do for you.

Sean Tanos: 10:00

So uh that that's definitely recovery in that. Yeah, so exactly what we can what we can do. And you know, we're always looking to improve. And though I think right now Slack is is the best tool. I don't know, you know, what down the what down the road looks like. You know, you say it's efficient today, but maybe after this podcast I'll get someone reach out to me and say, hey, I got a better way to do this. And I'm always looking for that for the next row, next step to to make everything more efficient.

Charlotte Ward: 10:30

Yeah, yeah, I hear you, I hear you. I think that um even though I'm not an engineer myself, I do come from that tech background, and I'm constantly looking at what the next tool or what the next evolution of a process might be, how we can improve the way we use something we've already got, or what the next thing is. It's uh it's really key because in a very, very heavily engineered environment, um, every second can count, can't it? I mean, um and we're not just talking SLAs.

Sean Tanos: 10:59

And you know, I've come from a lot of cyclical businesses where, you know, in this space, e-commerce obviously November, December is is your mad period, and and the rest of the year is really prep for that. And I, you know, I see that kind of thing where, you know, if we're doing a million transactions as an example, if I can shape one second, even just one second off of those transactions throughout the day and throughout time, you know, you save how many headcount overall, and and you're able to keep the support team a lot happier because they're not doing that day-to-day boring routine. Yes, we know that your password needs to be reset. This is what your new password is. It's you know, trying to keep it so that the people involved are doing the puzzle and the the robot does does the rest for you.

Charlotte Ward: 11:48

Yeah. Every time we save a click, it's a moment of joy, isn't it?

Sean Tanos: 11:52

Yeah, exactly.

Charlotte Ward: 11:54

Yeah.

Sean Tanos: 11:55

And I I come from a from a long customer service background, so I know the you know, the more we can take away the the routine troll, the the more engaged people are. And I like to think the more engaged you are, the better overall you're gonna work.

Charlotte Ward: 12:14

That's it for today. Go to customer supportleaders.com forward slash one six eight for the show notes, and I'll see you next time.