In this episode of Mastering CS: Candid Leader Insights, Irina Cismas sits down with Vlad Zholnerchuk, CS Team Lead at Health Samurai, a platform that helps healthcare organizations build and scale interoperable clinical data systems. Vlad came from e-commerce and SEO analytics before finding himself deep in the world of healthcare data standards, and that journey shaped how he thinks about building a CS function from the ground up.
He shares what customer success looks like when your customers are engineers building clinical systems on top of a complex technical platform, how he restructured his team to be cross-functional from day one, what an AI agent that auto-reproduces customer issues looks like in practice, and what he would prioritize if he had to build a CS team from scratch with just three people.
What You’ll Learn
- What customer success looks like in a highly technical, healthcare-focused platform company
- Why Vlad restructured his CS team to include engineers rather than separating support from CS
- How Health Samurai tracks customer health beyond product usage metrics
- What the sales-to-CS handoff looks like when CS is involved in pre-sales from day one
- How the team built an AI agent that reproduces customer issues in minutes instead of hours
- What roles Vlad would prioritize if building a CS team from scratch with three people
- What was hardest about transitioning from e-commerce and SEO into healthcare CS
Key Insights & Takeaways
CS in a technical company is a different job. When your customers are engineers building on top of a complex platform, the CS team needs deep technical expertise, not just relationship management skills.
Support and CS should not be separated. Having engineers embedded in the CS team rather than sitting in a separate support function means issues get resolved at the root cause, not just patched over.
Silence from a customer is a warning sign. If a customer stops asking questions, they are either struggling on their own or not using the product to its full potential. Neither is a good sign.
Start by observing before building. Understanding how customers behave and finding the patterns comes before designing any process. Build around what you see, not around a template.
AI can cut issue resolution from hours to minutes. An agent that spins up environments, reproduces bugs, proposes solutions, and flags documentation gaps changes what’s possible in technical CS.
Every team member should have a superpower. When hiring, look for the specific capability that the team is missing, not just a generalist who fits a role description.
Domain expertise is earned, not hired. Vlad learned to read the FHIR specification and picked up basic programming to be able to speak his customers’ language. That investment changed how he could serve them.
Podcast Transcript
Intro
Irina (0:07 – 0:31)
Welcome to Mastering CS Candid Leader Insights, the podcast where we dive into the world of customer success with industry leaders. I’m your host, Irina Cismas, and today I’m joined by Vlad, CS Team Lead at Health Samurai, a platform that helps healthcare organizations build and scale interoperable clinical data systems. Vlad, I’m really happy to have you here.
Thanks for joining.
Vlad (0:32 – 0:33)
Hi. Thanks for having me.
What Health Samurai Does and What CS Looks Like in That World
Irina (0:35 – 1:06)
You work with healthcare organizations that are building clinical systems on top of a box. And I hope I didn’t get it wrong, but I want you to tell me more about what does Health Samurai app do in general and paint me a picture of what CS looks like in that world. For the people who do not know what is the app doing in your world, tell us more about it.
Vlad (1:07 – 2:01)
It’s not really an application, it’s rather a platform. We do all the technical heavy lifting for all the teams and companies building software in the healthcare space. Specifically, we are focused on working with the FHIR standard. FHIR stands for Fast Healthcare Interoperability Resources, and it’s a standard describing how patient data and all medical data is supposed to be shaped, stored, transferred, used, and everything around it.
What we do is provide a database with a set of predefined APIs that can be used by our customers so that they can focus on developing their specific applications and solutions on top of it.
What Customer Success Actually Means at Health Samurai
Irina (2:03 – 2:09)
And in this world, what does customer success mean exactly?
Vlad (2:10 – 4:19)
I’m not even sure it’s unified within the market, so I’m solely going to be talking about how it works in our company specifically. The general idea is the same: the main goal is to help the customer reach their goals, to make them successful with our products and to make their products successful by leveraging our solution under the hood.
But in my world, it differs from common customer success because most of the teams I work with consist of technical people: engineers, architects, DevOps engineers, and product managers. Our solution is also a pretty complex technical one. One of the biggest things here is that we have a lot of deep technical conversations and a lot of support involved. It’s not that I just have a support team that I delegate tasks to, but rather the whole customer success team. We have managers like myself and engineers of different specializations.
One of the biggest things is that we need to dig deeper into the technical nuances of the challenges and solutions the customers are building. We need to have strong technical expertise, not only to help the customer understand how a specific feature in our product works, but to guide them through the world of the FHIR specification, explain how it’s supposed to work, find best practices, and help them design their solution, not only from the perspective of leveraging our product but from the whole technical perspective as well.
Irina (4:20 – 4:24)
And in that setup, what do you spend most of your time on?
Vlad (4:27 – 6:11)
Communication of all kinds. We have a lot of regular meetings with customers, not only Q&As but also architectural sessions and design meetings, and a lot of communication via chats and support channels.
Because of the complexity of the solution and the domain, the learning curve is pretty steep. When we have a new customer on board, it’s not only that they need to figure out how our solution works, but they are usually also new to the world of FHIR and medical standards as well. So we help them learn that too.
The remaining part of my work is focused on figuring out customers’ needs, priorities, and goals. Our product is driven by the specification, by legislation and compliance requirements, but mostly by customer needs and customer cases. It’s really crucial for me and my team to understand what the customer is doing, what their goal is, and what their pain points and challenges are. We try to collect that information, find the patterns, and figure out, for example, if a question a customer raises has been asked before and how other customers have addressed the same challenge.
What a Healthy Customer Looks Like and What Gets Measured
Irina (6:13 – 6:38)
In most CS roles, success is mainly about adoption, getting people to use the product. I’m curious, what is your definition of a healthy customer? What are you tracking when it comes to adoption metrics?
How does success look like in KPIs and numbers and in metrics that you are tracking on your side?
Vlad (6:38 – 9:12)
We have product usage analytics and we track what customers use and which features, because it’s definitely important. One of our goals is to make sure customers are using all the available tools. And it’s not even about upselling, because most of the features are already included in the core product. It’s rather about making the customer stick to our platform more, first of all because we provide them with the best solution in the market, and second of all because it takes a lot of burden off the customer’s shoulders. Instead of maintaining a lot of internal tools and different systems, they can get more just from using our platform.
Apart from that, we track how close the customer is with us, whether we are aligned on the executive level, whether we understand their goals, priorities, and needs.
Communication and engagement is crucial here because if a customer is not talking to us and the team isn’t asking questions, it can mean one of two things. Either the customer is trying to figure out a lot of things on their own, which is not good because if they’re not experienced in this space, they start making mistakes that others have already made, and we could have helped them avoid those in the first place. Or the customer isn’t really using the product, because the sheer complexity makes it impossible to figure out everything on their own, which means they’re not using it to its full potential.
And the last thing is understanding the customer’s progress: whether their implementation is on track or whether they are behind.
Building CS Processes from the Ground Up in a Technical Company
Irina (9:12 – 9:27)
I know that you’ve been building the CS processes right from the ground up. When you are doing that inside the deep technical company, where do you actually start?
Vlad (9:30 – 13:12)
I spent quite some time not trying to build processes, but rather observing how everything works: the interactions between teams internally, how everything works on the customer side, and trying to understand the patterns, how different customers behave, and what the similarities are. We have companies building very different solutions in different spheres within the health tech space.
Once I figured that out, I started aligning the customer patterns with our internal patterns and then came up with some processes. When I was starting out, I just had a couple of managers like myself on the team, and we built the team the standard way: CS managers, with a technical team next to you that solves support issues and helps with technical expertise.
One of the first things we did was reshape the team to include engineers. And they are not just support engineers, they are customer success engineers. They go to meetings with us, they consult customers directly on the call. If a ticket is raised, it’s not me trying to reproduce it and then escalate it to the support team. It’s the engineer who looks at the whole customer path. They know what the customer is trying to do, they know the product from a technical perspective, and they figure out the issue and come up with a solution that addresses the root cause. Why did the issue happen in the first place? Is it a bug? If it is, the first step is to help the customer, but the second step is to fix it so it doesn’t happen again. If the customer couldn’t figure out how something works, is it a feature design issue? Is it a lack of documentation? Then we go and create the documentation and make changes.
So building CS processes in my company started with making the team cross-functional: not only managers but also engineers. Second, support is not separated from us, it’s within the team. That may change once we grow our customer base to a thousand customers, but for now it works best. The product developers are focused on features and we are focused on helping the customer.
And then it’s about finding the patterns and automating everything that can be automated, and constantly improving the documentation. Every customer question will probably end up reflected in the documentation in the form of a guide. That’s essentially it.
How Sales and CS Work Together at Health Samurai
Irina (13:14 – 13:58)
There are a few things I want to dig deeper into based on what you’ve told me. The first is the cross-functional dynamic. You spoke about engineering and support sitting within the same team as CS, with strong synergies between those roles. But what about the sales team? How does the sales part work? Is it a traditional handover from sales to CS, or how do you land an account?
Vlad (13:59 – 15:56)
It depends. We work pretty closely with the sales team. We have weekly meetings dedicated to our interaction, but we also sync daily on our standup.
Sometimes it’s the traditional handoff dynamic. For example, if the lead during the pre-sales stage didn’t have that many questions or challenges and the sales team was able to address all of those without asking for external help, we would still know about the progress because they share it with us daily and weekly. And if something is coming up, I usually know about it weeks or months in advance. Once we sign the customer, we do the traditional handover meeting where we collect all the data.
But more frequently, we start working with the customer before that, during the pre-sales stage, because of the complexity of the domain. Prospects come with questions that can only be addressed by our team. So we go to meetings with prospects, do demos, answer their questions, and their support questions immediately land in our inbox as well. We usually create a support channel for all prospects just to make sure their evaluation process is going smoothly. And all of this is done by the customer success team.
AI and Automation: The Use Cases That Actually Matter
Irina (15:58 – 16:52)
The second thing I want to dig into is automation. I was expecting that automation is one of the things on the table when it comes to CS productivity and freeing up time. And I’m assuming AI is also involved. So what is the combination of AI, tools, and systems you are using to free up your time, and what are your actual AI use cases? This is a very hot topic and everyone wants to learn from others how they are leveraging AI. And I assume it’s more than just summarizing meeting notes in your case.
Vlad (16:52 – 21:14)
A couple of years ago when the first AI note takers came out to the market, it was a big change, not having to write notes manually anymore.
Everyone’s talking about AI and I think sometimes it gets to the point where people get tired of hearing about it. In our product, we don’t push it. We understand that our customers are going to be leveraging AI tools and agents, and we are just trying to make a product that is optimized for that, meaning that whether you’re a senior engineer or a junior coder, you will be able to use it.
Internally, when it comes to automations, the first thing to consider is security. In many cases we cannot leverage AI tools because they would get access to sensitive customer data. It’s a reasonable limitation and we respect it.
That said, I want to share one specific use case where we get the most value: reproducing customer issues. We built an agent for that. We created a set of skills, and once a new ticket is raised, the workflow is triggered and the agent on its own tries to reproduce the issue, spinning up the environment and going through all the steps. It then returns an exhaustive report explaining what it did, what the result was, and what the findings were, whether the bug was confirmed or not, where the problem is in our codebase, potential solutions, immediate workarounds, whether the behavior is well documented, and proposed enhancements.
To give you a sense of what that replaces: when a customer says something doesn’t work, we first have to figure out exactly what they did and what they used. Then we spin up the environment, go through all the steps, explain everything to the engineer, wait for them to look into it, find the problem in the codebase, come up with a solution, and then get back to the customer. Just reproducing the issue could take 30 to 40 minutes, and then you wait hours or even days depending on the complexity.
Now I get a response in about 10 minutes. You can’t trust everything the agent does, so you still review it, but in around 95% of cases you have something to get back to the customer with in minutes instead of hours. You still create a task for the engineer to address the issue, but the process is dramatically faster.
It’s also great for pattern recognition. When we roll out a new feature, you can run agents to search our internal database for similar use cases and surface relevant context quickly.
If You Had to Build a CS Team from Scratch with Three People
Irina (21:15 – 22:01)
Your CS setup is unique, the way you work and interact is tailored to the industry you serve. And I know you’ve been in other industries as well. You came from e-commerce and SEO analytics, and now you’ve been exposed to healthcare. If you had to rebuild the CS team from scratch with only three people, what roles would you prioritize first?
Vlad (22:01 – 23:40)
In my space, I would definitely have someone with a technical background, whether an engineer or a solution architect, someone with solid technical expertise to be able to talk to customers in their language. The other two would be customer success managers, but even when hiring for my team, we focus on versatile specialists. The wider your experience and the more technical background you have, the better.
One idea I borrowed from one of my supervisors is that when building your team, it’s great to have every member have their own superpower. We try to do that. For example, when I was hiring a new manager, one of the things we wanted to improve was the upsell process, so I looked specifically for someone with a solid upsell background. And if we’re talking about the technical person, they also have their own set of superpowers that can be helpful.
So to summarize: a technical person, people with versatile skills, and everyone has a superpower.
The Hardest Part of Moving into Healthcare CS
Irina (23:41 – 24:03)
And now the last question, you’ve been serving different industries and e-commerce and SEO is quite different from healthcare. What was the hardest thing for you when you joined the company? What was the thing that you needed to adapt the most to?
Vlad (24:04 – 25:27)
There were definitely two things. First, the technical part of the job. Before this, I was talking to marketers, product managers, project managers, and sales people. Now my main audience is engineers, and not junior engineers, but engineers with a lot of experience and deep knowledge. I had to learn their language, and it was new to me. I even went the extra mile and started learning a bit of programming, not to be able to code, but just to understand my customers better.
The second part was the healthcare domain itself, the world of healthcare medical standards. It was completely new to me, something I had never heard about before. I needed to dive deep into this world and figure out how to even read the specification and work with it, so that I could eventually teach customers to do the same.
Irina (25:29 – 25:50)
Vlad, this was a really interesting conversation. Yes, in a world where your product is someone else’s clinical infrastructure, it’s a different kind of responsibility. And I think that came through in how you talked about your day-to-day work.
Thank you so much for joining me and for sharing your story.
Vlad (25:51 – 25:53)
Yeah, thank you for the great questions.
Irina (25:54 – 26:01)
And to everyone listening, thanks for tuning in. Until next time, stay curious, keep learning and mastering customer success.
