Mindbody is the largest booking and management software for studios and spas. As a result of its central role in the lives of tens of thousands of customers, it has attracted hundreds of technology partners.
Jaimie Fucillo is Mindbody's VP of Partnerships and she oversees platform strategy and runs their technology partnerships program. Jaimie shared why her team recently moved from reporting to sales to reporting to product, how their program evolved as it scaled from a dozen to hundreds of partners, and her advice on how to run a successful partner program.
For the past four years, we have reported into the go-to-market Sales organization. Just in the last few months, we began reporting to the Product organization. That is new for us, but it is very welcomed. Primarily because we have found over the evolution of the program, our success is 80 percent based on the ability to craft and drive product strategy, and 20 percent on go-to-market tactics.
We have hit a scale in the number of partnerships where the days of sending out an email to our tens of thousands of customers about each partner are in the past. With over 200 commercial integrated partners, we’ve had to modify how we market them to our customer base - this resulted in what we call the Mindbody Partner Store.
There are three main reasons.
The first is the breadth and depth of our API. When we were in Sales, there wasn’t a natural advocate who was thinking about the API across all of our segments - fitness, integrative health, salon, spa, and our consumer marketplace.
We attract partners based on the APIs we put into the world. So we need the APIs in our partner portfolio to be diverse, so that there are innovative solutions available for our customers across all verticals.
Second is ensuring the developer journey is seamless.
In some ways, we are very fortunate, as we have the largest install base in fitness and wellness, and the salon and spa industry. That is very attractive to other companies.
That said, the key goal of our program is to make the program easy for developers. This requires developer resources on our side to make that experience seamless.
The third part is what goes into scaling our go-to-market strategy.
We have put our energy behind scaling our Partner Store, and we now need to scale the platform that powers it. We are working towards commerce capabilities - meaning the ability to try, buy and cancel an integrated solution directly from the Partner Store.
One of the biggest factors is how many partners you have in your ecosystem. We found we hit a natural breakpoint at about 30 partners - more than 30 and your sales and customer services teams can no longer know everyone, and can no longer adequately recommend a partner to a customer coming in the door.
We did well with personal recommendations for 12 primary partners, but after we passed 30, it became unwieldy. By establishing an App Store or Marketplace, what we call our Partner Store, our customers and customer-facing teams can discover partners directly, and we can scale our growing partner base.
The second factor is understanding what partners want from us.The majority want us to sell their solution on their behalf. They join to get in front of our audience, and are looking for Mindbody to act as the sales engine.
Manual revenue share reporting is labor-intensive and increases the risk of errors. When we realized we couldn’t scale the manual revenue share model, we moved more toward paying for API usage. But what partners really want is for us to sell their product and embed the economics in that process. That’s an automated revenue share system. And we plan to implement it for the partners that qualify for this type of model. That said, it’s unlikely we will ever get away entirely from charging for API usage. Customers, for example, build their own integrations that leverage the APIs.
The primary metric that we track and continue to track is their ability to drive revenue. Our partner ecosystem is monetized so that has served us well.
We are still trying to grow and innovate. However we are not starting from scratch. Our partner ecosystem has been monetized for at least 5 years. And there is no un-monetizing. But we do think about how we change pricing and packaging to lower the barriers to entry.
We also look at the partner attach rate compared to the full customer base. Fifty percent of our customers are using at least one integration. We look at churn for those using an integration versus those who are not, and, generally, it has been at least three-to-five times increased retention for customers using an integration.
We currently only have an external app store. Someday we would like to have an in-app store, but it’s currently like the Salesforce AppExchange.
Essentially, it is a listing property that allows customers to discover, browse, and contact the partner for a demo. Customers are generally introduced to the Partner Store as part of the initial sales conversation. We encourage our sales teams to talk about the Partner Store as a differentiator.
Customers onboard with our software first, and it takes time to get up and running, and they are generally re-introduced to our Partner Store after 90 days of being a customer, whether that is through a webinar, a newsletter, their onboarding specialist, or through customer service.
We have really invested in making the Partner Store tailored to users. So they can find apps by category, location, and need. Once they find one they want, they interface with our partners to get an account. Our customers enter a code or link to connect the integration, and that gives permission for the partners’ solution to access their Mindbody data.
Our integrations are almost all partner built. Very early on, we had built some, but we generally did not maintain the integrations over time. This is a common story when interfacing with partner prospects that have also invested in a platform approach. Our philosophy has been to provide an exceptional product, support and developer experience that enables partners to build quickly and to scale. We’re fortunate, in part due to our large, loyal customer base, we have been able to utilize our partner ecosystem to build to our platform.
We have an open API platform, it is open to essentially anyone except direct competitors. It is open to products that compete with some of the features we have, around marketing, waivers and forms, for example. So far that openness has served both us, our partners, and our customers well.
Anyone can sign up for a free Sandbox account. To request live access, they need to go through a simple approval process. If you’ve built an integration for one or a few customers, then all that is required is that those customers give their permission to connect their Mindbody account to the partner app. There is no limit to how long a developer can operate without broader visibility.
To get into the Partner Store, we have an integration review. We ask business, tech, security, and workflow questions. And you must have at least twelve Mindbody customers already using your integration to qualify.
Once the solution is in the store, partners must stay in good standing. If we get a lot of complaints, we reserve the right to take a solution down or to suspend an integration. We also have an overages model where we monitor if integrations are running well or off the rails.
Something that is new is a beta app program. We have new partners who might not have twelve or more customers. They have a bit of a lighter review process to be featured, but they have to show they are committed to growing their business with Mindbody. We identify them as a beta app. It is a way to give them a stepping stone. For some, twelve customers seems huge, for others it is not. We are piloting this concept because a lot of people are really trying to help our customers right now given the uncertainty and challenges brought on by the pandemic.
We have a system that monitors the traffic and tells us how the integrations are performing. Fortunately, it is very rare that we get customer complaints. We also have customer ratings and reviews on the Partner Store that help us to qualitatively keep a finger on the pulse of our partnerships.
The partners who are in our industry are very committed, and provide a high level of service. There are a lot of vertical offerings for certain types of wellness and fitness. Those solutions have done remarkably well because they have focused on these verticals, and they are very connected to a tight knit community.
Creating one cohesive experience for all of our developers is a high priority on our roadmap. We want third party developers to be able to access all APIs in one place, with a process that is clear and easy to understand, from getting an account, to building, to billing.
A good developer journey is incredibly powerful for us to have. I describe it as the importance of a whole product - meaning all of the elements that come together to create an exceptional product experience.
I regularly use the analogy of Legos when describing the developer journey. When my son receives a new box of Legos, the entire product experience is exceptional. Of course, it includes the building blocks and characters. But it also includes a visionary box, to get you excited about what you can build. Plus it has detailed instructions with no words - literacy is not required. There are extra pieces included, just in case you need them. And despite the unbelievable complexity, each kit demonstrates reliability-- every piece is always there. It’s also a whole product for me as a parent, as my son can entertain himself without my help, and lastly, they extend the experience by enticing him to access additional resources online.
This analogy is perfectly aligned to our developer experience, just with a few adjustments. The APIs are the basic building blocks. To reach a whole product, we must also deliver a full suite of resources we bucket into three categories: the business opportunity, the technical opportunity, and the ecosystem experience.
The business opportunity consists of a highly trafficked Partner Store, as well as robust sales programs, reference stories, and compelling events with customers and customer-facing employees. The technical opportunity is not only the constant evolution of new, rich API endpoints, but also predictable economics and the uptime of the API platform. Lastly, the ecosystem experience begins with an intuitive developer portal, strong documentation, SDKs, and analytics. It also includes reliable communications that are both pushed and self-service. Partner management, developer support, and a developer community round out the full experience.
While we have pieces of the whole product experience, we’re constantly investing to make it better. With limited resources, I recommend investing in automated developer onboarding, great documentation, and a steady drumbeat of new or updated API functionality. Bringing it back to the Lego analogy - it’s basically the building blocks and the crystal clear instructions that allow developers to onboard and start building toward that visionary end result.
Our program is built around a map - a hiking trail map. San Luis Obispo is surrounded by beautiful mountains and has a string of peaks called the Seven Sisters. Because hiking is so popular here, we use the trails analogy for our program.
It started with the problem that every partner was essentially weed-whacking their own trail to the top of the mountain. There were no defined trails or clear milestone markers. To solve this problem, we created our partner trails to unify both the channel partner program and the integrated technology partner program.
The bottom of the mountain, or the trailhead, starts with channel. Meaning if you want to ascend in the Mindbody partner program, the first step is to begin by driving leads to our sales teams. Our most successful partnerships are built on the principle of reciprocity - the partner refers prospective customers to Mindbody and in turn, we refer their innovative, integrated solution to our customers.
The partner paths then get a bit steeper over time, providing more resources, opportunities, and support the higher up the mountain the trail takes them. We’ve learned that helicoptering a partner to the summit, skipping the trails and training required to get to the top, undoubtedly leads to failure. Physical fitness and partnerships have a lot in common - it’s the daily training and the journey that result in the best long-term outcomes.
We have also found that having our partner program centralized is really important. In the past, we had two to three different partner management teams. This fragmentation created incentives for partners to approach different teams to achieve their goals. It was the old “Mom said no so go ask Dad” phenomenon. To provide a singular cohesive partner experience, we’ve found there are many benefits to a centralized partnerships team.
I would say you have to constantly be flexible and adapt your model over the evolution of your program. What works well in the early days, you will likely outgrow. It is a constant outgrowing of a model, and you need to change it. Flexibility is key.
Being able to onboard partners easily is a critical investment that pays back - I can't even tell you how much it has paid back in terms of organic growth and revenue.
If you can focus on being the platform, and you can get partners to build the integrations to you, that is a strong competitive advantage.
From our experience, focus on delivering a whole product to your partner ecosystem. A successful ecosystem delivers a better experience for your customers and enables them to better accomplish their business goals. In our case, a thriving ecosystem of integrated products enables our wellness customers to sell more and to sell better, providing a better experience for consumers.
A successful ecosystem also drives significant revenue for you and your partners. Building an ecosystem around your product platform is a winning strategy across the board, as it benefits you, your partners, your customers, and your customers’ customers.