Details
About the Reviewer
Reviewer Organization
Reviewer Tech Stack
Other Products Considered
Summary
Product Usage: Zendesk was used to centralize operations, handle member services and create effective workflows for incoming calls across a healthcare company servicing a Medicaid population.
Strengths: Zendesk is easy to implement, offers a low lift for internal IT and engineering teams, provides robust out-of-the-box reporting, and integrates well with other services like Talkdesk.
Weaknesses: The standalone telephony feature of Zendesk was lacking without integration with Talkdesk, and the text functionality was limited, more suited to respond to inbound text rather than initiate outbound messages.
Overall Judgment: Zendesk is a useful and cost-effective tool for streamlining operations and increasing efficiency in handling customer/member services, although there is room for improvement in its standalone features.
Review
Today we’re talking about Zendesk and how it is being used at your former company. Before we jump into that, could you give a brief overview of the company and what your role was there?
I first started using Zendesk in a production environment at a value-based care company working with a Medicaid population in 2019. At previous high-growth healthcare companies, we had done serious investigation and one of those times, we didn’t select it because at the time Zendesk didn’t have their HIPAA compliance in place, but that has been in place now for many years. I’ll primarily be referencing the period between 2019 and 2021 at the company I just mentioned.
What was your role at the company at the time? How did you interact with Zendesk and the other products mentioned?
I was head of national member services. Up until that point, the company had a state-by-state market model where they had traditional healthcare clinics for Medicaid members in urban areas that were being marginalized by the current clinical healthcare offerings. So, we were rolling out a holistic product and they realized that many companies had tried community-based holistic health care, but for it to scale with a high-quality health outcome, they were going to need to centralize certain aspects of operations. So, we wanted to create a national centralized member service center and move all of the initial interactions to that central member service center and create workflows for each state that were appropriate for their models.
That makes sense. When did you purchase Zendesk, and for how long had you used it by the time you left?
I was brought in by the Head of Product. They had already done pretty intensive due diligence, and we were ready to implement and launch Zendesk. So some of the other work I had done at previous companies, I got to skip ahead with this, but I was able to give them additional validation points. Another very high-growth startup had just moved several hundred agents to Zendesk after testing other CRM solutions for over two years. And I think that’s a huge proof point. They already knew from their alumni there that Oscar Health had also done a similar pivot to Zendesk.
So we were moving really quickly to get our teams up and running on Zendesk. We were still asking that classic question, ‘Do we still want to quickly build our own product or do we want to go with Zendesk?’ and I really lobbied (and I was fortunate that corporate leadership agreed) that we need to focus on our core business and not try to build a CRM. So that’s the direction we went in. As to the question, I was there using Zendesk for a little over a year and a half, and we went from zero to probably 150 licenses when I left. We started with support being on Zendesk. We quickly rolled that out to clinical teams in the state markets because we wanted a unified view of each point. That allowed us to actually do virtual triage at the central center, either resolving clinical issues and documenting in Zendesk for assigned market queue review, or escalating real-time from our virtual RNs to state clinicians. They actually had a better view of patient status than ever before because of the way we coordinated Zendesk with our proprietary product, which didn’t have the task management that Zendesk afforded us, plus we had the robust routing enabled by Talkdesk.
Which types of users interacted with this product, and what were their workflows?
So the initial launch was very, sort of standard, member service advocates that would help our members navigate to get to their holistic healthcare team. So really, we started out as air traffic control - very one dimensional. We were going to get a very large raft of new lower-acuity members from one of our health plans, so we needed a pure app-based tool and we needed the CRM to complement it. We also were about to launch services in a new state with the largest one-time attribution of patients to our services. Both of these lines of businesses were delayed, but we were already ramping up support and clinical staff. So, I basically put on my sales hat and went to the New York market, and got product and data analysis teams to run some studies of what we all suspected. We found a disconnect rate on the communication side of things and a real lack of ticket and loop closure outside of the EMR. So, we launched Zendesk and Talkdesk in concert, because we found that around 30% of our members weren’t getting to the right person at the right time. Member inquiries were going to clinic voicemail, work mobile voicemail, disconnected lines. Our early state telephony systems were not unified, and there was no CRM. We wanted a unified computer telephony integration where we would get a screen pop of who was calling and a Zendesk ticket created so our advocates could listen to the member. We wanted to measure the basics for phone service levels like wait times, call durations, and ticket touchpoints - effort and time to resolution in order to manage each team and provide reporting to leadership that would drive staffing decisions.
That makes sense. Could you clarify the relationship between Talkdesk and Zendesk?
I took sort of a jump there. So with Zendesk, you get their basic telephony and text products that are part of the Zendesk suite, but at a certain stage, you want to move to one of those partner products. For us and those workflows I just described, the Talkdesk telephony product - it’s omni-channel, but we’ll speak specifically now about their telephony because that was important for our clinical business. It had the ability, with the Talkdesk studio, for a business owner like me or one of my managers to actually get into the studio and write very complex IVR workflows. It used to take a telecom engineer to design this and now it is such a user-friendly interface that Ops managers handle it. So that’s why I was mentioning Talkdesk. If it’s a basic inbound use case scenario, then you can actually build the flow with a very cost effective part of the Zendesk product, but we decided to quickly integrate with Talkdesk. I think I’ve done that same integration at three companies, and just find it to be very nimble.
You built a variety of workflows out. It sounds like the studio was your primary workspace for creating those workflows, at least from the product perspective. What were some of the primitives that you were able to work with? So, more advanced IVR and call routing, some of perhaps the more AI-forward features. What were the composable set of building blocks that you had to work with?
From my business owner’s view, three times now, we’ve used that Zendesk-Talkdesk combo. And, again, I think one of the strengths I haven’t spoken about in detail is that the out-of-the-box reporting is just tremendous. This is for Zendesk and Talkdesk, and their combination of reports and standard call center metrics (which again, had been fragmented before when they were using some other vendors in the initial days where it was just clinics). The GMs for New York, Massachusetts, and Connecticut, before I left the company, said that one of their favorite reports was an end-of-day report we did. It was primarily driven out of Talkdesk reporting, where we were basically just doing a five-week rolling but week-over-week for each of the state markets - what their call volume was, what their average service level was, etc. This is very much blocking-and-tackling, but a lot of business owners in other departments, in other industries, weren’t exposed to that and they loved the ability to manage it. Someone at a state GM level could quickly say: we seem to be slipping with our staffing. Some of their HR managers might have been trying to make that argument, and now, in one end-of-day report, they could see that compared to New York, Connecticut might need to hire 10 more full-time employees to fix something - for the initial first impression, the user experience and everything downstream to be improved.
I don’t think I’ve fully answered your question yet, but Zendesk for ticketing, and for the automation and triggers of certain tickets to go to the right category or subcategory of viewer to take action on, and to be able to report out on that, was in Zendesk. And then, Talkdesk, especially with their studio, had much more robust routing power. One of our big discoveries was that clinicians and social workers were calling in to the 800 number to get help from our team. And there was actually initial confusion between them and the advocates, who weren’t sure if they were a member or an employee, if they were clinical or social or behavioral, etc. We deliberately did not build an IVR for the first year until we learned - we just wanted raw data, human-to-human. It was very expensive at first, but we wanted to learn as much as we could. And then we’d use the product and technology to create the sort of healthy deflections (because I don’t even like the word deflection - the more accurate word would be just the appropriate routing) that the end user would prefer to a human being once you learn enough.
So, for instance, that RN who is in her car, trying to call and get to a nurse practitioner to sign off on something - they have five minutes of confusion about who they are and where they’re trying to get to. So we learned to build an IVR where they could pick a branch, and then they could drill down and get exactly to where it would either create a ticket to where they didn’t need to talk to someone, or it would get them live, based on the priority, to a primary care physician. We had calls route so the system would look for those that were online in one market, then it would expand out to the other market, even though the member wasn’t attributed to them, just to get to a clinician licensed in both states. The last step, if we really needed to, was to barge into a current clinician’s call to see if they needed to take it instead.
This is another example. The clinical pods had a certain panel size, and managers were asking clinicians and social workers to increase panel size without a drop in health quality outcomes, just to make the financial model work, to increase their panel size from say 50, to 90. And some were saying there’s no way we can even attempt that stretch. With the combination of Talkdesk reporting and Zendesk reporting, we found certain pods that were already achieving the stretch targets. And there were little counterintuitive things that we found. For instance, pod two might be getting pats on the back every week for hitting their call attempts to their members. But then when we exposed to their managers that their actual average call duration was less than five minutes, we realized that material quality conversation interaction was not taking place. The other pod was both hitting its attempt numbers and with an average talk duration in the 15-20 minute mark. We knew that was how you could cover the consents that were needed, the assessments that needed to be completed and the scheduling of appointments. This could not be achieved if the call were 2-3 minutes long. On the opposite end of that, others were claiming it was going to take 40 minutes for the acuity of our members, and we found out through the reporting that we could go and listen to those calls, and correlate with the Zendesk notes. We could see that with social management, just by saying ‘Hi Mr Smith, I’ve really been looking forward to our weekly call. As you know, we serve a lot of members like you and we’ve got 20 minutes scheduled to get your weight, your blood pressure, and to schedule your appointment at your primary clinic, and then I need to help some of our other members that need this just like you do.’ They were done in 20 minutes instead of letting that person extend it in ways that weren’t really beneficial for either side. So we were actually able to expand, with an increase in health outcomes, the panel size, which again was one of the existential problems we were facing with the model.
That’s incredible. How do you see AI working to help scale that sort of effort?
I had approval for implementing AI - we were going to use Gong.io for both our member service and our outreach teams that we had (probably over 100 for all the markets). Members attributed to us are not considered really active and engaged until we’ve gotten their consents in place and we’ve assigned them to a primary care team. We were going to use Gong.io to try to get lockstep on who was doing the right delivery, outreach, and then same for member service quality - the first pass - for member service. We had to delay that because, at the time, Gong.io couldn’t work with the metadata at Zendesk. I think they may have since evolved to be able to do that and I know now I’m very, very keen on Authenticx, which is really doing great AI work with a trend analysis specific to medical and health tech, and then of course, Observe AI for the QA and trend analysis.
On the clinical data front, you mentioned that the metadata was hard to integrate with. I’m curious to understand, from Zendesk’s perspective, what degree of clinical data were you able to store? How much of that patient metadata was there for context? Or were the providers or clinicians really looking at multiple screens? Do they have multiple applications open?
No. Let me stay with the Gong example. They weren’t integrated with the standard metadata - what you would think of the CRM standard use. The clinical data - we were pushing it one way into our proprietary software. Our clinicians were using our proprietary software. That was our 360-degree member mapped tool, basically our electronic health record for our use cases, that was being used. So they were using both and data was at the time only pushed in one direction. We were hoping it would be bidirectional, but we hadn’t gotten there yet. So when, for instance, a member called in or there was a phone call with a member, the clinician had to look up that patient quickly in our unique software, in order to have all the context.
Moving in a little bit of a different direction, were there other integrations that you added? Did you supplement the product with any additional product functionality or integrate it with other parts of your stack?
There was an incredible founder who had a product called Karuna for the Massachusetts state market (they were later acquired by someone else). They wanted a little bit of a twist on how interactions were routed, and we had some very exciting preliminary results in Karuna. You had to have your separate telephony tool - Talkdesk or whatever else you chose. And you needed your CRM - in our case, Zendesk, but what Karuna did, once it was integrated, was that it would look for the member’s assigned Community Health Partner, which is sort of the quarterback for the whole health team, and try to get that interaction to that person if they were logged in and available first, and then you could have secondary and tertiary routing to other people in that virtual pod after that. It was a pretty cool experiment. I think that they ended up not going forward but they used it for about a year. And I do know Karuna was acquired, but it had some great potential I think.
Then, of course, there were Business Intelligence products like Looker or Tableau. We were pushing our data with all the other data into that tool. So that was helping across departments. Of course, Slack was a huge part of the Zendesk workflow, even from an informal stage to formalized actual triggers. But a great thing that made it work across state markets: being able to get on Slack and say, here’s what’s happening, and asking, do you want me to transfer them to you or do you want to establish when you will call back? So, like most of the world, we were heavy Slack users with the products I’ve just mentioned.
Yeah, certainly, I think that you and everyone else, especially during COVID. On the sales and procurement process overall, I know that you came in a bit late-stage, once it had already been decided. I’m curious, do you recall if you looked at other products to try to fit the need?
Yes, they definitely looked at Salesforce Service Cloud. I think that it usually is the big contender. At a previous company, we actually were asked in 2014 when we had an empty room, would we, even though I was used to Salesforce because I’d used it before, be willing to go with SugarCRM because they could put it on our servers, and the engineers could control it better. And we said sure. But they went through a vetting process with a very brilliant team that I worked with that was kind of roaming around , looking at all aspects long-range.. We were looking at Zendesk and Salesforce Service Cloud. They ended up experimenting with Atlassian. At that stage, it was very nascent. It was a CRM product that was really being customized. But that company later moved their support team to Zendesk.
At two other startups, I did the Zendesk-Talkdesk vetting. If you’re a startup and you’re series A or B, you should always check to see if Zendesk has their startup program (if it still exists, and I think it does). That was for earlier stage startups. For the two I put on Zendesk, that was huge because we put our teams on that startup program and we had unlimited licensing, unlimited product, and unlimited Zendesk support for six months. And then you could decide, we’re going to walk away or we only need 25 seats, we’ve done all of our testing, and it’s just our service team that needs it. That can be just a deal-breaker as far as a startup at that stage, being able to say, okay, we’re not going to try to build it and we’re going to buy it. I’ve just had very good luck with that. And then again, once you get the proof points, very dynamic data-driven companies, like the ones we’ve talked about; when they have pulled the trigger on hundreds of licenses after years of due diligence and perhaps even actual years of other product usage, it’s pretty strong. A good proof point.
Absolutely. Are there other competitors in the market that you would consider or look at today for different sorts of use cases? I think you mentioned Salesforce Service Cloud, maybe at a higher scale. Are there other folks that you would consider or compare if you were to go through this again?
I participated in the Customer Service Lab in San Francisco before COVID, and that group brought people from all over the world. Zendesk and Salesforce were always there but there were other vendors that were there too. And you could see the really creative forces out there. I need to do my homework on some of the newer offerings.
Gotcha. And that just to clarify, the pricing model for Zendesk and a lot of these other offerings is, is per seat. Is that correct?
Yes.
And are there other pricing structure nuances that buyers should be aware of? When they’re looking at these types of CRMs?
To get a HIPAA-compliant level of product and support, that’s going to be a higher license cost. Regarding AI product add-ons, it’ll be interesting to see how they do those price models. Of course, the product integrations like Authenticx and Observe AI and Gong, those are, I think, going to become essential - our most immediate integrations from the start. And there’ll be processing costs per user or at usage tiers.
Got it. I think that makes a lot of sense. So, circling back to the top and concluding the discussion we’ve had so far, what aspect or aspects of Zendesk really make sense or what do you like the most about the product?
I’ll be honest, I think number one is to be able to go to engineering and say, we only need this minimal support from you to get this into production. Especially the smaller you are, that’s huge. Oftentimes, even when you’re large, there’s so much core product work going on that’s already committed to the roadmap. To be able to go to them with these proof points and say, we know the work required. I think that’s number one - that you make a convincing argument that this is a low lift for our internal IT and engineering teams and product teams.
Second, I think the Zendesk implementation is fast but thorough, and they have incredible support, both formal, and by other subject matter expert users in your industry. They are creating things that you can pull into your industry from other industries - just from the Zendesk Slack channel, for instance. So, I think that the kind of crowdsourcing of how to use Zendesk both formally and informally is really important. I think it is cost-effective both from the startup phase and even after you transition into licensing. It’s still not cheap, but it’s competitive. Again, the out-of-box reporting is very robust. And then the suite of integrated partners with very easy API setup is just amazing.
You’re a super fan, but is there anything that you dislike? Perhaps the thing that you most dislike about the product?
I missed having Talkdesk when we were just using the light telephony of Zendesk’s standalone talk product. I think the text aspect is limited as far as how you can do certain functionalities. There’s a hack, but Zendesk is really built for an inbound text situation where you’re responding, and not for the member or user in your team to be able to go and proactively do individual SMS out-of-the-box, so that was a problem in the past.
Is there any advice that you have for someone who is trying to solve call center issues or trying to better organize their operations, and they’re considering which pieces of software and how to implement, what workflows to undertake? Do you have any advice for those folks?
I think that, to reiterate, no matter how small the startup or company, if you can get a partner in product, and the two of you work with whatever resources you have, with the current data, to expose gaps and see what you’re not measuring that you absolutely should be analyzing. That would be number one. And then number two - once you have made the decision and you’ve integrated, don’t underestimate the business context of the combined Zendesk/Talkdesk reporting - senior leadership loves having the right dashboard view that’s very simple, but consistent, and vital for their strategic planning.