113: Support Scope with Craig Stoss

Charlotte Ward 0:13
Hello, and welcome to Episode 113 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, just to I almost thought you’re 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 think I think the line comes later. Right? I feel like initially, especially in smaller companies, support scope is is significant. And I think support should expand their scope at every opportunity. So you know, the bread and butter of courses a ticket in ticket out and, and, but I mean, you know, 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, without necessarily a human being directly there on the other side, and then maybe voice of customer programmes, you know, getting feedback from customers. cset surveys and NPS surveys probably should be within support initially so that you can start to feed that information and Kool Aid information within a single tool or or feed that feed very specific feedback into the different teams. You know, if you get information about implementation going wrong, feed that into the implementation team or, or product, you know, feed back into the product team. You know, I think this could also include, you know, interesting tools like data and analytics tools that sit especially in the SaaS world, I think that this is something popular where you can use the data from a 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 use it to provide a better level of service. And all of those things may eventually leave support and be headed 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:55
huh? Yeah. The the thing that you said there about analytics struck a chord with me as well, because I think that, particularly if 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, 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 and 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 programmes or whatever. I think that a lot of that still sits significantly within support. Right.

Craig Stoss 3:50
Yeah, I mean, absolutely. Right. I, you know, if you think about a small company, starting out maybe the the CEO or the first developer has some support for or the company and then eventually, the role gets too big for them. So they have to hire someone who can be dedicated. And I look at the same way, you know, handing off these individual tools, right? You know, for example, I’m a big believer that the knowledge base should live within knowledge management programme should live within support. And the reason for that is support is ideally set up to contribute the most information to the knowledge base. Does every rep do that, again, maybe initially, and then eventually it gets a segment a team, like a technical writer team that lives in support to do that content. But But data is the same thing, right? If you’re going to 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 and be able to take actionable but take action on it and do something that is going to drive more value and so Yeah, 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, maybe voice of customer feedback, gets its own group somewhere else in the organisation, 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, were you happy with the level of service that you received? 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, you know, I think I feel like there’s a cornerstone here. 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 it I think it typically happens based the same way, as they said that the founder of the company starts to do support that eventually can. You know, same with the founder of the company, probably right signs every paycheck individually, and then, you know, eventually hires a person and financed and buys a tool that does it for you. Or, you know, I think that’s true. And support is your first few support reps, maybe the caseload is lower and you need added, you know, added engagement. And there are other tools, the other things again, and go back to knowledge base being a classic example of that, that they can do. As that scales, maybe, for example, in the knowledge base is going to encompass new product features 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 That, you know, the tone of the knowledge base doesn’t change and that the search ability 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. And I think that’s just an evolution as things scale. So that’s probably the biggest one, but, but beyond that, I feel like that 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 posts post sale, as I said.

Charlotte Ward 7:44
Yeah, and I think the final part of this then is, is that everything that we just talked about in in terms of the efforts that primarily go with scaling to move these activities out to other teams to other parts of the organisation is the 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/113 for the show notes, and I’ll see you next time.