Customer Support Leaders

262: Enhancing Everyone's Experience with Exceptional Supportability; with Alexis Grant

Charlotte Ward

Send us a text

Enhancing Everyone's Experience with Exceptional Supportability; with Alexis Grant

Unlock the secrets to crafting a B2B SaaS experience that customers love and support teams can rally behind. That's what we're bringing to the table with Alexis Grant

Alexis is a seasoned expert in B2B SaaS support, primarily as a support engineer for developer tools and tech products such as New Relic, HashiCorp, and Zapier, and is currently at Semgrep. She lives in Portland, Oregon with her cat and claims to only truly love two pieces of software: cURL and jq.

Together, we go diving headfirst into the concept of “supportability”. We chart the course for designing products that are not just powerful but also a breeze to support. Alexis imparts wisdom on how meticulously engineered reliability, predictability, scalability, and usability form the bedrock of products that practically support themselves. This episode is a treasure trove of insights for anyone keen on elevating their SaaS customer experience to new heights.
 
 Steering the conversation towards the empowerment of support teams, we dissect how vital knowledge sharing and the right tech stack can be in bolstering a team's capabilities. The introduction of a supportability checklist and the role of a 'support champion' come to light, detailing how they prepare new releases to face the frontline, fully equipped. We also stress the magic that happens when teams across the board—from support to product development—align their efforts. By embedding supportability into the DNA of every product cycle, we share how organizations can ensure operational success and deliver an unmatched customer experience. Tune in and transform your tech support experience!

Support the show

Charlotte Ward:

Hello and welcome to Episode 262 of the Customer Support Leaders Podcast. I'm Charlotte Ward. Today, welcome Alexis Grant to talk about supportability. I'd like to welcome to the podcast today Alexis Grant. Alexis, lovely to have you join me for the first time and I would love you to introduce yourself and then we'll talk about supportability today, which is a topic that's dear to my heart and, I know, dear to yours, but tell me why it's dear to yours by way of an introduction, will you.

Alexis Grant:

Yeah, thank you very much. I'm really excited to be talking with you about supportability. So I'm a support engineer. I've been in B2B SaaS support for over 10 years, mostly working for developer tool and technical products, so I've always been very focused on kind of the technical end. I've worked for companies including New Relic and HashiCorp in the past. I'm currently at SumGrep, which offers a suite of products for application security, and I've always been really interested in kind of working closely with engineers to improve the experience of support, because that's my experience.

Charlotte Ward:

Yeah yeah.

Charlotte Ward:

And because they've often been both my customers and my coworkers, it's a kind of person that I understand and really enjoy working closely with to try to improve the experience. Awesome, yeah, yeah. And I think, um, I, you know, I think that, particularly when you're getting into very technical spaces, supportability is just, it just has to be something you live and breathe, doesn't it? I mean, it's it's, it's a different beast. I think in a deeply technical organization, a deeply technical product, I think it becomes part of the process, and it becomes or at least I hope, and maybe that's what we'll talk about a bit on this session is how you make it part of the process. But it has to become part of the process ultimately, doesn't it? Because in enabling your support team, you're enabling your customers, because in that technical space, your customers are often working so closely with your support team anyway that we have to make sure we're able to deliver a good service, and that's impossible without a supportable product, isn't it?

Alexis Grant:

Yeah, and in particular for technical customers. They often really want to know the details behind why things are going wrong for them or what they need to do, and so the more detailed information that you can give them as a support person, the happier they're going to be as you try to work through them or, you know, work through their issues with them.

Charlotte Ward:

Yeah, yeah, absolutely, you know, work through their issues with them.

Alexis Grant:

Yeah, yeah, and I think you're right, yeah, it does have to be a part of the process and figuring out kind of in each organization where to slot it in can be kind of tricky.

Charlotte Ward:

Um, what's been your experience with that? Oh well, I, I think, I think for me, the you have to begin with, uh, talking about supportability as not just being about the support team. Actually, I, I think for me that the the key message to get across in the early days is supportability, is is about the customer at the end of the day, and and it it's a flow. You know, everything comes downstream, doesn't it? And? And if there are any hiccups in that, in that middle intersection, like where support sits between your product and your customer, then it's really hard to deliver a good support experience and therefore it's really hard, particularly for these kind of customers.

Alexis Grant:

It's really hard for them to get the value from the product, to to really activate and get full use of the product so so for me it's about making sure, it's about the customer first yeah, absolutely, and and I like to start talking about supportability with the thought that a supportable product is one that's also usable. Yes, the best support questions are the ones that never happen in the first place because the user you know, maybe they got a really helpful error message that said, hey, try this and they and they tried that and it worked and there's no support question.

Alexis Grant:

And inevitably there will be times when things go wrong, and if support can very quickly figure out what went wrong, then the customer's experience is better because you can correct it more quickly. Help them move through it all of that.

Charlotte Ward:

Yeah, usability is a key component. The other things I would lean into and I think usability touches some of these things and I think these are going to be more or less relevant, depending on the product. But I would also add, you know, reliability, predictability and scalability. Those are my big three reliability, predictabilityability, scalability. So usability actually sits across some of those. And when I think about usability from a customer point of view, I think actually it's about the predictability. If I do this, is the product going to behave itself and am I going to get the effect that I expect as a customer? And I think that's like the building blocks of usability, because if your product is just not, is failing, not giving helpful error messages or not giving customers the effect they want, you know, change that configuration and something completely unexpected happens, then I think you know that's where usability sits for me, right, it's the ability to to do things in a predictable way.

Alexis Grant:

Yeah, and I think scalability is a good one to include there, because if you have, you know, a small customer who you know maybe they want to delete a bunch of projects, is that easy for them, you know, maybe they need to delete five projects. They could do it all one, you know, all independently independently.

Charlotte Ward:

but like, but if someone wants to delete 500 projects, you're not going to want to do that all independently yeah, yeah and I I think, I think there's an arc to all of these things, and particularly on scalability, which is that in the early days, say, either of a business or of a, a new product or even just a new product feature, when something's a bit more experimental, it's okay to invest a bit more human effort into supporting it. So to your point, if that thing doing that thing five times for a customer is quite a lot of work, that's okay for a while. But as you acquire more customers, or customers do more of the same thing, scalability is important because you're very quickly going to go off the deep end if that ramps up in any meaningful way for your business, right.

Alexis Grant:

Yeah, and that kind of gets to the question of like when do you think about supportability in the process? And I think very frequently it comes in on the later side, especially in fast moving SaaS companies, and that's not necessarily a bad thing as long as it happens. But it is also really useful to think about it early on and think like can we build this in a way that's like supportable and scalable from the beginning and then we don't have to worry about that? Or is that too much work right now and we need to see if people actually want this feature before we do that?

Charlotte Ward:

Yeah, yeah, and I think, absolutely like in the experimental phase, you can have a relatively high tolerance for some things, but what you don't want to do is bake in problems later on. I think that's the if I was to get in early at any organisation and say you know what? You can throw a lot of supportability to one side just for now, but please don't bake in extra work later on, like just just if that's the only thing you do right now, on day one. Just don't make you know future supports work harder, for the sake of it. Um so, you know, be experimental, but don't code yourself into a corner, for goodness sake yeah, absolutely what.

Alexis Grant:

What do you think tend to think of as the most important topics, kind of for supportability.

Charlotte Ward:

I have my own list, but I'm super curious what yours would be um, I, I think finding the right time to get humans out is important. I think that's uh, that's a big one. Um, I think so much of this is going to be product and organization dependent, I guess for me also, um, in like, making sure that your support team is enabled to solve the problems even before the customer. So you know, you talked a while ago about, like, isn't it great if we avoid a support ticket altogether? Yes, it is.

Charlotte Ward:

But I think, taking, if you can think of support being the customers of engineering, isn't it great if support don't even have to escalate to engineering as well? So, like, let's like reduce the escalations, and I think a lot of that sits in enablement from a knowledge point of view and a tooling point of view. So so I think, I think it has to. You're almost pushing from the top, like reduce the escalations and then, and then reduce the tickets ultimately at the end of the day. But, um, so I think for me it's, I think for me it's uh, it's enablement and like I mean I'm going to come back to that don't, don't bake problems in early on, that you're going to have to pay for later.

Alexis Grant:

Yeah, yeah, I wonder if it it might be my perspective as kind of an IC, as like the recipient of that kind of enablement that I get like to get really specific about it.

Charlotte Ward:

So I have this nice little list. Yeah, I have this nice little list.

Alexis Grant:

Yeah, I have this nice little list and it does depend on the product. So every time that I've written the list it's a little different, but it always has logging and monitoring. So you know, does the product tell you what it did? If it didn't do the, it didn't do the right thing especially. Yeah, and you know, error handling like did you know, is the customer facing error message makes sense if there's no customer facing error message cause it's too sensitive or something, is it something support can get to you?

Charlotte Ward:

know, do you?

Alexis Grant:

have tooling and training for support. Um maybe, maybe you've been in a situation where there always is enablement, sometimes there isn't.

Alexis Grant:

I don't think any support team has ever been in that situation yeah, so it's certainly not me, um, but depending on where you are, you might have more or less structure around this, I guess, um, and so I've, I've sort of said, you know, like, is it like within existing tools, you know, are there new tools that you're using? Can you keep us from having to learn to use the new tools maybe? Yeah, that's always a little bit of a dubious ask. Yeah, yeah, just like there's, there's stuff that you don't want to tell users, but it just you're gonna need to know as support. Like, hey, this reacts very strangely, you know, with this one weird feature that we have.

Charlotte Ward:

Uh, yes maybe like a beta or something yeah, and I think I think that's part of like. I think a lot not everything, I mean observability and uh, measurement and things like that are a big part, depending on the product, right but but a lot of what you've touched on there one way or another is is knowledge management and I, I think I think I would include that kind of we know that this thing that we've just built doesn't work under this very specific set of circumstances. Let's not keep that secret inside engineering. Let's just tell the support team and I think that enablement that whole knowledge transfer piece touches across all of the things you've just described, like the, the troubleshooting guides, you know, meaningful alert playbooks, things like that and uh, so much of that is just good knowledge management and knowledge transfer practices, I think. And it's important. Who should drive it?

Alexis Grant:

yeah, I was gonna ask you that question, so I guess I'll have to answer it myself I.

Charlotte Ward:

I got there first.

Alexis Grant:

Fair enough.

Charlotte Ward:

And I'm the host, you know so my prerogative.

Alexis Grant:

Also fair? I don't know if there's one answer to that question. I have had the role of being one of the people who drives that quite often and what I find is that, depending on the size of the organization, you might need sort of multiple people on the support side and kind of multiple people on the engineering side. Or maybe, if it's a smaller org, you just need kind of one of each or a couple of each, or one support and a couple of engineers, or you might do it per product. But there has to be this kind of recognition that it's a thing that needs to happen. And, as you were talking about sort of process, you know, maybe it's part of the scope or or you have, you know, pre created like tickets, that kind of remind people that they need to do it. So it's a little bit about that people aspect and it's also a little bit about institutionalizing the process.

Charlotte Ward:

Yeah, yeah, I think there's collective yeah, collective responsibility.

Alexis Grant:

And then I'd be curious like how do you approach like you're more of a manager, so how do you approach kind of the management and executive buy-in on that kind of thing?

Charlotte Ward:

Yeah, I mean, I think you're absolutely right, it's collective responsibility. What I've done is essentially kind of we've touched on it a bit. I mean, have a checklist, you know, have your supportability checklist and get buy-in from that. And I think that buy-in, largely, is easy to get if you can back it up with data. These are the situations where we just didn't get the knowledge. Or these are the situations where we just didn't get the knowledge, or these are the situations where we didn't have the tooling and look at what a terrible situation it left us in.

Charlotte Ward:

Look all, I mean, if you've got clear-cut metrics like that, you know, like certainly you know, typically you'd be looking at escalations, for instance. Then, um, no engineering team wants to be spending all their time just sitting effectively in the support queue. You know so. So I, for me, it's, it's, maybe it may be data around escalations is an obvious one. Like how can we reduce this? Again, thinking of your support team as the customer of your engineering teams. In the same way as we would want our customers to be able to solve their own problems, an engineering team really would want a support team to solve its own problems. So, looking at the causes where tickets escaped support and got pushed up to engineering. I think is a big one, and that can be tackled depending what your data looks like. In so many ways. It might be knowledge, it might be tooling, it might be, you know, front-loading, some sandboxing or something like that.

Charlotte Ward:

It might be, you know, front loading, some sandboxing or something like that, and I've got. Ultimately, what I've done is I have this idea of a supportability checklist, which is my slightly more palatable phrase for acceptance criteria, and it has a lot of the things on it that you described. So I set up a key stakeholder inside support. We call them a support champion. We have a support champion for every new product and it has a lot of the things on it that you described. So I set up a key stakeholder inside support. We call them a support champion. We have a support champion for every new product, new feature, major new version of an existing component, things like that. Where things dramatically change. We assign a support champion to be the main point of contact and to ensure that we run the supportability checklist for that thing.

Charlotte Ward:

And then on there I've got things like sand, you know, do we have a sandbox environment? Do we have um market? Like access to marketing, actually the you know the value statements for this thing we've just built um support is often left out of that loop, and so you end up with a support team that's overly focused on solving the technical problem rather than trying to get the customer to the place this thing is supposed to get them. So I think it's really important to include your support team in your marketing efforts, your product marketing efforts as well. Um, training, knowledge transfer, all of that observability, all of that is on that checklist and that's all been driven, ultimately, by the kind of escalations and things that that we see. Um, and what could have stopped those escalations? You know, stop that work getting outside of support, which is really what it's about yeah, that's, that's definitely a compelling value point.

Alexis Grant:

I've found, uh, to sort of say like hey, you know, we're, we're sending you a lot of escalations about this thing, and then sometimes even as a first step, like why don't we just make sure that we know absolutely how we should send you those escalations? What information?

Charlotte Ward:

Absolutely.

Alexis Grant:

We don't have this kind of churn around it. And then you go from there to like, hey, what if you didn't have to do this? What if this is self-service? Yeah.

Charlotte Ward:

So I actually have a great example of that.

Alexis Grant:

Yeah, so I actually have a great example of that We've. We have some challenges with like authentication configuration and we were making a lot of escalations on that and kind of. I don't think we played as much data into this as would have been kind of ideal, but we did have data saying this was a big case driver for us and eventually the team that was responsible for this was like okay, you've been asking us to do this a lot Like we're actually just going to give you a way to do it. I think they just kind of took it into their own hands and I was like this is great actually, and I've made sure to be really, you know, sort of publicly grateful to them for taking that kind of initiative and I think having that carrot could be really nice, because sometimes you have a lot of sticks of like.

Charlotte Ward:

this was a bad situation we could have avoided instead of like this is a good situation, where we did avoid the bad situation very true, very true that, yeah, that's great and and I think you know, I think the other thing that demonstrates is to your point earlier a little bit about it being a collaborative effort is that so much of this is not just push or pull, it's a bit of both. You know it has to be and that's that collaboration. You know, you kind of know what you need and certainly you develop a bit of a spidey sense for it over the years. But also, like, just sit down with the people who are producing this stuff and come up with you know what between you you think is a reasonable set of expectations, which is really what we're talking about in terms of, like checklists and things like that. It's what can you give me and actually what I think I need, and particularly kicking off supportability for a new product or new feature.

Charlotte Ward:

You've got to start there. It's got to be a bit of push and pull, I think, but then that just carries on right. Got to start there. It's got to be a bit of push and pull, I think, um, but then that just carries on right, as you just described, like there will be ideas, because engineers don't want those escalations either. Whether, whether they're, you know whether they're, whether they're technical escalations that are caused by problems, or whether it's just, you know, repeated requests for the same thing? Um, yeah, uh, directly or implied I?

Alexis Grant:

I think it's all a bit of push and pull yeah, I think that's definitely true and and I love, I love the people who push. I mean, at one point I remember getting asked by an engineer like hey, where are their docs like docs written for this. And I was like oh, engineers who ask me if I wrote docs for something, I like that like oh, engineers who ask me if I wrote docs for something, I like that.

Alexis Grant:

Yes, yeah, yeah, it's amazing, um, so I think it's it's challenging to to sometimes cultivate these like less tangible things of like the culture of supportability, um, but but I really love trying to do that and and kind of highlighting, like I was saying, kind of highlighting when it does work and these things about like kind of establishing empathy. So one cool thing is, like both support and engineering speak the language of reproduction, and so often you can kind of find a common ground of like hey, we reproduced this issue. And then you realize like okay, both of us are kind of looking for the same thing here in a way, even though our like focuses are different yeah, yeah, absolutely, absolutely, um.

Charlotte Ward:

The. The other thing that, um, I I think is quite nice just on the note of like loving people who just push, push the stuff down is is um, is that I think when that happens, more that's when you are, for me that's quite gratifying because I think that's that speaks to having had an influence on the culture. You know when, when you spot that shift from like I'm having to drag this stuff out of engineering all the time to hey, guys, what do you need? Like I mean it's, it's, it's. For me it's like the light bulb. Sometimes in some organizations I've worked with, it's just gone on. You know, um, and like actually, actually this isn't, there's no tension here, it's, it's, it's for the benefit of all of us.

Charlotte Ward:

And, uh, you know some organizations that I've worked in, um, that has been easier to achieve than others, that's for sure. And I mean going back to the early 2000s, like downright real tension between support and engineering. You know, like we're fighting different fights, which is not the place you want to be, and actually supportability is just off the map completely by that point, I think. And it's all everyone for themselves. And I think if you can get in there early enough and make that culture shift, then you get a lot more people pushing, that's for sure, pushing towards you rather than trying to run off in the opposite direction.

Alexis Grant:

Yes, I've definitely been the person who's greeted by like oh no, if you're coming my way, it means there must be a problem. It's like that could be a challenge. Yeah, but in general, you want to also be a person who's welcomed because you bring insights yeah, yeah, absolutely, absolutely.

Charlotte Ward:

What? Um, what's your in terms of the people who should get involved? Do you think it has to be? You know, I mean, in some organizations it's a dedicated role, isn't it? But in that early stage, who are the key players, do you think?

Alexis Grant:

That's a really good question. I would say. If you're in a pretty early stage, whoever is kind of the head of support or one of the major managers is a really important person to kind of have backing you up. Also, somebody like the VP of Eng or the CTO, to at least have them understand your goal and be supportive of it is very important goal and be supportive of it is very important. And then I think beyond that, cultivating this teamwork idea.

Alexis Grant:

If you have multiple different teams, you know, with those team leads, maybe with the managers of the teams it's not that every single one of them is essential, but you kind of cultivate that sort of relationship. And on the support side, people who are more oriented toward kind of like bug tracking and like proactive work, um, and maybe people who need new challenges. Sometimes you know you're sort of you're a person in support and you're like I'm just like chugging through the tickets and then you're like I could be doing more and and sort of those people who are like I want to to do more, I want to improve this, like those are good people to think about. And I've never done it as a fully dedicated role. I've always been also partly frontline and I think that's really beneficial because you're actually seeing what happens.

Alexis Grant:

So I think that's one tricky thing about the dedicated role on the support side about the, the dedicated role on the support side.

Charlotte Ward:

Yeah, yeah, I agree, I agree, and and actually to your point, um, it's, it's a really good opportunity for for growing someone I think getting, because it's very cross-functional, it's very nature. Everything we've talked about is cross-functional, I think, and I I would say, yeah, if you've got people as a leader, if you've got people on the like that on your team, then use their enthusiasm for working across the business, cause this is one thing where they will have a huge impact very quickly, um, if they throw themselves into it. The. The other, the other stakeholder that I think about is product. You know, the product team as opposed to the engineering team. And this just goes back to what I was saying right at the start, which is just don't bake in problems for future. You and I think that begins in product design even more so than engineering, I mean, obviously engineering are in there sometimes creating problems for us as well, but the same goes for products.

Charlotte Ward:

So I think, if you can get that buy-in on supportability, particularly when it comes to things like self-service, um, and just enabling customers to solve their own problems, um, you know, reset their own passwords is always the classic example isn't it you know, like that, that's a product decision though, right and uh, and so I think I think getting product on side is really important too, and I think they are, they have to be part of the conversation if you want to prevent.

Alexis Grant:

Prevent, you know, those problems getting baked in yeah, I think that that connects also to what you're talking about with the launch to to kind of consider, like with product launches, like you're not just considering the technical enablement but you're also considering like what's the value of this product, what problems is it solving? That you know users have been seeing what problems is solving that support has been seeing, and that can often the product cycle, because there's sort of this marketing stuff. It's very official, like can be a little bit easier to get plugged into and then you can kind of try to plug a little further into the engineering stuff yeah, yeah, I yeah, absolutely.

Charlotte Ward:

I think all of these things have their own, their own kind of uh um runbook effectively, but but it's finding how they, how they, weave together, and I think that one thing that's super important is not to think of supportability, that, as something that you do after the code is written you know, yes, absolutely it's like we're not going to write the whole thing and then, and then, right now, we're going to think about how we support it.

Charlotte Ward:

It has to be early on, and and so I think it becomes part of any kind of release readiness as well, then. Which is product, it's marketing, it's everything, because you choose the moments where different bits of your checklist or your supportability plan, whatever it looks like, weave in. So you know that value statement. Early sandboxing come way earlier than maybe like ensuring that you know you've got the right playbooks. You know the day before go live, you know so. So I think understanding like and again, that's a great opportunity for somebody who's got the appetite for growth inside a support team is to see how actually quite a lot of the business functions quite differently from support and and where we fit into it and where we should be a key stakeholder. It comes down to kind of getting that seat at the table, doesn't it?

Alexis Grant:

Yeah, it definitely does. You have to kind of plug into the different processes at the right point. It was actually one of the first questions that my career manager asked me when I was showing him this checklist. He's like, so what part of this happens at what part of the release phase? And I was like, oh, that seems like a good thing to write down. Yeah, should maybe write that down. Yeah, good call, yeah, yeah, and that's been important for us to kind of like because every engineering org has kind of existing release processes and marketing orgs. And you got to plug into that and not just come and say like I need to bolt this on because nobody wants to do an extra bolted on thing.

Charlotte Ward:

Yeah, yeah, yeah. Make it part of their processes as much as yours. Absolutely, yeah, yeah, exactly, I couldn't agree more, I couldn't. For which you've got to get their buy-in, which takes us neatly back to where we started.

Alexis Grant:

Sure does. Yeah, if there's anything I've learned, I think it's the buy-in is really the most important part of any effort that you do yeah, very true, very true.

Charlotte Ward:

Um, thank you for talking us through your checklist a bit, alexis, that's been great, and and for listening to bits of mine. Um, it's always good to compare a checklist. I think, um, yeah, um, will you come back another time and talk to us a bit more about support engineering more generally, because I know, I know, that you've got lots of stuff to talk about there. I can just feel it.

Alexis Grant:

Oh, I would love to. That's so nice. Yeah, it's been a pleasure chatting.

Charlotte Ward:

Thank you so much and I'll talk to you again soon, then. Thank you, that's it for today. Go to customersupportleaderscom, forward slash 262 for the show notes and I'll see you next time.