Objectives, Requirements, and SLAs, Oh my! Part One

Objectives, Requirements, and SLAs, Oh my! Part One

January 29

When working with customers to provide technology services, it’s not uncommon for backup and recovery plans to be an afterthought to delivering servers and software that meet the customer’s on-premise data and application requirements. I still remember when you simply added a tape drive and a couple ten-packs of tapes to your order regardless of the server’s role. Today, continued and uninterrupted availability of IT systems is increasingly critical to the smooth operation of business. And rapid recovery in the event of an interruption is more important than ever.

Many providers are meeting this growing need by offering Recovery as a Service (RaaS) to their service offerings. In other words, for a modest monthly fee, they commit to restore functionality to the customer’s servers within a predetermined amount of time with a Service Level Agreement (SLA). It sounds complicated and risky doesn’t it? Well, yes and no, but it can very profitable.  Let me explain.

If there’s one thing I learned in 12 years of running my own VAR/MSP, it’s that the hardest part of adding any service offering to my service portfolio was not the technical stuff. It was creating a clearly defined and easy-to-understand service offering and a set of agreements or SLAs to back the offerings.  Chances are, if you’re selling and installing ShadowProtect, you already know most of what you need to know to build a complete disaster recovery solution. You just might not have packaged it as a service offering yet. So, let’s take some time to explore the profitable, yet challenging process for creating a set of defined recovery services and SLAs. Since this is a detailed subject, we’ll break it into two parts (I’m a big believer in eating an elephant one bite at a time). Be sure to check back in February for the second part on defining SLAs.

Part 1—Defining Your Service Offerings

Let’s start by breaking your services into logical components that can be sold and scaled per customer.  I like to think of this as creating layers that can be individually tiered or joined with other layers as bundled service offerings. You start with number one, and then, as per each customer’s recovery objectives, requirements, risk tolerance, and of course budget, you layer on additional service. This allows you to write a single terms-of-service agreement, then add separate service level agreements per service (more on that later).

As far as productizing your services (yes, I just had to get that word in this post), we will let your creative marketing team, or well-paid marketing consultants, come up with catchy names for these offerings. You need to figure out how they work. For example, your service components could be broken up and defined as:

1)      Onsite Backup w/ Recovery as a Service—In this offering, you setup a scheduled backup to a local appliance/server and promise to be able to locally recover the customers systems and/or data in the event of any type of loss or interruption but a major disaster (something that renders their location unusable). 
The length of time it takes you to recover is primarily going to depend on if you use a remotely accessible backup server that has virtualization capabilities or if you intend to send a truck with a utility box. Each customer will have a different RTO (recovery time objective: their targeted maximum length of time between a disruption and recovery). Your ability to meet that RTO is what you need to calculate, then ultimately—for a fair price—commit to in your SLA.
Selling or renting the backup appliance/server hardware is your choice. Each option has its advantages and disadvantages. Either way, you typically want to charge a setup fee that covers your hard and soft costs, and a monthly service fee that allows you to share the risk of possible costs associated with a potential recovery across the rest of your customers according to the odds of a server crash. This is an insurance policy for servers.

Tip:  Charge a setup fee that is 2-3x your setup costs, but waive a large portion contingent on the completion of a minimum term contract. That way, should your customer cancel early, you have some prorated fees due (as you can’t easily sue for undelivered services). Think of the last phone you got for free (or discounted) with a term-based contract. This is the same logic.

2)      Offsite Backup—Let’s agree that 100% of your customers need offsite backup to an alternate location or cloud storage but, unless you are selling into a unique vertical market,  I would dare to say that only a few would ever need an off-site recovery solution (I just heard a gasp from someone in Sales/Marketing area).  As nice as it sounds, how many of your customers would actually be able to continue operations within a day or less if tomorrow morning there was a smoking crater where their business used to be. With few exceptions, most business wouldn’t have a way or need to access their systems immediately and would be more than happy to have a recovery drive or server delivered within 24–48 hours of a major disaster.

Offsite backup can be billed monthly, either per monitored replication target (for customers backing up to alternate sites) or per/GB for those backing up to a cloud service such as your data center or StorageCraft Cloud Services.
Tip: Offer regular recoverability testing of offsite backup as a part of this service. Be sure to learn more about how StorageCraft’sImageReady tool can help you automate this test.

 3)      Offsite Backup w/Offsite System Recovery as a Service—This ultimate layer of service provides for the immediate availability of their most recent offsite backup to be virtualized and made available to users from a remote location. While this service may seem expensive to some, for those with low tolerance for downtime (like municipalities or multiple site customers), the ability to recover their system in minutes is critical and much more affordable than alternate “high availability” solutions.

This service should be charged per GB and include a full business continuity plan to ensure each step of the recovery process has been planned and tested.
Tip:  If you are hosting your customer’s data, be sure to look at StorageCraft’s HeadStart Restore.  It enables you to have standby VMs created with your customer’s replicated data.  Otherwise, be sure to look at StorageCraft Cloud Services Cloud Premium.

Now that your recovery services are broken down into individual components, you’ll want to create a single-page document for each that communicates the features, benefits, and prices.  Do not go down the rabbit hole of writing up product briefs that explain your services in specific technical details.  The specific technologies may change from customer to customer, and perhaps more importantly, most customers don’t care about the details.

Tip— Don’t be afraid to create tiered options of service like Good, Better, and Best simply by adding the “layers” of service.    

Looking Ahead

So, now that you have a clearly defined set of service offerings created around the technologies you are confident you can deliver, it’s time to start selling right?

Not so fast.

I’ve been on the keyboard end of a nearly-failed disaster recovery and it’s one of the worst feelings in the world. And while we all like to believe that customers clearly understand the limitations of technology and the expectations you’ve attempted to set, it’s absolutely essential that you put everything in writing.

You must have clearly defined terms of service and service level agreements to establish not only reasonable expectations for your service levels, but more importantly, you must establish clear limits to your liability.

So what goes into good SLAs? More on that coming soon in Part 2 of Objectives, Requirements and SLAs, Oh My!

  1. fred.trovato on

    Great article. I agree, if you break a project down into smaller pieces it’s a lot easier to manage. I enjoyed the useful tips as well. I’m looking forward to reading the second half of the article.