What does Customer Success in EdTech actually do? The big picture seen after 7+ years
Introduction
"What exactly do you do in Customer Success?"
I have lost count of how many times I have been asked this question.
In particular, information on CS in the EdTech (Education x Technology) field is still scarce, even within the SaaS industry. While BtoB SaaS CS case studies are increasing, stories dealing with the unique difficulties of "learning" products rarely emerge.
In this article, I will share the big picture of EdTech CS, based on my 7+ years of experience in CS for corporate learning services.
I wrote this for those who are "interested in CS but want to know what EdTech CS specifically entails," or those who "want to know if their CS experience can be applied to EdTech."
What makes EdTech CS decisively different from other SaaS CS
First, EdTech CS has characteristics not found in other SaaS domains.
That is, the degree to which "value is not created just by introducing the product" is extremely high.
For example, with an expense reimbursement SaaS, operational efficiency increases once it is introduced. But what about learning services? Even if introduced, no value is created unless the learners actually study.
In other words, EdTech CS must design for behavioral change not only in the "contracting company" but also in the "people who actually learn." This is its greatest characteristic and its greatest difficulty.
Main business areas of EdTech CS
The tasks I have been responsible for so far can be broadly divided into three categories.
1. Implementation and utilization support for corporate clients
In corporate learning services, the person in charge at the contracting company (HR or training manager) is the first counterpart.
What we do here is similar to onboarding for general BtoB SaaS. We align on the purpose of the implementation, draw up a schedule for internal rollout together, and accompany them until operations are on track.
However, there is a difficulty unique to EdTech. The points where the client's person in charge feels success depend on metrics that are hard to control oneself, such as "login rates" and "completion rates."
That is precisely why reaching a consensus on "what constitutes success" at the time of implementation is so important.
2. Analysis and visualization of learning data
I believe this is my greatest strength and the core of EdTech CS.
Learning services contain vast amounts of data. Who logged in and when, how far they progressed, and where they dropped off. The job of CS is to analyze this data to visualize 'what is happening' and connect it to the next action.
I have operated by using SQL to retrieve data myself. For example:
Visualizing completion rate trends weekly to use in client reports
Automatically assigning learning statuses (Not Started/In Progress/Completed/Dropped Out) to narrow down follow-up targets
Listing users who haven't studied for 10 or 30 days and automating alerts
Even without a CS platform, you can do quite a lot with just SQL and a CRM. I will write specifically about this in future articles.
3. Churn Prevention and Retention Strategies
EdTech churn has unique patterns.
The most common is the 'implemented but not used' pattern. In other words, 'No Start.' Learners don't log in to begin with, or they start but stop halfway through. If that state continues, it is judged as 'ineffective' at the time of contract renewal, leading to churn.
To prevent this pattern, it is crucial to catch the signs of churn as early as possible.
In my case, I designed health scores to visualize 'Churn' and 'No Start' separately. This is because the actions you should take are completely different for a state of 'using it but dissatisfied' versus 'not being used at all'.
Building a CS team with 'Teachers'
EdTech companies have many members from the education industry. In the teams I have managed, members who were former teachers or from educational NPOs have joined the CS team.
They have a very strong desire to 'do it for the learners.' That is a major strength. On the other hand, it required some ingenuity to help them develop a CS-oriented awareness of numbers.
The thought process of 'the completion rate is X%, so we should take this action' is not intuitive for educators. However, to achieve results as CS, data-driven judgment is indispensable, not just intuition.
I feel that balancing this 'educational mindset × data-driven CS' is the most interesting and most difficult part of building an EdTech CS team.
What is the difference between Customer Success and Customer Support?
When explaining the work of CS, this is a question that cannot be avoided. Both inside and outside the company, I am always asked, 'How is it different from support?'
I always answer like this.
Customer support is the job of solving problems that have already occurred. Customer success is the job of preventing problems from occurring.
For example, if a learner contacts us saying, 'I can't log in,' solving that is the job of support. On the other hand, anticipating that 'learners at this company haven't logged in for 10 days, so there is a high risk of cancellation at the time of contract renewal, let's follow up now' is the job of CS.
Support is 'reactive,' while success is 'proactive.' Support is 'inquiry-driven,' while success is 'data-driven.' This difference is clear when you actually do it, but it is very difficult to understand from the outside.
The reason it is difficult to understand is that the better CS functions, the more 'nothing happens.' The fact that a problem did not occur is invisible. That is precisely why it becomes difficult to communicate the value of CS within the company.
How to communicate the value of CS within the company
Proving the value of a 'job that prevents problems' is not easy.
It is a struggle to convey the importance of 'preventing problems that haven't happened yet' to management who have no CS experience.
There is also the reality that because it is not a department that directly generates revenue, its opinions are easily disregarded. However, CS is the one that has the longest relationship with the client. Sales hears the needs, and CS proposes 'what can be done.' When that cycle works well, the value of the CS department becomes clear.
What I will be writing about in this note from now on
In this note, I will share the know-how I have actually used in CS within the EdTech field.
For example:
Designing automated onboarding follow-ups using SQL
Practical examples of health score design and operation
How to help team members without CS experience develop the habit of 'speaking with numbers'
How to present data to communicate the value of CS to management
I will only write about things I have tested in practice and that have actually been effective.
I would be happy if there is even one thing that CS personnel handling products involving 'learning' or 'behavioral change'—not limited to EdTech—can take away.
If you follow me, you will receive updates. Thank you.
Dan | Data-driven CS. Over 7 years of CS experience in EdTech and Travel Tech fields. Armed with SQL and CRM, currently practicing onboarding design, churn prevention, and health score operation.