113: Support Scope with Craig Stoss

Charlotte Ward: 0:13

Hello and welcome to episode one hundred and thirteen of the Customer Support Leaders Podcast. I'm Charlotte Ward. The theme for this week is the scope of support. So stay tuned for five leaders talking about that very topic. I'd like to welcome back to the podcast today, Craig Stoss. Craig, it's lovely to have you back. And we're here to talk about the scope of support.

Craig Stoss: 0:43

Yeah, thanks for having me, Charlotte.

Charlotte Ward: 0:46

So, so uh just to I I almost thought you were going to go with it then, but I will actually ask you a question. So when it comes to thinking about what a support team should or shouldn't be doing, do you think there's a line we should draw? And when when should we draw that line? I mean, I guess the I guess the first part of this question is where does it all begin?

Craig Stoss: 1:11

Yeah, I I think I I think the line comes later, right? I I I feel like initially, especially in smaller companies, uh support scope is is significant. And I think support should expand their scope at every opportunity. So um, you know, the bread and butter, of course, is ticket in, ticket out, and and but I mean, you know, uh start a knowledge base. I mean, that that initially should be a support remit, you know, making sure you're providing value to your customers uh without necessarily a human being directly there on the other side. Um, and then maybe uh voice of customer programs, you know, getting feedback from customers, uh, CSAT surveys and NPS surveys probably should be within support initially so that you can start to feed that information and collate the information within a single tool or or uh feed that uh feed very specific feedback into the different teams. Like, you know, if you get uh information about an implementation going wrong, feed that into the implementation team or or uh product you know feedback into the product team. You know, uh I think this could also include um, you know, interesting tools like data and analytics tools that that sit, especially in the SaaS world. I think that this is something popular where you can use the data from a uh analytics tool to understand how how customers are using your product and be able to make better support decisions on that, you know, be able to gather more interesting support data and and and use it to provide a better level of service. And all of those things may eventually leave support and be handed off into other segments of the company. But initially, I think support has to be the driver as the main customer-facing team post-sale.

Charlotte Ward: 2:56

Yeah. The the thing that you said there about analytics struck accordingly as well, because I think that particularly of that, but probably true of almost everything else you alluded to as a as the kind of activity that support can get involved in early on, is that so many of these things sit within support because even if eventually they do get segmented away, um, they they should still remain a two-way street. So they can quite happily live in support early on, can't they? And I think everything you were saying there about all of the kind of data that we have available to us in support, particularly can live in support for a pretty long time. And in fact, probably support should remain the driver, even if you do ultimately get a data analytics team or other teams who are responding to that data to run different programs or whatever. I think that a lot of that still sits significantly within support, right?

Craig Stoss: 3:50

Yeah, I I mean, absolutely, right. I, you know, if you think about a small company, you know, starting out maybe the the CEO or the first developer does some support for the company, and then eventually the role gets too big for them, so they have to hire someone who can be dedicated. I look at the same way, you know, handing off these individual tools, right? Um, you know, for example, I'm a big believer that the knowledge base should live within um knowledge management programs, should live within support. And and the reason for that is uh support is ideally set up to contribute the most information to the knowledge base. Um, does every rep do that again, maybe initially, and then eventually it gets um uh a segmented team, like a technical writer team that lives in support to do that content. Um, but but data is the same thing, right? If if you're going to um be able to interpret data and you're the people that talk to the customers most frequently, then then you have the most context to understand what that data means and be able to take actionable um uh take action on it and do something that is going to drive more value. So yeah, I I just I feel like that's that's important. And and as you segment out, the goal would be to build those bridges. So, okay, maybe uh maybe voice of customer feedback gets its own group somewhere else in the organization, maybe under a marketing team, for example, to be able to control the branding of that of that feedback form. But ultimately you're getting feedback on things like support. You're getting feedback on things that support is doing, you know, did were you happy with the level of service that you received? Um, were you happy with the product? And if not, what were the technical limitations? Support again is set up ideally to to look at that. So I you know, I I think I feel like there's a cornerstone here uh that that should always exist to your point.

Charlotte Ward: 5:51

Yeah, yeah. Do you think that that segmenting happens by virtue of simply we can no longer resource that activity within support, or do you think there are other factors at play?

Craig Stoss: 6:07

Um it's probably a combination of things, right? I think I think it typically happens based the same way as I said, the the founder of the company starts to do support and then eventually can't. Um, you know, same with the founder of the company, probably right signs every paycheck individually, and then you know, eventually hires a person in finance and buys a tool that does it for you. Um, or you know, I I think that's true in support is um your first few support reps, maybe the caseload is lower and you need added um, you know, added engagement, and and there are other tools, the other things. Again, I go back to knowledge base being a classic example that that they can do. Um as that scales, maybe, for example, the knowledge base is going to encompass new product features uh and and things that aren't directly related to support. So maybe the product team starts contributing to that. Well, now you have to have shared ownership in order to make sure that you know the tone of the knowledge base doesn't change and that um the searchability is maintained, the tags are maintained. And so so maybe there has to be a team for the knowledge base that sits somewhere in the company but works directly with product and with support. Um, and I think that's just an evolution as things scale. So that's probably the biggest one. But but beyond that, I I feel like that there the way to separate these things out is to still maintain that core central idea that all of this stuff still is customer-facing and support is usually one of, if not the most customer-facing team post post-sale, as I said.

Charlotte Ward: 7:44

Yeah, uh and I think the final part of this then is that everything that we just talked about, uh, in in terms of the efforts that primarily go with scaling to move these activities out to other teams, to other parts of the organization, is that the focus becomes different. As you said before, the focus becomes different in that you have to concentrate on building those bridges and making those processes work and making the communications work. That's it for today. Go to customersupportleaders.com forward slash one one three for the show notes, and I'll see you next time.