Get a free demo
Episode 28
Data for Subscriptions Podcast

How Algolia Manages Billable Usage

Guest

J. Stefan Crespo-Donaire & Michele Leo

J. Stefan Crespo-Donaire & Michele Leo
Algolia

Watch:

Episode description

How Algolia Manages Billable Usage

Catch on Algolia’s strategic approach and technical design for usage-based billing. This episode covers why they place an immense importance on usage-based billing, and how it influences their offerings. Gain insights on the utilization of usage data (internally and externally), monitoring and managing usage, and how they assess whether a usage metric is billable or not.

Highlights

Especially when it comes to sales-led pricing, the challenge is constant adaptations and changes. Is that a challenge that you guys have faced, still facing, and how are you tackling that?

Transparency, not only for the customer, but also internally in terms of communication. What plans are including what. At Algolia, we have what we call the Pricing OPS Council, where we constantly meet between the go-to-market teams, the internal product team, and myself included as part of the billing and usage team, to really understand where we’re trying to take the pricing in the coming year, coming months, as new products become available, and then how are they becoming available downstream to existing customers and then potentially being grouped in future plans. So I think it really is just a matter of making sure that the go-to-market teams are always set to speed with roadmap items. What are the things that we’re wanting to deliver and what’s the value to the customer? How they can then communicate that to the customers, and ultimately, also part of the billing system, is really being backward compatible, so as we’re deploying these new features to future or existing current plans, we’re trying to always see how this can become also available to existing customers on previous generation plans. We’re always trying to incentivize customers to upgrade, and that’s where we’ve done work with our growth team.

How do you use usage data internally?

We use usage metrics as the backbone for many critical services. For example, the billing system for us is the main internal customer. You can see the metrics as the raw values in our billing pricing equation calculations. We also use usage for product and feature adoption so teams can fine-tune for a specific product strategy. And then at a higher level, we also use usage metrics as business intelligence, data analysis, and many other things. That’s the internal part of it. But when it comes to our customers, usage metrics are the key in helping them understand the functionality of their app. It helps clarify why they’re getting billed a certain amount, so that helps a lot all the way through our fast and reliable public usage, API dashboard, and dashboard graphs, and ultimately ensuring we can provide them with top notch support whenever necessary as well.

Do you see situations where usage-based isn’t necessarily the right approach?

I think it comes down to strategy. So we have some new features that are instead of them being actual one-to-ones in terms of usage, like search request, for instance, the more you use it, the more you’ll generate, and there’s a fixed cost to the bundle, or kind of like usage that you’re burning through. There are other features that we have internally, like dynamic ranking, customizing and personalization. There’s some of those products that are more like bundled into the actual plan and those are then managed at the non-plan that you’re entering, whether it’s like the billed, the pay-as-you-go, or sales-led contracts, those costs are amortisized within the discussions that are being held within sales or at the bundle of the product. But realistically, yeah, we’ve identified that the search request records and then, for those who activated the recommend product generating the usage and measuring and billing on that is the most effective way for those products. I think it’s always going to be up to the pricing brainchild of hey, do we make this available metric? And of course, there’s a hypothesis phase. When we’re creating the new billable metrics, we do kind of pressure test it. We do the analysis of hey, do we want to make this a billable metric? Does it make sense? How can we validate that? When we’re in the pilot phase, do we pressure test this as well with the customers? Do we see what the engagement is in terms of should this be billable, and then the decisions are made from there between the product or feature team, and the pricing. From the billing and usage side, we’re more of the executioners or the enablers. They tell us, hey, make this a billable metric. Then we go from there.