Customer Support Leaders
Customer Support Leaders
277: Reducing Escalations Through Strategic Engineering Partnerships; with Robert Cabral
Unlock the secrets to mastering technical support as we, Robert Cabral and I, guide you through the art of enlisting engineering support for complex inquiries. You'll discover how data-driven strategies can transform your support processes, leading to a drastic reduction in ticket escalations. Robert shares his expertise on creating a robust taxonomy for categorizing issues, ensuring clarity and efficiency in resolving them. We promise you'll leave with actionable insights into improving collaboration between support and engineering—essential knowledge for anyone navigating the SaaS landscape of platforms like DataCamp.
Robert and I also delve into the power of empathy and continuous improvement in fostering a proactive support environment. By embedding support team members within engineering, we’ve not only improved communication but also decreased escalations from 40% to under 10%. Our conversation sheds light on the importance of strategic conversations, empathy-building, and securing engineering buy-in. Join us as we unravel the gradual journey of transforming support teams with small wins and iterative progress—your roadmap to a more efficient, less reactive customer service experience.
Hello and welcome to Episode 277 of the Customer Support Leaders Podcast. I'm Charlotte Ward Today. Welcome Robert Cabral, to talk about enlisting the help of engineering in your support tickets. I'd like to welcome to the podcast today, robert Cabral. Robert, it's lovely to have you guesting with me, coming on for a chat for the first time. Nice to meet you properly in this forum. I know we've had a couple of chats before we go into the recording today, but thank you for joining me and I'm very excited about today's topic. But first would you please introduce yourself for our listeners.
Robert Cabral:Sure, well, thanks for having me, charlotte, pleasure to be here. My name is Robert, I'm from New York and I've been in the customer support industry for over a decade, leading teams for about 10 years as well, and the industry that I've primarily been in has been educational technology, but I've also worked in a few other industries, and lots of my career has been about optimizing processes, building teams, scaling teams and hoping to touch on that a little bit today.
Charlotte Ward:Awesome, awesome, very cool, very cool. So we've had a couple of chats about topics, and I know we've got another one that we're thinking of lining up in the near future, I hope. But today we're talking about escalations, aren't we? By which we mean how we move a question or a problem from inside support to elsewhere in the business, and typically that would be engineering, right, sometimes product, but particularly engineering when we need, in this technical kind of support environment that you and I are in, when we need technical help from someone who knows the code from the inside, I guess would be the way I would put it.
Charlotte Ward:Um, so let's talk about, uh, the landscape, because not everyone is going to have this kind of environment where they need to access those deeper skills. I mean typically for maybe a more b2c environment or, say, retail, things like that. Um, access to other resources in the business would typically be to finance or maybe a product question, right, but? But we're really talking about access to, uh, technical skills. Aren't we different technical skills than you have inside support? What does that landscape look like for you?
Robert Cabral:yeah, so I've been working in in SaaS for the majority of my career and so software as a service for B2B customers and, like you're saying, typically those products are a little bit more technical, at least on the back end for the customer support team that's actually managing those inquiries, that's actually managing those inquiries. So you still get those very basic I forgot my password types of questions. But there's also much more complex questions that you get. For example, when I worked at DataCamp, the platform was for teaching data science. There was a coding platform within the platform that was part of it.
Robert Cabral:So we ran across all sorts of issues that were in some cases more technical. In some cases we didn't even know if it was a technical issue with the product or just something going on with the code the customer was entering. So we had those sorts of situations going on and the situation I'll just skip ahead there there were quite a few escalations early on because of that ambiguity, because of those gray areas there yeah, yeah, the gray areas do, uh, do, contribute to, to volume, don't they?
Charlotte Ward:um, what, um, what does quite a lot look like in terms of a percentage of all of your support tickets? How many would have been escalated typically in that kind of environment for you? And if you share your number, I'll share mine.
Robert Cabral:Yeah, I think initially it was somewhere around pretty large. I would say 30 to 40 percent were being escalated and part of those issues were the ones that I just described. Some of them were legitimate product issues on the backend. Others were because of a lack of tools that we didn't necessarily have. We didn't have the ability to resolve them, but it was a pretty high number.
Charlotte Ward:Yeah, I think. I think I can broadly say it's similar in in the role I'm currently in and and actually in previous roles too. Somewhere in that, somewhere for this really deeply technical support somewhere in that sort of 20 to 35 40, I think is not unusual. You know, I I wouldn't say it's desirable, but it's not unusual, I think. I think one of the things we need to talk about today is how you bring that down right.
Robert Cabral:Yeah, yeah. Well, coming from a company called DataCamp, I tend to look at the data quite a bit.
Charlotte Ward:Yeah.
Robert Cabral:So that really is my first step whenever faced with pretty much any issue, but especially one like this one. And if you look closely enough, the data is going to tell you a story. What are the patterns that you're seeing? Which tickets are being escalated the most? Why are they being escalated? And just start to do a little bit more digging. That might prompt you to actually talk to people, to get a little bit more color into what the numbers mean. That's typically the starting point what's going on? What is the story behind this? What you don't want to do is just jump right in and start assuming things and fixing things without actually knowing what's going on.
Charlotte Ward:Yeah, solutionizing right. Yeah, absolutely yeah, I agree, the data is the place to start, so, like winding that back even a little bit further is almost like having a good taxonomy, or tagging or whatever you want to call it. You know, categorization of some sort, so you can begin to drive conversations from those data, is crucial, and you made a really, really important point, which is that that tagging or taxonomy or categorization isn't just about the, what, it's about the why as well, so not just the product screen or the product area or the job to be done, but also why it's landed over there instead of being handled inside support. And I think that's really crucial, because there are going to be things that always need to be escalated. And I don't actually like that word, I'll be honest. I feel like it implies kind of a heightened sense of urgency, which isn't necessarily there. It shouldn't be there, by inference, let's say, but um, I I've yet to find a word that is just as easily kind of well understood in the industry, because I think of escalating, as you know, increasing urgency, increasing attention, but actually what we're really talking about is access to skills, right, but but the why, you know, is it, is it a knowledge gap? Is it a product gap? Is it? Uh, you know that there are really deeply specialized skills that actually you could only ever hope to access inside certain individuals or teams within the business. Um, you know what that there's? There's a multitude of things, isn't there? There's a multitude, obviously, there's bugs and all of all of that other stuff which is always going to land in engineering's lap.
Charlotte Ward:But, um, so I, I guess, I guess, when I think about the why, that has to then and and as you said, like, enrich that with those conversations um, that's my primary focus when it comes to looking at the data. For me personally is kind of what are the things that we, first of all, inside support, have agency over on the why front? So knowledge is a big one, isn't it? Because I think there's so much you can do inside support with knowledge, or or working, you know, collaborating with your engineering team to capture and get access to that knowledge, um, so it's more readily available inside the support team. I think that's a big one. What? What are the other kind of um whys that you might look at and how you might tackle them?
Robert Cabral:yeah. So I guess, leading up to that, you know, once, once I have the data, the next thing I'm going to do is basically share that internally, and that's where the conversations start. And you don't have to do it this way, but I like just creating a quick Google slides or PowerPoint presentation on what I'm seeing meeting with the team and then have more context there. And once we have that context, I'll actually work with the engineering team to get their why and try to understand what's going on on their side.
Robert Cabral:And a lot of times what's going on is that the escalations are going to one or two people when it comes to a specific area. So on the engineering side, that one person or those two people are feeling very overwhelmed, but then somebody else looks at it and says well, you know, maybe we should build a tool for this. It's pretty simple to address. Or, you know, maybe we could have a lunch and learn and just show the team how we actually solve this. It's not something that we need to change in the code, and or maybe it's just something that I can train the team on, you know?
Charlotte Ward:or maybe it's just something that I can train the team on, you know.
Robert Cabral:So I think from those conversations you also get a little bit of the solution, which is enablement through tools, through training and also through a better onboarding process as well. It helps inform me as a manager like what do I need to do better when I'm onboarding new reps?
Charlotte Ward:Yeah, yeah, that's very true, that's very true. And I also think something you said there has been typical of my experience that it's usually one or two engineers that are feeling the brunt of this because they are the specialists in a particular area. That is painful for customers, you know, or painful for the team yeah, yeah, for customers, you know, and all painful for the team, yeah, yeah. So what success have you seen, then, with this kind of approach of like applying data, looking at the why, starting let's look on the upper end of your band there of like bringing that down from 40%, I hope, bringing it down what sort of gains have you been able to make?
Robert Cabral:I guess spoiler.
Robert Cabral:We brought it down to under 10% and it took a took a little bit of time, a few months, to actually get everything in place, but that's the place where we were able to get and the solution was, you know, tools like we just building out, simple tools that took less time for the engineering team to build, to actually do all of these one-off solutions. There was also, you know, just training and internal knowledge base. So just building that out and just even better tagging as well, so that we could further categorize and really analyze it over time.
Charlotte Ward:So it was really a refining process over time. Yeah, yeah, that's really key, isn't it? And I think that you know, when we think about like that refinement, it's useful to think of our engineering teams as our support team. You know, we are their customers, so they're really, it's really to everyone's benefit that they come up with some sort of kind of tick effectively, ticket deflection plans as well, right, in terms of like, how they can enable you to self-serve, and that's really whether that is tooling or knowledge or a number of other things. I think.
Charlotte Ward:I think it's really actually, I would actually say that the conversations are a good part of like, um, like, engaging the engineers in that outcome as well, right, I think, I think they feel the pain, but, and unless you're able to kind of talk to them as a customer and like, express the wish to be able to self-serve and here's the data where we think we could self-serve then it's a, it's a unicorn of an engineer who's going to like, know what the problem is and go and find, go and create the tool for you or whatever, without that conversation and without you know, without being so motivated, I guess, um, yeah, so so you got that down to 110.
Charlotte Ward:That's amazing and um, I mean it's really amazing. Um, and the ongoing refinement I I guess those conversations also help in um make you know, bring some kind of regular cadence of review or some kind of process to this going forward, do they?
Robert Cabral:yeah so. So the conversations really help, I think, build empathy between both teams, because you know the engineering team they want to be working on actually building things. The support team wants to work on resolving issues. And when you start that conversation you realize, okay, both parties are actually trying to help each other out.
Robert Cabral:And you know it sort of breaks that siloed perception that everyone has, and both teams have new people all the time, new processes all the time, and I think it's a good reminder to just show where we're at when it comes to that and have that escalation metric be an ongoing metric and conversation, because the tools that the team built were very helpful for the first three months, but then three months later, we have new processes, a new product, new changes and we need to change things all over again. And the benefit of having these conversations and having the support team ingrained is that we did something which was product liaisons. We would embed support team members within engineering and now we were actively having these conversations. Engineering is thinking about building out this tool and the support team can raise their hand and say wait a minute, how do we debug this, this, this and this happens, and so we're being much more proactive instead of reactive and and that sort of maintains that escalation quite well yeah, and and this is uh.
Charlotte Ward:This is a mechanism that I'm hearing increasingly. It's something that I've done at my current place. I I don't call them product liaisons, I call them support champions, but same same. Like they are embedded with an engineering, like it's essentially a product delivery unit which is a product manager under an engineering team, you know um, doing much the same function I've. I have heard other places call them product liaisons as well. Maybe I should consider a rename, although I quite like support champion um.
Robert Cabral:I like it too.
Charlotte Ward:yeah, um, but yeah, I, I, I really like the idea because those are the people who know right and they can have those conversations um, much more proactively than filing a jira ticket and and letting it kind of run through due process, which, if you're lucky, is a couple of hours and if you're not so lucky, it's a couple of weeks or more. Let's face it. Yeah, yeah, no, that's cool. So I guess then, so number of escalations have gone down to less than 10%. How do you feel about the quality of the escalations over time? From where you were at 40%, what did the quality of those escalations look like, and what's the quality of them look like now? And I mean by quality, I mean really every aspect really every aspect.
Robert Cabral:Yeah, when, when I think of quality, I think of how much information are we sharing that's actually relevant and how effectively are we communicating not just the issue, but also the business impact of this issue. And initially I would say it was pretty poor. It was like this is going on, please fix it. And part of this conversation helped me sort of build the process and also work with engineering to figure out what do you guys actually need? What is helpful, what is helpful for you to resolve this issue as soon as possible that we can provide you in front and limit back and forth. So, yeah, the quality has improved drastically through this process and I think it's just going to continue to do so once you continue to maintain that relationship.
Charlotte Ward:For a number of reasons. Right, people have a bit more time they can self-serve and less just gets thrown over the fence. Exactly, a bit more time they can self-serve, and and less just gets thrown over the fence. Um, exactly, but. But? But also the expertise begins to build inside supports, which has a knock-on effect.
Charlotte Ward:Um, even though, even not processed or templatized, it definitely has a knock-on effect on the quality of the escalations and some of the things you're talking about. You know, just a a good level of basic handover and things like that are hard to do when you feel, as a support engineer or support agent, a bit in the dark, a bit like this is an unknown quantity of a technical issue for you and all you can do is just ask someone else to have a look at it. I think that's a really important point because actually, that saves a lot of time in the engineering teams as well. Uh, the sort of quality handovers just enables them to pick it up and run rather than doing a lot more discovery yeah, and those, those same support champions that you create.
Robert Cabral:They kind of become like an internal escalation point, whether it's official or not. They, you know they can handle things more effectively than the broader team can, because they're working with engineering more closely yeah, that's very, very true.
Charlotte Ward:I'm finding the same here, and I would bet other people are who are listening. So so let's wind this back to the beginning then and, uh, let's give some, some action. A couple of actionable points for the people listening. Um, yeah for those support engineers, uh, for those support leaders, uh and support engineers who are currently wading through a mire of uh jira tickets that are unloved and uh, you know, support tickets that are waiting on those unloved jira tickets and uh, it all feels a bit hopeless. What should they do today to get going?
Robert Cabral:yeah, I, I guess if I were to summarize everything, it would be look at the data and actually analyze it. And number two have conversations based on that data, both within the team and outside of the team, so that you understand the landscape, understand what your game plan is going to look like.
Robert Cabral:Number three is enablement and I guess, going back to the second one you also get buy-in from, from the engineering team, once they have a better understanding what's going on yeah yeah, once you have that buy-in, once you have that data and have those conversations, it's really about executing through training, enable, enablement, working with the engineering team and trying to get stuff built. And that's why the buy-in is important. If you share the impact of these issues and you know you can talk through how long it's going to take to build out those tools, versus resolving all of these one-off cases, that's how you build a case for yourself. And, yeah, I think if I'm not skipping over anything else, just continuing to maintain that relationship and monitor the quality of those escalations, like you mentioned warning that you made at the start is is that this is a journey of months, if not years, in, depending on the situation.
Charlotte Ward:Right, I think you, you cannot fix that kind of environment all in one step. You have to take one thing at a time and and actually that becomes part of the engagement with the engineering team that you're talking about um, you show one win, you make one engineer's life a little bit better, then they're all a little bit more motivated to engage and just uh, stop, like who wants that level of reactivity? And I know no engineer on the planet does. But frankly, even as a very reactive function, support doesn't really want that level of reactivity either. So so I think if we can all kind of find the early wins and use those to just start that cycle that you're talking about, find the next data point, tackle that one and figure out what the ROI is of a tool versus a training, versus, you know, self-serve for the customer themselves, whatever it might be Like.
Charlotte Ward:It's one step at a time, isn't it? Yeah, exactly, yeah, yeah, awesome. Thank you so much for this conversation, robert. It's, it's nice to, uh, it's nice to know that there is, uh, you know, uh hope out there for support leaders in in very similar situations and uh, yeah, you, you know, you, you, you you've completed this or well, you're in this journey. But you're definitely at the happier side of this journey than than some others out there and I can, I'm aspiring to below 10 percent. I know it's the environment, I mean right now, where you know where we are in that, in the early stages of applying data and getting the early wins in and actually turning that crank a few times. So I'm looking forward to under 10% myself.
Robert Cabral:Yeah, look for those little wins. That's what I always do, yeah absolutely.
Charlotte Ward:Yeah. Thank you so much for joining me today. Please do come back and have another conversation soon, won't you?
Robert Cabral:All right, thanks for having me.
Charlotte Ward:Thank you, that's it for today. Go to customersupportleaderscom. Forward. Slash 277 for the show notes and I'll see you next time.