Customer Support Leaders
Customer Support Leaders
274: Mastering Incident Management - Part 4 of 6; with Kat Gaines
What happens when the adrenaline rush of an incident meets the need for effective communication? Join us as we chat with Kat Gaines, the leader of PagerDuty’s developer advocacy and community team, who brings her expertise to the table. You’ll walk away with a clear understanding of how maintaining transparent communication not only soothes nerves during crises but also keeps customer expectations in check. Gain insights into how developing empathy between engineering teams and customers transforms the user experience, all while fulfilling our innate craving for solutions through timely updates.
Imagine engineers and customer support colliding in a world where Pokémon and bunnies serve as perfect analogies. Kat helps us explore this fascinating intersection, revealing the challenges engineers face in making their technical know-how understandable to the average person. Learn how empathetic customer support representatives become the unsung heroes, bridging this gap and ensuring that customer anxieties are kept at bay through consistent terminology and clear definitions. It’s a lesson in how collaboration between engineers and support teams ensures that even the most complex technical concepts can be translated into relatable terms, easing the often tense atmosphere of an incident.
We also unravel the intricacies of internal communication, stressing the importance of proactive practices that go beyond routine operations. From the use of codified channels and platforms to striking the right balance between internal transparency and external caution, we cover it all. Gain tips on fostering trust during incidents, creating templates for updates, and ensuring your team is equipped to handle external inquiries with confidence. Whether you're managing incidents or fine-tuning communication strategies, this episode promises to arm you with the tools you need for success.
Hello and welcome to episode 274 of the Customer Support Leaders podcast. I'm Charlotte Ward Today. Welcome Kat Gaines. In part four of a six-part series on incident management. I'd like to welcome back to the podcast today, Kat Gaines. Kat, lovely to have you back. We're here for episode four of our six-part series on incident management. Thank you so much for joining me again. I have a feeling this topic is going to be a meaty one. So if this runs to a couple of sessions like, let's do that rather than, you know, truncate or speed, walk through what is an important part of incident management, right? What are we talking about today that's so important?
Kat Gaines:Yeah, I think you're right, this is a little bit of a meaty one, so we'll just work with whatever we're given here and see how long we ramble on. So today we've been talking a lot about just the basics of incidents, what our customer support team should expect during them, what good looks like, a little bit, and we're really deep diving today into the communication piece. So a little bit of context even for our audience. So my day job is leading PagerDuty's developer advocacy and community team and with that comes a lot of speaking at conferences, kind of writing and thinking on the subject. And I was telling Charlotte before we started recording that this particular topic, just the subset of the topics we laid out for this series, has at one point filled a full 40-minute conference talk.
Kat Gaines:So, we've got a lot of material to discuss and cover here.
Charlotte Ward:Honestly, by the time, I add my own like chaptering away into that once I get going, like this is going to go way longer than 40 minutes, which is why I suspect we'll cover two parts.
Kat Gaines:Yeah, exactly, you've got both of us. You've got at least two hours of material here, right? Oh my goodness.
Charlotte Ward:At least at least I here, right? Oh, my goodness, at least, at least I'm looking forward to this one, then. So so let's dive in. So, communications important, like we all know. Everybody says, at least like we're on LinkedIn, we're in, you know, we're reading all these blogs and everything. Communication is vital. Quality communication is vital to any aspect of your working life and, you know, when we're managing incidents, doubly so. And, as we've touched on this a few times in the last few episodes, but, um, why is it so important? Why is it doubly important in the middle of like that? I mean, I I'm trying to avoid saying heated like situation, because everything we've said about incidents up to this point should mean that you're not in a heated situation, that it's calm and it's lovely and you're feeling very zen about this. But and maybe that's part of the why of good communications, right is to maintain that zen feeling of a good incident being managed. Well, but but what? Why? Why do we need such good communications during an incident?
Kat Gaines:yeah, I think you can manage calmly, but you're still going to get that adrenaline rush right. You're still going to feel, oh gosh, something's happening. And if we just kind of step back and take a, take a quick think about anything that's happening in our lives when something doesn't go to plan, I I don't know about everyone else listening to this, I don't know about everyone else listening to this, I don't know about you but my immediate instinct is okay. But why? Why is this happening to me? What is going on? What can I do to fix it? How can I get back to a state of normalcy as fast as possible? And that is for me. It's consistent. I think it's also part of the support personality right that?
Kat Gaines:you're constantly looking for solutions, and that is the thing that we crave and want so much.
Charlotte Ward:it's an addiction, isn't it?
Kat Gaines:it's an addiction, oh gosh, yeah, uh. If there were support groups for constant solution seeking, we'd all be in them, um, but so we're always looking for the why. And it's not even just a support, you know, background thing. That's just a human condition of wanting to know why and how to get back to normalcy. And the easiest way you can manage customer expectations around that moment where they're asking why and how do I get back to normalcy, is to communicate with them, to be transparent, right. And you have a little bit of a moment there where you have maybe your developers, your engineering team, working really hard on the issue and they're doing everything they can to solve it. The way that they perceive your products and services is going to naturally just differ from what your customers are seeing and experiencing, whether it's as simple as back-end versus front-end understanding of what it does, to just not having the same user experience of being in it right and not having the same needs. All of those things get in the way of kind of letting them develop true empathy. And that's not to say that engineers don't have or can't have empathy for the customer experience, just that they have that kind of extra hurdle there and so, communicating what's going on. They might say, oh, the technical details of what's happening. Right, you know, xyz system is down. A lot of us come up with like really cute C code names for our system, so I unfortunately this is a visual component, so folks who are listening will just have to trust us.
Kat Gaines:I have on my desk these little bunnies that a friend gave me and they all have different designs. So this one is, I think it's, like a pink lemonade bunny. It has some little lemons printed on the side and we might, for example let's see, can I find another one? Yeah, we have like our tropical bunny who has little like swim shorts on. There's a good variety of them, and if I was in a team of engineers, oh, this is a good one. It's a magician bunny. It's got a little magician's hat, very cute.
Charlotte Ward:Usually the bunny's coming out of the hat, right?
Kat Gaines:Yeah? So let's say that you and I are in an engineering team and we know about these bunnies and they make a lot of sense to us because we've seen them, we've connected over them and we decide to name our internal systems after these bunnies. So maybe our notification system is the magician bunny and our web UI is the lemonade bunny, and so on and so forth. That makes perfect sense to us because we've seen the bunnies, we've talked about the bunnies. Our customers in this case the folks listening to this podcast who think I've gone off the deep end at this point don't have familiarity with the bunnies. They think about the product in a different way. They just think about it as notifications, the web UI. They think about it as the thing I log into every day when I want to go use this product. And so your engineering team might say, oh, let's publish info about the bunnies and you know, magician bunny is down. Your customer doesn't connect with that.
Kat Gaines:This is a really extreme example. Usually it's going to be something a little more identifiable, but you have folks in your organization spoiler alert, it's customer support who happen to speak both languages. They speak Magician Bunny and Notification System. They speak Pink Lemonade Bunny and Web UI, and so they're really in a good position to make sure the communication happens in the right way so that both parties can understand it and benefit from understanding just what the heck is going on and again that search for, but why and how do we get back to normal can understand it and benefit from understanding just what the heck is going on and again that search for, but why and how do we get back to normal?
Charlotte Ward:this is such an amazing analogy. I mean, I think the bunnies are way out there as an example. But you know a little bit. Yeah, you had to see the bunnies, everyone. The bunnies were something to behold. But, like I mean, I guess I'm going to just bring us a step more. Perhaps I'm going to broaden the cultural kind of hooks here a little bit. They could be Pokemon, right, in some ways it's kind of.
Charlotte Ward:When I try and talk to my 10-year-old about Pokemon, I'm a bit like he'll say well, why wouldn't you know that he's the engineer of pokemon, isn't he? He knows everything about every pokemon. He knows their environment, that they do well in what their evolution was. They're the same with bunnies, right, you know what they're good at, what their weak spots are, what works, what doesn't, how you feed, who gets on with who, what their language is, etc.
Charlotte Ward:I mean, I'm sure I'm showing my ignorance about pokemon here as well as bunnies, it has to be says, but but he's the engineer of pokemon and I have to ask him ridiculous questions, because I'm the customer of pokemon and what I actually need is a support person in the middle who says ah, when he's fire type, this is what he means and when he says evolves from you know, I don't know, pidgeotto, like this is what that is, and that's why he's telling us about something that isn't even a thing in front of us, right? So, absolutely, I completely understand and hopefully I've been the support person for our listeners in between going via, via pokemon, from bunnies to pokemon, to something that I know makes sense somewhere to somewhere someone's going to understand where we went here, and that's great, yeah, yeah that's the main thing, right?
Charlotte Ward:um, you're right, and I think this, I mean, I just want to go back to something very, very quickly, which you said, which is about engineers and empathy. You know, I think, what we're absolutely said, which is about engineers and empathy, you know, I think what we're absolutely not saying is that engineers don't have empathy, and you said that engineers yeah it's not that engineers don't have empathy, it's that I mean, it's just the world they inhabit has boundaries.
Charlotte Ward:that, yeah, it's. It's the natural course of any human, in the same way that a support person would sit here and not necessarily know the depths of the functioning, the internal workings of any of those bunnies or pokemon or technical components of your product, right, um, but? But you sit on the boundary, and and where the intersections, intersections happen is where the translation needs to happen, and it just so happens that, being in the middle, a customer support person intersects with two, whereas engineers would typically, at this level, intersect with the code and the support people, and so you have to make these leaps right.
Kat Gaines:Exactly your support folks really. Just they have so much practice in understanding how both parties work and how both parties communicate and talk about the product and they've also they've kind of been there done that right. They've made the mistakes in talking to customers where they've had to think about their own language and how they refer to the product and you know, their own still internal understanding of what it is.
Kat Gaines:They've made those course corrections. They've they've spent time developing that common language to just understand how to speak to these folks and get the message across. And that's why they are so vital because, yeah, you know, I don't understand pokemon, but if I have someone to explain it to me in non-pokemon terms that customer support person sitting in the middle, cool, I'm going to be able to relate that to my experience a lot better.
Charlotte Ward:Yeah, yeah, absolutely, and I wonder if this is partly why so many support folks that I speak are really good at drawing analogies, and sometimes very, very funny analogies like bunnies or whatever. We're all able to explain things in really kind of almost tangible terms, aren't we?
Kat Gaines:well, if this was this that?
Charlotte Ward:yeah, all sorts of analogies um yeah yeah, and it even comes down to yeah, it's like word choice too when you're thinking about it, right?
Kat Gaines:so a good example I can think of is that, even like incident terminology we use around incidents really matters heavily, not even the product itself, but just even relaying the severity of something that's going on. And so, for example, you don't really want someone to say outage to a customer during an incident if it's not a true outage right, if it's not what your company defines as an outage, because that can imply that something is really wrong and could really add to the anxiety and stress that those customers are feeling. So instead, you have a support rep who, again, have spent time honing this language. They spent time understanding.
Kat Gaines:Okay, if this particular issue is why we're having an incident, what does that mean for the scale of severity around what's going on here? So they know where to step out phrasing and say things like service disruption, incident and how to minimize concern. Obviously, if it's a true outage, they know when to say that too. But it's about knowing when to kind of pull those triggers and either either raise or lower the level of alarm that customers are going to you with.
Charlotte Ward:Yeah, absolutely. And this harks back to something we talked about before, about having really consistent definitions, because that builds the dictionary, doesn't it for that translation?
Kat Gaines:Yeah, yeah, very much so. If we can just talk about definitions for a moment, this is something that I find myself able to just go on and on about for a moment. This is something that I find myself able to just go on and on about for a while.
Kat Gaines:So you know the key piece of making sure that this works again. Your support reps are amazing. They know how to speak your customer language. If, as a product or engineering team, you don't give them the tooling to also speak the language of what you're talking about internally, to also speak the language of what you're talking about internally, things fall apart. We're back to bunnies and Pokemon, basically.
Kat Gaines:So one of the things that I like to coach people to do is to make sure that you're partnering with your customer-facing team so they have the information they need and if you're part of that customer-facing team, seek it out, demand it, be a little bit relentless until you have what you need. You basically, as a support rep, need to be treated as a stakeholder during incident communication by your product and engineering team. So we had talked a little bit about stakeholders in an earlier episode, little bit about stakeholders in an earlier episode, and you know executive teams and other customer facing teams. The rest of the support team, even if someone is holding that customer liaison role, is also a stakeholder, and this extends beyond the moment of an incident. So if I'm thinking about different things that can get in the way during an incident, it's not knowing things like tooling terminology, internal code names, creative names that we've come up with for things.
Kat Gaines:Going back to our bunnies example, um acronyms that might not be clearly defined. That is my personal pet peeve, that if you have acronyms it's really easy to just kind of assume that everyone knows what they mean. Right, it's fine. The example I gave in a talk around this was if you know, you know IYK, yk, something, someone, uses everywhere, you don't want to make it.
Kat Gaines:So they have to just intuitively know you want to just find it for them. You can't put your acronyms in that state, and so that's kind of the first step of saying does that team have everything they need? The way that we talk about our product, the way that we talk about incidents, does our customer-facing organization really understand what we're talking about? When we're on an incident call, we're referring to system X.
Charlotte Ward:Yeah, I think it's really important that you come up with a glossary, you know, a dictionary of terms, super important and I think, as I said before, like that becomes the foundation on which your customer facing teams can talk to customers.
Charlotte Ward:Um, because without, without clarity around what is happening and without a point of reference for those things, even if you do ultimately choose to lean heavily into TLA's or in the moment of an incident, just to save you some time like it saves you 0.4 of a second to type out you know three letters instead of three words.
Charlotte Ward:We all know that adds up it feels like it adds up anyway. Um, then at least with the point of reference, your support team stands a chance of translating it properly for the customer rather than making it up. Right, if you don't give them, if you don't treat your support team like a customer, then they are just going to fill in the gaps when they communicate to customers and, oh yeah, is the worst possible state for an incident? Right, they're going to start using the wrong term to your point, as an outage is not really an outage, but you're panicking customers, probably panicking your support team as well, because they are working in, you know, that kind of gray area of like I don't really know, and because I don't know I feel anxiety. I'm not going to respond during an instant. In every direction.
Kat Gaines:Yeah, you don't want folks to feel like they have to just kind of make stuff up at a hot. You want to give them the toolkit to be able to say I know where to go, I know where to look, I know what this means.
Kat Gaines:And to your point about the glossary too, that is something that I saw someone once come in with really valiant effort to make a glossary of all the terms and acronyms. They heard company wide and it was beautiful for about two months and then it got stale because you know what they shift and they change, and so the thing about that too is to make sure that those types of efforts to provide that documentation for people and provide that clarity for folks don't become a kind of one-off forgotten project.
Kat Gaines:but there's something that both parties continuously work on, and you should be adding customer service terminology to that too. You should be saying here's how we talk about this thing, here's what, from the CS side, we mean when we say XYZ, so that again the backend teams can get a little bit more understanding of okay, how are we talking to customers about this. And it's something that has to be a collaborative effort, and so it either has to be leadership from both teams continuously working on that or nominating folks from both teams to be each other's ambassador and make sure those projects are ongoing.
Charlotte Ward:Yeah, absolutely. I think everything we're talking about is highly applicable, let me say, to day-to-day support as well. Right, when I think about things like a glossary in the moment of an incident, or the need for that common understanding, that single understanding of every single thing you're talking about, um, yeah, consistency to me. If we're talking about, for example, a glossary that's well maintained, I just apply knowledge centered support principles to it and it's done.
Kat Gaines:Yes, one.
Charlotte Ward:Oh my god, please, yeah 100, right, 100, a thousand percent, like. Let's use the thousand percent emoji on this one, because if everybody just was had the freedom to go in and update something and improve it, we would all be living much easier lives, I feel that autonomy is so crucial yeah, it is, it is, it is.
Charlotte Ward:And then the other thing that you were talking about, you know, um, where you mentioned be demanding as a support team, make sure you have what you need. This has so many echoes of my conversation with Alexis Grant about supportability. Like you have to just stop taking the shit frankly, like just stop accepting it, like just actually draw a line in the sand and say I, without this baseline, without this minimum level of information and tooling and and everything else, like we can't do our jobs properly, like we need this.
Kat Gaines:Yeah, that's actually oh god, you know I love to talk a big game about setting boundaries all the time, and that is such a great point that you have to set those boundaries with those teams and be able to say exactly that that we, we just can't even operate. We can't start supporting this until we have this information, and this is the type of information that goes into that.
Charlotte Ward:Yeah, yeah, absolutely. It's so important. It's so important. So I think we've probably talked for like 15 minutes on why communication, good communication practices, are so important. Where do you want this bit, because I'm already sensing how meaty this topic is. Where do you want to take the next bit of this? Where are we going next?
Kat Gaines:I think we mentioned stakeholders and the team being treated as stakeholders, right, and so let's talk about that a little bit, about what is, what does that process look like and what does good look like there? Because I think we all, we all think a lot and there's probably more literature out there on external communication and I can't stress enough how much internal communication is still wildly important. We've talked about the definition side, understanding terminology, so you've got the building blocks of internal communication there, where you do kind of have to have those prerequisites in place and have that process going um, but then the how you do it, how you communicate, that is um. That's something that deserves as much process attention as external.
Charlotte Ward:Yeah, it really does. Actually, it really does Because I mean, when I think about the how I think of a number of things, I think about channels, I think about platforms, I think about tone, yeah, I I think about where is this being disseminated? And like there are so many aspects to just rather, rather than just firing something out there and assuming that a bit, a bit to your point, about, like, if you know, you know right, like, rather than making all those assumptions that you're hitting the right people with the right information at the right time, like actually codifying some of that is worth doing, isn't it?
Kat Gaines:yeah, it really is, and so I think, like practice number one um is to try to do it in a proactive manner. So, whether it's the type of communication you have between teams and a peaceful scenario where there's nothing happening, that is part of proactive communication. And then the communication you have when there is an incident ongoing also has to be proactive. Sometimes we have a an urge to say, oh, I don't want to say anything until I know what's going on. I want to be clear, I want to have all the facts. With external communication, you have to have a little bit more of that caution, because you do have to put out something there that's accurate and factual and if you don't know everything, you can't say, you can't assume or conjecture about the things that you don't know. Right. In internal communication, you have a little more flexibility, not a ton. You still have to be factual, to to be clear, but you have a little bit more flexibility to be proactive and also to not have all of the details and set expectations too, that details are coming.
Kat Gaines:But hey, we want to get a message out there and we just want to let everyone in the company know that there's there's something happening.
Charlotte Ward:We think it's affecting this system, we think it's probably going to be customer facing yeah we'll let you know more soon right, there is a, there is a level of certainty that you can apply to internal communications. Yeah, we think this is happening, we're you know, we're 85 sure, or we're investigating 50, 50 at this point, like there's, you can apply levels of certainty and know, or maybe maybe you don't make the assumption that your teams know how to communicate that externally if they need to, yeah, but like, at least use some indication of certainty as to drive expected next actions.
Charlotte Ward:So we're investigating should infer we're not going to tell anything to customers right now.
Kat Gaines:You know, because you want to be more certain when you go external, right, yeah, there's a lot of trust involved in that internal communication to the point you're making that you might not be able to assume that everyone knows how to talk about what you're saying internally, externally, and one of the better practices for that is just to let them know that this message is not approved for external communication whether it's in the moment or whether you again to the proactive piece, spend time training everyone in the company on what your incident communication practices are, so they know when they see that internal stakeholder notification coming through, that I am not to repeat that externally to customers, to the media, to anyone.
Kat Gaines:that is not my job right now. That is just information for me. So that, at the very like most, when you get that, when your customer who you have a relationship with reaches out to you and says, hey, is there something weird going on, you can say, you know, yeah, we think so Go ahead and stay tuned to our status page.
Kat Gaines:We're going to have some updates there for you soon, right yeah, and you, you don't feel you take away the pressure to then to have each person know how to communicate what's going on, but they can at least say yep, we're on it.
Kat Gaines:We know there's something a little funny happening and we can promise that you're going to get communication through the channels that you expect to get them from as soon as we're ready for an external message. So it's a trust fall, but a lot of it does include that proactive side of making sure that you train folks or you just clarify in the messaging. This is not external communication, this is just so everyone here knows what's going on and where we are, and at a point it's going to overlap. You should keep up internal communications even after you've started external comms.
Kat Gaines:Oh, yeah, yeah, yeah and so at a point like, yeah, some of this messaging is the same stuff that's going into the external communication. But still, your internal communication may have a little more in-depth technical detail. Still, your internal communication may have a little more in-depth technical detail. It may have, again, conjecture about different parts of what's happening. It may include maybe, let's say, it's a problem with a third-party provider that's causing the problem that you're having. It might name names where you're not ready to need names because you don't want to play the, you know, blame and shame. Um, I feel like I'm just rhyming aggressively. I was going to say blame and shame game with your external communications. Uh, that's wow, that's a lot of rhyming really there's a lot of rhyming.
Charlotte Ward:Um, I want to go back to your point about being a a trust fall. It is, it's an internal trust fall, but what that actually helps is it minimizes the amount of trust falls that your customers have to do with you. I don't know if that analogy remotely makes sense when you're able to say we are aware and what you know, what should stay to the page or whatever. It just stops customers feeling like you as a customer support organization are as much in the dark as they are Because you never put your support people in that position anyway.
Kat Gaines:It's awful.
Charlotte Ward:Just, you know the time that you question something funny going on from a vendor and they say, well, I, um, I'll have to go and check, like, like, where's the trust after that point? Yeah, uh, it's, it's super, um, it's super important, even if they don't have a great deal to communicate yeah, you're so right.
Kat Gaines:Incredibly, it takes away the the feeling from them that they have to blindly trust you just because they're supposed to, but instead that they can trust you wholeheartedly because they know that you know what's going on and that you're important yeah, exactly, exactly, yeah, yeah, um.
Charlotte Ward:So in terms of, like the what we're kind of authorized to say and not, and levels of certainty and everything else, what else would you apply to um, to the, to the how?
Kat Gaines:I think just a basic template for folks of what kind of information you're including in these internal updates I think that can be really hard to suss out, and so, when I'm thinking about the different kinds of information, you want to go to the basics and again, some of this is going to make it out to your external comms once you know, here, but you really just want to think about. What do folks need in order to operate? What knowledge?
Charlotte Ward:do they?
Kat Gaines:need, so you're going to grab things like when the incident began. That's the very first thing. How long has this?
Kat Gaines:been going on? How long could this be affecting folks? Giving kind of a brief description of what is impacted, and so you might not know much early on about impact, right, and that's okay to say so. It's okay to say yeah, I'm not really sure of the scope yet, but here's anything we do know, whether it's a business or technical service or you know part of the experience of the user interface that your customers are going to see. And then that comes into my next point, which is what impact is it having on customers? Again, if you know it, if you don't, you can also ask for it.
Kat Gaines:Right, because you probably have support folks, sales folks, et cetera, who are starting to hear from customers, and so you might put a call to action in this communication to say we don't know the customer impact, but if you hear from customers and they have symptoms that seem like they may be related to this issue, please let us know and tell them where to give you that information. Right, you don't want 40 new people jumping into the incident call, but maybe you want them to throw some feedback in a Slack channel or maybe you want them to go through what the person who is acting as customer liaison and pass that feedback to them so they can pass it into the incident call. Any way you spin it, make sure they know where to go. And then, on the other where to go side, it's where to find the information. So you already have hopefully thought about that by the time you're sending this communication, because they should know where to go to find it. You know a tool like PagerDuty that has tools to send internal updates like this, whether it's a Slack channel, whether it's you're inviting a certain set of people to come join the incident call and listen along.
Kat Gaines:Maybe there's even an internal status page where you're publishing some information and they can go subscribe to that. You don't have to have status pages be only external. Internal is a totally valid use case. Make sure they know where those places are that they can keep up to speed. The next couple of pieces are how to respond when customers are asking them for details. So we were just talking about that right, that trustful piece, and so if you have guidance on how to respond and include that, if you don't go ahead and say so, you honestly should be putting this in a template and trying to fill out as much as you can, and then how often to expect updates? When are we going to tell you next what's going on? So that you do two things there. You set expectations, you help folks understand what to expect and you also protect yourself. Whether you're the customer liaison or whether you're someone in engineering or another role, you protect yourself from getting interruptions every five minutes, every 30 seconds.
Kat Gaines:Someone is pinging you saying where's the update? When am I going to hear about it? Next? When are we publishing something else? You set that expectation. You say, no matter what happens, we're going to have an update in five minutes and it's going to be in that channel that we told you about. So you know that specific place where you can go to look for information.
Charlotte Ward:That is happening in five minutes, no matter what information we have, and you really save a lot of heartache yeah right, one thing I've often observed and and maybe we'll we'll dive more into, like the super practical practicalities, if I can even say the word practicalities, the super the super practicalities are hard when you well, when, when it starts to get into super practicalities, I begin to feel a bit like Mary Poppins.
Charlotte Ward:But when we get into the super practicalities next time? But I think one thing, just on that note everything you just said there reminds me of something that I say quite a lot, which is that good instant communications have so much in common with good handovers in every other part of the business of being in support. So, whether you're handing a ticket, a complex ticket off from one support agent to another, or from support to engineering, like if you can construct a good handover which includes everything you just talked about, what you you know, what you know about the context, what you've tried or what you know the impact to be, what the um you know, what has happened and what is about to happen and what you can expect to happen after that too, like all of the all of the elements of a good handover are there in any other good instant communication, I think as well. And um I I just wish that we applied templates to all these things. But right, we'll get into the rigor of it a little bit more next time perhaps.
Kat Gaines:Yeah, you're right it's, it's basic support skills applied to a high urgency context, and so it's a really lovely way to show how the skill set I said basic, but also the skill set someone who's honed working in customer support which are not basic, to be clear, they're complex and they're hard to learn and they are developed in expertise, but it can scale out to just so many different ways of how your organization operates, and it's just that foundation which is critical yeah, yeah, absolutely, absolutely.
Charlotte Ward:Well, I think, have we, have we covered everything you wanted to cover today, because I feel like we're about to get into, like the really, really depths of like I think we're about to get into the nitty-gritty and that's, yeah, quite a bit longer. So all of the things that I'm quite excited, so all of the things I talked about a couple of minutes ago, like tools, platforms and how and tone and da, da, da, da da, all of the pieces we're going to deconstruct that next time and think about all of the nuts and bolts.
Charlotte Ward:You think?
Kat Gaines:Yeah, and we'll give our readers or our listeners gosh, I've been watching too much Bridgerton. And we'll give our readers or our listeners gosh, I've been watching too much bridgerton. We'll give our listeners a break. Um, I'm I'm all dear reader over here, and we'll give our listeners a break to digest everything we just talked about before we get into that so somewhere in here we've, we're moving from austin through to bronte and we'll keep going awesome, right, okay, maybe it'll be dickens next time he got into the like yeah, little nuts and bolts we'll just cover you know what?
Kat Gaines:I was an english major in school. We'll just cover the literary gamut if we can, yeah I, I'm up for that.
Charlotte Ward:I'm up for that. This could be, this could be uh, yeah, this is gonna be a an awesome, uh, multi-part series. I know it. Um, I have a feeling this is this. This is two parts. We may be extending our initial plan of six, do you think?
Kat Gaines:yeah, I think potentially.
Charlotte Ward:Yeah, it seems that way yeah, I think that's where we're going. Well, I'm looking forward to it. Thank you so much for joining me again today. Uh, lots more to talk about next time, uh, so I will see you then. Welcome back, I'll see you soon thank you so much.
Charlotte Ward:Thank you all. Right, there we go. All right, that was all I like. I I was trying to think about how I can. I felt like we were just straying into what you said. You and I was like I need to just kind of somewhere here how do we find? This spot? Yeah, yeah, did we. Did we miss anything from your attention?
Kat Gaines:no, those were kind of the three big points that I thought we wanted to cover the why, the just the general how for support, and then what does that stakeholder conversation look like?
Charlotte Ward:Yeah, yeah, yeah. Good, right into the nuts and bolts next time, then looking forward to that I'll get all excited about slack channels and stuff and dms. I may I may include a bit of a rant about dms, just to give you a heads up.
Kat Gaines:Yes, oh, I'll join that rant with you, that'll be fun yeah, it's.
Charlotte Ward:It's very easy to get angry about dms, isn't it? Extremely, extremely. That's it for today. Go to customersupportleaderscom, forward, slash 274 for the show notes and I'll see you next time.