WEBVTT
00:00:14.160 --> 00:00:17.199
Hello, welcome to the Customer Support Leaders Podcast.
00:00:17.199 --> 00:00:18.640
I'm Charlotte Ward.
00:00:18.640 --> 00:00:27.440
Today we're listening to one of my favourite episodes from the archives.
00:00:27.440 --> 00:00:37.280
I would like to welcome to the podcast today, April Allen.
00:00:37.280 --> 00:00:40.399
April, it's lovely to have you join me for the first time.
00:00:40.399 --> 00:00:44.880
We're here to talk about knowledge management in support this week.
00:00:44.880 --> 00:00:48.159
But first of all, would you like to introduce yourself?
00:00:48.880 --> 00:00:49.200
Sure.
00:00:49.200 --> 00:00:51.119
Hi, thanks for having me, Charlotte.
00:00:51.119 --> 00:00:55.840
My name's April Allen and I'm a specialist knowledge management consultant.
00:00:55.840 --> 00:00:58.159
I'm a certified KCS trainer.
00:00:58.159 --> 00:01:00.320
KCS is Knowledge Centered Service.
00:01:00.320 --> 00:01:04.400
For anyone who doesn't know about that, it's a bit of a secret weapon out there.
00:01:04.400 --> 00:01:09.760
And I've got my own business called Knowledge Bird, and I've had that for about 10 years.
00:01:10.640 --> 00:01:13.760
10 years, well, that's a lot of time in knowledge management.
00:01:13.760 --> 00:01:17.359
So I have great hopes for the next 10 minutes or so.
00:01:17.359 --> 00:01:20.799
Let's talk about knowledge management in support then.
00:01:20.799 --> 00:01:37.920
And you know, I I last time we spoke, I gently suggested that I might have entirely selfish motives in some of the questions I ask today because uh this is a journey I'm beginning in my current organization.
00:01:37.920 --> 00:01:49.840
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?
00:01:49.840 --> 00:02:00.319
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?
00:02:01.359 --> 00:02:03.680
Yeah, it is the beginning of the story.
00:02:03.680 --> 00:02:20.560
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.
00:02:20.560 --> 00:02:29.439
And uh so coordinating around how we capture and capturing um in particular the customers' words that they use when they describe an issue.
00:02:29.439 --> 00:02:51.759
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.
00:02:51.759 --> 00:02:55.199
So the customer's words are really important, yeah.
00:02:55.199 --> 00:03:05.520
So that's the first thing I tell people is capturing uh the customer context um at the time that they're describing the problem or taking it straight from the ticket they've submitted.
00:03:06.400 --> 00:03:07.680
Yeah, that makes sense.
00:03:07.680 --> 00:03:14.639
Um so so is it entirely for the customer then that we're that we're embarking on this exercise, do you think?
00:03:14.639 --> 00:03:22.319
Because I feel like there are a lot of beneficiaries when it comes to having a really solid knowledge management process in place.
00:03:22.719 --> 00:03:23.599
Yeah, that's right.
00:03:23.599 --> 00:03:25.439
So it's not just for the customer.
00:03:25.439 --> 00:03:32.560
I mean, they're ultimately who we're writing for, because if the customer can find it, then we can find it internally.
00:03:32.560 --> 00:03:49.759
So the best approach is to start internally and we capture the customer's words, uh, we uh write the resolution in in scannable bullet points, we don't need to write a perfectly drafted piece of prose.
00:03:49.759 --> 00:03:51.599
We need to be able to scan it quickly.
00:03:51.599 --> 00:04:09.199
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.
00:04:09.199 --> 00:04:13.919
But in the meantime, what we have is this fantastic um just in time training tool.
00:04:13.919 --> 00:04:24.079
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.
00:04:24.079 --> 00:04:28.560
So we've got this centralized knowledge base of consistent answers.
00:04:28.560 --> 00:04:38.879
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.
00:04:38.879 --> 00:04:43.360
And that means it's uh reliable, trustworthy knowledge.
00:04:43.360 --> 00:04:55.279
I know that something's already being worked on, so it saves me from spending time um reinventing the wheel on it on a solution because somebody's already written the knowledge article because I can see it straight away.
00:04:55.279 --> 00:05:00.000
So there's a lot of benefits time saving, just in time training.
00:05:00.000 --> 00:05:15.839
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.
00:05:16.000 --> 00:05:16.319
Yeah.
00:05:16.319 --> 00:05:28.319
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?
00:05:28.319 --> 00:05:53.360
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.
00:05:53.360 --> 00:05:55.040
That that's quite a significant burden.
00:05:55.040 --> 00:06:02.160
I think like anything you can do to make that training simpler and quicker is just a massively worthwhile investment.
00:06:02.800 --> 00:06:15.120
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.
00:06:15.120 --> 00:06:23.439
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.
00:06:23.439 --> 00:06:44.240
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.
00:06:44.240 --> 00:07:00.399
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.
00:07:00.399 --> 00:07:04.160
Like it's it's super stressful when you when you don't have any anything to look for.
00:07:04.319 --> 00:07:04.639
Yeah.
00:07:04.639 --> 00:07:17.600
I and I really like something that you touched on there, which is that it g it empowers a new um individual contributor.
00:07:17.600 --> 00:07:38.240
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.
00:07:38.240 --> 00:07:48.959
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?
00:07:48.959 --> 00:07:58.959
I think people think although we are framing things for the customer and in the customer language, hopefully, idealistically, um but hope, right?
00:07:58.959 --> 00:08:04.480
But um, but I think also we we just think of that as the as the goal.
00:08:04.480 --> 00:08:09.439
Like we we only ever think about should we have a knowledge base to help our customers?
00:08:09.439 --> 00:08:12.399
Should we have a knowledge base so that we can deflect tickets?
00:08:12.399 --> 00:08:16.319
Should we have a knowledge base so our customers can self-serve more and be more successful?
00:08:16.319 --> 00:08:23.680
However, however, you frame it, most of that conversation around knowledge in its first instance is around the customer, isn't it?
00:08:23.680 --> 00:08:28.720
But it has a huge impact on the on the uh efficacy of your team.
00:08:29.040 --> 00:08:29.920
Yeah, that's right.
00:08:29.920 --> 00:08:50.480
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.
00:08:50.480 --> 00:09:02.480
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.
00:09:02.879 --> 00:09:04.559
Coincidentally, yeah, yeah.
00:09:04.559 --> 00:09:09.120
So do you think that do you think that's the answer then that we should focus first internally?
00:09:10.240 --> 00:09:11.200
Yeah, I think so.
00:09:11.200 --> 00:09:25.840
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.
00:09:25.840 --> 00:09:38.399
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.
00:09:38.399 --> 00:09:48.960
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.
00:09:48.960 --> 00:10:04.879
So, why wouldn't we want to sort of invest, you know, that extra 10, 20, 30 seconds in 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.
00:10:05.200 --> 00:10:06.799
Yeah, yeah, that makes sense.
00:10:06.799 --> 00:10:14.720
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.
00:10:14.720 --> 00:10:19.120
Like I have I have given the customer the answer.
00:10:19.120 --> 00:10:24.399
It might be a you know page-long communication, could be very technically in-depth.
00:10:24.399 --> 00:10:25.039
And what?
00:10:25.039 --> 00:10:26.799
Now I have to go and write an article?
00:10:26.799 --> 00:10:29.679
It doesn't have to be that big a journey, does it?
00:10:30.240 --> 00:10:39.200
No, uh most of most of our platforms these days in help uh help centers allow us to turn out a ticket response into a draft article.
00:10:39.200 --> 00:10:53.039
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.
00:10:53.039 --> 00:10:55.840
Um and that that would be the ultimate goal.
00:10:55.840 --> 00:11:02.480
But the next time that article comes up uh when somebody goes another team member goes searching, they can check it in the moment.
00:11:02.480 --> 00:11:03.679
Is it still right?
00:11:03.679 --> 00:11:05.120
Is there any typos?
00:11:05.120 --> 00:11:11.440
Looks good to me to solve this problem, and then they've kind of validated that that's uh a good enough article.
00:11:12.559 --> 00:11:16.000
Yeah, and good enough is is probably good enough, isn't it, right?
00:11:16.000 --> 00:11:17.120
Uh yeah.
00:11:17.840 --> 00:11:20.080
Definitely with internal internal knowledge.
00:11:20.080 --> 00:11:21.679
Good enough is definitely good enough.
00:11:21.679 --> 00:11:21.919
Yeah.
00:11:22.159 --> 00:11:23.360
Yeah, yeah, that makes sense.
00:11:23.360 --> 00:11:31.279
So so if we're starting internally then, and idealistically we might make these customer-facing at some point.
00:11:31.279 --> 00:11:34.720
If we're starting internally though, when would when should we begin?
00:11:36.240 --> 00:11:42.080
Uh I think um beginning now with what you've got in your ecosystem already.
00:11:42.080 --> 00:11:57.600
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.
00:11:57.600 --> 00:12:03.279
Um if you don't, then you might have to do a little bit of shopping around to see what you can integrate.
00:12:03.279 --> 00:12:06.080
Um but you more than likely will have something.
00:12:06.080 --> 00:12:34.960
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.
00:12:34.960 --> 00:12:39.600
So that's why we've got to preserve that context that the customer's using.
00:12:39.600 --> 00:12:57.360
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.
00:12:59.519 --> 00:13:00.639
Yeah, yeah, yeah.
00:13:00.639 --> 00:13:01.919
Start now.
00:13:01.919 --> 00:13:10.879
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.
00:13:10.879 --> 00:13:41.519
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.
00:13:41.519 --> 00:14:02.720
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?
00:14:03.120 --> 00:14:05.039
Exactly, yeah, that's right.
00:14:05.039 --> 00:14:20.080
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.
00:14:20.080 --> 00:14:25.200
Um so we need to understand how they are experiencing our product from their perspective.
00:14:25.200 --> 00:14:37.200
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.
00:14:37.200 --> 00:14:43.519
Like there may be pervasive issues out there that we don't know about because we're not listening for those words.
00:14:47.679 --> 00:14:48.639
That's it for today.
00:14:48.639 --> 00:14:54.879
Go to customersupportleaders.com forward slash two one one for the show notes, and I'll see you next time.
00:00:14.160 --> 00:00:17.199
Hello, welcome to the Customer Support Leaders Podcast.
00:00:17.199 --> 00:00:18.640
I'm Charlotte Ward.
00:00:18.640 --> 00:00:27.440
Today we're listening to one of my favourite episodes from the archives.
00:00:27.440 --> 00:00:37.280
I would like to welcome to the podcast today, April Allen.
00:00:37.280 --> 00:00:40.399
April, it's lovely to have you join me for the first time.
00:00:40.399 --> 00:00:44.880
We're here to talk about knowledge management in support this week.
00:00:44.880 --> 00:00:48.159
But first of all, would you like to introduce yourself?
00:00:48.880 --> 00:00:49.200
Sure.
00:00:49.200 --> 00:00:51.119
Hi, thanks for having me, Charlotte.
00:00:51.119 --> 00:00:55.840
My name's April Allen and I'm a specialist knowledge management consultant.
00:00:55.840 --> 00:00:58.159
I'm a certified KCS trainer.
00:00:58.159 --> 00:01:00.320
KCS is Knowledge Centered Service.
00:01:00.320 --> 00:01:04.400
For anyone who doesn't know about that, it's a bit of a secret weapon out there.
00:01:04.400 --> 00:01:09.760
And I've got my own business called Knowledge Bird, and I've had that for about 10 years.
00:01:10.640 --> 00:01:13.760
10 years, well, that's a lot of time in knowledge management.
00:01:13.760 --> 00:01:17.359
So I have great hopes for the next 10 minutes or so.
00:01:17.359 --> 00:01:20.799
Let's talk about knowledge management in support then.
00:01:20.799 --> 00:01:37.920
And you know, I I last time we spoke, I gently suggested that I might have entirely selfish motives in some of the questions I ask today because uh this is a journey I'm beginning in my current organization.
00:01:37.920 --> 00:01:49.840
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?
00:01:49.840 --> 00:02:00.319
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?
00:02:01.359 --> 00:02:03.680
Yeah, it is the beginning of the story.
00:02:03.680 --> 00:02:20.560
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.
00:02:20.560 --> 00:02:29.439
And uh so coordinating around how we capture and capturing um in particular the customers' words that they use when they describe an issue.
00:02:29.439 --> 00:02:51.759
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.
00:02:51.759 --> 00:02:55.199
So the customer's words are really important, yeah.
00:02:55.199 --> 00:03:05.520
So that's the first thing I tell people is capturing uh the customer context um at the time that they're describing the problem or taking it straight from the ticket they've submitted.
00:03:06.400 --> 00:03:07.680
Yeah, that makes sense.
00:03:07.680 --> 00:03:14.639
Um so so is it entirely for the customer then that we're that we're embarking on this exercise, do you think?
00:03:14.639 --> 00:03:22.319
Because I feel like there are a lot of beneficiaries when it comes to having a really solid knowledge management process in place.
00:03:22.719 --> 00:03:23.599
Yeah, that's right.
00:03:23.599 --> 00:03:25.439
So it's not just for the customer.
00:03:25.439 --> 00:03:32.560
I mean, they're ultimately who we're writing for, because if the customer can find it, then we can find it internally.
00:03:32.560 --> 00:03:49.759
So the best approach is to start internally and we capture the customer's words, uh, we uh write the resolution in in scannable bullet points, we don't need to write a perfectly drafted piece of prose.
00:03:49.759 --> 00:03:51.599
We need to be able to scan it quickly.
00:03:51.599 --> 00:04:09.199
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.
00:04:09.199 --> 00:04:13.919
But in the meantime, what we have is this fantastic um just in time training tool.
00:04:13.919 --> 00:04:24.079
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.
00:04:24.079 --> 00:04:28.560
So we've got this centralized knowledge base of consistent answers.
00:04:28.560 --> 00:04:38.879
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.
00:04:38.879 --> 00:04:43.360
And that means it's uh reliable, trustworthy knowledge.
00:04:43.360 --> 00:04:55.279
I know that something's already being worked on, so it saves me from spending time um reinventing the wheel on it on a solution because somebody's already written the knowledge article because I can see it straight away.
00:04:55.279 --> 00:05:00.000
So there's a lot of benefits time saving, just in time training.
00:05:00.000 --> 00:05:15.839
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.
00:05:16.000 --> 00:05:16.319
Yeah.
00:05:16.319 --> 00:05:28.319
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?
00:05:28.319 --> 00:05:53.360
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.
00:05:53.360 --> 00:05:55.040
That that's quite a significant burden.
00:05:55.040 --> 00:06:02.160
I think like anything you can do to make that training simpler and quicker is just a massively worthwhile investment.
00:06:02.800 --> 00:06:15.120
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.
00:06:15.120 --> 00:06:23.439
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.
00:06:23.439 --> 00:06:44.240
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.
00:06:44.240 --> 00:07:00.399
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.
00:07:00.399 --> 00:07:04.160
Like it's it's super stressful when you when you don't have any anything to look for.
00:07:04.319 --> 00:07:04.639
Yeah.
00:07:04.639 --> 00:07:17.600
I and I really like something that you touched on there, which is that it g it empowers a new um individual contributor.
00:07:17.600 --> 00:07:38.240
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.
00:07:38.240 --> 00:07:48.959
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?
00:07:48.959 --> 00:07:58.959
I think people think although we are framing things for the customer and in the customer language, hopefully, idealistically, um but hope, right?
00:07:58.959 --> 00:08:04.480
But um, but I think also we we just think of that as the as the goal.
00:08:04.480 --> 00:08:09.439
Like we we only ever think about should we have a knowledge base to help our customers?
00:08:09.439 --> 00:08:12.399
Should we have a knowledge base so that we can deflect tickets?
00:08:12.399 --> 00:08:16.319
Should we have a knowledge base so our customers can self-serve more and be more successful?
00:08:16.319 --> 00:08:23.680
However, however, you frame it, most of that conversation around knowledge in its first instance is around the customer, isn't it?
00:08:23.680 --> 00:08:28.720
But it has a huge impact on the on the uh efficacy of your team.
00:08:29.040 --> 00:08:29.920
Yeah, that's right.
00:08:29.920 --> 00:08:50.480
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.
00:08:50.480 --> 00:09:02.480
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.
00:09:02.879 --> 00:09:04.559
Coincidentally, yeah, yeah.
00:09:04.559 --> 00:09:09.120
So do you think that do you think that's the answer then that we should focus first internally?
00:09:10.240 --> 00:09:11.200
Yeah, I think so.
00:09:11.200 --> 00:09:25.840
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.
00:09:25.840 --> 00:09:38.399
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.
00:09:38.399 --> 00:09:48.960
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.
00:09:48.960 --> 00:10:04.879
So, why wouldn't we want to sort of invest, you know, that extra 10, 20, 30 seconds in 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.
00:10:05.200 --> 00:10:06.799
Yeah, yeah, that makes sense.
00:10:06.799 --> 00:10:14.720
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.
00:10:14.720 --> 00:10:19.120
Like I have I have given the customer the answer.
00:10:19.120 --> 00:10:24.399
It might be a you know page-long communication, could be very technically in-depth.
00:10:24.399 --> 00:10:25.039
And what?
00:10:25.039 --> 00:10:26.799
Now I have to go and write an article?
00:10:26.799 --> 00:10:29.679
It doesn't have to be that big a journey, does it?
00:10:30.240 --> 00:10:39.200
No, uh most of most of our platforms these days in help uh help centers allow us to turn out a ticket response into a draft article.
00:10:39.200 --> 00:10:53.039
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.
00:10:53.039 --> 00:10:55.840
Um and that that would be the ultimate goal.
00:10:55.840 --> 00:11:02.480
But the next time that article comes up uh when somebody goes another team member goes searching, they can check it in the moment.
00:11:02.480 --> 00:11:03.679
Is it still right?
00:11:03.679 --> 00:11:05.120
Is there any typos?
00:11:05.120 --> 00:11:11.440
Looks good to me to solve this problem, and then they've kind of validated that that's uh a good enough article.
00:11:12.559 --> 00:11:16.000
Yeah, and good enough is is probably good enough, isn't it, right?
00:11:16.000 --> 00:11:17.120
Uh yeah.
00:11:17.840 --> 00:11:20.080
Definitely with internal internal knowledge.
00:11:20.080 --> 00:11:21.679
Good enough is definitely good enough.
00:11:21.679 --> 00:11:21.919
Yeah.
00:11:22.159 --> 00:11:23.360
Yeah, yeah, that makes sense.
00:11:23.360 --> 00:11:31.279
So so if we're starting internally then, and idealistically we might make these customer-facing at some point.
00:11:31.279 --> 00:11:34.720
If we're starting internally though, when would when should we begin?
00:11:36.240 --> 00:11:42.080
Uh I think um beginning now with what you've got in your ecosystem already.
00:11:42.080 --> 00:11:57.600
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.
00:11:57.600 --> 00:12:03.279
Um if you don't, then you might have to do a little bit of shopping around to see what you can integrate.
00:12:03.279 --> 00:12:06.080
Um but you more than likely will have something.
00:12:06.080 --> 00:12:34.960
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.
00:12:34.960 --> 00:12:39.600
So that's why we've got to preserve that context that the customer's using.
00:12:39.600 --> 00:12:57.360
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.
00:12:59.519 --> 00:13:00.639
Yeah, yeah, yeah.
00:13:00.639 --> 00:13:01.919
Start now.
00:13:01.919 --> 00:13:10.879
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.
00:13:10.879 --> 00:13:41.519
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.
00:13:41.519 --> 00:14:02.720
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?
00:14:03.120 --> 00:14:05.039
Exactly, yeah, that's right.
00:14:05.039 --> 00:14:20.080
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.
00:14:20.080 --> 00:14:25.200
Um so we need to understand how they are experiencing our product from their perspective.
00:14:25.200 --> 00:14:37.200
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.
00:14:37.200 --> 00:14:43.519
Like there may be pervasive issues out there that we don't know about because we're not listening for those words.
00:14:47.679 --> 00:14:48.639
That's it for today.
00:14:48.639 --> 00:14:54.879
Go to customersupportleaders.com forward slash two one one for the show notes, and I'll see you next time.
