Ribbon

So today we’re chatting about Ribbon and how it was used at your prior company. Before we jump into that, could you give a brief overview of that company and your role there?

Our organization was a data-driven behavior change company. Essentially, we had a technology platform that we sold to large self-insured employers to help them manage their employees’ health. We would gather data from different sources, mainly claims from these employers, and integrate them into our system. This allowed us to better understand the members on the platform and identify areas where they could improve their health. We could then intervene and incentivize them to make healthier choices. The technology platform was focused on mobile usage, with an app available on both Android and Apple devices. The app used an incentive system and had a lot of data behind the scenes to customize the user experience based on their health history and diagnosis. Additionally, we offered services through a team of trained individuals who would chat with our members through the mobile app. They had various tools to help our members, including Ribbon Health, which powered provider search and provided information based on their health plan and location. That’s how we incorporated Ribbon into our overall experience.

How long have you been using Ribbon?

We’ve been using Ribbon for about four years. I think we were one of their early customers, and, at this point, probably one of their most loyal as well.

What caused you to look into purchasing Ribbon?

So there was a problem we identified when we were working at a large national insurance company before joining our current company: the provider data was poor, inconsistent, and not up to date, which posed a lot of issues. We knew that one of the most important things we could provide our members with our technology solution was accurate information on provider types and the medical services they have access to. It wasn’t just about what services were covered by their plan, but also which providers could accommodate them, if they were available, and if they accepted new patients, and what cost the member might be responsible for.

Our primary goal was to improve provider search and provide accurate information to our members. We would give simple recommendations like get a flu shot or schedule an annual health maintenance exam. Many people don’t have primary care physicians, so it was important for us to find someone who could see them quickly and accept their insurance. Ribbon allowed us to provide real-time data and fill in the data gaps, which helped us shorten the window between encouraging someone to take action and them actually going to see a doctor, which was important in closing out the action that we wanted them to take.

What problems was it able to solve for you?

Like I mentioned, we needed to enable provider search and get accurate information to our members. We recognized that provider data was generally very poor, and datasets tend to be pretty stagnant. We had found Ribbon as someone who could help us solve those sets of problems. We knew that one of the most important things we could be providing to our members on our technology solution was helping them understand the provider types and medical services they had access to based on their plan. Further, can those providers actually accommodate you? Do they have the bandwidth, are they taking new patients? Does it fit within your health plan? We didn’t get into cost with Ribbon at the time, btu have been exploring that more recently. Our main use cases for Ribbon were really simple: if you need to get your flu shot or get an annual health maintenance exam and you don’t have a PCP, who can you see in a short period of time that will be covered by your health insurance? What Ribbon allowed us to do was sort of fill in those data gaps in real time, so that the window between intervening and incentivizing an individual to take an action shrank.

Given your tenure in using Ribbon, how did the product change over time?

The first big change was increased coverage. When we were both smaller, we focused on areas where we had membership and they had coverage. If there was a mismatch and they didn’t yet have coverage where we needed, they would direct their attention to that specific geography or health insurance company, so we could have more overlap in coverage between Ribbon and our system. As our client base grew, Ribbon was able to offer us more coverage, resulting in a mutually beneficial relationship. It then expanded to include additional offerings, such as more specialized data and more detailed geographic information for individuals. More recently, we started discussing the incorporation of pricing into provider search, availability, and quality. We want to develop a comprehensive solution where we can present this information to our members and ensure they receive the care they need from the right provider at an affordable price.

Did you have a set of requirements that you were looking for during your vendor search?

Yes, we did. Some of the main requirements we had were ease of implementation and the level of attention and service we would receive. Since we were a small company at the time, we wanted to ensure that any partnership we entered into would quickly generate results. Ribbon satisfied both of these requirements. They were efficient in implementing their service and were readily available for meetings and problem-solving during the early stages of our product. So those two things were great.

Another important requirement was coverage. We needed to know if Ribbon’s network and coverage could effectively service the members on our platform. This was the aspect that we deliberated on the most before making our purchase decision, because their network was still in its early stages. If we were to approach Ribbon today, ensuring coverage for our customers would be much easier. Despite the initial concerns about network coverage, we felt confident in our purchase decision because Ribbon compensated for it with their great customer service and attention to detail. That gave us the confidence that any gaps in coverage could be quickly addressed.

Price was another obvious requirement for us. As an early stage company, we had raised funds but were also conscious of being cost-effective. Ribbon aligned perfectly with us in terms of pricing. So, overall, Ribbon checked a lot of the boxes we required.

Were there other vendors that you did evaluate, and how did they stack up against Ribbon?

We looked at LexisNexis, which was one of the bigger players in the industry. They had been around for a while, and in terms of coverage, LexisNexis would have been on the opposite side of the spectrum to Ribbon. However, we had some concerns about the accuracy of their data and how often it was refreshed. We were familiar with the problem at the large national insurer we were coming from, and we confirmed this through our own testing. At the time we were making a decision, the LexisNexis technology didn’t allow for frequent refreshes, so we were unsure if the information would be up to date. While LexisNexis had better coverage than Ribbon, there were question marks around data accuracy.

I also want to mention that, as a consumer-facing tool, we placed a lot of importance on each interaction we had with our customers. We were very mindful of the fact that we had to stand out from the noise to get their attention. If any touchpoint we had with our customers didn’t meet their expectations, we could lose them forever. We didn’t have many chances to win them back, so we focused heavily on ensuring the accuracy of the data we pulled into our system and presented to our customers.

How did pricing models compare?

During our previous conversations and negotiations with Ribbon, when they were relatively new, we were able to benefit from their flexibility, which ultimately helped us in making our decision. I believe that they now have a more standardized pricing model in place. The contract we currently have with them is most likely aligned with the contracts of their other customers. It has become much more structured. It’s interesting to note that our two companies have grown and evolved together to some extent. However, their current pricing model is generally more friendly toward founders and companies in their early stages than what might be offered by incumbent vendors.

How was the sales process?

Honestly, it was very collaborative. Ribbon came to us with a solution that we needed to improve our product and enhance the experience for our members. We worked closely together to figure out how we could solve problems as a team. I’ve worked with a few vendors before who had a similar mentality in the sales process, where it felt like we were working together instead of just being sold something, and that’s exactly the experience we had with Ribbon.

What was the onboarding and setup process like?

Yeah, it was also a collaborative process. Their API documentation is good, and I actually looked at it again yesterday. It’s simple yet effective, which is great from a product and engineering standpoint. However, being early in our relationship meant we had to be much more collaborative. We had some specific things we wanted to see in the product, and they were quick to align with us, as long as it made sense for them. Of course, as an early stage company, they didn’t want to create a customized product for just one customer, which we understood. But being collaborative also meant that we had to be patient to ensure the product reached a level of quality that worked for us.

When it came to onboarding and setup, we started with a pilot phase involving some of our smaller customers. This allowed us to test if the coverage and data accuracy met our needs and if we felt comfortable presenting this information to our members on a daily basis. It made a lot of sense for us to start at this pilot level to ensure everything was in order. Once we became more confident in the solution, we rolled it out to the rest of our customer base.

What features of Ribbon do you use?

We use the filtering feature and functionality. The goal was to filter the right provider set based on the member’s location, health plan, and availability. Over time, we expanded the filtering capabilities to include other factors. And this was an internal tool for us. Our internal team would use the tool and share the results with the member. It wasn’t a self-service tool for the member, but rather a service tool for us.

Performance and speed were also key. Initially it was a bit challenging, but it improved over time. When we were talking to a member, we didn’t have to fill empty conversational space with the member while waiting for the results.

One ongoing challenge is that, as Ribbon grows its network, accommodating large customers with employees across the country and on multiple health plans becomes challenging. Regional plans and even plans from big national insurers like United, Cigna, and Aetna have nuances that we have to address. Not all plans from these insurers are the same. It can take time to load new coverage into our system when we discover gaps in our service for a new customer.

With time, as Ribbon’s coverage continues to expand, I believe these challenges will be resolved.

How would you get confidence in Ribbon’s data?

One of the biggest things was that when they were setting up new geographies or health plans they would often share sample data. This allowed us to work with it in a sandbox and see how well it worked, how accurate it was, and how well it met our needs. This early access to the data was really helpful.

We did receive metadata on the general source of the data, but not the exact source data. This was fine with us because we understood the way their algorithms work is proprietary, allowing them to scrape and pull data from various sources such as claims, clinical data, and billing systems. They could determine if a provider was part of a private practice or also performed procedures at a larger health system and uncover accurate contact information. Ribbon had ways to deduce or find the actual source of truth. However, they did provide us metadata on the geography, health plan, and the last time the data was updated.

How would you characterize Ribbon’s overall strengths and weaknesses?

From my perspective, the team is the company’s biggest strength. Our experience with them, both during and after making the purchase decision, was excellent. We had very productive conversations with people at all levels of the company. Personally, I had good conversations with the CEO. He’s one of those CEOs who is more hands-on and product-oriented. He can handle both sales and product, which I think is effective. This collaborative and relationship-driven approach sets them apart from other companies we’ve spoken with, both within and outside of Ribbon’s realm.

As far as weaknesses, as the company has grown and continues to grow, we don’t receive as much attention as we did in the early days. This means that turnaround times for addressing our concerns have become slower. These growing pains are common for most companies, but I would say that’s probably the biggest weakness. As they scale, can they remain true to the things that initially attracted customers like us? Can they maintain the qualities that make them stand out from their competitors? It’s a hard balance to find. It has become more difficult to have the same level of collaboration and fast response that we were used to.

How was the product stability?

They were pretty solid. I would say that their more mature products were solid. We rarely experienced any major outages that affected our members. I can count on one hand the number of times we had issues like that over the course of four years, and they were quick to resolve them. That’s a pretty good track record. One thing that contributed to this is that they set expectations. If they were introducing a new release or feature that wasn’t fully developed yet, they would let us know in advance. This allowed us to adjust our usage of the tool until it was stable. So even when there were instances of lower stability and performance, the expectation-setting helped us plan a workaround in case any issues arose on our end.

Did your team build using Ribbon’s API?

We were using their APIs. Basically, whatever data they had would feed directly into our system, and then it would be displayed in our internal tools and the user interface that we had developed.

How was the developer experience and documentation?

Overall, I think it was generally positive. However, I did notice that in the early days their documentation was weak. This meant that Ribbon had to be more hands-on and collaborative in working with early vendors like us. However, over time, their documentation has improved significantly, and they have become better at identifying and addressing any issues that arise during implementation. It’s worth noting that, as Ribbon expanded their solution base, the rollouts and implementations progressively got better. When we first integrated their tool set into our product, the documentation was weak, and there were definitely bugs. However, a lot of these issues have been resolved over the past couple of years.

In terms of developer experience, as well as our experience as a vendor, the implementation and setup process with Ribbon was relatively seamless and quick compared to other vendors we have worked with.

Do you have any tactical advice for other folks who might want to build on Ribbon?

One of the nice things about Ribbon is that their solution is highly modular. If you have a clear understanding of what you want and need, they can provide it to you without the need for building a new product. They have designed their product in such a way that it can meet your specific needs. So, from a practical standpoint, if you are evaluating Ribbon or any other provider search/provider data company, it’s important to narrow down exactly what data and use cases you’re aiming to fulfill.

While I think Ribbon does a great job, there may be other use cases, especially in specialized domains, where they have recently improved or where other solutions may offer better coverage. I’m sure Ribbon is working on further enhancing their offerings, you’ll want to make sure you consider your specific product’s requirements to find the right vendor. It’s important to avoid selecting a broad and shallow solution when what you require is a narrow and deep one.

Looking back, do you think that you made the correct choice in going with Ribbon?

I would say yes. It wasn’t perfect, but it met our needs. We were able to provide our members with reliable and up-to-date data in a timely manner. We tried to keep our requirements straightforward, and Ribbon was able to meet all of them. If there were any areas where they fell short, they were responsive and quick to address them. Even if they couldn’t implement changes immediately, they assured us that those changes were part of their plans and kept us informed about when they would be available in the production environment.

Can you think of any areas of growth that you would want to see Ribbon invest in?

Yeah. Our initial relationship had such a great collaborative feel. We felt like we had a partner and not just someone selling something to us. That makes for an effective and productive relationship. As they start to grow and scale, I hope they do their best to preserve that mentality. Obviously, they want to produce a great product, but the dynamic combo is backing that up with great service and great relationship building and maintenance. I wouldn’t say they’ve lost that feeling as they’ve grown, but there are little chinks in the armor.