Salesforce (Health Cloud)

So today we’re chatting about Salesforce Health Cloud and how it’s used at your company. Before we jump into that, could you give us a brief overview of your organization and your role there?

We’re building an ACO provider that has some additional value-added services, where we are hiring local resources in the markets that our providers are in to wrap around them and offer them some additional support as they take on risk. And then we’re helping those providers take on full risk with their payors.

I’m the Head of Technology and was involved in helping us make the decision to move forward with Health Cloud.

How long have you been using or implementing Health Cloud?

We signed a contract in Q2 this year and we’re probably 75%–80% of the way through our Health Cloud implementation. So it’s been maybe four or five months that we’ve been building, and then our local teams will be hired and using the platform by Q1 2024.

Going back to the overall purchase decision itself, what problem – or what discrete event – caused you to look into purchasing Salesforce Health Cloud, and how do you think about the set of problems that it solves for you?

We have a few different types of users who we’re trying to support in the field. One is a network development user who is doing sales to provider groups. That group was going to be on Salesforce no matter what, since that was going to be the CRM that we were going to pick. There is also a user that is a health coach, or a care management user, that’s wrapping around a provider panel and delivering some health coaching and care to their members.

There are a bunch of different levels of credentials that those providers could be – some of them could just be coaches, some of them could be nurse practitioners, some of them could be social workers – but having a platform that that whole team could use and could interact with each other on was important. The third type of user was an account executive for the practice.

There’s a pretty interconnected series of workflows across all three of those different types of users, and we wanted to have a platform that would be able to provide workflow visibility across all three user types, with some shared data models in between.

The practices that providers are part of would be pitched and then signed on to or contracted with this organization, so they would roll into our ACO agreement. Underneath that practice, there are individual providers that our team will need to have relationships with, and those providers will have patients that our team is caring for. So it’s creating a single view into those different types of relationships and then being able to provide visibility into what is going on with the patient at a specific provider across the full team of people who need access to that, whether it’s a clinical person or somebody on the account management side.

Essentially, we needed a care management platform. So we could either build a care management platform or buy a care management platform, and if we were to build it, there were still these integration points into Salesforce for the account executives and the network development people. So our question was: Is there a platform that can do all of this? We were working with maybe a six-month timeline, so we wanted to find a platform that would give us a higher starting point, and Health Cloud was something that we could configure pretty quickly for that use case.

Did you outline any additional requirements that you used to evaluate Health Cloud versus other providers?

There were a few different exercises that we went through to outline what we needed for the platform. So there was a set of care management use cases and the personas within those – health coaches, nurse practitioners, social workers, and others – and then there was a separate use case around the account management function.

So basically, across those personas, we listed out the different things that we needed people to be able to do. There’s a telephony need around being able to dial out from Salesforce. There’s a need to manage care plans. There’s a need to communicate with the provider, and there’s a need to communicate with other members of the team. We listed these out and then we did the analysis to determine which platforms were available and which of them could meet all of these needs.

We found a big gap across some of these platforms. Salesforce also didn’t have all of the functionality that we needed, so the question became which other vendors we could bring in to partner with Salesforce to get us the functionality that we needed.

I could go into specifics about the requirements we had, but at a high level, these were care management functions. That includes conducting assessments, documenting the encounters and then creating care plans. There’s a piece around calling patients and calling physicians. There’s a piece around generating documents that we would send to our practices – providers whose patients we’re taking care of – so that they’re able to put those into their medical records. So there’s the actual creation of those artifacts. And then on the account management side, there’s making notes. It’s the typical CRM stuff: making notes on providers, documenting next steps, tracking addresses, and being able to map how you visit each of these different practices and keeping track of when you do that. There’s also creating educational materials and reports to bring to the provider during your recurring visits with them as you build the relationship.

When you think through the competitive set, were you looking at multiple vendors, and how did they stack up both against those requirements and maybe against other facets that we haven’t yet discussed?

We looked at a company called Pear Suite, which is in the health coaching world and has a platform that’s purpose-built for coaches and coach workflows, but we felt they lacked the scale that we needed. We briefly looked at Welkin, but we’ve had experience in the past with Welkin and didn’t move forward with them based on that experience. Then we looked at tools like Retool – low-code platforms that would allow us to build pretty quickly. Those were enticing because it was going to be easy for us to build a V1 of the platform, but they lacked some of the more sophisticated pieces around security and integrations with external vendors.

So across the board, there were maybe a few different factors that we were looking at. First was the scale of the organization and the amount of funding – will they be around in a few years? Second was the amount of integration and sophistication with vendors. If certain functionality didn’t exist in the platform, would we be able to bring it in externally? Third was pricing, which was a bit tricky because I think Salesforce was probably the most expensive option to go with. Fourth was control: being able to decide what we were able to change while tweaking the platform. Retool scored very high on that access. Other platforms scored a lot lower because either we couldn’t actually go in and change anything or we would need to drive through an implementation to make the change. And then fifth was probably scalability: what are their security standards? Are they defensible? If we’re subjected to a security assessment, can we defend that we’re using this platform and demonstrate that we’ve locked things out accordingly? Those were a few of the facets we looked at.

And basically across each of those facets, you found – perhaps price aside – that Salesforce Health Cloud would be the right option for you?

Pricing was hard for us to work through because we projected it out and it looked like Salesforce was going to be pretty expensive. Salesforce uses a per seat/per license model. So there are a few questions here, one of which is what types of licenses we would need. There’s a Sales Cloud license, a Health Cloud license, and—in the event that we want to build a provider portal— there are external app licenses as well. So across each of the three different license types, there are slightly different pricing structures, and we needed to size up, across each of those, the size of the team that we would need.

We didn’t get far enough with Welkin or Pear Suite to see how their pricing structures differed.

I’m curious to get your perspective on the initial sale process through to the signature stage.

The sales process was fine; we had an existing relationship with a VP at Salesforce. In a traditional sales process, we may just have been working with a specific sales rep. In this case, we had more of a buffer because of this pre-existing relationship. Overall, we spent maybe two or three hours going deep with Salesforce on specific workflows that we wanted to see from the platform. We basically handed over the set of activities that we would want to see a health coach or a case manager do, and Salesforce built out a demo that lined up with what we had asked for.

We had two or three sessions with them where we went pretty deep. I think it was pretty good. During the negotiation process, we were just very upfront about what our needs were and they were very upfront about what they were doing. I think Salesforce should be a pro at the sales process, and it was pretty smooth for us.

I’m curious to dig into onboarding. This is an interesting product because the implementation timeline for Salesforce tends to be so much more substantial than a lot of products, so I’d love to dive into that aspect of the product as well.

I think the unusual bit about Salesforce is that Salesforce doesn’t configure your instances – once you’ve signed a contract with them, the contract just starts and then it’s up to you to figure out how to build what you need. We put out the feelers to people we knew, but we also got Salesforce to give us a few names of development partners that they would recommend who had experience in the healthcare space. We spent maybe two to three weeks going deep with those vendors or consulting groups, and then we did our due diligence with people who had worked with them in the past. Then it was just a matter of finding the right partner.

In terms of timelines, we executed our contract with Salesforce around May, and I think our development cycles with our development partner started in mid-June or early July. So it was around a six-week process for us to find the right partner and then for them to step up our project. From there on out it’s been just building, which I think is fine – it’s just a little bit more work for you to do.

The overall cost of implementing Salesforce may be a little bit higher than other platforms, but a lot of the vendors that we looked at were probably running at a spend rate of anywhere from $5,000 to $15,000 a week. So depending on the size of that team, over a 10-week span, you’re looking at basically $50,000 to $150,000 in overall implementation cost, and then there’s the maintenance cost that comes alongside that. So maybe the way to think about that is that it’s basically FTE if you were to build it in-house, and then you’d have to hire somebody or have a managed services agreement with a consulting group to maintain the platform and help you work through iterations as you learn more once it’s live.

In terms of the implementation, what is the work that needs to get done in order to make it usable?

Part of the challenge is that you scope out the work with your consulting group. You need to give them some details about what you need, and then the consulting group needs to tell you how long it’s going to take. For example, we’re setting up care plans, we’re setting up questionnaires, we’re setting up patients, and the development partner needs to assess how many questionnaires, how many care plans, and how you want to set up patients. So depending on what we’re working on, it could be a sprint of a week or longer where you’re giving context to your development partner, they’re framing it, translating it into work, and then coming back to you with what they’ve done. That’s how we structured it.

We spent a few weeks building out the Sales Cloud portion of our implementation, and then we moved forward to the Health Cloud part of our implementation. And as part of that implementation, there was a section of time devoted to the care plans and a section of time devoted to questionnaires. We would tell them what the questionnaires will look like and what the care plan will look like. They would stitch things together, tweak those objects, and then build out the right views inside of our instance. And then it’s a week by week iteration cycle.

They just make as much progress as they can, and then at the end of the sprint, where we’ve scoped for a specific thing, we determine what the follow-up needs to be and what we need to work on. We put that into a backlog and then there’s some time left at the end to clean everything up.

Are there any specific features or pieces of functionality that are worth calling out – any opinions you have on what’s working well and what’s not?

The perspective that’s been forming for me is that Salesforce is a really highly flexible system.

For context, Health Cloud is a product that I think has been around since 2017 or 2018. A lot of people don’t use it – a lot of organizations are on Salesforce with a healthcare use case but have built that use case around Service Cloud. So they’re not even using the Health Cloud pieces; they’ve just built this with whatever Salesforce provided. And the majority of those use cases are case management use cases. So it is just interesting to think about that for a second: think about how customizable a platform needs to be in order for you to have something that is basically built out for a care management use case. But then – and I can’t substantiate these numbers – I think probably more than 50% of organizations that have a healthcare use case and that are using Salesforce are actually not using Health Cloud.

So clearly Salesforce is a really customizable platform. And the piece of feedback that we kept getting from people who had been using Salesforce for many years was that we shouldn’t be customizing Salesforce. Anything that there is a standard Salesforce object for, we should just take that object and build on top of it, rather than creating a custom object or tweaking something or taking advantage of the flexibility of the platform.

So to answer your question about what features we use, we use the care plan and assessment features. There are some pieces that we’re building out around tasking and events management, and then there’s stuff that sits outside of Salesforce, for instance the pieces around telephony. Salesforce doesn’t really have an out-of-the-box telephony system. So we did a pretty broad assessment to figure out which telephony vendor we wanted to work with and how they integrate into Salesforce. For those types of things, we want to pick features that the platform is built out for. And then anything that the platform isn’t built out for, we want to just be very judicious about how we supplement it.

How would you characterize the platform’s stability, both in terms of uptime and bugs you might have encountered?

In terms of the platform’s reliability, we’ve encountered at least one instance where there’s some business-critical functionality that Salesforce should be supporting that we’re encountering a bug for. It’s not really clear how to work around this; we’re troubleshooting it as best we can, but it seems the issue stems from Salesforce, and so it’s not clear how we move forward on those things. Either you hire a developer who is much more technically savvy than an admin, and you have them see what they can do about it, or you try to work around it in Salesforce. But things like that are kind of scary to me, because if this were to happen in production, you’d be stuck. You wouldn’t be able to work around it because you don’t have the right talent in your team. But from an uptime perspective, Salesforce is very stable; we haven’t had any issues getting into the system at all. There’s no downtime – although we’re not live. But they adhere to a pretty good SLA.

How do you think about Salesforce Health Cloud’s relative strengths and weaknesses?

I think that its strength is that it’s a very flexible platform. The weakness is you have to be very careful about how you build it out. Many organizations have built themselves into a corner where they’ve used a lot of custom objects and then they run out of them, or they run out of space, or they hit up against API limits. And I think some of these are things that you can’t necessarily immediately anticipate if you haven’t had the experience of working with Salesforce before. So I think it’s certainly good to get started but then there’s a question mark around how it will scale with you once you hit a certain scale.

Maybe we can actually double down on that: Do you have tactical advice for organizations that might want to build on top of Health Cloud?

I’d say really dig into your networks and try to find other organizations that have built in Salesforce to get their read on everything. Get their read on developers they’ve worked with that they’ve liked or disliked, get their read on specific technical gotchas. If they could build a whole platform over again, what would they do differently? Learn about how they hire in their teams too – at what point did they hire an admin or a developer? What were the drivers to bring that in-house versus keeping it out of house? And then understand how Salesforce fits into the rest of their environment.

For us, Salesforce is the workflow application, but then underneath and around Salesforce, there’s a data layer that needs to tie into the workflow. So the question is how best to do that – how much of that do you outsource? Do you build your own, or do you have organizations that help you do this? What are the costs and benefits of working with each of those? There are plenty of people with experience with the platform, so try to use as much of other people’s scar tissue as you can to build out the platform, in the hope that you don’t run into so many of these issues yourself. That’s been our approach.

You’ve been building on top of the platform and integrating with APIs and the primitives that they offer, both API and non-API. How would you characterize the developer experience and the associated documentation?

So we plan to vend out a lot of the integration work – like the ETL stuff, and then the reverse ETL stuff where you’re pushing back into Salesforce. However, it looks like the Salesforce documentation is actually pretty good. Something that I would suggest that people be aware of is that when you’re looking at vendors that integrate with Salesforce, it’s possible that those vendors may not integrate with the most recent version of the Salesforce APIs. So that is something to look into: Health Cloud is being developed continuously. So if you have a vendor that is working off a version of the Salesforce APIs that is three releases old, or six releases old, you’re looking at a vendor that has an integration that’s at least a year or two old from where Health Cloud is today. So there may be specific things that you’re trying to get out of those APIs that you just can’t get. I think the easiest way to ask the question is to ask vendors which Salesforce API version they integrate with and then to go back and look at what version Salesforce is on. Look at the change logs to see what is available and what isn’t to make sure that what you need actually works.

Yeah, that’s pretty tactical. Did you integrate Health Cloud with some other products?

Yes; the biggest one is the telephony solution. There are a bunch of telephony solutions, like Talkdesk, Fastcall, and Five9. I think some of these integrate with Health Cloud or Salesforce natively, while others don’t. The integration process was fine overall. I think it’s up to these organizations how good they choose to make the integration experience for you. So if you can, set up a demo with them, or get them to show you how the integration would work. I think that, in the majority of cases, if you have a poor integration experience, it’s not because of Salesforce but because of the vendor. And Salesforce isn’t really even able to help with that – you have to go to the vendor that you’ve contracted with to help you help yourself.

I would characterize the marketplace or the list of integrations that Salesforce Health Cloud offers as pretty good – it’s pretty easy to find vendors. It’s hard to know which vendors are really good, though. There are tons of telephony vendors on Salesforce. The piece that maybe didn’t exist was clear insight into who was going to sign a BAA with us and what the pricing was going to be. So it’s easy to know what the universe looks like, but it’s hard to know who would actually be a good fit unless you talk to each vendor.

What is Health Cloud’s support and account management like?

Account management has been super responsive. Our account manager left while we were working with Salesforce, and that was fine – Salesforce was a pro at keeping the continuity. The support team has been pretty good. I think they’ve been pretty responsive.

There’s one issue that has come up a few times that we’re still trying to work through, but I think many questions that we’ve posed have been resolved. So I think support is okay. The only thing to add here is that we have support from Salesforce through our own accounts, but if your developmental partner has a good enough reputation with Salesforce, they may also have their own support resources. So that’s just something to think about.

Yeah, that’s a good flag. In closing, do you feel you made the correct decision with Health Cloud?

Yeah, I think so. I mean, these decisions are tricky, because you’ll know in 18 months what you missed now. I think there are actually two questions here. Is Health Cloud the right platform? And then did we select the right development partner? I think the answer to both of those questions is yes for us. But my advice for buyers selecting these types of products is, if you’re going to select Health Cloud, make sure you spend as much time thinking through who the consulting firm is that you’re going to work with and how you’ve stacked it as you spend thinking through the actual Health Cloud decision.

Do you recommend any areas of growth for Salesforce Health Cloud?

In terms of areas for growth, I’m not sure – it’s hard to say right now. We haven’t bumped up against the fringes of what the platform is capable of yet, so it’s hard to assess areas for growth. But we do feel good about our decision, and that’s the advice I have for buyers.