4 Ways To Price BaaS – Which Should I Use?

Are you considering offering BaaS to your customers? Or perhaps you’re already delivering the service but wondering if you’re pricing it correctly. Either way, figuring out how to price any service to optimize customer satisfaction and profits is not an easy task. Pricing BaaS, due to its nature, presents a number of different options to consider. But which one is the best for you? Read on to find out.

When it comes to providing a new product or service for your customers, pricing can often be a hang-up for getting things to market. Pricing is tricky. There is no sugar-coating it. If your pricing is too expensive, people won’t buy it. If it’s too complicated, people won’t buy it. However, on the flip side, if it’s too cheap, people will assume it has no/low value. 

You have to tread a fine line between conveying value and staying competitive. These concepts apply to BaaS pricing just like any other product or service. With that in mind, I thought an article covering some of the common pricing models for BaaS would be in order.

Pricing BaaS Per GB

The first model I’ll discuss is likely the most common: a per GB model. Many MSPs providing BaaS services opt for this model because it does a good job of scaling up and down as customer needs change, and it’s simple for the customer to wrap their heads around as well. They understand that storing more data equals additional costs for backups. When determining that magical price per GB amount, there are a number of items you need to consider. Some of these are:

• Licensing Costs for Software
• On-Prem Storage Costs
• Off-Site Storage Costs (including applicable public cloud fees)
• Engineering time for recoveries, test restores, maintenance
• Networking costs

These are the main items that you need to keep an eye out for. Basically, the list boils down to anything that costs you money in providing BaaS services. If you missed something after you’ve made your calculations and sold it, now you need to either eat the costs or go to your customer, hat in hand, and ask for more money. Neither is a good situation, so you’ll certainly want to spend some time on this.

The other aspect of Per GB pricing that you need to determine is whether or not you’re going to change for the Deduped/Compressed storage used or the fully hydrated dataset. While it’s easier for the customer to understand the fully hydrated number, you, the MSP, will likely find the deduped/compressed number advantageous as it makes it easier for you to correlate your own costs per GB.

Whatever route you choose, make sure it’s well-documented and easy to understand

Per Protected Workload

While less common, this is still something that I see pretty regularly. Instead of charging per GB, an MSP will determine their average cost per workload across the customer base and then use that as a baseline for determining how much to charge per workload per month. This method is VERY easy for the customer to understand. For example, if they have eight servers, then they pay for eight protected workloads per month.

This method is more difficult for you, however. There is an added risk in that the average does not always work. Let’s say you’ve been servicing the SMB space to date, and you bring on a marketing firm as a customer only to find out they have 20TB of marketing copy to protect. There goes your average. Now, you can certainly build some wiggle room to the pricing, but again, if the price is too high, your customer won’t pay, defeating the purpose.

Another thing worth mentioning here is that some MSPs using this model will break the model down per the type of workload it is. $X/Month for a SQL Server, $X/Month for a Domain Controller….etc…etc. This helps deal with the abovementioned issue regarding your average. However, keep in mind that if the model is too complicated, you’ll make your customers’ heads spin.

Strictly Value Add

This model has gained traction amongst MSPs in the last couple of years. Many customers today see backup as a 101 type of service that any MSP should offer. They assume they will pay the introductory rate for a given server, and the service will just come with a backup. In line with this, many MSPs have taken this to heart and have just rolled up the backup costs into the monthly rate they would change for monitoring and patching a given workload.

While you may be a bit more expensive than your competitors on a per/node basis, you provide more value with that cost. The other added benefit here is that it simplifies your go-to-market strategy and ongoing support in that any workload you manage already has backups accounted for. The same applies to any new server added after the fact. This greatly reduces the number of touches needed for approvals from your customers, and it leaves you more time to provide your usual fantastic support and your customers more time doing whatever it is they do.

Per SLA

While a bit more uncommon, this is something that I’ve come across a few times. Instead of tying backup pricing to a particular size or number of workloads, an MSP will simply ask the customer a question. “How fast do you need to be back up in the event a recovery is needed?” With that answer, the MSP will present a cost per SLA type of list:

Recovery within

• 5 to 15 minutes – $X/Month
• 15 minutes to 1 hour – $X/Month
• 1 hour to 4 hours – $X/Month
• 4 to 8 hours – $X/Month
• 8+ hours – $X/Month

It’s an interesting model in that it gives you more flexibility per customer. Each customer is going to be different, with different datasets, and your costs for recovering customer X within 5 minutes may be widely different than doing the same for customer B. With this in mind, your pricing is likely going to be different for each customer based on their needs. Yes, it’s flexible, but it adds overhead because you need to figure out costs each time you onboard a customer.

The other thing to consider with this approach is that with price tied to SLA, you can be sure that they’ll hold your feet to the fire on that SLA. More so than normal because now the price is directly linked with the SLA. Something to consider, at the very least.

Per User or Endpoint Model

Lastly, a growing trend is the per-user or endpoint model, tailored for businesses with a clear count of users or devices that need backing up. This model is straightforward for both MSPs and customers: you simply charge a flat rate for each user or device protected each month. It’s appealing due to its predictability and ease of understanding. 

For example, a business with 50 employees pays for 50 users. This model scales neatly with the size of the business, ensuring that your services grow with them as they grow. It’s particularly suited for organizations with a mobile workforce or numerous devices, as it aligns the cost directly with the scale of usage. Just be mindful to define what constitutes a ‘user’ or ‘endpoint’ clearly to avoid confusion and ensure transparency.

Wrap-Up

So, while this post doesn’t cover ALL the pricing methods you’ll run into out there, it certainly covers some of the most common. How about you? Have you seen or come up with a BaaS pricing model that doesn’t fit neatly into any of the above?

Finally, if you’re not offering BaaS to your customers – why not? But before you do read this guide 3 Steps for MSPs to Get Started with Backup-as-a-Service to make sure you deliver the service properly.