311: Stop Escalating And Start Routing; with Alex Batchelor

WEBVTT
00:00:12.080 --> 00:00:17.600
Hello and welcome to episode 311 of the Customer Support Leaders Podcast.
00:00:17.600 --> 00:00:19.199
I'm Charlotte Ward.
00:00:19.199 --> 00:00:28.160
Today Alex Batchelor talks about how support can solve more by partnering with engineering.
00:00:28.160 --> 00:00:36.960
Alex, thank you so much for joining me today for the first time.
00:00:36.960 --> 00:00:38.560
It's lovely to see you.
00:00:38.560 --> 00:00:41.280
Lovely to see you too, Charlotte.
00:00:41.280 --> 00:00:47.520
Now, uh, you haven't been on the podcast before, and indeed, I think is this your first podcast?
00:00:47.520 --> 00:00:50.079
It's actually my second podcast.
00:00:50.079 --> 00:00:53.439
Your second, so you've done one since we lined this up.
00:00:53.439 --> 00:00:55.520
Oh my goodness, I should have been faster.
00:00:55.520 --> 00:00:56.479
I'm so sorry.
00:00:56.479 --> 00:01:00.880
Um, I'm I'm glad to have caught you now, a seasons podcast seasoned podcast guest.
00:01:00.880 --> 00:01:01.840
Season podcast.
00:01:01.840 --> 00:01:03.600
I'm basically famous now.
00:01:03.600 --> 00:01:05.120
Basically famous.
00:01:05.120 --> 00:01:05.920
Uh love it.
00:01:05.920 --> 00:01:13.120
Um for for the people who don't know you through your fame, um, would you please would you please introduce yourself?
00:01:13.120 --> 00:01:14.719
Tell us who you are, what you're doing.
00:01:15.120 --> 00:01:15.599
Yes.
00:01:15.599 --> 00:01:18.319
Um, so uh I'm Alex Batchelor.
00:01:18.319 --> 00:01:21.439
I am the founder and CEO of Pebble.
00:01:21.439 --> 00:01:26.480
Pebble is a technical support resolution platform.
00:01:26.480 --> 00:01:31.439
We integrate with a whole bunch of help desks and desk intercom.
00:01:31.439 --> 00:01:55.359
Um, you seem to be Help Scout, Salesforce, and we help support folks take on um more technical issues, and we give them the context and kind of engineering information um to be able to very quickly debug and understand technical issues that customers are running into.
00:01:55.359 --> 00:02:01.760
And um, we're also very into using our own product for our own support.
00:02:01.760 --> 00:02:08.960
So um I'm kind of hands-on doing support every day with our customers and using our product to do it.
00:02:08.960 --> 00:02:13.039
So kind of half CEO hat, half support leader hat.
00:02:13.120 --> 00:02:20.960
That's all all the best, uh all the best support leaders, I think, have uh got deeply into the product at some point as well or other.
00:02:20.960 --> 00:02:32.159
Um whether it's through doing support, like not necessarily actually building, but like spending a lot of time in the product or uh, you know, building it.
00:02:32.159 --> 00:02:39.120
Like at some point you have to, I think, just kind of get in there and understand things.
00:02:39.120 --> 00:02:43.120
Um enough, anyway, I think I think is the point.
00:02:43.360 --> 00:02:54.000
Um I saw I saw a really wonderful talk last year um from um a woman called Meg Adams, I think I think that's her name.
00:02:54.000 --> 00:02:56.080
Um she works for New York Times Cooking.
00:02:56.080 --> 00:03:12.639
And she was talking about how as a leader she actually does this thing that kind of seems like micromanagement, where she will like jump in and work as an IC on her teams for a week.
00:03:12.639 --> 00:03:22.639
And she'll do like all the regular work that they do, and then then kind of like give the the leader feedback each day about how the team runs.
00:03:22.639 --> 00:03:37.280
And I feel like that's a she was using it for engineering, but I think it could be something that's really powerful for support leaders as well, where they like pop, you know, pop in and out of like being an IC and seeing what it's like and and running the team.
00:03:37.680 --> 00:03:47.919
You know, I actually think from a support point of view, um there is a lot, just generally, there is a lot of value in anyone in the organization doing support.
00:03:47.919 --> 00:04:18.160
Um I think it's such good proving ground for understanding the product, obviously, but understanding the customers, understanding the kind of challenging challenges they're facing, and why certain requests are popping up and why your support team is like behaving like you know, manic chickens or uh, you know, all sorts of other like uh maybe uh other busy animal references.
00:04:18.160 --> 00:04:35.839
Um uh like yeah, I I just think that um understanding why your customers are behaving how they are behaving and why they're asking the questions they are asking, as well as how that then has echoes in your support team, which then echoes in your organization.
00:04:35.839 --> 00:04:46.720
Um, I think it's a really valuable use of time, even if you only do it for half an hour, and even if you don't have the technical knowledge to get into the product, sitting alongside the support team is valuable time, isn't it?
00:04:46.720 --> 00:04:48.240
It's it's time well spent.
00:04:48.560 --> 00:04:48.879
Yeah.
00:04:48.879 --> 00:05:14.399
And actually, for you know, what today we're gonna talk about support and engine engineering collaboration and engineering getting in involved, especially because normally engineering only sees the fraction of tickets where they actually need to like make a fix or um answer a really deeply technical question.
00:05:14.399 --> 00:05:30.079
And actually a whole bunch of those like frontline issues that um that supports handling without engineering it engineering should be seeing too, to like see oh, where actually is the product unclear?
00:05:30.079 --> 00:05:41.040
And there are patterns in how we design the product that would make it more straightforward to understand without documentation and and help along the way.
00:05:41.040 --> 00:05:49.279
Or maybe there's a pattern of um things that people are trying to do that's outside our scope, but maybe that's a new product to build.
00:05:50.160 --> 00:06:01.040
Yeah, um patterns are really uh I I think that um when we're talking about patterns and uh servicing them inside engineering, inside the product team, um as well.
00:06:01.040 --> 00:06:08.959
The I you know, I think I think the fallback is so often like here's some data.
00:06:08.959 --> 00:06:10.399
Here's some data.
00:06:10.399 --> 00:06:17.120
And and I do think that patterns are at a data level very, very important.
00:06:17.120 --> 00:06:34.079
Like I wouldn't ever say you can sit happily at the data end of the spectrum and just keep feeling like feeding, you know, data points on usage or ticket volumes on certain feature of you know, features in the product or whatever back to product and engineering.
00:06:34.079 --> 00:06:35.920
But also the same is true at the other end.
00:06:35.920 --> 00:07:04.000
Like I think that engineer like my my kind of perception is that engineering and product people who deep dive on a tiny subset of tickets and then overindex to that is kind of it it's such a narrow view, like it just requires you to get one slice and suddenly like you're in that kind of parable of the men and the elephant where you only see the trunk or you only see the leg or something, and like you don't see the whole picture.
00:07:04.000 --> 00:07:15.279
So I think when when I think about the value in what support teams can give product and engineering teams, it it's the whole it has to be the whole package.
00:07:15.279 --> 00:07:31.839
And so it is verbatims, it is actual experiences and complaints or requests, it is also the data, and it is it is also that increasingly AI-enabled middle ground, which is there's some here's some data-informed insights, right?
00:07:31.839 --> 00:07:37.279
And I think that can be really powerful because if you sit at one end or the other, you're missing the point somehow.
00:07:37.600 --> 00:07:39.279
Yes, yeah, yeah.
00:07:39.279 --> 00:07:58.720
I always like to myself, I find it I'll start with an example and um go and find a specific example of something happening, and then I'll build the metric that shows this happens repeatedly or not.
00:07:59.199 --> 00:08:00.959
Yeah, yeah, yeah, exactly.
00:08:00.959 --> 00:08:02.160
That's often the case.
00:08:02.160 --> 00:08:18.800
Um, the example can be, you know, you've spotted some particularly unhappy customer or two, or uh, you know, a kind of passing comment from one of the support team as a support leader in your one-to-one with them, where they say, you know what, this is becoming a pain in the ass, or whatever, right?
00:08:18.800 --> 00:08:26.480
It's just you just need that signal, and then you can deep dive on the data and get the supporting experiences and everything else.
00:08:26.480 --> 00:08:29.680
And and support has a lot of signals, doesn't it?
00:08:29.680 --> 00:08:31.680
Yes, yes, exactly.
00:08:31.680 --> 00:08:32.480
Yeah, yeah.
00:08:32.480 --> 00:08:39.679
So, so I I think like we are here to talk about like how we can improve, how we can work with.
00:08:39.679 --> 00:09:25.840
And I think for me, the um the the with the partnership element, the the the kind of thinking about the the relationship and the symbiosis between support and engineering teams is really um, I mean, for a start, so often um traditionally support teams have used this kind of language of escalating, almost like engineering is I I mean, obviously they they they have more in like more knowledge of how particular bits of the system work, and you know, they are more possibly empowered in terms of tooling or or time or or uh you know uh like deep product knowledge about a particular slice of the product.
00:09:25.840 --> 00:09:59.840
Um and so we kind of we have historically, I think, anyway, almost like imbued our engineering teams with this kind of aura of expertise, which isn't inaccurate, but I think it um somehow demotes the support folk, um, uh even inside deeply technical organizations, to um, if we use this language of escalation, which implies more attention, more expertise, and everything else, we kind of end up demoting our support folks to just people who are passing the messaging back.
00:09:59.840 --> 00:10:16.000
Um, and so I really like I really like using different language because I think it talks much more to the partnership and the relationship and the symbiosis, which we actually should be um uh the the relationship we should be growing with our engineering teams, right?
00:10:16.000 --> 00:10:19.600
So I so I I never use it escalating, I always use routing.
00:10:19.600 --> 00:10:25.919
We're rooting this to another team because that routing language you can use sideways as well as back deeper into the organization.
00:10:25.919 --> 00:10:30.320
There's a a ticket can root anywhere if you just need something else.
00:10:30.639 --> 00:10:32.720
Yes, I I totally agree.
00:10:32.720 --> 00:10:36.080
I like the example when you first taught me about this.
00:10:36.080 --> 00:10:42.720
The example you used was you wouldn't escalate to finance if you ask a finance question.
00:10:42.720 --> 00:10:45.679
You would just ask them route to finance.
00:10:45.679 --> 00:10:52.720
It's they have a different skill set from your team skill set, and that's why you're rooting to them.
00:10:52.720 --> 00:10:56.639
And I think it should be the same with engineering.
00:10:56.960 --> 00:10:58.399
Yeah, absolutely, 100%.
00:10:58.399 --> 00:11:23.519
It is it's exactly that, it's a different skill set, it's not it's not it's not cleverer, it's not you know, it's not uh it's not, you know, uh access to something that um you know is gate or should be gate-kept in any way, is just access to different people, different skills.
00:11:23.519 --> 00:11:25.759
And um, yeah, I wouldn't root to finance.
00:11:25.759 --> 00:11:28.639
I'm sorry, I wouldn't escalate to finance, I would root to finance.
00:11:28.639 --> 00:11:33.519
Or, you know, to use similar language, I might pass this question over to the CSM or something.
00:11:33.519 --> 00:11:45.120
You know, it's like I never escalate unless to me, escalation talks about increasing the level of activity and attention on something rather than just getting access to a different person.
00:11:45.120 --> 00:11:59.840
And so I I think this also enables like the um clarity, this gives clarity to what escalating actually means, which in my mind is that it's like we need more attention, this is more important for some reason.
00:11:59.840 --> 00:12:15.600
So it's increased in priority, we need more attention on it, it has commercial risk, it has, you know, um, there are any number of reasons why you want might want more people to give more attention to and give a heightened um response to.
00:12:15.600 --> 00:12:19.120
And that's what I use escalating for, not routing.
00:12:19.519 --> 00:12:21.120
Yes, yeah, exactly.
00:12:21.120 --> 00:12:21.919
Yeah.
00:12:21.919 --> 00:12:33.279
Um yeah, and often we know that those issues that escalate to engineering actually end up going into a black hole when no one knows what's happening with them.
00:12:33.600 --> 00:12:43.759
Yeah, and I think I actually think, and one final example which I've just thought of, so I'm gonna say it, is um is uh the the the obverse is true as well.
00:12:43.759 --> 00:12:50.320
I think you would never escalate to finance, but also you would never escalate a feature request.
00:12:51.039 --> 00:12:52.000
Yeah, yeah.
00:12:52.240 --> 00:12:58.240
And you would pass it to your engineering teams, but you wouldn't ever say to a customer, thank you for asking for that red button to be blue.
00:12:58.240 --> 00:12:59.840
I'll escalate that to engineering.
00:12:59.840 --> 00:13:03.440
That's that's like there's a dissonance there which doesn't fit either.
00:13:03.440 --> 00:13:06.559
So I'm gonna pass it to the right people, is what I'm gonna do.
00:13:06.559 --> 00:13:09.039
All right, I think we I think we've made the point.
00:13:09.039 --> 00:13:12.320
We're no longer escalating, we're rooting.
00:13:12.320 --> 00:13:16.080
And so, and in that environment, we're passing things around.
00:13:16.080 --> 00:13:25.759
That's literally what routing is, and so there's a lot of opportunities for communication, for collaboration, for partnership, which is where we kind of began this.
00:13:25.759 --> 00:13:40.559
And so um, when we're talking about that collaboration and those insights, then, and and we are passing and routing messages around uh at the insights level or ticket by ticket, and both both are certainly true.
00:13:40.559 --> 00:13:46.559
What um what opportunities does that create if we break down those barriers?
00:13:47.200 --> 00:13:48.480
Yeah, yeah.
00:13:48.480 --> 00:13:52.159
Um there's there's a couple of different things.
00:13:52.159 --> 00:14:18.559
One of the reason that I started Pebble was in my last company, I was um was running an engineering team, and my team was constantly getting pulled between answering questions for um for the support team and fixing issues that customers were running into um and trying to build all the new features that customers wanted.
00:14:18.559 --> 00:14:48.639
And so my kind of mission in starting Pebble was actually to enable support teams to be able to self-serve and take on um more of the more kind of kind of take on some responsibility from engineering and be able to um have all the context that engineering has to answer questions, um, and have also the the kind of knowledge needed to answer a question.
00:14:48.639 --> 00:15:03.440
Um and then kind of be able to protect engineering's um focus a little bit on whatever project they happen to be working on at the time.
00:15:03.440 --> 00:15:10.559
And um, so so that was kind of one of the things that that we're trying to do.
00:15:10.559 --> 00:15:20.879
But um the other side of it is that actually we don't want to reduce in doing that, we don't want to reduce the information that is going to achieve.
00:15:20.879 --> 00:15:35.600
So we might want to enable, okay, support's already working on this issue, let's enable them to self-serve, um, rather than having to um distract someone that isn't working on the issue yet.
00:15:35.600 --> 00:15:56.480
Um but then how do we enable support to actually aggregate all the learning and like share that back so that um you actually improve the product over time through the all the rich feedback that that support is getting from customers and learning from working with customers.
00:15:57.039 --> 00:15:59.519
So um it's interesting.
00:15:59.519 --> 00:16:12.799
It's interesting there because you touched on protecting engineers' time, which I actually think is where some of the problems begin with this kind of idea that engineering is some sort of ivory tower and therefore we escalate to them.
00:16:12.799 --> 00:16:14.320
And all of that I'm not gonna touch on.
00:16:14.320 --> 00:16:15.840
I've done that hobby horse to death.
00:16:15.840 --> 00:16:18.480
I'm not gonna touch on that again this talk, this podcast.
00:16:18.480 --> 00:16:22.879
But I think like this idea that I think that's where it began, right?
00:16:22.879 --> 00:16:24.720
Like engineering needs to be protected.
00:16:24.720 --> 00:16:30.000
They live in this bubble, like, and and we post things over to them and then they disappear.
00:16:30.000 --> 00:16:40.399
But but what you're talking about is actually, yes, it's protecting engineers' time because you kind of, I suppose, have this kind of vehicle to carry those insights.
00:16:40.399 --> 00:17:07.279
You know, it's kind of well formatted, it's data-driven, it's packaged, everything else, um, which means it makes it consumable in a way that perhaps just throwing ticket by ticket by ticket isn't um and is hard for um engine it is easy for engineers to be distracted by potentially, um both in terms of time, but also in terms of focus, focusing on the right thing.
00:17:07.519 --> 00:17:19.680
Um Yeah, and I think it's not when I say protecting engineering is time, I'm not trying to say that engineering is like, you know, it's protected.
00:17:19.839 --> 00:17:23.039
Um Yeah, no, but I think that's the historic view often, right?
00:17:23.039 --> 00:17:31.200
Which I think is where that whereas which is where that escalating language probably was born somewhere, you know, three dec decades ago.
00:17:31.200 --> 00:17:50.480
Um but but what what I want to get at though is that like in making that in operationalizing some of that relationship around these packaged insights, around well-formed conversations, around it like it enables more focus.
00:17:50.480 --> 00:17:55.200
Um, but also it becomes a two-way, a two-way street, I suppose, right?
00:17:55.680 --> 00:18:14.880
Yeah, and I think the you know the the same issue actually can be seen from the support side where um you know support is equally distracted by switching between tickets when you have to, you know, you root a ticket to engineering and then you're waiting on the engineering team.
00:18:14.880 --> 00:18:17.359
And so you have to then switch to a different ticket.
00:18:17.359 --> 00:18:32.880
And um you're now okay, you've got five tickets waiting on engineering now, and then you have to ping engineering, and it turns out, oh, if someone's on vacation, they're not working on it.
00:18:32.880 --> 00:18:44.319
Oh, you move it to the right team, then that then like eventually they tell you it's merged, but but you actually have no idea about whether the fix is deployed, and you have to again.
00:18:44.319 --> 00:19:03.759
And so by actually moving some of this work over from engineering to support, support also has more of a flow state in being able to work on an individual ticket, resolve it all at once quickly without switching between tickets.
00:19:03.920 --> 00:19:04.799
Yeah, and is it fun?
00:19:04.799 --> 00:19:13.680
Because because in some ways, the way you're describing that, it almost makes it sound like it's a single support engineer and a single engineer, support agent and engineer.
00:19:13.680 --> 00:19:17.519
So these are one-on-one and white, you know, but actually that's not the case, is it?
00:19:17.519 --> 00:19:22.720
We're talking about that you might have, even if it's five tickets, they're not all with one support person.
00:19:22.720 --> 00:19:28.000
Like you can have five, five support engine, uh, I tend to say support engineer because that's the environment.
00:19:28.000 --> 00:20:00.480
I mean, support agents or support people scattered globally who aren't even necessarily talking to each other and uh kind of filing these historically, like all five individual tickets would go to engineering, all of the aggregation and reporting would happen in engineering, engineering would pick, you'd have five people waiting on individual pieces of news potentially, and to your point, without necessarily knowing in in five different countries when this thing was going to be rolled out and when customers might expect it.
00:20:00.480 --> 00:20:21.359
So, so does it improve that, like you know, one-to-many or even many to many relationship as well, the the kind of relationship building and the kind of vehicle that we're talking about, which in in this case is is Pebble, but but also like just it outside of tooling, um, the kind of relationships we should be building.
00:20:22.240 --> 00:20:42.160
Yeah, I I'll say one thing we're like doing in the product right now, because it's it's like top of my mind in answering this question, which is um one of the things we're trying to do is make sure that anything that we learn from is shared across the team.
00:20:42.160 --> 00:20:55.119
So it becomes not um, you know, I think a lot of folks are starting to use um Claude or maybe maybe they've like set their support team up with using Cursor locally.
00:20:55.119 --> 00:21:03.680
And then the kind of disadvantage of that, it's all like happening on your local machine, it's not shared team knowledge.
00:21:03.680 --> 00:21:26.160
And so we try to make it so that we learn from every support ticket and every interaction that is happening between support and engineering and use that to improve the the resolution of the ticket and also um the the knowledge, the kind of consolidated knowledge that the team has.
00:21:26.160 --> 00:21:44.480
So I think it does improve that that team knowledge, and then we also have try help to distribute okay, now this is deployed, and now it needs to go back to five different support agents because they've all got tickets they're working on that are related to this.
00:21:44.480 --> 00:21:56.079
So we kind of think of it as solving this um collaboration between support and engineering is a systems problem.
00:21:56.079 --> 00:21:59.759
There's a lot of different people involved, it's actually not even.
00:21:59.759 --> 00:22:04.559
Just support in engineering, this product and documentation and QA.
00:22:04.559 --> 00:22:18.000
There's all these different people involved, and the part of what has delayed resolution and made it difficult is actually like the passing of information between all of these different people.
00:22:18.000 --> 00:22:36.640
And so we kind of think of ourselves as um one being like the glue between all of these different people and like helping to um make the the workflow for the system as a whole more efficient.
00:22:37.440 --> 00:22:41.759
And and everything we're talking about so far begins with a ticket.
00:22:41.759 --> 00:22:52.799
Um but does this mean that uh the same set of systems um can work for problems that are discovered inside engineering?
00:22:52.799 --> 00:23:01.039
Because you know, engineers are often, because you know, these are their babies out there in the world, they're often looking for looking for signals directly as well, right?
00:23:01.039 --> 00:23:13.519
Not everything begins with a ticket, like they're doing their own monitoring, they're looking at their own, you know, usage reports or you know, um tracking or whatever whatever it is that's happening inside the product.
00:23:13.519 --> 00:23:16.480
Um, they're looking at their own signals as well.
00:23:16.480 --> 00:23:27.680
So d does it enable more communication and uh, you know, more does it support the support team still if it's just stuff happening inside engineering?
00:23:28.240 --> 00:23:29.680
Exactly, exactly.
00:23:29.680 --> 00:23:53.759
So the way that we solve this systems problem is that we deeply integrate with all of the engineering systems and all of the support systems, and so we we'll have context from the logs and databases and the code base, documentation and error monitoring and product analytics like amplitude or um or session recordings.
00:23:53.759 --> 00:24:16.079
And so we can use that all of that data and bring it to support to help resolve a ticket, but then we can also say, oh, like this alert came in and or this error occurred, um, or actually this pattern of log showed that a customer was trying to do something that isn't yet possible in the product.
00:24:16.079 --> 00:24:24.960
And we can pass that back to support to say, oh, this is uh an issue we saw this customer run into.
00:24:24.960 --> 00:24:30.640
And let's actually like reach out to them and tell them we saw they ran into that issue.
00:24:30.640 --> 00:24:35.599
Maybe, maybe actually like their authentication for an integration has expired.
00:24:35.599 --> 00:24:40.240
And we can say, Oh, we saw you run into an error.
00:24:40.240 --> 00:24:48.079
You're that integration has expired, you need to reconnect it, and then you can try that thing and it will it will work this time.
00:24:48.079 --> 00:24:56.720
And I think that that's such a delightful experience as a customer that I didn't even have to file a ticket.
00:24:56.720 --> 00:25:08.319
Like you saw that run into an issue and you fixed it and you told me about it, and um, and it really shows that you care about your customers.
00:25:08.720 --> 00:25:10.079
And it's interesting, isn't it?
00:25:10.079 --> 00:25:14.319
Because there's so many reasons why a customer wouldn't file a ticket if they run into a problem.
00:25:14.319 --> 00:25:33.119
They could just simply not have time in the moment, or they may assume it's a uh, you know, a product capability issue rather than something underneath that actually is working as intended, but just doesn't signal that it's working as intended very well, and they need to take action to your point.
00:25:33.119 --> 00:25:45.599
Um or they've given up, like they've actually they've they've been trying out your free tier and it didn't work, and so they've just got bored and moved on to your competitor at that point, right?
00:25:45.599 --> 00:25:47.200
Um, it really depends.
00:25:47.200 --> 00:26:09.039
I I I think that's I I suppose there's also um an opportunity to drive other improvements, not just that proactive support, which is super valuable and to your point delightful as a as an experience, like if you get that kind of outreach as a customer, but but looking for those signals, you made the point earlier that there's so many teams in the system.
00:26:09.039 --> 00:26:27.200
If you're looking at signals from tickets and product insights and logs and everything else, you can you can create more documentation, you can create education, you there are other ways to support your customers as well than just the support team.
00:26:27.200 --> 00:26:40.960
Um, and I think this is where um as as we're moving increasingly to a world where um support is being delivered increasingly by AI.
00:26:40.960 --> 00:26:52.240
I'm assuming that whole ecosystem can feed your agents to provide, you know, self-serve or AI deflected support, then you're left with a support team that has all the really complex issues, of course.
00:26:52.240 --> 00:26:56.720
And um, that's where you create opportunities inside support, right?
00:26:57.440 --> 00:26:58.640
Yeah, yeah.
00:26:58.640 --> 00:27:08.880
I think the way that I see support roles evolving is um like a couple of different new kind of roles.
00:27:08.880 --> 00:27:12.240
One is actually the systems builder.
00:27:12.240 --> 00:27:24.960
Um, you go and actually figure out how to build a support system that um may be largely automated or providing assistance to people.
00:27:24.960 --> 00:27:48.400
Um the second role is it's more technical where you're now working on the hardest tickets that often your like vanilla coding agent will not be able to resolve and um and working working through those.
00:27:48.400 --> 00:27:56.240
Um and I think there's still a lot that you know humans can can can do there.
00:27:56.559 --> 00:28:24.000
Um and then the an a third kind of role is the merging of customer success and support, where actually your the ability to build a relationship with a customer as they face an issue is because you have the time and because you have because the problems by their nature, I I think I would call this consultative support.
00:28:24.000 --> 00:28:38.319
Like the problems by their nature are longer formed, they're more nuanced, and so it's not a matter of find the answer with Claude or um, you know, in the docs or whatever, or from an engineer, um, and and pass it back.
00:28:38.319 --> 00:28:46.240
It's it's actually much more about like, oh, you want to do something more and something deeper with our product, I'll go on that journey with you.
00:28:46.240 --> 00:28:53.759
And that can be that can take a support ticket, you know, average handle time from minutes into hours or days.
00:28:54.160 --> 00:28:55.359
Yes, exactly.
00:28:55.359 --> 00:28:55.920
Yeah.
00:28:55.920 --> 00:29:08.160
We had an example with a custom one of our customers that we're working with, where we actually have kind of largely AI agents, uh our agent responding to all of our support issues is the first line.
00:29:08.160 --> 00:29:13.200
I always respond later on every issue.
00:29:13.200 --> 00:29:23.200
So um, we had a customer ask for you know, run into an issue yesterday, and it turned out that the issue was really something we didn't yet support.
00:29:23.200 --> 00:29:32.799
Um, but uh the way that um GitHub works, it kind of made it look to the customer like it support, like we support it, but we don't.
00:29:32.799 --> 00:29:38.880
And and then I was able to have a discussion with them about, okay, well, why do you need this?
00:29:38.880 --> 00:29:39.920
Like what's the timeline?
00:29:39.920 --> 00:29:50.559
And it turned out that they had actually um acquired another company and they were planning to um merge the companies together, but hadn't done that yet.
00:29:50.559 --> 00:29:52.400
And that's why they needed this new feature.
00:29:52.400 --> 00:29:54.640
So it may eventually become irrelevant.
00:29:54.640 --> 00:30:05.839
And so it's actually like quite a detailed like back and forth that understanding the context of the business in order to um understand, you know, whether this was really an issue we needed to resolve.
00:30:06.559 --> 00:30:07.359
Yeah, yeah.
00:30:07.359 --> 00:30:09.680
I I I I can completely see that.
00:30:09.680 --> 00:30:25.599
That I think the other the other way I sometimes frame this kind of consultative support idea is it's kind of use case two, you know, um, for complex problems, uh complex products, sorry, you you often have an implementation team.
00:30:25.599 --> 00:30:35.519
You might have a sales engineer or an implementation engineer, solution engineer of some sort in the first few days or weeks with a complex product.
00:30:35.519 --> 00:30:41.920
Um, but they move on, they move on to the next implementation, and you know, then you're with support.
00:30:41.920 --> 00:30:55.200
But what happens when you want to, to your point, refactor something or build something new on top of what was built during those first few precious weeks where you had that one-on-one attention, and suddenly, suddenly what you've got is a support team.
00:30:55.200 --> 00:31:28.160
And you know, worst case scenario it there is it's an AI agent, and you can't really explain to an AI agent deeply why you want this thing to function the way you or build this thing the way you want to build it, you need a human in there, and so that kind of understanding and deep dive on why is often something that a support uh AI agent or you know is is not capable of like dealing with that nuance over time as well, crucially, which is often what we're talking about here with that type of support.
00:31:28.480 --> 00:31:29.920
Yes, exactly.
00:31:29.920 --> 00:31:51.519
And and not necessarily having access to oh, there was this Google Doc that you wrote when you were as part of like the statement of work for this company, and does your AI agent for support have access to that for that customer in a way that's not gonna give it access to that across customers as well?
00:31:51.839 --> 00:31:53.519
Yeah, yeah, absolutely.
00:31:53.519 --> 00:32:01.519
And and that's really interesting, I think, then as well, because again, the problem with implementation teams is they work with very few customers at a time.
00:32:01.519 --> 00:32:08.079
And um, so they have deep knowledge on what a customer's trying to do, or what a couple of customers are trying to do in the moment.
00:32:08.079 --> 00:32:10.960
They move on, they put those customers down.
00:32:10.960 --> 00:32:16.079
Um But they've in that time they've come up with clever solutions to things.
00:32:16.079 --> 00:32:17.839
Um, they take that with them.
00:32:17.839 --> 00:32:26.960
Those are often buried in a few, you know, gong recordings or something, or or DMs or Google Docs with the customer.
00:32:26.960 --> 00:32:34.799
Um, but you don't have access to those decisions or those clever clever implementations that were made inside the customer you're talking to.
00:32:34.799 --> 00:32:41.440
Never mind maybe something that was achieved for another customer two months ago that was a bit similar but not quite.
00:32:41.440 --> 00:32:53.279
Like your agent just can't access that kind of, you know, takes that kind of human eye on something that says, I I've spotted that we did this thing over here in a weird way.
00:32:53.279 --> 00:32:54.720
There actually is a good reason for that.
00:32:54.720 --> 00:32:57.359
I can lift it over here and do something slightly different with it.
00:32:57.359 --> 00:33:07.359
Like there's a there's a lot of opportunity you can create in that kind of um with that kind of visibility and that kind of um opportunity being created, right?
00:33:07.759 --> 00:33:08.799
Yes, yeah.
00:33:08.799 --> 00:33:41.839
And part of what we're trying to do is like how do we enable companies to bring in more of that context, like bring in those custom Google Docs to be able to then surface that information to support folks as they are working back and forth with this assistant to help them understand, oh yeah, sales engineering did this during the PUC and they never actually finished that particular thing, and now the customer wants it.
00:33:41.839 --> 00:33:43.039
Or yeah.
00:33:43.359 --> 00:33:43.680
Yeah.
00:33:43.680 --> 00:34:05.200
Do you find I I guess the final question for me, from me then at this point, is like going back to something you said before, like when you've created all this time to work complex problems inside support, um, and you've created focus inside engineering, um, but that's sort of built on systems.
00:34:05.200 --> 00:34:08.639
Do these teams actually spend more time together as well?
00:34:08.639 --> 00:34:13.199
Is there an opportunity to for like person-to-person collaboration as well?
00:34:13.199 --> 00:34:14.239
Do you think?
00:34:15.199 --> 00:34:20.239
Yeah, I think it's um well, there's a there's a couple things there.
00:34:20.239 --> 00:34:27.199
One is I think the better that your support is, the more your customers will report.
00:34:27.199 --> 00:34:38.719
And so while we, you know, we save, you know, make it faster to resolve any particular issue, if you make support really great, then you end up with more issues.
00:34:38.719 --> 00:34:42.320
And that's a great thing because it's more feedback.
00:34:42.320 --> 00:34:53.199
Um, and we find that um, you know, our most successful active customers in using the product are also the ones that are filing the most issues as well.
00:34:53.199 --> 00:34:59.119
And so um that that's one thing that happens.
00:34:59.119 --> 00:35:38.719
Um, but I I do think it allows also for support in engineering to get together and have a richer conversation where um both sides have more information and are able to um uh think more strategically about how to um how to improve the system um because you're able to take the time to kind of aggregate your learning and and share them work together.
00:35:38.719 --> 00:35:48.880
So um yeah, I I think we've we've seen that where the teams it does provide an opportunity for the teams to talk together.
00:35:49.199 --> 00:35:49.679
Hmm.
00:35:49.679 --> 00:36:29.920
I I I would imagine as well, and I I I I do find this in in my day job even now is that when when you provide enough insights, they want to talk to each other because it uh a little bit of information, a little bit of the right information, the right focus enables the right question to be asked, or it enables the right people to get together to say, you know, and I find that there's uh like some of the best engineers will find out something that interests them and then want to deep dive on it, and the people who have the who can enrich those insights of the support people who can say, yes, that is a thing.
00:36:29.920 --> 00:36:38.880
And here's a customer I spoke to last week, and here's how they expressed it, and here's why, and and all everything we just talked about with consultative support, right?
00:36:38.880 --> 00:36:50.480
It it carries through because you find engineers become curious and they they cross the boundary into support, and then they learn with the support team, or maybe even directly with customers as well.
00:36:50.480 --> 00:37:00.000
They want to deep dive into actually what is being trying to, what is trying to be achieved here, what's the why of this behavior we're seeing or this number we're seeing.
00:37:00.320 --> 00:37:01.519
Yes, exactly.
00:37:01.519 --> 00:37:02.000
Yeah.
00:37:02.000 --> 00:37:15.199
And I think a you know, a good change that is happening in the engineering culture is the idea of the forward deployed engineer that do get more involved with with customers.
00:37:15.199 --> 00:37:24.719
And yeah, I think that uh, you know, engineering kind of coming out of the ivory tower and saying actually doesn't really work.
00:37:24.719 --> 00:37:41.360
It's much better to be like hands-on working, working with customers and um support can be great, great partners in enabling actually, okay, I'm a I'm an engineer, I want to get more involved with customers.
00:37:41.360 --> 00:37:42.639
Like, how do I do that?
00:37:42.639 --> 00:37:49.679
Well, go and sit side by side with someone in your support team and and learn from them.
00:37:50.639 --> 00:38:03.039
I couldn't I couldn't think of a better way to uh wrap up, actually, is just go and spend time with your support team and have those conversations because because they've got the information for sure and the enthusiasm for getting those problems solved.
00:38:03.039 --> 00:38:04.960
So yeah, absolutely.
00:38:04.960 --> 00:38:06.239
I couldn't agree more.
00:38:06.239 --> 00:38:08.639
Alex, thank you so much for joining me today.
00:38:08.639 --> 00:38:16.000
What a lovely, uh lovely um uh thought-provoking kind of um view on that that gap.
00:38:16.000 --> 00:38:18.000
It's so often a gap.
00:38:18.000 --> 00:38:21.119
But I feel like we can we can bridge the divide at last.
00:38:21.119 --> 00:38:24.639
So that um you've left me with quite a lot of hope for the future, which is great.
00:38:24.639 --> 00:38:25.840
Thank you so much.
00:38:26.079 --> 00:38:33.280
Yeah, thanks for having me, Charlotte, and for for being someone who is uh you know helping to bridge the gap.
00:38:33.519 --> 00:38:33.760
Yeah.
00:38:33.760 --> 00:38:34.719
Thank you so much.
00:38:34.719 --> 00:38:37.360
Will you come back and have another conversation another time?
00:38:37.360 --> 00:38:43.440
I'd love to have uh have another conversation about this relationship or um indeed anything else in support, you know me.
00:38:43.440 --> 00:38:45.519
I'll I'll talk for I'll talk to anything.
00:38:45.519 --> 00:38:48.159
So we come back and have another conversation sometime.
00:38:48.480 --> 00:38:50.000
For sure, definitely.
00:38:50.000 --> 00:39:02.960
I will um next time I'll bring uh um our founding engineer Sarah, who has been split her time between support and engineering across her career.
00:39:03.119 --> 00:39:04.239
So perfect.
00:39:04.239 --> 00:39:04.960
Thank you so much.
00:39:04.960 --> 00:39:05.840
I look forward to that.
00:39:05.840 --> 00:39:07.519
Thank you for joining me.
00:39:07.519 --> 00:39:11.039
That's it for today.
00:39:11.039 --> 00:39:17.119
Go to customersportleaders.com forward slash three one one for the show notes, and I'll see you next time.