215: Knowledge Management with Craig Stoss

Charlotte Ward: 0:13

Hello and welcome to episode 215 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'd like to welcome back to the podcast today, Craig Stoss. Craig, lovely to have you back. This week, we are talking about the hot topic in my life right now. And so I'm very excited to talk about it with you, who I know has some strong feelings and a lot of experience in this area as well. And we've just been having a chuckle, it's true. Um knowledge management, knowledge management in support. So it's a it's a challenge, isn't it? And it's so necessary.

Craig Stoss: 1:03

I think, I think that's exactly it. It's it's necessary. And to try to sell the concept, it just seems such a no-brainer. I mean, I don't have the metrics off the top of my head, but I mean, there's metrics everywhere that say people want to self-service. I mean, as a consumer, think about any the last time you had a problem with any product, be it software, hardware, the first thing you do is, oh, my, my blender engine will run. Is there a quick fix for it? Or my monitor won't turn on. How do I, you know, how do I fix it? Or everything. The first thing you do is search for it. And it's just an instinct now that we grew up in the the age of the internet, the age of the searchable internet. And I I don't know why it takes so long to sell some people on this concept, but that's what your customers want. And and and the numbers are staggering. I've seen metrics uh from articles that I've written that range from 70 to 90 percent of people are demanding self-service. And the simplest way to do that is knowledge management. So necessary to me is the the key word.

Charlotte Ward: 2:04

Yeah, and and I think you know, there's so many perspectives on it, and so many metrics, as you just like we could we could literally spend the next 10 minutes just bouncing around metrics. I'll I'll get I'll give you some actually that are um perhaps slightly controversially less customer focused. Because I happen to have some right here. Who knew? Right here now. Um 50 to 60, these are all I should say from the KCS, the Knowledge Center Support Practices Guide. Um, 50 to 60 percent improved time to resolution. How's that? Boom. Harvey resolution time.

Craig Stoss: 2:39

Uh this one's always one that that is interesting to me when people talk about improved resolution time. I I don't know how you improve the resolution time of something that shouldn't even come to you in the first place, right? So, you know, there's kind of two concepts of knowledge management in general. Like, I mean, there's tons of them, but there's two that I kind of focus on. There's helping your agents answer questions fast. That's there's products like Guru, for example, that are really good at embedding themselves directly inside your your uh your ticket management tool. And the ticket comes in, it does some smart things, and it says, here's how to answer the ticket. Um, and then there's the outward-facing things, the more traditional help desks, you know, you see with with Zendesk has one built in and FreshWorks and all the ticket managers tools seem these days to have their own knowledge management system that are public, customer facing, and and meant to just stop the ticket from even coming to you. Um, so when I hear a metric like that, I I think, okay, well, that's great. And and and so reducing time is an awesome metric, and we all want to make sure that we're solving our customers' fat tickets faster, but but they still had to contact you. And so is that what is that okay in your business? Um and that's the thing that I think about when I hear that metric.

Charlotte Ward: 3:54

I I think that metric probably, you know, simple metrics like that. TTR is is such a a face value metric. You look at what comes in and how quickly on average you resolved it. And I think that my reading between the lines on that improved time to resolution through a decent knowledge management practice is is that it it takes all of those things you just talked about into account. Those are all factors in that reduced TTR, I think. I think it's customers are contacting you less, so you have probably um, you know, some portion of tickets taken away. So that's work taken away, which is going to affect for the in one direction or other your TTR. Um, secondly, I don't think there is such a clear division between internal and external knowledge in the sense of I I get what you're saying about like they're surfaced in different ways, but I think it's the same knowledge. Obviously, your internal knowledge is going to be greater, but but I think that improved TTR is also in surfacing the knowledge to your agents in the moment, allowing them to respond quicker. But it's also uh definitely in just frankly reducing the workhorse nature of having to type out every single response every time, right?

unknown: 5:16

Yeah.

Craig Stoss: 5:17

Yeah, it it definitely cuts out in the the custom messaging and and the the you know accidental swapping of two steps or something, you know, when when you have a reviewed and and uh validated article available. Um you know it's it's it also very much depends on the type of support you do, right? And you know, I would argue um for true technical support when you're doing like log analysis or code analysis or things like that, um, your TTR might r might actually go up uh when you have a knowledge base. Because if you have a knowledge management system that that handles you know whatever the repeatable questions are in your world, so password changes or you know how to how to accomplish certain use cases, and you get rid of all of the easy stuff, all of the quick, you know, five second I know these off by heart answers, all that's left is those more deeply technical problems. And so, therefore, on average, your TTR might actually go up because you're trying to you know resolve a ticket that is fundamentally harder to solve. And so um, you know, I think your your point about the same knowledge is is is also roughly how people use it, but I don't think that's how it's intended in some cases, right? There are tools that I think are intended to be internal guidance for your agents, like these are the things, you know, when something of this topic comes in, these are the things uh to be conscious of. These are maybe the questions to ask, these are the you know, these are the do's and don'ts, or these are the available options to you. And it and that's stuff that you probably wouldn't present as a list of if A, then B, then C, or maybe D, or you wouldn't present that to a public facing. Now they're they're used interchangeable changeably all the time. Um, so I don't know, it's it's an interesting thing about how you use knowledge. Um, I'm a big fan of the knowledge being identical with maybe some internal notes that say, like, here are the do's and don'ts and things to be conscious of. But when you're reading the same script as a customer and they have a problem, you can you can actually see eye to eye what with what they're reading as opposed to having like an internal version and an external version.

Charlotte Ward: 7:26

Yeah, yeah.

Craig Stoss: 7:27

Yeah. You know, internal people just need more context, maybe.

Charlotte Ward: 7:32

Yeah, I I think I think I think the internal um layer is that it it's it's stuff that helps your team interpret at greater depth what you present to a customer, right? Or and maybe enables them to take actions that the customer doesn't have any ability to take either, you know, particularly in deeply technical support. So there's definitely a layer of knowledge that's internal only. And of course, let's not forget you can house things in a knowledge base that aren't just customer or product knowledge, you can house your operational knowledge and everything else in there as well. So there's always a component, I think, of internal knowledge, right?

Craig Stoss: 8:11

And I would absolutely encourage that, right? I mean, having multiple systems that store different types of knowledge is just you're gonna have duplicate knowledge, you're gonna have differing knowledge, you're gonna have one team using one set of data or one set of information, another team using a different set of information. A single source of truth is is vital, or at least something that that overhangs them all, and you search on a global basis, like some tools exist that do that and aggregate your information. But yeah, uh a single source of truth is so so vital. Um you know, it's we're dealing, I'm dealing with that right now in my work in the sense that uh there is uh people there are people that are storing common answers kind of in a Google Doc on their on their desktop you know in their own environment, and they're just copy and pasting their responses. Well, then the problem is using that as opposed to either an external knowledge base or a built-in macro, which is a type of knowledge, you know, uh causes a disconnect because if that knowledge changes and your your personal macro, the thing you've you've stored yourself doesn't change, then you're sending outdated information to a to a customer. And so um, you know, we don't want that fractured knowledge inside any environment.

Charlotte Ward: 9:23

Yeah, for sure. And and you know, you said a really interesting thing there that you know a macro is knowledge. I and I think that just to broaden that, um processes are knowledge, operations are knowledge, documentation is knowledge, knowledge-based articles are knowledge. What's in your people's ever notes or OneNotes or heads is knowledge, isn't it? Or confluence or JIRA or any of these places. So so I guess knowledge management under that, um like when you think of that sphere, it's a huge thing. Um and I guess you just have to start somewhere, but but I guess one thing that I I've always always been conscious of as well is thinking about knowledge as two things. It's all of those things, and yet in all also in a support environment, it's quite specifically often we're just talking about the knowledge base, aren't we? What's what's what in your mind is, for instance, is there even a distinction between a knowledge base and either all of those knowledge pieces or a knowledge base and maybe documentation, for instance?

Craig Stoss: 10:27

It's um that's a that's a really good question because I just actually was look reading about this the other day. So um my my gut is that the storage of knowledge, whatever that that portal or or software, whatever it is you use to do that, is the same. So so I think that the tool should be the same. But the types of knowledge are different, right? There's there's kind of uh I and I forget the exact names of these, but there's there's like knowledge that's just factual, you know, the system does X, you know, roses are red, you know, those types of things that you know that they're they're very factual. Um then there are things, there's a type of knowledge that is the combination of those factual things into knowledge that is something that's that's learned or studied or solving a use case. Um, and then there's then there's like this experience knowledge of taking the the the middle pit of knowledge and taking that experience and and using that to the best of the ability, fine-tuning it, making it your own. Um the the analogy I use is that you know, the factual knowledge is knowing what an apple is, what cinnamon is, what sugar is, you know, intrinsic knowledge is knowing that you can combine those to make some you know a nice pie. And then experiential knowledge is knowing the exact amounts of all of those things, you know, that that make your family drool and request more, right? And um, and and the thing that that's really important there is um the factual knowledge bit is how I think docs used to be written, right? You know, you remember back in the day you used to get a cell phone and you used to open the box and right at the top was a was a huge thick manual, and it would say this button that you know, this button does this, and this button does that, and this button does the third thing. Um, you know, we don't have that anymore because I think it's become very commonplace and the and the technology has become more intuitive. But now we're focused on the use case knowledge, right? We want to know, I want to solve this business problem or this personal problem, and I wanted something to tell me how to do that. And so the articles are now laid out in such a way, or they should be laid out in such a way where it's like, here's you know, how do you solve use case X? Here's the the you know, here's how to solve use case X using these five pieces of factual knowledge, and here's links to like those descriptions, but you don't you don't need to know the you're not gonna read it the other way around. You're not gonna read those five factual knowledges and be like, ah, I know how to do use case X. It's it's not it doesn't work the other way.

Charlotte Ward: 12:51

Yeah, yeah.

Craig Stoss: 12:51

And then the experience comes, you know, it's very personal again, very, very, uh, very custom for each you each individual or business. And so that's something that's incredibly hard to document. That's your white papers and your and things like that that are you know a bit more in depth or your consultative uh practices. That but again, more knowledge. So I I like to live in that middle bit. And and to your to your original question, sorry, I keep interrupting you, um, but the to your middle bit there, or to your original question, it's like that middle bit, if you take that and you make that as part of your central knowledge base, that helps everyone, that helps support, that helps your customers.

Charlotte Ward: 13:28

I think I think I'm with you. I I think I think what you're referring to is the that pyramid, isn't it? That um D-I-K-W, the data, information, knowledge, and wisdom. Wisdom being that like the pin pinnacle of like applied knowledge, like this is how I take everything that I've learned and can apply it to this specific situation. But I think I think you're right. I think the the middle bit somewhere is where we mostly inhabit. And um I I think that that is ripe for like evolution as well, isn't it? It's a very living place to be. It's not just signals, it's it's like constantly evolving at a micro level, what this means all the time, which is really how our customers approach our products, as you said now.

Craig Stoss: 14:18

And and the thing is the other thing that I I it's interesting to me, and technology is starting to advance to allow it, is Google is actually a really good example of this. Their knowledge base will figure out who you're logged in as, if assuming you use G Suite services in your company, and will actually present you different information based on who you are. And I I remember doing this just at a previous company where I went to a Google Doc because something wasn't working, or sorry, Google Knowledge Base because something wasn't working, and it said right at the top, you know, uh Craig Stoss, you you don't have the available permission to do this thing. So here's the article. But just know that if you want to do this, you have to contact someone with this permission. And I was like, that's powerful, right? Presenting the context so the user knows. Like, I mean, how many times have you done that? Read an article for something online, go to do it. It's like, oh, click the profile button. You're like, there is no profile button. Now you have to figure out why there's no profile button. But if you just say, hey, Charlotte, you're not going to see the profile button because your permissions don't allow you to see it. Well, now your your your next issue avoidance is kicked in, which again is another type of knowledge that we could talk about.

Charlotte Ward: 15:23

Right, yeah. And and I mean, maybe even more powerfully, you don't have that, but here's the premium service.

Craig Stoss: 15:28

Yeah, yeah. We'll sell it to you. We'll sell we'll sell it to you. Always be selling, right?

Charlotte Ward: 15:34

Yeah, absolutely, absolutely. And I I think like this for me is the the final bit of um the value of knowledge, like just thinking about the value of knowledge, um, not just in that improved customer experience, it is the value to the business, isn't it? It's it's getting to know your customers more, it's understanding because we can draw analytics from it in the same way we can draw analytics from all of our tickets. You know, what are customers searching for? How are they interacting with our knowledge? What are they really using? Um, and that's probably that's probably as informative as what they are typing out in the help center field, just you know, problem description to you, right?

Craig Stoss: 16:15

Yeah. You you need to learn about your audience, right? And and so I again, this one I use car maintenance because that's something that I'm completely awful at. And I go into a mechanics shop and I don't say, you know, the this the head gasket of my engine needs to be replaced, right? I go into my mechanics shop and I say there's a rattly noise in my engine, you know, or you know, that's how because that's all I know how to describe it. And so if you're running a knowledge base system for or or a knowledge porter for a mechanic shop, you know, the title of the article or the keywords of that article shouldn't be, you know, um, you know, my my head gasket needs replacement, what do I do? It should be like my engine has a rattling noise, and then here's a bunch of things to check to determine what what specific thing you want, right? And and you know, is that how your customers talk? What's the I was worked at a company where some of our terms are very overloaded. The word project could mean one of many different things. Um, and depending on your industry, you might not even call it a project, you might call it a program. And and so, how do you keyword your knowledge base to make sure that your users uh are getting the the value that you want within the words that they would expect to get it? And that that is I mean, that's the holy grail of of things like natural language processing is can you make enough smart connections to to to um to bring all that right information to the to the customer? And so, yeah, to me, it's customer voice, it's it's the the value is in providing the information in the customer's voice. That's a KCS principle. Uh, you mentioned that earlier. And it's to me, it's one of the most fundamental ones, and using analytics and data to do that is is super important.

Charlotte Ward: 17:59

Yeah, yeah. Um, exactly that. So you serve surfacing knowledge in terms of the customer is searching for that knowledge. Um, and that is never going to be the way that anyone writes their documentation. And I think that's why the knowledge base, as I would kind of compartmentalize that support-created knowledge, is is really it's it builds fast because your your agents, your engineers, talk to your customers in the voice. The customers want to talk, you to talk to them all the time. So they're not crafting this from a blank page ready for you know to create section 1.4.7.2 of the documentation, the how to, you know, the full like you know, config settings list for this bit of the product. But but it is a case of, you know, let me tell you what we can do about that rattly sound. And yeah, yeah.

Craig Stoss: 19:06

It it's um it's just so it's it and that it goes back to our original point. Like convincing people to do knowledge should be the easy part. Doing the knowledge should be the hard part. And honestly, I find it the exact opposite in most companies. And and you know, the convincing it takes forever to get the budget to buy a tool, you know. Well, who's gonna do it and how are we gonna pay it? And what's the headcount increase to do to do this exercise? How do you uh how do you uh, you know, I was talking to someone recently who had to do this in three languages because they're cut their company sold to three different and it was like, well, how do we add, you know, what's the overhead of that? And and you solve all the you know, you talk forever on those projects when, like you said, your your agents do this every day, they just don't put it into a system, they put it into an email or they put it into a Google Doc, or they put they write it on a notepad or a whiteboard. They your team is already doing this, you're just not capturing it and you're wasting effort. It's it's it's um.

Charlotte Ward: 20:00

it's such a silly thing that that that we reverse the the difficulties of these these two things like it's i and i don't i don't know the resistance i don't understand the resistance i've never been able to figure that piece out yeah if you want to if you figure it out let me know and we'll we'll write a book on it and be get rich oh please please let's just let's just silo away how we did that and no i i think like the buy-in is really hard particularly if you're in an environment where it's not been done before or you know the the surrounding organization doesn't come from a place of like what seems to us to be obvious because we've been in this business a long time and we've done it and we've done it and we've done it and and I think that um I think that you know the final thing that I would say you know you talk there about getting money for tools and everything else and I I would frankly say if you've got a help center you've got it haven't you I mean if you've got a Zen Desk or a Help Scout or a whatever you've got the beginnings like all of these tools have a basic kind of ability to hold knowledge and surface it to your customers and I think for me frankly it's just a matter of getting going because um I I I just think like a lot of things I've found in support um they have a long lead time to value and you know I think knowledge is just one of those things that you'll you can theorize as much as you like but sometimes you just have to show and tell yeah and say you know what we've been capturing and servicing to our customers for six months and these are our findings.

Craig Stoss: 21:49

Yeah and I think I think that's the hard the hardest part of knowledge base is is just getting going. And you know it's it's I did a presentation on on quick starting a knowledge base several years ago and and I and I basically just put the two points on the board saying you know what do you need to document and where are you going to put it and and you know like it's that simple and and like you said if you have a tool that does it already um and even if you don't there's there's again share out some something you know like use a a Dropbox or a Google drive or something uh but just capture it because honestly like as I said earlier your team is already doing this and so make it available uh you know advertise it make the knowledge base is just a or that the the the place where it's looked at is just the storage facility you know you can put the storage anywhere until you have a proper solution or you've got the approvals or whatever um but it does existing inside someone's you know email inbox or inside you know a Zendes ticket that you'll never search is just not the right the right replace and yeah and so yeah your your point is is absolutely valid just literally just what do you want to document it and where are you going to put it and and answer those two questions and you know my advice to any of the listeners would be just just just do it and and and worry about the tool as a secondary thing if if that's what's holding you up.

Charlotte Ward: 23:13

Yeah yeah I couldn't agree more um create the knowledge and and then I think stage two is use and review use and I mean good old fashioned KCS use review use review because that is the only way you're going to make sure that it continues to be successful. Yeah do it and keep it going. That's right and and like you said the value will will come yeah for sure your customers will thank you very true very true well in the meantime I will thank you thank you so much for your time Craig it's been a pleasure to chat to you as always yes thanks Charlotte that's it for today go to customersupportleaders.com forward slash two one five for the show notes and I'll see you next time