The Business of RaaS — Don’t Kid Yourself About (Acquisition) Cost
In RaaS Operations 101, I talked about the importance of understanding operations management in the context of a huge fleet of robots. I also teased the idea of a new metric that highlights something important about the RaaS model.
The two are connected. And that “something important” needs to be understood at every level and stage of a RaaS company — from mechanical engineering to customer success; from conception to launch to scaling.
For most new, low-cost robotics applications, the single biggest cost in acquiring the customer and generating revenue is the cost of the robot itself.
This may seem obvious as you sit here reading it. But I’m bringing it up and harping on it because this is fundamentally different from how SaaS operators have come to think about customer acquisition cost (CAC). In SaaS (and asset-light, software-driven marketplaces), CAC is primarily defined by sales and marketing spend (plus proper allocations of overhead and marketing tools and time adjustments based on your sales cycle). The cost to actually serve the customer is secondary.
To put a fine point on this, consider that it costs Zoom less than 20 cents per dollar of revenue to actually deliver their product to users and they spend twice as much on sales and marketing. Slack’s numbers are even more extreme. (And thanks to the major cloud infrastructure providers, the cost to deliver a finished product or service over the internet is mostly variable. You don’t need to pay a lump sum for your own infrastructure.)
A fleet of robots is different. You don’t just need to account for a lump sum for every new customer. You need to account for one for every single robot you deploy to do the customer’s job. In other words, you can’t turn on service or capture a revenue opportunity — you can’t truly acquire a paying customer — without accounting for the cost of inventory. From a financial perspective, RaaS looks more like an infrastructure provider and it requires cash flow upfront whether or not you account for it as CAC.
How can we drive this home and be more transparent about what it costs to acquire a customer? By thinking about our Deployment Acquisition Cost (DAC). This is a metric I’ve been experimenting with and I do not yet consider it a finished product. Having said that, it currently looks like this (in high-level, quasi-accounting speak):
$Expenses in Sales & Marketing + $Change in Total Inventory / Change in number of robots deployed (OR acres covered OR pickups OR…)
At its most basic level, DAC tells us how much it costs to create (via S&M in a given period) and capture (via inventory change during the delivery period) a revenue-generating opportunity. That number is then divided across the change in the metric or unit that represents your primary revenue driver.
(For the sake of simplicity, I’ll ignore the aforementioned cost allocations and time adjustments. There are also other costs associated with actually getting the robots to your customer and servicing them that will likely vary widely depending on the application and the size of a deployment. I’m also not certain how well this comports with recent accounting standards changes that converted operating leases to capital leases. And I’m going to punt on depreciation. So many caveats apply!)
How can we use this information? A simple example might help.
Let’s pretend you’ve developed a robot that costs $5,000 to build and ship and can patrol any shopping mall parking lot while working in pairs. Imagine it looks something like this. You spend $1M on S&M and you land several customers who between them represent 1,000 malls. They’re going to pay you $500/month for every mall parking lot you patrol.
$11M ($1M on S&M + $10M on inventory) / 1,000 malls = $11,000 DAC
If we were just thinking about S&M spend like a SaaS provider, you might say that your payback period is 2 months and call it a day. But your financials are not going to look like a software company. You need to treat this like a lower-margin business (even though recurring revenue and proper cohort analysis make this very attractive in the long-term) and make sure you always think about the cost of the robots, which adds 20 months to the payback period.
This may seem pretty obvious. But some interesting things start happening as a RaaS business grows.
Let’s step forward one year and assume you spent another $1M on marketing and landed 1,000 new mall deployments. Let’s also assume that half of your malls from the previous year churned and that you can perfectly redeploy those robots to new customers with minimal repair or refurbishment. What does DAC look like for this new cohort?
$6M ($1M on S&M + $5M on new inventory) / 1,000 malls = $6,000 DAC
Now we’re seeing something really interesting. Yes, the old cohort is going to take longer to reach profitability, but the payback period on this new cohort is only 12 months and it’s due entirely to the lower cost of inventory!
If you want to have a lot of fun, throw in one last thought experiment: What if you ship a software update that makes it viable for a single robot to patrol these same mall parking lots OR for the same two robots to patrol parking lots that are twice as large? What does that mean for your next cohort? What does that mean for the price you can conceivably charge?
When you think about RaaS this way, you realize how important the cost lever is in RaaS. Anything you can do to make your inventory more efficient is going to have an outsized impact on your business relative to modest changes in S&M. This is a balancing act between reducing all-in BOM cost, designing products that can easily and inexpensively be refurbished and redeployed, and improving the efficiency of these products and how much value they can capture.
(That last element offers fascinating pricing questions once you leave the world of temporal pricing and get into pricing by discrete action or continuous coverage areas. Minimums and maximums become very important. But that’s a post for another day.)
One thing that I haven’t addressed: DAC can make sense as long as your inventory is growing. But what if it’s shrinking (even if we’re adding depreciation back into the value of inventory)? What if, in some future state, you spent $1M in S&M, successfully acquired and began servicing another cohort of 1,000 customers, but the total value of your inventory fell by more than $1M? Is it still a useful metric?
At this point, I am speculating. I suspect negative DACs are not very useful for any kind of cross-cohort analysis. But they ARE binary indicators that reflect one of the following scenarios:
- Bad: Revenue is falling as previous cohorts churn out too fast and their robots are found to be EOL but with no economic reason to replace them with new inventory.
- Good: Revenue and profit are rising as robots at EOL in other cohorts are being written off and replaced by newer and cheaper models that can do the same work. (I wonder: What’s the best way to finance inventory if you’re on this trajectory?)
I’ve written a lot here about acquisition cost and not at all about its cousin: lifetime value. This last bullet implies the existence of two different versions: Customer Lifetime Value and Robot Lifetime Value.
Maybe that will be the subject of my next post. Until then, follow me on Twitter.
