Varun explains how managed marketplaces set prices using cost-plus math to hit roughly 20% margin, then dynamically test and adjust hourly across countries and devices to measure demand. The algorithm optimizes within a floor-and-ceiling band based on available supply, customer elasticity, and what competing suppliers charge.
Chapters
As a managed marketplace, kind of how do you set pricing and then also monetize? Yeah, so pricing is an interesting one because it's still not a solved problem statement, right? We essentially are deciding what the experience should look like, which includes deciding what it should have and what it shouldn't have, and then deciding what the appetite is there for user to pay and trying to sort of figure out the right, uh, you know, I would say optimum price point. Now the first thing that we realize is it's impossible to be able to figure out the right price point on day 1. And so we kind of go bottom up, we go with the number where we sort of figure out all our costs, both the supplier costs, our costs. We want to sort of ensure that we at least have 20% margin and as a marketplace to be able to sort of function and provide the kind of quality of service that we want to provide. And we do that bottom-up math and we go with a number, right? And then we do 2 things. One, we are testing the elasticity of demand against that number. So we keep changing the number on a dynamic basis literally every single hour, right? And we're checking the elasticity of demand not just against that number but also in terms of the cohort of that demand. So we're looking at, are people coming from these countries willing to pay this much amount for this experience? What languages do they speak? Which device are they on, right? Um, and because we are managed marketplace and because we have control of that end price point, uh, we now have invested enough time and money to be able to sort of build systems where this sort of iteration of price is automated and the system sort of does this, optimizes for what it finds to be the right price point and keeps changing it. This is also of course subject to supply, right, and there are 2 interesting things that happen on the supply side. First one is the amount of unused capacity that there is. If you have a tremendous— if we have a lot of capacity that is unused, then we of course sort of lower our price and then we keep increasing it as we get closer to the fill rate. What was also interesting that we figured out was that when we have multiple suppliers on the backend for the same SKU, right, because we're now sort of creating our own experience and standardizing it, we can have more than one provider for that exact same SKU or for that exact same experience. And there is now an inherent incentive. If there are, let's say, 5 providers for a single SKU, the provider that's giving us the highest take rate at the highest average rating, um, with, uh, the lowest price point is the provider that we would channel the booking to, right? And so there was this interesting play where our algo was optimizing price looking at customer elasticity Our algo was optimizing price based on availability, and then we had this whole supply-side equation where we had multiple suppliers and they were competing against each other by looking at what's the best thing that they can do to be able to get sales to themselves. And so it was this trifecta of availability, customer elasticity, and supply-side competition to be able to get to the right price point. We also sort of figured that We don't have a single price point for an experience, and so we kind of play in a band. We have a floor and a ceiling, and we just let the algo optimize between the— between that range depending on these 3 variables that we sort of keep optimizing for at all points in time.
