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 and 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. There really is a fine line you have to tread 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.

NOTE: While this post covers pricing methods for BaaS, we recently announced a new free eBook that covers MSP pricing in general in excruciating detail entitled The Price is Right: The Definitive Guide to MSP Pricing. More information on the eBook can be found near the bottom of the page, or you can simply head over to the download page if you’d like.

Pricing BaaS Per GB

The first model I’ll discuss is likely the most common, and that is 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 which 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…etc..etc.
  • 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 what their average cost per workload is 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 8 servers, then they pay for 8 protected workloads per month.

This method is more difficult for you, however. There is 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 in some wiggle room to the pricing, but again, if the price is too high, your customer won’t pay, which defeats 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 issue mentioned above 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 is a model that I see to be gaining traction in the last couple of years amongst MSPs. Many customers today see backup as a 101 type of service that should be offered by any MSP. They assume they will pay the introductory rate for a given server and also assume the service will just come with 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 managed by you 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 customer more time doing whatever it is they do.


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 allows you a little more flexibility per customer. Each customer is going to be different, with different datasets, and your costs for recovery 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 for you, in that 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 price is directly linked with the SLA. Something to consider at the very least.

Want to Learn More About MSP Pricing? **FREE eBook**

Looking for more information and some practical guidance and examples? We’ve actually got a new eBook out specifically about pricing MSP services. The book covers many of the concepts mentioned above and goes into much greater detail. It also applies to any/all MSP services, and not just BaaS. It’s a great guide if you’re looking to price out some new services, or if you want to just do a head check and make sure your pricing is following the correct logic. Whatever the case, it’s a great guide to keep handy and can be downloaded HERE.

The Definitive Guide to MSP Pricing

Download the Free eBook


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? Let us know in the comments section below!

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.

Thanks for reading!

Altaro O365 Backup for MSPs
Share this post

Not a DOJO Member yet?

Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!

Leave a comment

Your email address will not be published.