Episode 129 Sep 202648 min
Karthick JL spent 21 years in post-sales. At Freshworks he found 40,000 long-tail accounts driving most of the churn, covered them with 30 people and built what is now called scaled customer success. We talk about how he did it, the cancellation survey that saved 10% of leaving accounts, and what AI really changes for CSMs.
The episode in 10 points. Each timestamp plays the video from that moment.
Everyone at Freshworks was focused on mid-market and enterprise churn. Karthick pulled the churn data himself with SQL and found around 40,000 long-tail accounts at $300 to $400 MRR that nobody covered. They drove most of the churn and made up about a quarter of revenue. He presented that case to management, product and engineering together, and it became Freshworks' digital CS team, now called scaled customer success.
Just because you don't want to station a team on a segment doesn't mean you can ignore it.
Karthick JL
That is roughly 1,300 accounts per CSM, in 2018 and 2019, before AI. There was no target at the start. The team grew slowly, ran on Freshworks' own product for automation from onboarding through engagement, and within about a year beat what management expected.
We didn't solve for those 40,000 customers with more people. We solved it by changing the way we worked.
Karthick JL
First came hand-picked, manual emails. What worked became automated onboarding and post-onboarding journeys. When adoption still did not move, he added in-app guides for new customers, returning customers and the pages people got stuck on. Then came personal-looking check-in emails, a pooled CSM team, a triage team for escalations, a growth team for upsell and cross-sell, a dunning team for failed cards and chat pop-ups at trigger points. It took about six months, with one rule: fail fast, learn and move on.
The survey sorted reasons into themes: product, budget, management, and service or support. Customers picked one theme and answered three to five quick questions, all radio buttons and checkboxes except one text field. There was no forced gate, and customers were told answering was optional. The response rate surprised the team, and about 10% of cancelling accounts were saved, because many were leaving over gaps in understanding, not a bad product.
That honesty actually gave us better information.
Karthick JL
The first version of the flow just offered a chat with the team before cancelling. Later versions showed a downgrade path based on usage: you use this feature a lot, it is on the lower plan, and here is what you would save. Karthick never believed in last-minute discounts. They work like bait, and the customer comes back to cancel two or three months later.
Companies decide they need customer success and immediately hire a CSM, without asking where they are as a company, who their customers are and what problems they are solving. The person you need at 20 customers is different from the one you need at 500 or 5,000. By his estimate, at least half the founders he talks to still think customer success is support.
The expensive AI mistakes he sees come from adding AI because everyone else is. If the data or the process is broken, AI does not fix it. Too much AI can even add work: summaries, alerts, scores and tags that someone still has to sort through to find what matters.
CSMs lose eight to ten hours a week to internal work: filling in data, answering leadership and piecing together escalations. As AI takes that over, the same team can spend the time on customer outcomes, retention and expansion. His answer is to keep the team and slow down hiring, not lay people off.
CSMs shouldn't be scared of AI. They should be scared of staying exactly where they are while the work around them changes.
Karthick JL
A customer at 70% adoption can churn while one at 30% renews, because the second one adopted the features that solve their problem. Clicks and page visits are not enough anymore. CS has to know which features lead to each customer's outcome. That is why, forced to choose, Karthick calls churn a CS problem rather than a product problem.
Early in his career the customer was god: whatever they asked for got built, even if it burned out the team. Now he asks whether the request makes sense for the customer, fits the product and is sustainable for the business, and whether they are the right customer at all.
Saying no doesn't mean you're not customer-centric. Sometimes it's actually the more honest thing to do.
Karthick JL
Two options per question, no third answer allowed, and only one follow-up.
The one follow-up: why churn is a CS problem.
Edited for readability: filler words removed and grammar fixed, nothing cut. Click any timestamp to play the video from that point.
Hello folks, welcome to the first episode of The Second Year.
Today's guest is very special. He has spent 21 years in post-sales, which, to be honest, is very close to my age. He moved from software engineering into customer success, managed 40,000 accounts at Freshworks and has written eight books on customer success. Welcome, Karthick. How are you feeling today?
Thank you for inviting me, Dhiraj. It's a pleasure, and I'm excited to have this chat with you. I hope you'll make this comfortable for me.
I'm going to try my best. We're going to talk a lot about your work in this episode, but first, help me understand: who is Karthick outside work?
I'm a dad to a four-year-old, so as you can imagine, that takes up a good part of my life. I used to be an avid biker and loved exploring different places. I still enjoy nature, spending time with my kid, helping my wife and learning new things. I also love movies. I used to watch quite a lot of them, but I've almost stopped now because we're bringing up our kid completely gadget-free. So if you ask me what happened to my movie time, my four-year-old happened.
Awesome. You mentioned you're an avid bike rider. What has been your best trip?
Earlier I lived in Bengaluru, and every weekend I would take my bike and start riding around, visiting different places nearby. As you know, there are a lot of places you can go from there. I did that every weekend.
Awesome. Wonderful. You've been in post-sales since before customer success was a job title in most companies. A lot of companies had adopted customer success, but you were probably one of the people who experienced those early customer success setups firsthand. During that period, when someone asked what you do, how did you explain it to a person who wasn't in SaaS?
That's actually one of the hardest things to explain, especially to someone outside SaaS. I usually tell them: you know how you buy something and sometimes you don't really know how to use it, or you don't get what you expected from it? That's where I come in. I work with companies after they sell their software to make sure the customer actually gets what they came for.
If I put it in very simple terms, I help companies make sure their customers don't regret buying from them.
Fair enough. You were a software engineer first, and then you moved into customer success. How did that happen? Walk us through that transition.
That's probably one of the questions I get most often. I started as a software engineer way back in 2005. After a few years, I realized that sitting within four walls writing code all day wasn't really my cup of tea. I did enjoy technology, but I also enjoyed interacting with people, solving different kinds of problems and understanding what customers were actually trying to do.
So I moved to a product company as a tech support engineer, because at that time CS wasn't even a department. I spent a few years in tech support and then moved into a TAM role. Eventually, I was given the opportunity to build customer success as the first hire for a multi-million-dollar portfolio. It wasn't really a planned career move. One opportunity led to another, and I just kept saying yes. That's all.
Okay. Awesome. You bring a good mix of engineering and customer success. Do you think the forward deployed engineer role was built for you?
Maybe. I used to think this background gave me an unfair advantage, because I could troubleshoot problems and understand the product deeply. It was very easy for me to talk to technical teams without depending on someone else for every technical question. So I became a product expert fairly quickly and then added the customer-facing side to that.
That combination of technical knowledge and customer experience probably helped me move into TAM and CS faster. And if you ask me now whether I want to become a forward deployed engineer, why not? That's what I have been doing. It's not something new for me.
Absolutely. Absolutely. Now let's focus on your time at Freshworks. This is the part I'm most interested in. You mentioned that everyone at Freshworks was shouting about churn, churn, churn, and when they said churn, they mostly meant mid-market and enterprise accounts. But you found 40,000 customers in the $300 to $400 MRR range who were also bringing in significant revenue, and that's where you put your focus.
Help us understand what you were doing, how you ended up finding these accounts and why you decided to pick up this cohort.
Definitely. One thing about me is that even after moving into customer success, I never really stopped behaving like an engineer. I like getting my hands dirty, especially with data. So I learned analytics and used SQL to look at our churn data. At that time we didn't really have analytics tools like we have today, so I actually built a dashboard for our entire CS team. While looking at the data, this long-tail segment of customers caught my attention. There were around 40,000 customers who were largely untouched, because the focus was mainly on mid-market and enterprise, as you rightly said.
So I started digging deeper, because I wanted to understand who these customers were, what they were doing and why we weren't paying attention to them, even if they were paying less ARR. What I found surprised me enough that I wanted to take it to management. That conversation eventually led to us creating something called a digital team, which is now called scaled customer success. That created the opportunity for me to build and grow it.
Right. If you had to pinpoint the exact insight from that analysis that made you think, if I put this in front of management, I'll probably get a yes, what was it? Put it in one line.
The majority of the churn was coming from this set of accounts, and we were completely blindfolded to it. The entire team and management were only looking at mid-market and enterprise and breaking their heads over why it wasn't working. Nobody had made the effort, or I would say we didn't realize it. Like I said, we were blindsided.
When I went deeper into the data, I found that churn there was way too high. Even though these accounts made a decent contribution to revenue, customers were coming in and going out, and we had no clue what was happening. Just because you don't want to station a team or people on a segment doesn't mean you can ignore it. That's what pushed me.
Okay. And since you said it was a significant contribution to revenue, was it above a quarter or below a quarter?
Above a quarter. I'd say close to a quarter.
That's crazy. That's probably why management heard it loud and clear. 25% of the revenue coming from a cohort we weren't even touching. That makes a lot of sense. How big a team did you have to manage roughly 40,000 accounts?
I started with a small team and grew it to 30 people. That felt like the sweet spot for me. Not more, not less.
But 40,000 accounts and 30 people is roughly 1,300 accounts per CSM. And this was the pre-AI era, I'm assuming?
Correct, yes. It was around 2018, 2019.
That's crazy. That's the real case study for a scaled CS motion. Help us understand why you stopped at 30. Was there a goal or target set for you from above, or was it your own goal not to hire beyond a certain threshold? Or did it simply start working, so you didn't have to focus on hiring anymore?
It was an experiment, so we built it slowly but steadily. In fact, there wasn't really a target at the beginning saying you need 30 people to manage 40,000 accounts. The first challenge for us was figuring out how to operate in completely different territory. I couldn't use the traditional way we manage enterprise customers. At a ratio like one CSM to 2,000 accounts, I felt that approach would definitely fail, and fail miserably. So my focus was on how to make this efficient with the resources we had. Freshworks being a customer experience company actually helped. I leveraged our own product, eating our own dog food, and our platforms to build automation all the way from onboarding through engagement, and eventually it worked. I set the targets, built the team, built the processes and kept experimenting with what worked.
Roughly a year later, I would say we had achieved more than management originally expected. And the interesting part was that we didn't solve for those 40,000 customers with more people. We solved it by changing the way we worked.
You could say that was the era when scaled customer success was born.
Awesome. You mentioned a couple of things here. You changed how you operated for a problem statement like that, and you didn't only solve for churn mitigation, but also for onboarding, engagement and education for that cohort. Can you walk us through that year of effort on those 40,000 accounts, step by step, in the next five minutes?
Okay. Sure, five minutes. I can cover it. So the thing is...
It's not a hard timeline. We can take ten. But help us understand how each event happened, which insight it led you to, which process came out of that insight and how the whole cycle was built.
Definitely. The first thing was identifying where the gaps were. These customers were mostly organic, which means they were completely in self-serve mode. If someone is in self-serve mode without proper resources or assistance, it'll fail miserably. I couldn't hand-hold them personally because there was no human stationed there.
In fact, even the salespeople didn't know these customers existed, because they were all organic. They just came in, maybe through referrals, or it was all inbound. They clicked a link, thought this could solve their problem, signed up by themselves and started exploring. If they had an issue, they raised a support ticket. If it got solved, they moved on and kept trying. Then, if they felt it wasn't their cup of tea, or that it wasn't helping them achieve what they wanted, they just cancelled. It was like a queue: first in, first out. Cancelling was easy, there was no restriction and no one was monitoring it. That was the first thing that caught my attention.
So I thought: these customers have self-served, okay, let's leave them that way, but make it more efficient and convenient for them so they still don't have to depend on us. As you know, everything starts with onboarding, so I thought about how we could make the onboarding process easier. The first thing is that you need to tell them the basic steps. Even though the product is fairly simple compared to others in the market, you still need some basic support.
So I started sending emails. The first experiment was manual emails. I picked certain customers I thought might engage and started with targeted, manual emails. Then I used those learnings to automate. Again, we didn't have fancy tools like we have now, so there was a lot of experimentation, failures, drop-offs and so on. But eventually, after testing with a small sample, it actually worked. Then I moved on to automating other things, like creating the customer journey: which emails go out during onboarding, which go out after onboarding and how you can hand-hold customers virtually.
I felt it was working, but not completely. There were still a lot of gaps. With the emails we sent and the information in them, customers could get through to an extent, but they were still getting stuck, because when I looked at product adoption, the needle wasn't moving at all. So what could we do? I saw there were certain pages where customers would stay and then leave. That meant they probably needed in-app help. So I worked with the product team and we bought Appcues, similar to the digital adoption tools we have now.
With Appcues, I created a digital adoption program. For a new customer, what kind of guide do you give them when they log in to the product? For a returning or existing customer, what kind of guide do you create? If a customer is stuck on one particular page, what do you do? It went in phases. Once onboarding was more or less fixed, we came to post-onboarding.
As you know, successfully completing onboarding doesn't mean a customer won't churn. It's an ongoing process. They have to keep using the product and seeing the value. So for post-onboarding, again, it was a combination of emails and in-app guidance.
But what I did was make it look as if I was personally emailing them, trying to understand what they wanted to achieve. I wanted to know why they had even bought the product. Some answered, some gave us interesting use cases and some said they just wanted to try it.
So it was a combination. Again, we picked what actually helped and what didn't, and used that to tailor the experience. Where customers wanted help, I did station some people. It's like a pooled CSM concept: whenever customers were in trouble or needed help, whether on support, success or product consultation, I stationed people there. That actually worked.
The other part is that with 40,000 customers, you can't escape escalations. So I had a triage team to manage escalations. I also brought in something called a growth team, where we constantly identified opportunities to upsell and cross-sell by looking at multiple data points. Are they already an enterprise company? What does their product adoption look like? Do you see growth in them? Different factors, and we kept adding to them.
Then, obviously, comes the last part, which is churn. You try to control certain aspects, but people still cancel. I can't stop them, because it's a SaaS product. I can't create a forced gate. So I thought, why don't I create a survey, with no hard push? It just says: I understand you want to cancel, and that's well and good, but just for our understanding, would you fill in this five-question questionnaire? I made it simple. That gave us a lot of learnings, which we put back into the system, refined and worked on. That helped us.
I also had a separate cancellation team. Because these were all organic, credit card customers, you get a lot of credit card failures. So we created dunning options and stationed a team: if customers weren't entering the right credit card, or a card failure happened, the team would call them and check. There was a separate chat team as well. At specific trigger points, a chat pop-up would appear so customers could reach out to us.
Those are some of the highlights at a high level, but it was all experimentation. We didn't start this on day one or even day 30. It took about six months of experimenting, experimenting, experimenting, and then I had a different process. The idea was: don't sit on something for months. If you see it's failing, fail fast, learn from it and move on. That was the idea behind it.
The typical startup lesson.
Yeah, exactly.
I have a couple of questions about the flow you mentioned. One was the email automation flow for all the SMB customers. The other was in-app guidance, which is essentially a digital adoption system. You built a cancellation flow as well, and iterated on the feedback from each of these cycles to improve it. Emails, I understand, were 100% your decision. You could set everything up on your own.
But getting an in-app notification or user journey tool, and building a cancellation flow inside the product, would have meant working with the product team, and we all know how that goes in any business. Engineering and product teams are always short on bandwidth. When new requests from mid-market and enterprise sales compete with customer success requests for an SMB cohort, how does that stack up, and how did you make it work?
The interesting thing is that I had a direct line to the executives. So I bypassed that.
Nice. So you probably went directly to them with: this is 25% of the revenue, what do you want to do?
Right, exactly. That was the trump card. I wasn't threatening anyone, I just presented the case. When I presented to management, it wasn't just to the customer success leaders or the CRO. I was presenting to everyone. I brought in the product team, the engineering head and the CROs. Except the CEO, everyone was there while we were presenting. So they understood the reason behind going for it. And back then, the CEO was very supportive. He fought for me against multiple odds, so it became easy. That's why I said I had a direct hotline.
You mentioned you built a five-question survey. Can you help us understand what those five questions were?
It was simple. I couldn't directly identify what the problem was, so we set up criteria. Is it a product-specific problem? Is it a budget issue? Is it a management issue? Or are they facing a service or support issue? Those were the high-level themes, and we worked around them.
They didn't have to answer every question, only the right one. If they said it was a product issue, they selected only that theme, and we had about five questions around it. If it was a management issue, there were three to five questions and they had to select one. That helped us narrow it down for them, so they didn't have to think too hard. Sometimes they would hastily select something, but we set the expectation that it wasn't a hard push, and that if they were willing to answer, it would definitely help us. That was the questioning we built, rather than saying, no, you have to do this, otherwise we won't let you cancel. That was the idea behind it.
So if I summarize: you categorized your existing churn patterns into three or four buckets, say management decisions, budget issues, service and support issues, and product issues. Whenever a user selects one of those, they get a specific set of questions that helps you understand why exactly the churn happened. And you chose to make those questions easy. Most cancellation flows I see have one dropdown, either multi-select or single-select, and then a text field.
No one in the entire universe fills that in. I never fill it in myself, to be very honest. You can't make me write text when I'm cancelling something. It has to be more intuitive, something that prompts me to answer because I think it will genuinely help you. Making me write a lot of text isn't going to help.
Yes, that's why it was theme-based. There was only one descriptive question. All the rest were radio buttons and checkboxes.
Awesome. You also mentioned you were saving around 10% of accounts through this cancellation flow. And you said there was no churn save plan and no hard, forced gate saying you have to answer this before we cancel your subscription. How did you end up saving that 10%? What was in that flow, or after it, that helped you save 10% of whatever came through?
Correct. Like you rightly said, we couldn't expect everyone to fill it in. But there was a decent survey response rate, which itself was a surprise for us. Secondly, we discovered some very interesting things. A lot of customers weren't leaving because the product was bad.
They were leaving because of gaps in understanding. Some customers didn't know the product could actually do what they were looking for, even though the capability was right in front of them. Some simply didn't understand the process. And in some cases, they had subscribed to more than they needed and decided to cancel instead of moving to the right plan. That's where the roughly 10% recovery came from. The interesting thing was that we weren't aggressively trying to save all of them. We were only asking why they were leaving, and telling them we weren't going to push.
That got us more answers. That honesty actually gave us better information.
What was the channel? When they fill in that form, do they save themselves then and there? Take your example: they're probably overpaying, they feel the ROI isn't enough, and they could move to a base or lower plan and still do everything they're doing on the platform. Do they see all of that on that screen itself, or is it something you analyzed after they submitted the form, and then reached out through another channel?
What did that flow look like?
Initially, after they filled in the form, the next page said: before you make your final decision, we're here to support you. If you want to talk to us, we're happy to do that. That's how we started. It's like building a product. The cancellation flow was also a mini product inside the product. So at the MVP stage we made it very simple: just ask these questions, then tell them that if they wanted to talk to us, we were there. Just click this chat button.
Then, in the later phases, like you said, came the downgrade option. If they wanted, we were able to give them some answers, saying something like: you've been using this particular feature a lot, it's available in the lower plan, and that can save you this much.
That insight is really good.
Correct. Everything went in phases. When we started with the MVP, everything was very simple. We stuck to the basics. We didn't want to experiment too much, because what if you come up with a great idea, think it'll work, put a lot of effort into it and then find it's not helping? Then it's a waste of effort. So I applied a typical startup strategy here.
Before joining Freshworks, I was at a core startup, and that experience also helped in designing this system.
Awesome. This is super helpful, and I think that's a very good cancellation flow, because most cancellation flows you see on a lot of tools will only offer you a 20% discount if you don't cancel your subscription. And if I'm not happy to pay $99, I'm not happy to pay $79 either. Let's be honest.
You still see it. The thing is, it's like bait. They'll take it, but there's no guarantee they'll stay for long. They'll probably use it for another two or three months and still come back and say, no, I want to cancel. So I never believed in these kinds of discounts, unless it was the last resort and we felt maybe we could give it a shot. But I never agreed with it.
Yeah. Now coming to your time at Josys, where you were the first international hire. You mentioned on your LinkedIn that you improved productivity by 30%. This is the most difficult part, and it has been difficult for me as well. I do know now, but it was a struggle for a very long time. How do you measure productivity? That's the biggest challenge in customer success. You either focus on NRR and then on productivity, or maybe you take the reverse approach.
But these are the two key things you need to solve for: NRR for the business, productivity for your team. So what processes did you put in place to increase productivity by 30%, and how did you measure it?
Right. This isn't specific to the customer success team. When I mention 30% productivity, it's operational productivity. Let me tell you the story. When I joined Josys, I was the first international hire, and initially a big part of my role was helping the company go global, because it's a Japanese company. The challenge was that there weren't really any established processes for the international market. So I started building some of those foundations around sales and marketing operations. We automated some of the daily work, removed unnecessary licenses and dead leads, and created workflows around the sales process. Some of these improvements also helped the Japan team. When we compared operational performance to the previous year, we saw about a 30% improvement. What I particularly liked was that once we removed a lot of the operational noise, the Japan team could spend more time looking at expansion opportunities.
I helped them there as well, with how to hunt for them, because they were sitting on a gold mine that we had started uncovering.
How did you measure that this operational productivity improvement came in?
Like I said, there were a lot of dead leads and a lot of licenses that weren't being monitored, so we were spending on unnecessary costs. The biggest thing was making it more efficient: making sure you focus on the right leads and remove unnecessary expenditure. That's where the 30% savings came from.
That was productivity, I would say. And there was a lot of manual work, because nothing was automated. Even though we had a sales CRM, it wasn't used effectively. Considering my background, and the CRM knowledge I had from working at Freshworks, I used all of that combined to improve operational productivity.
Now let's summarize a lot of your broader learnings. Since early 2025, you haven't been running your own CS org. You've been looking into a lot of other teams' CS functions and trying to help them. What is one mistake you see repeated most often, one you also made yourself?
Correct. It's a typical one: hiring the wrong person at the wrong stage. I've made that mistake myself, and I see companies making it all the time. A company decides, yes, we need a customer success team now, and immediately goes out and hires a CSM. But the real questions should be: Where are we as a company? Who are our customers? What problems are we trying to solve? And what kind of person do we actually need?
The person you need when you have 20 customers can be very different from the person you need when you have 500 or 5,000 customers. I also see companies treat CS purely as a cost center. That's another mistake, because CS sits very close to retention, expansion, customer feedback, revenue and so on. Sometimes the problem isn't that customer success isn't working. You simply hired the wrong person at the wrong stage and gave them the wrong job.
Absolutely. And you mentioned one interesting fact: a lot of people look at CS as a cost function. How many founders have you spoken to who think customer success is support?
I'd say 50% at least.
And did you end up changing their mindset about how this function operates and what it does?
Yes, I did. Not all of that 50%, but I was definitely able to change the way a sizable number of founders looked at customer success. In fact, even when you look at some job descriptions, they say customer success, and when you read them, it's completely about support. It's fine, it's ignorance.
But I try my best to educate them, because in some cases they come from a non-SaaS background. And why would a CEO need to understand everything? All they want is for their customers to get a good experience, and prima facie, that always goes back to support, because they feel that if support is good, you're giving a good experience.
That's what we have to change.
And you've written eight books on customer success, which is crazy. It takes me 25 minutes to write one LinkedIn post, and you've written eight books that are out there. Help us understand what motivates you to write and speak so much about this space. And how do you decide which topic to pick for a book?
Definitely. Honestly, I started writing because people kept asking me the same kinds of questions. Someone would ask me about building a CS process, someone else would ask about career growth, renewals or leadership. After answering the same thing repeatedly, I thought, why don't I put this somewhere people can keep it as a reference? That's really how it started. But writing books isn't as easy as people think.
I'll have an idea and get excited. Then I write a few chapters, read them again and think, what was I thinking? I scrap it and start again. The funny thing is, sometimes it takes me a month just to figure out what I actually want to write about, and another month or so to create my first proper draft. A lot of the topics also came from what I'm seeing in the industry and the questions people keep asking me.
And apparently eight books weren't enough, so I'm writing my ninth now.
Awesome. If you're open to sharing it, what's the title or topic of the new book?
It's called CS Career Accelerator.
Nice. Awesome. I have a few questions on that as well, but I'll put them in a very different way. You've also written an AI playbook for customer success. We're all experimenting with AI. Everyone's trying to become AI-native in customer success, but I don't want to go there. Help us understand: what did you try this year with one of the teams you're working with, in terms of AI, that failed miserably?
Personally, I haven't had a spectacular AI failure, but I've definitely seen and worked with companies that made expensive mistakes. The biggest one, if you ask me, is adopting AI just because everyone else is doing it, like you rightly pointed out. They don't first ask what problem they're trying to solve. They just add AI to the process.
If the underlying data isn't good or the process itself is broken, AI doesn't magically fix it. In fact, I've recently started seeing something interesting: too much AI can actually increase the workload, because suddenly you have a lot of AI-generated summaries, alerts, recommendations, scores, tags and all sorts of content, and someone still has to figure out what actually matters. So my view is pretty simple. Don't start with where you can use AI.
Start with what problem you're trying to solve, then see whether AI actually fits or is the right answer for it.
Absolutely. I had a crazy experience in the last couple of weeks. A prospect sent me a very lengthy email laying out, step by step, what they wanted to achieve with AI, and said, if you can show me this, I'm happy to jump on a demo. I actually built the entire demo for them on dummy data relevant to their industry, and we built out the entire set of agents that would do that job.
Then we ended up in a demo. And I know people who think that way: you need to have your problems first. No tool will magically solve what doesn't exist. So have your problems first, then take them to whoever you think is the best fit to solve them for you. That's fair. Now, to the hottest topic in AI and customer success: what do you think AI means for jobs in customer success?
This comes back to the same point. I think there will definitely be a transformation. We've seen this happen in other industries. Call centers, for example. Technology automated a lot of repetitive work, but people didn't simply disappear. The nature of their work changed. I think customer success is going through, and will go through, something similar. A lot of operational work will be automated, and it's already happening.
Things like gathering information, summarizing meetings, updating systems, analysis, customer communication and so on. If someone's entire value is doing this repetitive operational work, that role is going to be under extreme pressure. But if you can understand the customer's business, influence stakeholders, solve complex problems and make good decisions, that's a different level of value. So I don't think CSMs should be scared of AI, which is what I keep saying. They should be scared of staying exactly where they are while the work around them changes. You have to come out of your comfort zone.
Absolutely. But let's do some math. Say there are 100 CSMs in the entire world. With AI coming in, a lot of the job can be done by AI, and CSMs can focus on more customer-focused, relationship-focused work. Does that number of 100 CSMs the world needs go down? If yes, what would that number be, in your opinion?
I can't put a number on it directly, because then it becomes fake.
A guesstimate is fine. A guesstimate is fine.
I would say you can still stick with 100. Why? It's simple. When I keep talking to leaders and individual CSMs, something interesting, even shocking, comes up: 50% of their time goes into something unproductive from the customer's point of view. You have to fill in this data, answer your leadership team, answer your cross-functional teams, and if an escalation suddenly comes in, you have to find out why it came up, what this customer is all about, what the data says and so on. Typically, if you ask me, eight to ten hours of a CSM's week simply goes into that.
What that means is you haven't been helping customers achieve what they came for. The key thing is that you don't even know what the customer's outcome is. You don't know where they are in their journey. You don't know how or where to set milestones, because most of your time went into transactional work and internal catch-ups. So you still have to work with those customers, but in a more productive way.
So you still need these 100 CSMs, but the focus is completely different. Instead of working for yourself, your company and internal work, you'll actually be working for your customers. That in turn means you'll solve a lot of problems. You'll make customers happy and help them get the outcomes they want.
Everyone in that customer's company will realize, okay, this is the tool we have to stick with. That means retention improves. You have the opportunity to talk about upsell and cross-sell. You don't have to be just the retention person. Now you have the power to talk about expansion as well. You don't have to be completely commercial, but you use your time the right way.
That means you don't even have to think about downsizing. The one thing is that once this is done, you won't be aggressively hiring more people. You'll stick with your hundred CSMs, and I think that's still good enough, instead of laying people off and creating a bad reputation, with all the repercussions that come with it.
So I would slow down my people growth, not my company growth and not my customer growth.
So if I summarize what you're saying: the 100 stays, but if CS job growth was 20% year on year, that will come down, because the same book of accounts can now be managed by a smaller set of CSMs, since AI can do a lot of the background work for them. Fair enough.
One question for people trying to get into this space or switch into customer success: what skill should every customer success manager, or aspiring customer success manager, have? One that was true in the pre-AI era and is still true today, and one that has come up after AI changed a lot of things. What would those two skills be?
In both cases, I would say don't forget your basics. Customer success itself has evolved and become a complicated function. We now have health scores, AI, automation, dashboards, playbooks, my god, all kinds of frameworks. But at the end of the day, if the customer isn't getting what they bought the product for, none of that matters. If you want to grow in customer success, your customers have to grow.
And your job isn't just to make sure the team completes its activities. You have to help the team get better at understanding customers, driving outcomes, solving problems and contributing to the business. So I would say don't just get better at doing customer success work. Get better at understanding why that work matters to the customers and to the business. That's what eventually takes you from being an operator to becoming a leader.
Fair enough. Now we're moving into the best part of this podcast, the part I love the most, and it has some house rules. This is a rapid-fire round, and there are two catches. First, the questions are framed so that the right answer would be a mix of both options I give you, or some third option. But you don't have that option today. You have to choose one of the two.
It's not meant to be controversial, but imagine you're at gunpoint and have to choose one of the two. What would it be for you? Those kinds of questions. The second catch is that I can ask the why behind only one of the 12 or 13 questions I'm going to ask. So even I'll have to put the brakes on some of my curiosity, because I know some of these things can be very nuanced. Cool. Are we ready?
Yeah. You're putting me under fire now.
Awesome. First question: health scores, signal or theatre?
Signal.
QBRs, keep or kill?
Kill, but transform.
Okay, let's see. You don't get to do that. That's exactly why I made it keep or kill.
Okay.
Third: CS reports to sales, product, the CRO or the CEO?
CRO.
CRO. Okay, awesome. Is churn usually a product problem or a customer success problem?
I can see the controversy coming. Since I can't take the third option, unfortunately, I would say it's a CS problem.
Aligned, but we'll come to that later. Should CSMs carry a quota?
Again, it actually depends. But I'd say yes.
Yes or no? The renewal conversation: does it start in month one or month nine?
Month one.
Most overrated customer success metric?
Activity metrics.
Most underrated customer success metric?
GRR.
NPS: useful, or throw it out?
Not useful.
Sorry?
Not useful.
Adios, man. First thing you cut when your team is overburdened?
What we've been talking about: unnecessary operational work.
Onboarding: owned by customer success or a separate team?
Customer success.
Which CS task does AI take over first?
Day-to-day operational work.
Awesome. My why is going to be on this one: is churn usually a product problem or a customer success problem? You said customer success problem, and now you have to defend that.
The thing is, honestly speaking, I would say it's a company problem. But since that's the only option I have, I'd take it this way. With AI coming into the picture and products maturing faster, you can't keep blaming the product, saying customers churn because the product is complex or doesn't solve what they want.
Those days are gone. Why do I say it's a CS problem? Because a lot of churn is avoidable. You can't just say the customer is churning because they said it's a management issue. Why? You need to understand. If you're not engaging with all the stakeholders, you're blindsided. Second, you need to know how to monitor whether customers are reaching their outcomes. Looking at product adoption and usage at a basic level isn't going to help anymore. Going by clicks and page visits, and customers adopting some product feature, won't necessarily help you. A classic example: there could be two customers, one where you say adoption is 70% and another where adoption is 30%.
To your surprise, the 70% customer might churn. The reason is that they adopted a set of features, but not necessarily the features that will take them where they want to go. Maybe those features aren't even helping them reach the outcome they want. Meanwhile, the other customer has adopted only 30%, but probably 95% of that 30% is actually solving their problem.
So you need to understand exactly which features they need to adopt. That's the kind of maturity you need to bring in as CS. Obviously you'll need support and help from product and others. But until you get to that level of maturity, you can't blame the product. I could keep going on about this, but that's why I'm defending it.
I align very well with that. Customer churn is a customer success problem. Let's be honest about it and own it. We are accountable for it. Everyone else is a responsible party that drives the function alongside us, but we have to be the torchbearers of how to solve churn. These are my analyses, this is my insight, this team needs to work in X fashion to bring churn down by Y percent. That's the statement a CS leader should make, so that everyone aligns on a single goal and works toward it. But we have to be accountable for that metric.
Last few questions, Karthick. I know we've taken a lot of your time. What did you believe about customers in 2013 that you would argue against now?
Interesting. Back then, the customer was god. If a customer asked for something, your first reaction was, okay, how do I make this happen? Even if it was going to burn out your team or consume a ridiculous amount of resources, you did it because the customer asked. Today I would challenge that thinking. The customer is obviously important, I'm not saying otherwise, but customer success isn't about saying yes to everything.
You have to ask whether what they're asking for actually makes sense for them, whether it fits your product, whether it's sustainable for your business and whether they're actually the right customer for what you're offering. Sometimes the right thing to do is tell a customer no.
I've learned that saying no doesn't mean you're not customer-centric. Sometimes it's actually the more honest thing to do.
Absolutely. Last question. You've been in this function for 21 years now. Whenever a customer success leader feels underwater, like the ground is moving beneath them and they're in a tough situation, what is one thing you'd want them to remember?
I would say the same thing: stick to your basics. Don't lose touch with ground reality. If you want to retain your customers, it comes back to what we've been talking about: don't make your team work for the sake of activities, because that leads to failure. You can't just track how many QBRs they've done, how many meetings they've completed or what customer information they've filled in. Those are hygiene, in the sense that you do them in the background. But is it actually helping your team help customers better? If you don't know what outcome the customer wants to achieve, or what problem you're trying to solve, you're not going to help customers grow, and at the same time you're not contributing to the business. That's the mindset a manager or leader should have first. Only then can they coach the team to get there.
Absolutely. Absolutely. That's all from my end. Karthick, thank you so much for joining us. This was wonderful. See you soon.
My pleasure, and thank you for having me. Have a good day. See you.
The Second Year is a podcast by RetainSure.
All episodesWe use first-party analytics to see which pages are useful, and advertising tools to measure our ads. You choose what we may use. How we use cookies
Your browser sends a Global Privacy Control signal, so advertising is switched off by default.
