Kustomer

We’re talking today about Kustomer and how it was used at your former company. Could you give a brief overview of the company as well as what your role was there?

The company is the largest telemedicine platform for obesity and diabetes. We have an integrated care model where we make community behavioral coaching and prescription obesity medications accessible to patients through telemedicine.

I was formerly the Head of Care Operations. I led the marketplace function for the company, which is the entire clinical component of the company. Everything from hiring and onboarding all of our doctors, essentially making care accessible in all 50 states, and operationalizing our prescription formulary. The company was unique in that we made the full spectrum of obesity medications accessible to patients: everything from phentermine, which is a Schedule IVcontrolled substance, to GLP-1s, which are on patent. So my day-to-day on the pharmacy fulfillment side was program-managing doctors learning how to prescribe the medications and ensuring that on the supply chain side, we actually had the right sort of pharmacy network that could help fulfill the demand for this medication.

I’d say my day-to-day revolved around three tools: our custom, in-house EHR, Kustomer, and Dosespot. The custom EHR was built from day one of the company. It seemed easier for us to build our own versus buying one, as there just weren’t a ton of great options out there. Kustomer was our hub for all patient communications; our coaches used the product to check in on patients. Provider messaging was actually through our EHR. Finally, we used Dosespot as our electronic prescriptions provider.

One thing I want to flag is that Kustomer was acquired by Facebook or Meta. I’ll focus on why Kustomer was a good decision for us back in 2019-2020. They were later spun out of Meta, but this review will speak about Kustomer pre-acquisition and during the acquisition – the current implementation might look different.

When did you purchase Kustomer and how long had you been using it before you left?

We’ve always been on Kustomer because the venture studio we belonged to had an enterprise license for Kustomer. All the telemedicine companies in the studio used Kustomer.

So was procurement driven by the fact that this company was being incubated at a venture studio that already had used this CRM tool at other companies? Could you speak to what that procurement process looked like, given there was a comfort with an existing tool that you ultimately ended up using? Did you consider other vendors at all?

For CRM, not really. The Meta acquisition of Kustomer was a good forcing function for launching an RfP process. But until then, we were bought into Kustomer, noting that it might not have been the best tool. I had used Zendesk as a ticketing system and CRM earlier; I think Zendesk is a lot easier to use. What’s great about Kustomer, though, is the data structures. That’s really the main point of differentiation.

Kustomer was designed for consumer companies, which is what our company was at the end of the day. We think about engagement on a patient-by-patient basis, and at any given time, you have people from different teams working with the patient, whether it’s customer support, the coaching team or care operations. And we needed a CRM that could support that. That was one of the reasons why we started with Kustomer. The other reason was that another portfolio company of our venture studio also used Kustomer, so we were grandfathered into that license.

I’d love to better understand how Kustomer was used at your company. Who was using the product or engaging with it, and what were their workflows typically?

It was pretty much everybody that was patient-facing, except for our doctors. That included the coaching team (coaches provided regular check ins and behavioral therapy over Kustomer), customer support, and my care operations team. My team was a more specialized team that essentially served as the coordinating function for the clinical side of the business.

Given that you had three different teams working on the same platform, were there different feature sets that worked for each of these teams? I’d love to understand how the features mapped onto these three groups of users.

I actually think that we didn’t really need distinct feature sets across the three. They were different functions within the company, but we didn’t need distinct feature sets for them. The interactions involved a certain degree of automation. We also used a lot of intake forms.

We had solutions engineers and product ops folks who came in and helped wire a bunch of different systems together (Kustomer is ultimately a low-code solution). We actually felt like Kustomer was pretty good in terms of what they already had, but also how we were able to customize it.

Were there any features that you didn’t use or chose to exclude either because you didn’t need them or because they didn’t really work the way you would want them to?

I actually think we didn’t use Kustomer to its full potential. I’ve seen some massive implementations of Kustomer at other companies and there are Kustomer solutions architects whose full-time job is to set up these systems. I think it was hard for us because we had a custom EHR. Kustomer is known for having really great integrations with Airtable or with Zapier – essentially every B2B SaaS that you can think of – but they didn’t have an integration with our EHR. That’s where it got a little more manual and messy. Our ingestion or digestion process would involve exporting a lot of that data into an Excel spreadsheet and having to manually import it into our EHR.

I have seen e-commerce businesses use Kustomer in a much more effective way than us. It’s fully programmable – think of it as a low or low-ish code solution. It still requires some code, but you can actually code workflows and have different systems talk to each other.

It’s a bit of a unique situation, given that you had a custom EHR that you had to connect with this otherwise very well-integrated solution. How easy was it to build what you needed? What kinds of resources did it take and as well as time I think, to actually get it to work the way you wanted it to?

When I left, it was still not integrated. It’s not easy. We built manual workflows around it.

Given that you weren’t submitting claims in a significant way, what drove the need for an EHR in the first place; why not just do everything in Kustomer?

We probably could have because Kustomer was HIPAA-compliant. We built our own EHR because we wanted the most streamlined experience for our providers. Our intention was to build an EHR that could help summarize the intake form, which was long and comprehensive. The reality was that you couldn’t expect every doctor to read exported PDFs. Having our own EHR allowed us to, for example, flag comorbidities that were identified in the intake form. Eventually we even had a prescription recommendation engine based on the intake form.

So it was oriented around the prescribing workflow specifically.

Right.

In your situation, which came first? Did Kustomer come first and then you built the EHR around the things Kustomer wasn’t able to do? Or was it the other way around, or perhaps were they both set up around the same time?

Parallel processes; we saw them as serving two different user groups.

Given that you were doing all of this manual work to bring the two together in whatever ways you needed to, I’m curious what the experience with the APIs was. Did you feel like they were robust and comprehensive and easy to use or were there issues with that?

I thought Kustomer’s APIs were really easy to use and robust. On the low-code side, I thought Kustomer was great – it was modular, configurable. If you want to create efficient workflows, Kustomer is really good for that.

When you think about the features that Kustomer had, what worked well and what didn’t?

I loved how programmable and modular it was. It was easy for us to spin up new workflows with Kustomer. And it was not really hard to use.

Data privacy is a big component in health care delivery, and Kustomer was never designed with that in mind. I came from the world of B2B SaaS, so there was a lot about Kustomer that I liked. I thought it was pretty comparable to Zendesk and better in some ways.

The reason why Kustomer was not a great option for healthcare was that there was no access control. The way Kustomer is set up, a user can see everything. But your coach, customer service team, and even your clinical admin teams are not medical professionals at the end of the day. They are there to support the patient, but there are certain conversations that need to just be between the provider and the patient. I could go back in time and look at conversations that a patient had with a CX representative two years ago, but you might not want that level of access for other people. This was why we kept it separate from the EHR and limited access to our EHR.

And that comes down to the fact that there were no access permissions and that it wasn’t built for some of the very industry-specific regulations that healthcare has? What would you ideally like to see in a healthcare CRM – in a platform that’s actually built for healthcare that you would be using in a context like this?

First of all, access control. I don’t recommend any company to have bifurcated systems. For most of my time at the company, we essentially had two CRMs – Kustomer and our custom EHR, which was like a CRM because providers were still interacting with patients in it. Good healthcare CRMs should definitely have robust permissioning.

Being able to handle escalations is also really important. Kustomer wasn’t set up well to do that. I think it was designed for e-commerce and so it’s great if you’re trying to, for example, sell shoes on the internet. Once your customers become more complex, there’s more variance and you just want a little more data on them, Kustomer is not set up to do that. I wasn’t able to run analysis on an issue-by-issue basis. It was always on a customer-by-customer basis.

You had two tools that worked like CRMs for different user groups in the organization. What did that look like for patients? Were they engaging with different platforms? Or did everything come together on your own platform?

The customers did not experience that. We had a mobile app and a web app. Patients would go to different places on either of those apps, but they were not using two different systems.

How did you manage the source of truth? Where did it lie? Was it in different places for different details about the customer?

This was tough. We did a lot of manual reconciliation towards the end.

I will give you an example of a workflow where that bifurcation was challenging for us. We launched a pilot for GLP-1s and decided not to integrate them in the broader intake form and medical recommendation engine. We were still testing our capacity to deal with insurance and prior authorizations, so we decided to open it up to a very small cohort of our patients. Everything was manually maintained and updated. Note that different drugs had different prescription refill periods. We had to make sure that for every single patient that we ever prescribed to GLP-1s (whose source of truth is really in DoseSpot and our custom EHR), their data was moved to Kustomer – manually. There had to be a way we tagged every single patient profile with GLP-1, to make sure they were on the right GLP-1 refill schedule.

You’ve mentioned a few times that Kustomer was built for the e-commerce industry. How did that influence how you used the platform or the sorts of customizations you needed to make it work for your needs?

They had good in-house analytics that went beyond only measuring efficiency. Built-in dashboards helped us measure response rates, SLAs, and patient responsiveness, which helped us count daily, weekly and monthly active users. This was in line with how consumer businesses defined success. Zendesk, on the other hand, only focused on efficiency.

Leading care operations, however, efficiency was only one metric I cared about. I was also interested in understanding the distribution of issues that were coming up and trying to systematically tackle them. Kustomer was less good for that and didn’t have the level of issue-tagging that Zendesk had.

There are service-focused CRMs, that help address issues and tickets, and CRMs that are longitudinal in nature, managing patient relationships and guiding patients through programs. How did you use Kustomer – was it both use cases? Were there others?

That’s a great way of framing it. We used Kustomer for longitudinal relationship management. But you could imagine, as the care operations org matured, we also had issues-based use cases. Both needed to coexist, but Kustomer was disproportionately for relationship management. In the earliest iterations of my company, health coaches used it to build rapport with patients. In my part of the organization, providers were the most scarce resource. Having a CRM where we could be more proactive and answer patient questions without provider interaction was pretty key, but it was hard to do that in Kustomer.

So, while a Zendesk might be better for ticketing use cases, Kustomer was more useful for longitudinal relationship management. Is that reasonable?

I think Zendesk is fantastic when customer service or issues can be addressed through standardized, discrete responses. Newer versions of Zendesk turn responses into FAQs, for example. Kustomer is very high-touch relationship management, where even if you are sending automated responses, it shouldn’t feel like that. And I’ve noticed a lot of D2C companies try to make the customer experience feel longitudinal: they want patients to have a real relationship with the brand and with all the people who are part of their care team.

There are ways to have longitudinal care management but also introduce discrete objects. In the airline industry, there are chatbots where you might be chatting with a real person but they’ll also send you a survey to put in your frequent flier number or have you select something from a drop down menu, which enables better routing. Healthcare probably has to move towards something similar, where it’s integrated.

Did Kustomer support the development of programs or plans that patients are moving through, using automations related to specific events? (With a program, you’re going through a series of steps and phases, as opposed to features that just make it easy to communicate with a customer)

We were not able to build programmatic elements. For programs, we used Kustomer in combination with Braze. It’s more of a marketing tool but we used Braze for programmatic elements. For example, we would remind folks to do weigh-ins on Wednesdays so they could report their weights. Kustomer was still the backend and we used Kustomer objects to store such patient information.

And was that an easy integration to set up, between Braze and Kustomer? Did you get it off the shelf? Did it work the way you wanted it to in terms of data flow or were there any hiccups with how well those two systems worked together?

We didn’t need a special implementation of Kustomer: it was off-the-shelf. Kustomer is low-code, but low-code is a misnomer because a lot of folks don’t realize that even low-code tools still require some solutions or engineering support to ensure everything works. We hired a specialist (Kustomer has a whole marketplace of specialists) and they set it up for us. In terms of ease, it was easy for me to design the workflow. I could read the API docs which made it cut and dry, but we never felt it was so easy we could actually implement ourselves.

I’m curious to hear more about the onboarding and implementation process with Kustomer. Once it was known that Kustomer was going to be the tool you were using, how long did it take before the platform was actually implemented and usable for users?

It was really fast for us because I we’ve always had a good external solutions engineer. Kustomer is sort of like Salesforce – there are people who do all the implementation for you.

Do you recall how long that took?

Less than a week. It was fast. I would write out the PRD (product requirements doc) and then sit down with our solutions engineer. He was fantastic. He would review it and then scope it out. He was the person who probably had the best sense of the feasibility of what I needed. And then he and his team would implement it for us.

Was this someone who sat outside of Kustomer?

I don’t think he worked for Kustomer. This was his own practice.

How did you feel about Kustomer’s customer support and account management, granted that this sat within a bigger agreement that your venture studio had with them?

We didn’t have any negative interactions with them. With the Meta acquisition they told us they couldn’t sign a BAA going forward and gave us about a year to go and buy a new CRM and migrate all our data. So that was a bit stressful. But I feel like that was out of their control.

Did your being grandfathered into the agreement with Kustomer influence features that you had or didn’t have access to?

No. As far as I’m aware, we had everything we needed. I’ve never had to upgrade to get access to other features.

Could you talk a little bit about what the procurement process was like once you knew you had to migrate to a new CRM, especially given that you weren’t choosing one for the first time but were looking for a CRM that you would have to migrate to?

We ended up going with FreshWorks. We were pitched a bunch of other tools. We started looking for a replacement in early 2022 and were pitched CRMs designed just for digital health and wellness. We went with Freshworks because it was the most similar to Kustomer. The company was huge at that point. We had about 150 non-clinical and over a 100 providers, so we were a 250-300 person company. Buying a CRM that was radically different from Kustomer would have required us to completely retrain our workforce. We got feedback from our customer service teams and it was pretty clear that we wanted a CRM that was close to Kustomer’s so we didn’t have to drastically change how we use these tools.

Do you have advice for anyone who might have to go through a similar migration process, leaving one CRM and finding another?

Personally, I feel like that never happens. The only reason we got off Kustomer was because we couldn’t use it after a year. CRMs are really sticky: they have more influence on how people do their work than the other way around. You asked how I tried to adjust Kustomer to meet my needs, but honestly, I think we spent most of our time adapting to the core functions and features of Kustomer.

That makes sense. You adapt to what the system or platform allows you to do and not.

I don’t think this is always a bad thing. When you’re evaluating a CRM, you have to buy into their vision for how you should work: how you organize information, how you coordinate teams, especially in a remote workforce. It really helps inform how you run your organization. And so with the RfP process, you have to buy into their vision of how you do your job.

What do you like most about Kustomer’s product?

I really like the automated workflows in Kustomer and how easy it is to build custom workflows. To be even more specific, Kustomer allows you to add custom fields to provide more color to your customers (this is where its e-commerce or consumer DNA comes in). I haven’t seen that in other CRMs. So it’s a fantastic tool for building robust profiles for your customers and creating high-touch tailored services at the customer level.

What did you dislike most about the product?

I just didn’t think it was good for health care. It was really hard to run a care ops org with it.

Was the ability to tailor permissions the main reason you’d say that?

Yes. Lack of access control was one of the issues. But I also think it would have been too complicated for doctors to use. The custom EHR we built had its challenges but it was also really simple to use. From my experience, a lot of doctors are not the most tech-savvy. And when you look at Kustomer, it’s really complex. There are a lot of columns and different use cases. I liked the modularity, but I can’t imagine ever onboarding a doctor and them being able to just go in and start using it. I couldn’t do so even if Kustomer had introduced access controls.

Looking back, do you feel like you made the correct assessment to go with Kustomer?

Back then, we didn’t have better options. This was 2019. Athenhealth was not viable for us because it was too expensive. And the problem of Athenahealth is that non-doctors don’t know how to use it. I think Kustomer was probably the best tool for us across functions.

Is there anything we haven’t covered? Is there anything you wish you had known as you were choosing a CRM or implementing it?

Ultimately, I ran an operations organization. People need to appreciate how iterative some processes can be. The company I worked for was one of the first players in the weight loss space and so, when we were building in 2019-2020, we were figuring things out from scratch. We had a high level of nimbleness and flexibility because we needed to change our workflows. Iteration is super important and having tools that can support that is also important.