305: Measuring Your Support Maturity; with Neal Travis

Support teams don’t usually fail because they “don’t care” or “aren’t working hard enough.” They fail because they scale on instinct, accumulate tribal knowledge, and measure whatever is easiest until the whole system starts to wobble. We sit down with Neal Travis, Head of Customer Experience and Operations at AIHR, to talk about measuring support maturity in a way that leads to real decisions, not a prettier dashboard. Neal shares how a small team can support a large customer base by getting ruthless about what support owns and how the work is designed.

We walk through Neal's support maturity framework built around three domains: knowledge, quality, and data and insights. On the knowledge side, we dig into self-service experience, internal knowledge management, and training that prepares the team for what’s coming next, not just onboarding. We also unpack why “supportability” is an outcome when documentation, enablement, and cross-team alignment are strong, and why customers learning changes before support does is always a red flag.

From there we move into quality, separating communication quality (standards, coaching, QA programmes, onboarding for great conversations) from operating quality (channels, capacity, coverage, incident management, and the reality of a messy support tech stack). Finally, we get practical about support metrics and measurement architecture: choosing the right metrics, understanding trade-offs like handle time vs after-call work, building reliable data infrastructure, and turning voice of the customer into action that closes the loop.

If you want a clear picture of where your support function is mature and where it’s fragile, this conversation gives you a map. Subscribe for more, share this with a support leader who’s trying to scale, and leave a review with the one domain you’re working on next.

Transcript

Introduction And Guest Background

Charlotte Ward 0:12

Hello and welcome to episode 305 of the Customer Support Leaders Podcast. I'm Charlotte Ward. Today, welcome Neal Travis to talk about measuring your support maturity. Welcome back, Neil. Neil, lovely to have you back on the show. It's been a little while, but here we are, having a good catch-up. But first, just to catch everyone else up, would you mind introducing yourself for the audience again?

Neal Travis 0:47

Yeah, of course. And thank you so much for having me back. I think it's uh it's been quite a long while. Um yeah, uh my name is Neal. I uh I'm then currently the head of customer experience and operations at AI HR, it's the Academy to Innovate HR. Um been there about seven years or so. Uh started when there were about eight people. Now we're uh over a hundred. Uh so really gone through the scaling experience and trying to grow our teams and grow our business.

Charlotte Ward 1:13

So yeah. Awesome. Yeah, welcome back. It has been a while. Um, so um growing teams, growing the business, um, quite a lot of change at uh AIHR um in seven years. Um and a lot of growth. And you'll see what I did there because we're talking about today, we're talking about maturity, aren't we? Um and quite specifically, I guess the stages that all support teams go through, um, some some of them multiple times as we experiment and ratchet back and try something else. But we're talking essentially about support maturity. And you've uh you've had you've done a lot of thinking on this, haven't you? I think it's fair to say.

Neal Travis 1:54

Yeah, yeah, indeed.

Charlotte Ward 1:56

Uh so so what what let maybe let's start with what provoked that thinking? Obviously, you've been through quite an evolution at AIHR. Um tell us a little bit about that journey and and sort of some of the thinking that that provoked.

Why Support Maturity Matters

Neal Travis 2:10

Yeah. Um when I started at AIHR, we were very, very small. And uh I think there it was like, hey, help customers figure out uh what will make the experience better and uh go from there. And when you're in that very small startup experience, you touch everything and you are a part of everything. And also there are a lot of things that you would do for customers then that you would not at all do later on down the road, or at least where we're at today. Uh it comes with a lot of flexibility, a lot of special case, a lot of things that you can really do a lot more of. Um, but a long while went down the road. Uh we we pretty much um it was me for a while doing sport uh for a few years, I think about three, four years or so um doing uh yeah, trying to to grow along with the business and scale things out and try to pick all the pieces together. And then we started to grow the team. Um we started to really build things out. And our team got to a point, our support team right now is quite small, or about four people, uh, one team lead and three reps in the whole team and the whole company. Uh we support a customer base of about 30,000 now, active member base or so. Um, and we got to a point where okay, we needed a team lead, we wanted to kind of settle things out, and it was time for me to hand over the solo ops builder uh side of things and and give the reins and pass that baton to the team uh to be able to move things back because as the as everything grows, you can't really always be a part of the in-depth building as much as we would want. So you can hand those Legos over. Yeah. Um and that really prompted me to sit down and really think like, okay, you need to build support now as a team. Where are all the exact places where the support team actually can take full ownership and should be working to develop? Um, and the activity for me was okay, uh I'm gonna think about these sections, these areas, try to build it out, and then also just prompt some questions for them to ask. So I ended up with uh three main domains or like three areas, uh a bunch of subsections uh and themes beyond that. And then I think I wrote like a list of like a hundred questions for them to ask themselves and go through. Um yeah, so that's kind of how it uh it came to be in general. Um, but I do think around that it can be really agnostic to any support team.

Charlotte Ward 4:54

Um so so it's birthplace was really that moment where you had a bit of space and you had the time to think about things. It's effectively by the nature of the hierarchy developing a level up, but also that that that also means you zoom out a little bit. You look at the you look at the edges of support, you look at the functions that you were touching on that maybe you should continue to touch on and aren't going to touch on anymore. Um, and and including obviously the customer-facing um part of the of the whole support function and how you deliver that. And so, in some ways, this kind of zooming out, but also uh an increase of focus as well, I suppose. Is that fair to say?

Neal Travis 5:38

Yeah, because there are so many things that I, for example, was doing that were not what support should be doing. And I think there was always this kind of confusion of like, oh yeah, support can do that. And then it's like taking a step back and say, no, I'm doing that because it's me and that's how we kind of evolve, but that's not what support as a function should be doing. And there it's also trying to separate those kinds of things. So uh it's creating focus for the team because the team could be like, yeah, we're doing all these things for like VOC and doing all these things. Like, you don't need to do that as a team. Uh it's much broader than what support really should be. So it's also creating that focus, I think, is important part of it.

Charlotte Ward 6:17

Yeah. So so the hundred questions that you you you uh developed, um 100 is a lot to get to get you to a point of focus, but but I know that you have really actually focused that on on a few key areas, haven't you, that really are at the heart of what it means to run support as a function. Not to do support on the front line necessarily, but to have that that perspective on it

Knowledge: Self-Service And Documentation

Charlotte Ward 6:45

as a function.

Neal Travis 6:47

Yeah. I think there's three big main areas. Um if you're gonna start support and you're gonna be building support even from the very beginning, if you're running it by yourself, you need to have the knowledge and information that's about your product itself to be able to actually help people. Uh, you need to make sure that things are pretty good quality. You want to have good quality conversations with people, and you want to learn from those conversations so that you can then improve your knowledge and quality. So it's a bit of a dysloop. Um as you grow your team and as you grow your function and start building things out, those three key things knowledge, quality, and data and insights, and just what you learn from those conversations, also continue to develop. Where, for example, uh at some point I was like, Well, I have all this knowledge, that's great. I'm I'm trained and I can manage my own knowledge. Uh, what happens when I need to pass it to other people? My knowledge management practices in place to actually document things. Um, do my customers have that knowledge? Uh so for example, there are there's three main domains and then three subsections uh for each of those that I've come to. Um so it's just a bit of translating those things out.

Charlotte Ward 8:03

So I I mean, I think I think knowledge is the first um hurdle that every support team has to to leap one way or well, let's be honest, multiple hurdles inside the not the knowledge domains. Yeah. Uh are we writing it down? Are we uh are we is it readable? Is it accessible? All of those things. Who is it accessible to? Are these the kind of questions, are these the kind of reflections that that let's talk about, let's dive into that knowledge domain first, because I think it is the biggest and earliest hurdle. Um are these the kind of reflections that you encourage?

Neal Travis 8:40

Yeah, yeah, yeah, 100%. And and that's uh so I recently also built an assessment for this, and that's also what those kind of reflection questions are around. Um, when it comes to knowledge, there's three main things. It's self-service experience, it's your internal knowledge management, and it's how you get new knowledge to the people who are actually doing the work. Um, so it's those three things. The self-service experience is really important because you want to make sure that you have uh a strategy around it. How are customers going to be able to help themselves? Uh you want to make sure that that content is actually up to date and it's actually working for you. Um, and then it's about positioning and access. Can they actually find the documentation? Can they actually get to those places? Is it actually surface to them when they need it? Um and those are the kinds of things that the questions are focused around. Um, do you actually intentionally set things around that? Or do you just think that oh it's fine? Uh it's moving, it's it's fine. Uh, but we only look at our uh document satisfaction scores every quarter or something. Then it's like uh how how much do you really monitor the success of it? Um, around the internal knowledge management, do you have your processes covered? Are your actual things documented, or is it just living in tribal knowledge? Is it just living in that kind of uh rep knows this, or oh, I think they know that? And uh, do you actually cover your processes? Are they accessible to people? Uh, I think that's one of the most difficult things. I've run into a lot of people who use a lot of acronyms and a lot of internal language that doesn't translate to the customer-facing language. And so reps are like, uh I'm looking for this thing, but I can't find it. No, it's because it's this knowledge and it's this kind of terminology that's used, or it's that acronym or something. So it needs to be covering your processes and accessible.

Charlotte Ward 10:35

Uh, and just the tribal knowledge is a big one in my experience, particularly where I um have spent a lot of my career at the deeply technical end of support. You know, there's a lot of like assumptions about the experience that any one of your support engineers has. Like, do they maybe they have experience with one cloud but not another cloud, or or they have, you know, experience with the infrastructure but not necessarily the security side, all of these things, or or you know, um have have developed more of a spidey sense for different tolerances for certain settings or or uh you know kind of behaviors on the platform. And and a lot of that um is really hard for new folks to access, particularly, but even even tenured folks, if they just don't happen to have come across that situation before. Um, new folks is uh is the final piece, though, isn't it?

Neal Travis 11:31

Yeah, I think uh if you can get your documentation to a level where somebody can walk in and try to do the job depending on the tier and the dream. Yeah, that's like the dream state, it's not really gonna happen in reality. Um, but that's always the goal, right? Like that's the goal is to have a solid level of documentation. And when you talk about the kind of telephone of knowledge that happens, uh, because I'm trying to teach you something, but it's not documented, so maybe you remember it, and then you try and teach somebody else, and then knowledge is just lost along the way. Uh, and especially the debt that it creates when somebody with all of that knowledge leaves, uh

Training For What Comes Next

Neal Travis 12:10

then you really see how good your documentation is. Very true, very true. Um, yeah, and the last piece of knowledge is training. Uh, I think it's something that people underestimate, um, which is a bit more how you actually prepare the team for where things are going. Um, this is something that we talk about a lot at the beginning of this year within my own teams. Um, for example, uh when new products are being released. What does that process look like for you? Is your support team enabled? Are they involved? Do they know what changes are coming down in the product and how that actually impacts customers? Um, how do you actually keep that knowledge up to date and relevant? And then also, if the business is going in a certain direction, do they have the capabilities to keep up with where that is going and training them on new knowledge? For example, we started releasing some more technical products that we'll need to support. Uh, our team is not necessarily a technical team, uh, so we don't have the capabilities. So we need to think of the training and the capability needs that we uh need to fill in order to be able to support those things. Um, that's a bit more of the forward-thinking lens of it. Um, but it's important to understand if if you know your customers know something about a product before your team, it's always a problem. Yes, yes. Your team is the last one to find out.

Charlotte Ward 13:30

I I mean so many organizations are guilty of that. It's it's it's an interesting perspective on uh training because when I was looking at your framework and saw training, my initial reaction was, well, that's that's the that's the natural output of everything that's gone before in terms of knowledge management, all of the uh the rigo that you put into understanding your processes and your product documentation and everything else, is what we just said about like it's it enables that new person to come in and sit down and do the work. And therefore, um, okay, there'll be some level of training potentially depending on the complexity, but but probably a lot of it is covered in in terms of like getting the earlier stuff right. But as you talk about what training means more in your framework, it puts me much more in mind of what I have historically called, or at least uh a big chunk of what I I have historically called supportability, which is you know, which is of which training is an element, but it is also the the associated documentation, which is another part of your framework. So, so this these kind of questions of like, do we have everything we need to be able to support this? This is future focused, as you say, to be able to support what's coming down the line in terms of knowledge, in terms of supportability is slightly wider. It talks about tooling and you know, if it's a technical product, maybe it's observability and things like that, and uh, you know, um recovery states and things like that. But um, but it's a big chunk of that, I think. So it's really interesting to think about training as future looking rather than just enablement for new people.

Neal Travis 15:05

Yeah, and and that that I separate into a couple of different things, uh, which

Quality: Standards Coaching And QA

Neal Travis 15:10

actually bleeds straight into the next one, which is quality. Um and I think this is where a bit of the difference lies between knowledge and training and coaching. Originally, when I made this, uh I had training and enablement as one section that bled across both knowledge and quality. Right. And it was a subsection of both. But I do think that there's a good differentiation to have because training and knowledge is new skills, it's new development of information. Um whereas you when you think of quality or like communication quality, it's more about keeping up and maintaining a certain level.

Charlotte Ward 15:49

Yeah.

Neal Travis 15:49

Um as things continue. So you're looking at where you currently are and what kind of things would need to be brought up. Um and supportability, I think, is if if you can get these things well rounded and happening, um, supportability is an outcome of these activities. And I think that's the biggest part is if you do have those good relationships with your product team and you have these goods in place, yeah. You can have good supportability practices.

Charlotte Ward 16:16

Yeah, yeah, yeah. Absolutely. I it it is yeah, it's a huge part of it. It's just that extension for a team like mine, it's the extension into essentially the bridge between people and product. Like, do we have that that tooling and everything we need? Yeah, yeah. I couldn't agree more though. I couldn't agree more. Um, solve all of this. You you've really just got to ask for a few grafana charts and you're done, right? Um so so let's let's move on and touch on quality a bit then. You mentioned coaching there, which is um which is training but for a different skill set, I suppose. And it's ongoing, it's not necessarily future focused, it's developing now, right?

Neal Travis 16:57

Yeah. Um there are two different types of quality. Um so for for each of these domains, uh, there's three three areas. Um, but there's two types of quality in my mind. One is the quality of our communication and the quality of the experience that we give to our customers. Um, and that is a bit more of do we actually have good conversations? Uh well, that is a couple of things. One, uh it's a byproduct of knowledge because if you don't have the knowledge and you don't have the training, you can't have good conversations with customers. Um, and that's why knowledge comes first in my eyes. Um when it comes to communication quality, you need to understand for people what does good look like. Um so you actually need to have those supporting uh resources, this is actual examples of like, hey, this is the standard. Um, and also I would always preach for a QA program to be in place so that you can maintain that standard of excellence. Um, so the main communication quality piece will talk to uh how you upkeep your standards, review your standards, and maintain that standard of excellence. Um, whereas the coaching piece will be more around skill development, um, onboarding, for example. How do you set your new people up for good quality conversations with customers? You onboard them well, you teach them uh all of the things about the product, the process, et cetera. You could also call that training, and that's why originally I had it bled under two. But this actually is a bit more setting people up for success and working on those fundamental and core skills around uh what it means to be a support person, and that's the ongoing activity to make sure that they can have good conversations. Um the second type of quality, and I think this will be a bit more into your realm of uh what you just mentioned,

Operating Quality Across Channels

Neal Travis 18:55

yeah, uh, is the operating quality. Um, because while you can have great conversations, your systems also need to work at a good quality standard. Um, and that's really thinking about your channels, your coverage, your capacity, your incidence. How do we operate well and maintaining a standard of excellence around operating quality? Um, do you actually how many systems does a rep need to touch when they need to help one customer for a situation? Um usually that tech stack can be quite a lot. Uh and if that's the case, you might want to think about how you're addressing it or what you're actually doing to set your systems up. Um the reason I put this under quality in my mind is because um where those customer conversations happen matters. Um, because for example, channels, uh, are you gonna have good quality conversations and be able to have a standard of excellence and quality if you're not intentionally thinking about do our customers need phone, do they need chat, do they need email? Are we actually thinking about what our customers need?

Charlotte Ward 20:02

How do they migrate between them and who else in the business they're touching as well, potentially, right? When you're talking about other teams, they do you do you have a an account team that you you need to loop in or that is routinely looped in? And what does that relationship look like? How is that managed? How does how does the conversation carry between the two? Yeah, there's there's there's a lot of complexity potentially.

Neal Travis 20:24

Yeah, and also incidents, for example, should be part of that. How do you manage and handle your incident management? Um, because, well, customers are not gonna have a good quality experience if everything is breaking all the time if you can't. Um yeah, the the main parts of quality in my eyes is just making sure that uh everything is running well, quote unquote.

Charlotte Ward 20:46

Yeah, yeah, yeah. Yeah. Um, and then the final part is really um ensuring the success, I suppose, and and allowing you to make judgment judgment calls and adjustments to the whole ecosystem,

Data And Insights With Better Metrics

Charlotte Ward 21:00

right? Yeah.

Neal Travis 21:02

Um you can have a whole lot of knowledge, you can train people and you can give them everything that they need. Um, they can have really good conversations, um, they can operate well and things can be running well. But one, how do you actually measure the success of what good looks like? Do you actually have the things in place to be able to do that? Um and we all know that support is a gold mine of interactions with customers, data, and feedback. Um, so what are you actually doing with that? The whole point of this last one, which is just data and insights in general, is that you really want to be able to learn from the interactions that you're having in order to be able to do something and improve to keep that cycle moving forward as you gain that new knowledge. How do you actually lead that back into those processes? Um comes down to three things one metrics and measures. Um you can measure Everything, uh, but then you're not necessarily measuring the things that matter the most. Um, the main themes here is talking about the metric choices that you make. Um you can have efficiency metrics, things that keep the lights on, these are hygiene metrics, you can have more effectiveness, things that start going into more outcome-oriented things. And also measure things that are really important to the business. Um, so how you choose your metrics kind of defines how you're going to start running support.

Charlotte Ward 22:28

I I think and I think it's really I think it's really um the right word, choice. Like to to measure the right things um and be willing to forget about the rest, even if they are like latently being measured by accident somewhere else. Like to to know what you should be paying attention to and how they I know you use the word architecture in your framework, but like how they relate to each other, how they influence each other, how if you want this to go up, this probably has to go down over here. You know, these kind of things is kind of and being able to explain that to the business as well, because I I so I think choice is absolutely the right word, and nothing fills me with horror than those support teams who just measure everything and stick it, stick it on a slide, you know, and expect the business to understand. I I remember a conversation, and this is quite some years ago, and I've I've genuinely forgotten who said it. So I'm not I'm not exposing any particular personal business here. Um, but I rem I do remember one conversation in uh support-driven Slack quite some years ago where a metrics discussion popped up and and somebody said, We have 31 metrics we routinely measure and listed them all. Oh no. I know I grabbed it and it made it into a LinkedIn article sometime later because it was just it filled me with horror. How do you even begin with a list of 31 metrics, weekly or monthly, or quarterly, and know what you can tinker with and what choices you can make because of those metrics. It's it was staggering. How many should we how many should we have? Five?

Neal Travis 24:06

There's no number, it depends on what's the best for the measuring. So maybe so maybe 31. Maybe 31. Maybe maybe if you want 31 things, you know it's important. I think I uh there's a whole separate discussion about metrics choice, um, which is one of the reasons I started the newsletter that I did, which is Metric Monday, talking about how to choose and how to use some of these metrics. Um it really comes down to starting with that business question first. Um, what is really important to you? For example, um, there was a company uh that uh close person to me worked for for a while, and they had this uh their scorecard of metrics that they wanted reps to do. Um and they said, Okay, you you have a handle time of X and you need to get it down to Y, and you can only have an after work time of like 30 seconds. Like you can only once you're off the call, you can only do things for a certain period of time after the call, and then you gotta move on. Um, but the combination of these two is not synergistic at all. Because you if you want the customer to have a very short handle time on the call, you're gonna have more afterwork time. Yes, exactly. It's just about finding the balance about what are the things that really matter to you. Uh if I was decision-making in that scenario, um, for me, for example, it would be thinking about okay, does it matter more for our customers to be on and off the phone really quick and then things happen and they get confirmations? Or do our customers prefer that everything is handled while they're still there that way they leave ever knowing everything is going? And it depends on your customer base, it depends on what's important to your organization or your business. Um, some conversations, you know, with customers are very different. Um so I think it's really just thinking about the balance there. There are efficiency metrics that keep the lights on, and those are metrics like that are kind of like maybe you could call them like Wi-Fi metrics. Nobody thinks about them unless it's not working. And then they're like, ah, nah, it's out, it's not working. And then all of a sudden when it's fixed a day later, they're like, Okay, I don't even think about it anymore. Yep, yeah, yeah, yeah, very true. Um but those are those are the kinds of things, just think it's really important to just think about them

Data Infrastructure And VOC Action

Neal Travis 26:25

intentionally. Uh one of some of that bleeds into the next section, which is a bit uh you have metrics and measures, and then you also have data and infrastructure. There are a lot of things that you might want to measure in metrics and measures, but you can't because your systems aren't reliable enough or set up in such a way that you can actually measure them. Um, and so there I would think about the processes behind how your information is set up. Is it reliable? And also, for example, if you want to measure topics and volume over time of what's happening, uh, having a good collection design and taxonomy uh for your tagging system and how you actually understand what customers are talking about is important. Um, because then you can measure other things. Uh, for example, we were not able to measure contact rates for a really long time because the system that hosts our active user base at a certain time period was separate from our help desk. So we couldn't actually get contact rate for a while. That's our structure to be set up in such a way um that we are able to do that. Um, and then there's also the the voice of the customer piece of when you do have all those metrics and you do have all that data, who is actually doing anything with it?

Charlotte Ward 27:39

Yeah, yeah. Which is a whole other episode again. Suite of episodes. Let's do a six-parter on that one. Yeah.

Neal Travis 27:49

Yeah. Um, and that's really about you know, how are you listening to what customers are saying? What are you learning about it? Are you actually sharing it and talking to stakeholders about it? And how do you actually close the loop with taking action and doing something on it? Um, but yeah, VOC is a whole depth of a topic. And I think each of these realms of things does have a very deep subset of things that you can do.

Charlotte Ward 28:12

Absolutely. Yeah.

Neal Travis 28:14

This is how a lot of our support programs were born. Um and this is something that we focused on. Okay, we're gonna have a VOC program that's an entire thing with multiple projects underneath. That's an entire investment that we're making to make sure that it goes well. Um, so this is a very big broad umbrella of things. Um,

AI As A Tool Not A Stage

Neal Travis 28:35

we also haven't talked about AI at all, for example.

Charlotte Ward 28:38

Yeah.

Neal Travis 28:39

Um the research.

Charlotte Ward 28:40

Which touches everything, really, doesn't it?

Neal Travis 28:43

It does, and that's the reason it's not included as a core part of it, because you can use AI across the board and all of these things to be able to mature them. Yes. But it's not necessarily it's only a tool or a way to get there. It's not one of the things that is like, oh, you have to use AI, and that's how you become more mature.

Charlotte Ward 29:00

It can help you to get there, but it's not the core root of uh and actually to and actually to that point, just briefly, like like like many tools, um using AI to help you mature can look very different. I mean, we'll we'll touch on your maturity levels within each of these domains in a second, but but how you use AI when you're just starting out on any one of these, in any one of the aspects of any of these domains, in any one of the the you know, the the things that we could do a six-part series about inside each inside each of these domains, the way you use AI inside any of them changes as you mature as well, doesn't it? So using AI on the front line to help you drive a conversation is different when it's it's three of you to when it's 300 or 3,000 of you.

Neal Travis 29:51

Yeah. Oh yeah. And even like if you think about a tagging system or a tag tech somebody, for example, like our at our current maturity, we have that set up in our custom fields and it's a drop-down. But for example, you could have, if you wanted to say, okay, we're gonna start using AI to do our taxonomy, uh, then how do you actually have that, you know, reading the conversations and defining what is the actual thing that it should tag, and then nobody needs to touch the thing, right? Yeah, yeah. Um of course there should be oversight, like disclaimer big asterisk. Of course, of course. So let's let's let's those kinds of things, right?

Charlotte Ward 30:26

Yeah, so so yeah, absolutely. So so let's um just round this out then. We've got these domains. Uh you've you've clearly done a lot of thinking. You've got, you know. Um and now that we we we know kind of the the domains, the facets that that we need to do that reflection about, how what does the measure look like? What is what is the aim here? We're we're talking really about maturity, so so that's a spectrum, effectively, right?

Neal Travis 30:54

Yeah, yeah, indeed.

Maturity Levels And Team Roadmapping

Neal Travis 30:55

Uh yes. And I also think the big bold letters at the top uh is that it really depends on where you're at in your journey, and it is okay to be at a certain maturity depending on where you're at in your journey. I would not expect to be a defined level three uh when we were eight people at a startup ages ago.

Charlotte Ward 31:17

Yeah, yeah, yeah. Absolutely, absolutely.

Neal Travis 31:20

It really depends. Um but yeah, it's a big broad spectrum of things. Um, and it can be per each of these areas. And for me, it's ad hoc level.

Charlotte Ward 31:30

And I was I was just gonna say different for each one, right? So you could definitely and and like we have touched on it, there is a a relationship, for instance, between your knowledge and your quality, or your knowledge and your uh you know, coaching, or your uh quality and the metrics you're able to pull from it and the voice of the customer, all of these things, while we've put them in nice boxes to be able to reflect on them and measure on them, there's a lot of inter interconnected tissues. Um and but actually, by because of that, or or maybe what drives that interconnection is the fact that you can be fairly immature on one aspect, in one domain, in one subset of one domain, and doing much better elsewhere. But because some of these things are precursors, particularly. So you might actually be getting slightly ahead of the game on knowledge, but still be fattening down the quality or the experience.

Neal Travis 32:26

Yeah, absolutely. I mean, it's like the human body, right? It's a living organism, uh, it's an entire system of organs. One organ fails, and it's probably going to affect many of the other things within the system. Yeah. Um, so in that case, like it is something that uh each of these pieces, while separate, do impact the other. Um and yeah, then if you get a full clear oversight of where you currently are, then you can make plans around, okay, let's take action here so that we can uh impact the other things.

Charlotte Ward 32:58

Yeah, yeah, yeah. You can begin to sequence out a plan, which is always uh which is always hard to do when you're you're just looking at individual problems and like, okay, we should probably solve our quality. Well, unless you realize there's that that other thing that you're actually you actually need to focus on first before you even think about uh slightly moving the needle on quality, then uh that that really is just super super helpful to think about it in that term in those terms.

Neal Travis 33:25

Um we had a we had a really interesting discussion. So we we what we what we did is um I made this assessment for the framework, specifically for my team, just to do something internal. Um but yeah, uh took it a little bit further. Um but what we did is we did we had every member of the team do the assessment themselves, and then we came together for a long workshop and compared everything together and had a really healthy discussion around the different areas and what we wanted to do and where we were at, and kind of um be able to make uh a roadmap. The team lead at the beginning was like, okay, this is not to say we're gonna do anything or add anything to our roadmap or anything, but just really get a sense of where we're at. And then she left, like, okay, I have a next six months roadmap. Uh there's plenty of things to do.

Charlotte Ward 34:16

Yeah, yeah. It's interesting though to give it to the team. I mean, it so so really this isn't necessarily a tool just for the support leader.

Neal Travis 34:24

Like no, you can use it as a reflection tool, sure, but like that think the conversation is really, really a good one to be had if you do it as a 360 feedback.

Charlotte Ward 34:33

Yeah, yeah. Awesome.

Free Assessment And How To Use It

Charlotte Ward 34:35

So so um the whole framework is available. People can go and uh actually take in all of the all of the uh domains and deep dive on all of the sub we've we've skimmed the surface here, but but they can get started, can't they? They can go and actually work through the framework.

Neal Travis 34:54

Yes. I haven't told anybody yet, but yes, they can do it. Um if you go to uh tools.growth support.io, you'll be able to find the assessment and the framework and everything.

Charlotte Ward 35:11

Awesome, awesome.

Neal Travis 35:12

Um I think about the 360 option for your team to do it in Kubernetes.

Charlotte Ward 35:16

Ah, perfect. So uh and and we can sign up to that. It's all uh it's free, it's anonymized, it's safe, it's all of those things. And uh um it'll hopefully help us all do uh do the reflection that is necessary at that level that we uh we established at the beginning of this conversation is um it is is something that we rarely make time for, but but just create a little bit of space and hopefully you can actually make some needle-moving decisions as as an outcome of this. So thank you so much for joining me today, Neil. It's been lovely to see you again. Thank you for coming back. And uh I know when we talked a couple of weeks ago, we've got at least another two or three ideas to talk about. So I'm definitely I'm definitely going to ask you to return. And I think we've established there's a six-part series on VOC at some point.

Neal Travis 36:04

Oh, we yeah, that's the whole thing.

Charlotte Ward 36:06

It's a whole thing. All right. Well, I'd love to invite you back for some other conversations. Would you come back sometime?

Neal Travis 36:12

Yeah, of course. Thank you so much. And I really appreciate you having me for this conversation and being able to go through and talk through it uh in the way that we did.

Charlotte Ward 36:19

Awesome. Thank you. Uh thanks so much.

Closing And Future Topics

Charlotte Ward 36:25

That's it for today. Go to customersportleaders.com forward slash three zero five for the show notes, and I'll see you next time.