RaaS Operations 101
Back in 2016, Manu Kumar wrote a post that touched briefly on everything that can go wrong with a hardware product and business plan. In short, it’s extremely expensive and literally everything can go wrong; anticipate the worst at every step. So why would a dispassionate, economically-minded investor risk investing in hardware? Because — as Manu noted a few months later — if the hardware is ultimately a delivery system for software or for a service, a new business model becomes very appealing.
(Manu wasn’t the first VC to start talking about hardware or robotics as a service. Rodrigo Martinez has been on this since at least 2015 and has written more about it since then.)
I’ve written about why this is appealing from the customer’s perspective. Let’s go deeper into what it takes to be the service provider. I’ve pulled some of the key points below from my work with Vivid Robotics and RosHub. Others are theoretical — it’s still the first inning for the RaaS model.
Lean into the positives
Let’s start with a couple of things that Manu touched on in his “Hardware-as-a-Service” post.
It’s relatively easy for a customer to try a RaaS offering because they don’t need to commit to significant capital expenditures. They treat the robots as an operating expense.
Implication: Minimize ramp-up time. This reduced friction to trial can significantly shorten a sales cycle. That’s a big win compared to the OEM model. One trade-off is vulnerability in the early deployment stage. So a good RaaS company needs to have an awesome customer experience out of the box. Productivity during a trial period is critical.
Customers are willing to pay more over time than you could have charged them up front because they are paying for the continuous delivery of value.
Implication: Customer success is a key function in a RaaS business. This increased revenue potential is driven by the tight alignment between the RaaS company’s incentives and the customer’s incentives. You have to design your culture and organization to protect that. You need to make it someone’s job to ensure that customers are getting their money’s worth. Switching costs and the sunk cost fallacy won’t protect you. (And they shouldn’t. They aren’t good for the customers.)
I want to highlight two more major positives.
Because you deliver and capture value over time and drive that value through software, it is easier to price based on value.
Implication: With common hardware differentiated primarily by software, you can spread non-recurring engineering and design costs across a much larger number of units relative to an OEM model. Take a look at the vast array of SKUs available from a legacy robotics company. There is some overlap between them, but each one is a unique combination of custom hardware and custom software. In a RaaS business model, you want to drive more hardware volume across fewer SKUs by using your software and your pricing strategy to effectively gate how much customers pay based on how much value your solution has for them. In other words: Ship the same hardware to almost every customer, but let them pay based on which feature set they need. (If I didn’t stop here, I would go on about pricing strategy and value management all day, but in the most extreme version you can price per action.)
Because you retain ownership over the robot, you are justified in retaining ownership of the data you collect (within reason) and using that to improve your offering.
Implication: Machine learning and RaaS are a natural combination. Imagine being able to spin up a RaaS operation for a customer and have your system adapt itself to their needs. Your customer can even choose to optimize based on their priorities — cost, speed, service level. This is another huge customer win.
The potential to add more value to a hardware offering over time without major hardware updates is profound and novel in the robotics industry. And the potential to price based on that customer value instead of on cost means robots are now economically feasible for use cases that were once too low-value for a fine piece of hardware.
Manage the new complexities
Because this is priced as a service, you’ll be rightfully judged on your service’s uptime and reliability. This is measurable.
Implication: Do the math to minimize downtime, optimize your operations, and plan ahead for growth. Let’s do some basic ops management arithmetic.
- Say your robots are about as reliable as elevators. (This is not a random comparison — I expect elevator service and repair to inform RaaS companies in the future.) Under normal use, you may be looking at 5–6 service calls per robot per year. Let’s assume 5 service calls per year. And let’s assume that the average service call is a 4-hour turnaround from “this robot stopped working” to “back in service.” Finally, let’s say you’ve deployed 10,000 robots in a service area.
- 5 service calls multiplied by 4 hours each = 20 hours per robot out of service per year. 20 hours divided by full uptime (let’s assume that translates to 24 hours per day 365 days per year, so 8,760 hours) = 0.23% chance that a robot is out of service at any given time. 0.23% multiplied by 10,000 robots = 23 robots are out of service at any given time.
Now that you are expecting this, what are you going to do to preserve uptime and/or reduce your maintenance and service burden? Do you just accept this as inherent to your business (and coach your customers to accept it as well)? Or are you going to keep more units onsite ready to deploy at a moment’s notice? Keep offline units in reserve nearby? Work with a company like WiBotic to reduce the number of robots you need to deploy to preserve your service level? How much extra space do you need to store extra units? How many service technicians do you need to hire to cover the service hours implied by these calculations? There will rarely be one right answer — and that answer may differ based on your product and your customer base.
(One day I’ll write a much longer post on this topic alone that pulls in where you do repairs, whether you keep extra inventory onsite or nearby, how critical any one robot is to proper functionality, how big your robots are… but, like pricing strategy, I’ll save that for another day.)
After you go beyond one robot in one location, you need to build scalable processes for provisioning, monitoring, and securing your robots. Tasking engineers for everything doesn’t scale.
Implication: Automated fleet monitoring and management is make-or-break. This was never a major problem in places like car factories because the number of deployed units was relatively low and their value was extremely high. You could tack on a dedicated person (or even a team) to keep your systems up and running and still make the budget work. Importantly, the absolute number of robots was still at a human scale. That won’t be true for much longer. So you’re going to need a way to monitor, manage, and even troubleshoot robots remotely and automatically. This is how you’re going to scale up with that maintenance burden I talked about. This is what we’re building at RosHub.
— —
I have another big issue I want to address: A key metric that drives home what’s important for RaaS businesses and why you can’t rely on a well-known SaaS analog. That’s my next post.
