211: Knowledge Management with Aprill Allen

Charlotte Ward: 0:13

Hello and welcome to episode 211 of the Customer Support Leaders Podcast. I'm Charlotte Ward. The theme for this week is knowledge management, so stay tuned for five leaders talking about that very topic. I would like to welcome to the podcast today, April Allen. April, it's lovely to have you join me for the first time. We're here to talk about knowledge management in support this week. But first of all, would you like to introduce yourself?

Aprill Allen: 0:49

Sure. Hi, thanks for having me, Charlotte. My name's April Allen, and I'm a specialist knowledge management consultant. I'm a certified KCS trainer. KCS is Knowledge Centered Service. For anyone who doesn't know about that, it's a bit of a secret weapon out there. And I've got my own business called Knowledge Bird, and I've had that for about 10 years.

Charlotte Ward: 1:10

10 years, well, that's a lot of time in knowledge management. So I have great hopes for the next 10 minutes or so. Let's talk about knowledge management in support then. And um, you know, I I last time we spoke, I gently suggested that I might have entirely selfish motives in in some of the questions I ask today, because uh this is a journey I'm beginning in my current organization. Um and I and I think that I think that there um are lots of good reasons for wanting to take a more formal approach to knowledge, aren't there? And and I know what my reasons are, but but I I feel like um just kind of getting that knowledge out of people's heads and into a central location is only the beginning of the story, isn't it?

Aprill Allen: 2:01

Yeah, it is the beginning of the story. There is to get the the biggest bang for buck in terms of you know, whatever expense, actual expense, but also the time we put into knowledge, um there's a a lot more activities that if we coordinate around properly, we can see a lot of benefits. And uh so coordinating around how we capture and capturing um in particular the customers' words that they use when they describe an issue. So whenever we write knowledge articles in advance, and like we all sort of anticipate frequently asked questions, and what often happens is that those questions don't actually get asked or they get asked in a different way, and so the customer is using different words to um uh search for, and they don't find the answer that you've lovingly put a lot of time and effort into creating. So the customer's words are really important, yeah. So so that's the first thing I tell people is capturing uh the customer context at the time that they're describing the problem or taking it straight from the ticket they've submitted.

Charlotte Ward: 3:06

Yeah, that makes sense. Um so so is it entirely for the customer then that we're that we're embarking on this exercise, do you think? Because I feel like there are a lot of beneficiaries when it comes to having a really solid knowledge management process in place.

Aprill Allen: 3:22

Yeah, that's right. So it's not just for the customer. I mean, they're ultimately who we're writing for, because if the customer can find it, then we can find it internally. So um the best approach is to start internally and we capture the customer's words, uh, we write the resolution in in scannable bullet points, we don't need to write a perfectly drafted piece of prose. We need to be able to scan it quickly. Uh, and if we can find knowledge in the moment of solving a problem, um at a certain point in time, when we're more often finding uh knowledge to reuse than creating new knowledge because it didn't exist before, that's a great time to turn on self-service. But in the meantime, what we have is this fantastic um just-in-time training tool. And if we get new hires coming on, which you know, in support, we have new hires coming on a fair bit, and often other geographies like we're handing over to other geographies. So we've got this centralized knowledge base of consistent answers. Every time they get reused, um, the person using it in the moment is responsible for how accurate it is, so they're reviewing it at the time of reuse. And that means it's uh reliable, trustworthy knowledge. I know that something's already being worked on, so it saves me from spending time um reinventing the wheel on a solution because somebody's already written the knowledge article because I can see it straight away. So there's a lot of benefits time saving, just in time training. Um, people, new people into um a support team can be confident and productive in their role a lot quicker when you've got a uh centralized knowledge base that's um owned by the team and maintained in that workflow. Yeah.

Charlotte Ward: 5:17

I love that idea of just-in-time training because I think particularly in smaller organizations, taking on a new hire has a really big impact on a small team, doesn't it? And and the amount of support that your team has to provide potentially to onboarding a new agent or engineer or whatever, it's a big drain on them as a collective, as a group of people, just just helping that person into the role, understanding obviously all the operational side, but then the thing that they actually have to support in the longer term as well. That that's quite a significant burden. I think like anything you can do to make that training simpler and quicker is just a massively worthwhile investment.

Aprill Allen: 6:03

Yeah, and that when somebody new starts, often we do uh like a pairing sort of situation, like a buddy, someone else in the team, and they're kind of become responsible as the go-to person for the new hire. And um, that is still a really valuable thing because that's the only way you can transmit sort of the cultural norms of the team and the organization. So you do still need to have that sort of thing, but but the uh the knowledge base um really takes the uh the stress off somebody when they get something uh that's new to them, and um you know, maybe some maybe there's a customer that's got a really urgent issue or there's a major incident, and you know, it's kind of stressful. And if you don't have that centralized um go-to place for things that have come up before, um, or uh you might have a new issue, but you find an answer that gives you a clue about what might solve that, um, there's the chance of burnout's really high. Like it's it's super stressful when you when you don't have any anything to look for. Yeah.

Charlotte Ward: 7:06

I and I really like something that you touched on there, which is that it g it empowers a new um individual contributor. Uh it to it gives them uh the ability to self-drive much much quicker, but also um in a more impactful way for the team, but also like really personally take their own onboarding in hand and and accelerate it much quicker than than relying on anyone else. And I think actually maybe maybe that's a thing that's kind of lost in a lot of conversations in organizations around should we have a knowledge base? I think people think although we are framing things for the customer and in the customer language, hopefully, idealistically, um can but hope, right? But um, but I think also we we just think of that as the as the goal. Like we we only ever think about should we have a knowledge base to help our customers, should we have a knowledge base so that we can deflect tickets? Should we have a knowledge base so our customers can self-serve more and be more successful? However, however, you frame it, most of that conversation around knowledge in its first instance is around the customer, isn't it? But it has a huge impact on the on the uh efficacy of your team.

Aprill Allen: 8:29

Yeah, that's right. And that's what attracted me to knowledge management as a specialization was the benefit to the team because you know I've been that person under stress, and it's and I've ended up taking stewardship um individually of the knowledge base, and um, because I know what it feels like to be able to um uh find an answer in in in an urgent moment of need. So um, yeah, I I I love being able to support support through uh better knowledge flow, and uh that's always my goal, even though the customer does end up benefiting down the line anyway.

Charlotte Ward: 9:03

Coincidentally, yeah, yeah. So do you think that do you think that's the answer then that we should focus first internally?

Aprill Allen: 9:10

Yeah, I think so. And and the re I think the most people say no to the I or they're hesitant to start a knowledge base because they they think that it's going to cost a lot in resources of technical writing and all of that, but you don't need technical writers for support documentation. You know, support answers are very often timely, like um they're created in the moment of need and then they're reused often within 30 days, and then we may not see them again. But they may be one of those high-value um knowledge base articles that that solves uh the question for lots of agents and lots of customers over time. So, why wouldn't we want to sort of invest, you know, that extra 10, 20, 30 seconds in turning this response I gave this one customer into an article that can be reused by the rest of my team and me next time that same question comes up.

Charlotte Ward: 10:05

Yeah, yeah, that makes sense. And uh I like the idea that it takes 30 seconds because I think it always feels such a big, as you as you said before, such a big task. Like I have I have given the customer the answer. It might be a you know page-long communication, could be very technically in-depth. And what now I have to go and write an article? It doesn't have to be that big a journey, does it?

Aprill Allen: 10:30

No, uh and most of most of our platforms these days in help uh help centers allow us to turn our ticket response into a draft article. So if we can do that with a click of a button, um, take out like genericise it, take out the customer specific bits and pieces, then you've already got an article that's pretty close to publishing to self-service if you wanted to do that. Um, and that that would be the ultimate goal. But the next time that article comes up uh when somebody goes another team member goes searching, they can check it in the moment. Is it still right? Is there any typos? Looks good to me to solve this problem, and then they've kind of validated that that's uh a good enough article.

Charlotte Ward: 11:12

Yeah, and good enough is is probably good enough, isn't it, right? Uh yeah.

Aprill Allen: 11:18

Definitely with internal internal knowledge, good enough is definitely good enough, yeah.

Charlotte Ward: 11:22

Yeah, yeah, that makes sense. So if we're starting internally then, and idealistically, we might make these customer-facing at some point. If we're starting internally though, when would when should we begin?

Aprill Allen: 11:36

Uh I think um beginning now with what you've got in your ecosystem already. So if you've got um a platform that you're responding to customers with, which you're likely to have if you're listening to this podcast, um, have a look at whether you have a knowledge-based functionality that's attached to your platform already. Um if you don't, then you might have to do a little bit of shopping around to see what you can integrate. Um, but you more than likely will have something. And uh if you do, that's that's when I would uh that's what I would use to start um building a culture around capturing the customer's words, um, not just so the customer can ultimately find it in self-service, but so that we can find it, because we can also search with the customer's words and any automation that's happening, any um automation in the background where answers might be suggested, it's going to suggest answers based on the words that were in the ticket. So that's why we've got to preserve that context that the customer's using. Um, so capturing those customer words, um centralizing it in that knowledge base uh that we have attached to our help desk and building a team um sense of ownership of of its health, of the the health of the knowledge article, yeah.

Charlotte Ward: 12:59

Yeah, yeah, yeah. Start now. And uh yeah, I I really like I really like this idea of just consistently using the customer's words for all the reasons you just said as well. And I think I'd possibly also layer one more on, and I'm sure this has occurred to you before, but but one that occurs to me in the moment as I as you're prompting lots of thoughts, is um that also continuing the customer's words through every communication ensures that we don't switch out of that customer context, like even though we might be having internal discussions and not like knowledge transfers, training sessions, whatever within the team. Even if we're stepping away from the knowledge side, actually just persisting that the customer's way of talking about something means you don't ever lose that connection with the customer, and also makes it like a really easy journey back once that agent or engineer has got the knowledge, it makes it a really easy journey back for them to talk to the customer again, doesn't it?

Aprill Allen: 14:03

Exactly, yeah, that's right. And you know, we we get stuck as technical folks um using our own internal sort of uh ways of describing things and and but we're building an environment that uh our customers are experiencing. Um so we need to understand how they are experiencing our product from their perspective. So unless unless we sort of shift the way that we um understand our the way our product is out there, it's really hard to be able to meet the customers' needs. Like there may be pervasive issues out there that we don't know about because we're not listening for those words.

Charlotte Ward: 14:47

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