228: Fireside with Craig Stoss

Charlotte Ward: 0:13

Hello and welcome to episode two hundred and twenty-eight of the Customer Support Leaders Podcast. I'm Charlotte Ward. Today, please welcome Craig Stoss for a fireside chat. I'd like to welcome back to the podcast today, Craig Stoss. Craig, it is so lovely to have you back after so long.

Craig Stoss: 0:41

It's been a long time.

Charlotte Ward: 0:42

It really has. But what on earth happened?

Craig Stoss: 0:52

I I don't know. I I feel like the weather got nice and and we were allowed to be a little bit freer than we have been in the past year and a half, and everyone just took advantage of it.

Charlotte Ward: 1:03

Yeah, that's probably a fair summary. Too much advantage was taken and uh and now I'm paying the price.

Craig Stoss: 1:09

Exactly, exactly. Catching up before before the break.

Charlotte Ward: 1:13

Exactly, exactly. But you know, it nonetheless, it's lovely to have an opportunity to catch up with you. And um I just I'm I'm looking forward to what we're gonna talk about today because I asked you asked you to bring your own topic and you did. I knew you would come up with something really interesting.

Craig Stoss: 1:32

Yeah.

Charlotte Ward: 1:33

Um, do you want to tell everybody what we're gonna talk about?

Craig Stoss: 1:36

Yeah, absolutely. I I I think a big trend that I'm seeing, and I I feel like COVID has something to do with this, to be quite honest. People are demanding you know, better services. And and and some of those are are you know more online services, um, you know, less having to do things like you know, maybe keep receipts if you're a retail brick and mortar store. Everything is going to be accessible, and and a lot of that, in my opinion, is driven by data. And so, so the topic I love to chat about today is where I see um how how how I see support using data and how to get the right data to support so that they can meet some of these new expectations that uh the customers have.

Charlotte Ward: 2:24

Yeah, super interesting. I um I work for a company that's all about data in my day job. So uh I have thought long and hard about this, particularly in the last year and a half. Um and and and there is, I think, a real um there's a real gap in understanding, I think, between what is often like what people's perception is on a surface level of what a support team needs and can make use of in terms of data in the day-to-day when they're on the phone or on the emails to customers. The gap in in understanding is between that and I think what support teams really could use and do need and could like extract value from day-to-day. And to me, that gap seems a chasm. I mean, I it just seems huge. Um what are the what are the sort of things in terms of data that spring to mind when you think about because I think typically, you know, uh externally other business functions would say, well, you need the customer contact details, you need, you know, a couple of bits and pieces about maybe their their tier, maybe if you're lucky, their contract values, things like that. What else do you need? But but but what do you really think we can make use of?

Craig Stoss: 3:50

Well, I think I think there's there's two parts to it, right? I think there's the part of um contextual data about a situation, right? And and with new machine learning and AI algorithms, uh, I mean, that could mean anything. That could mean what were the last five things a person did with your your SAS product, you know, and and and pull that out of your system and put it right into your your ticket management tool. Um, that could be uh when was the last time this this person called and and what was the last CSAT result this customer gave so I know you know how to treat them. Uh an interesting use case that I I saw recently was um a customer wanted to treat the first X number of interactions. Uh sorry, a vendor wanted to treat the first number of interactions with a customer differently than other interactions. And the idea being that give the person really good support, convince them you're a great organization, and and and give them that extra little bump in their inside their first you know, X number of interactions, and and and then you know they'll be super happy and they'll stay with you and they become a bit more sticky. And then maybe the other interactions are still good, but maybe not as as good. And so there's context there is what's the number of interactions this customer has had with us, or how or how soon, how long ago did the customer sign up? Um, so there's things that you can give to support. Um, I met with a company recently that had a really interesting solution where they presented um back-end data to support to either view or edit. And and this is common in my opinion. This is common in a lot of SaaS companies where think of the support use case where something comes in and you realize, oh, there's something um was you know misconfigured or or corrupted or or something is wrong in the backend database. And what do you do? You have to escalate to an engineer to fix that. Um you know, this product surfaced that to support, it's surfaced in a readable way. It's not just raw database data. It's it's surfaced by the engineering team with different queries and and how they want to present it. And then there's permission sets that supporters allowed to view this to understand what went wrong, or they're allowed to correct it if you trust to support to correct it. Um what and I think again, what a great way to to offload um some work that engineering probably doesn't want to do, and all it does is cause customer response delays. So to me, that's that's the first set of data is that you can get to support, which is which is just anything contextual about the customer and the interaction itself. And the second set is around the automation world where, you know, um, let's say you have a chat bot and and someone you know uh uh tries to come in and say, hey, this is what I want to do. And um, you know, maybe I'll think of a use case uh refunds, you know, like like Uber. So Uber, you you know, they probably get tens of thousands of refund requests uh in a in a day or a week. And but the thing is, do you need a person to look at every one of those refunds, or can your automation pull out the data that makes sense? Like, oh, you've taken five recent trips, which one would you like a refund for? Why do you want a refund? Here's the cost of that trip. Is this acceptable to refund this? You know, or do you or you have a further complaint? Do you want further compensation? And and all of that's handled automatically. Uh, and and and then uh using the data so it's all contextual, it's all the user's data, and they can say, yep, this is acceptable. And maybe there's someone on the back end reviewing that, or maybe there's red flags that if someone refunds five trips in a row or something like that. But the data is is propelling support and and saving you your support reps actual time. And so I think those are the two types of data that you can give to a support team to enable a better customer interaction.

Charlotte Ward: 7:43

Yeah, yeah. The second the second one I think is is really clear and obvious to me uh as a um the the only way you can enable effectively ticket deflection, which is what you're talking about. And I hate the term, but we have to live with it. We it is a thing, right? When you talk about saving your support team time, you're basically talking about preventing needless interactions. And and I think that, you know, so long as that isn't detrimental to the customer experience and actually in many ways can enhance it because you can speed things up for your customers as well, then there's nothing wrong with ticket deflection in that sense if it's it if it's frictionless for both parties and reducing needless work for both parties. So so I think like the the interesting thing about ticket deflection is you can't do it and you can't if you can't measure it, and because you can't justify the investment in any ticket deflection activity without measurement and without that data to show the the differences you're making and and to drive those kind of decisions that you were you were talking about before. The the first um the first set that you talked about, that sort of contextual information getting serviced to your support team is a really interesting one because I think that sort of enablement is is um the I think it's a big a big driver um in our support team's ability to contribute to revenue. And I think that um I think that some of the things you talked about there, like saving an engineering team's time, val validating data, using it to improve the interaction, to improve the customer experience, to reduce churn, all of like it can like that enabling your support team with the right data where they are when they're talking to customers in that exactly relate to that context is and can I think almost always be directly um influential on revenue or or at least reduced costs. But very probably I suspect if you draw a uh a targeted enough line can actually contribute to revenue, would you say?

Craig Stoss: 10:06

Yeah, I mean, absolutely, right? I think that uh the sky's the limit when it comes to this, right? It's it's every every product will be different, hardware will be different than software, then then you know, then retail, then whatever it is, and and the data is all very important. Uh, I mean, I I remember um I ordered a product once uh from a from a retail store and it got delivered to me. It was uh ordered online and it was I forget whether it was the wrong size, but I had to return it. And I went uh the the website clearly says return to any store. And I thought, okay, well, that's easier than than getting a package and dropping it off at a at a FedEx booth. So I I went to the store and they said, Well, you know, where's your receipt? And I and I said, Well, okay, I pulled up the email and I showed them the email and they're like, Well, that's not your receipt. There was a risk, you know, there's a receipt in the box that came with your product. Why would I ever save that? Right. I mean, yeah, you sent me an email, you know, you know I bought this. I mean, I'm sure you could search some number that that that has, you know, a unique identifier within your system to find it. And I think that that's the type of thing that that needs to go away, right? You you you need to and and and it's gonna help me buy again because if you make this process seamless, then that drives your revenue at this this particular retail store. Um so there's tons of these little things that that the data exists and you just have to identify the areas that you want to focus on. And if if your focus is on driving revenue, there's tons of places where you can find those little savings. Um, I love uh, you know, there's also areas where you can find you know upsell opportunities. You know, maybe there's ticket, you know, the customer's asking a question to do with some feature that that's part of a bigger package. Well, you don't want support selling it, but you know, through some machine learning or or some, you know, some factor that's pulled in, maybe they're due for renewal and this conversation is already open. And if you pull that in from your customer success management tool, you can see that and and the support has more context and can say, hey, you know, so CSM, I just had this conversation with a with a customer. I think if you're already in renewal conversations, there might be an add-on here, you know. And but in empower, I the word you use enablement. I think enabling your team is exactly what this is. And and if you choose to focus on revenue enablement, uh it's it's there. It's just you need to take it.

Charlotte Ward: 12:38

Yeah, absolutely right. I think um I think that um interactions with support teams are are really interesting and very, very different from interactions with sales or marketing or even customer success. I I think that generally speaking, customers trust support teams more than they trust most other business functions because they come to you with a problem and you're there to solve the problem. And I I think that um this like enablement, this kind of getting away from the generic and providing like deeply personalized support, I I think really um it increases that level of trust. And I I think actually that um it it helps it's more than an illusion because it is actual understanding of your customers. It's not an illusion of understanding, but but the but that um projection of understanding that you give your customers when they contact you, if you have all of that data to hand, if you understand what their needs are, um builds that trust. And I think that um what you said crucially, like it is that it allows you to respond to them. It's a it's a much better customer experience, but it also allows you to validate predictions, doesn't it? You can you can begin to try and predict what a customer's needs are, and when you have the data in there in the moment in the in the support contact, you can validate that prediction and proactively solve for them and then you know use that to drive potential upsell activities within the organization or within your support team, right? And I think that's all like that that's that direct line to revenue for me.

Craig Stoss: 14:27

Yeah, and I would say the uh the proactive bit of that is probably even an extension of what we're talking about. I think that's you know, you can do, hey, they've called me, here's a bunch of information that's contextual to this customer. And then the proactive bit is now that we start getting more and more of an idea of of the patterns when people call us, um, you know, we can start to prevent that. We can pop up, you know, knowledge base articles in real time, we can um we can write better, you know, knowledge articles, we can, we can, you know, change the product so that this this kind of error case doesn't occur. We can whatever it might be, you know. I I we're using a new HR system uh at my company and and I someone missed a time card punch in, and and so I had to go in and correct it. And I kept getting this random error saying, you know, there's an empty time punch, but there was it didn't refer to what day, it didn't refer to to where. I I mean I'm approving you know 10 people and and and uh um and and you know two weeks worth of of time cards, and all it's saying is there's an empty one somewhere. It's like, well, I mean, come on, your your error message must needs to be bigger, uh better than that, right? I mean, it needs to point me to at least a person or a day where I can focus on it. And and and so, you know, there that's data, right? And the data exists, they know why they know there's an empty one because they've told they they found it and and and they've given me the error in the first place. So that's not really a support one, that's more of a product, but the point being that they could have prevented me needing to to do something, more expend more effort. Um they you know, maybe I need to call support to figure this out because I don't know where to look, and you know, I'm not gonna search through you know a thousand different records of information. Um it's it's uh I think that's why starting with the data you have is really important so that you can get to this proactive nature in the future because uh you it's almost invisible, right? The proactive stuff to me is the invisible bit that people they're not gonna they're they're not gonna demand it. People are gonna demand, I want a quick and easy way to get a refund, I want to have a good experience, I want you, I don't want you to ask me to confirm the last things, the five things I did because you know the last thing, five things I did. They're not gonna demand, please stop me from getting an error about a missing time punch, you know. Because they, you know what I mean? It's it's it's a thing where if you fix that somehow through some sort of proactive nature, um people are gonna love it because it removes effort, but they're not gonna, they're not demanding it. But the first part I think is where customers are actually asking the questions of you.

Charlotte Ward: 17:06

Yeah, yeah, I hear you. I I and I think that um I think you're right, that proactive step, that next step is invisible. Um, but it just it it relies and and it relies on the early part of that journey, right? It relies on getting the data into your teams, but you can only do the next step if you make that data a loop. That data does doesn't that data, and this is what you touched on at the start, isn't just a push, like you actually have agency to affect it, either directly through like correction or adjustment or whatever, but but also um, you know, it affects your behaviors and therefore affects the support that customer receives. And so it then drives further actions inside the business, I guess is what I'm saying. So I think it needs to develop a sort of looping behavior somehow.

Craig Stoss: 17:59

Well, and it's it's funny you use the word loop because uh there's a company called The Loops that I that I'm um that I've done some work with, and uh they do stuff like that. They they pull in the context from your your logging tools, your back-end systems, your internal systems, your database, and they they pull in um what they call a loop. And uh the idea is that they have all this context, and some of it may not even be for support, some of it may be for development. And the reason is is that if I now need to escalate this ticket to a developer, to an engineer um in the software world, um, all of that context comes with the ticket. And and so the developer can look at it and be and be like, oh, well, this logging line, I know exactly what that means. You know, they did this thing wrong or or whatever it is, and they can answer their stuff. So you're actually providing enablement to development to have to not have to manually do a bunch of steps. Um it I think this all comes down to the data is there today. Every system now, like you know, I I I made a comment the other day to my wife. I I I hit the snooze button on my phone. My phone is my alarm clock, and I hit the snooze button. I never hit the snooze button, but I had did sleep well that night. I just needed some more time, and I hit the the the snooze. And I and I thought to myself afterwards, you know, does does you know I have an Android phone? Does do Google now know that I hit the snooze button? Like, does did that you know and and and oh they do, you know that they well that's just it. And are they measuring and then they're like, oh, well, Craig must be tired. What does that mean for the rest of the way I function today? And what should I should I advertise him something different? You know, maybe I have a two coffee. Um, you know, and and and that the the world has harnessed that and almost accepted that that's can be done in Facebook and Google ads and and all these different things that they can harness data and give us contextual things back for their for their sales and marketing purposes. I'm just saying apply those same concepts to Support, right? Because the data's there.

Charlotte Ward: 20:04

I that's that's the uh most insightful like parallel I've heard when it comes to like all that investment. We said this at the top of the of this conversation, all that investment that goes into sales and marketing activities, and yet we don't invest the same, like data in sales and marketing activities, and yet we don't invest the same in data in support activities when support interactions are your most trusted interactions from a customer point of view. Um, which brings us full circle. And I think that that if we had that investment, then that is that loop that you begin to generate is when your support team is no longer that underinformed, like operational silo, right? They're really at the heart of the customer journey.

Craig Stoss: 20:52

Yeah. And and I think that the way to do this, so so you know, we we talked about how to get it to support. And I think the way to do that is is to start involving support in some of these conversations. I um, you know, one of the if you're an agile, um, you know, you use scrum methodologies in in your development shops, um, there's a concept of the definition of done. And it's it's a really uh it was neat, it's a neat way of thinking about when is something done? Because we all know that software, especially, is never done. Um, so so when is something ready for release? Like what is the minimum viable thing that we should release? And and I think if you involve support in those conversations before you start writing the code for a feature or or whatever it might be, you're you're gonna start thinking of these things because oh, do you see how this feature works? Well, support can say, well, listen, in order to support that feature, we need to understand you know how these widgets uh are set whenever there's an error, or you know, we need a special error message to be thrown, you know, so that we know what widget to look at or whatever it is. But that should become part of the definition of done, uh, as opposed to the definition of done being very feature-based, like all the widgets exist, and then support gets a tech question that maybe they've never been trained on, and all of a sudden it's like I don't even know what what I'm looking at here, because as you said, support is typically is the last to be informed of a lot of these things. And so, yeah, uh, I think that's one way to do it, is just involve support sooner so that these these areas where data is collected and not used can be exposed sooner in the process. And and there's all sorts of tools today that uh that embed right within a Zen desk or a Salesforce that can expose this data directly without the support agent having to swap tools. And and that's that's gonna be a huge win.

Charlotte Ward: 22:47

Yeah, absolutely. Getting the data right where they need it, um at their fingertips. That's what I that's what that's what I try and uh that's the message I try and get across in these conversations when I when I think about um what my team needs. Like they need it at their fingertips, and that's in the tool they're in. Make it easy for them. Thank you so much, Craig. Thank you. That was super interesting. Uh one of the things I'm very passionate about. Let's um come back another time. I could talk for another 20 minutes about the definition of done.

Craig Stoss: 23:24

Absolutely.

Charlotte Ward: 23:25

I really could.

Craig Stoss: 23:27

We've just invented another three or four podcasts worth of conversation here.

Charlotte Ward: 23:30

So it's I uh uh always, always. It's always interesting. Um and yeah, I um I I do mean it. Come back. Let's talk about the definition of done um and running work streams in support. And um I yeah, I'm sure I will think of three or four other things at least from this conversation.

Craig Stoss: 23:49

So yeah, absolutely.

Charlotte Ward: 23:51

Thanks for joining me. It's been an absolute pleasure to see you again after so long. Come back soon.

Craig Stoss: 23:55

Will do. Thank you so much for having me.

Charlotte Ward: 24:01

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