4 Steps to Quickly Determine a Customer’s Backup Requirements

How quickly do you assess a new customer’s needs? Making a fast and accurate judgment of what a customer needs is a hugely important first step in any business relationship. The following steps will ensure you can figure out what a customer’s customized backup service should look like within your first meeting.

Successful service providers tend to keep their services tightly wound around a common service definition and rarely allow one-off services. It’s unpredictable and can be less than profitable. But one service does require some degree of flexibility when it comes to specific execution – backups. Backups are the one service that revolves around what the customer already has in place and what they need to be delivered to work alongside that existing environment – instead of the usual “you put it in place so that is what they need to be delivered.”

Most service providers start with the tech they have in place – the backup solution, storage mediums, use of the cloud, etc. – and then build a service offering around that. But, unless you focus on the exact same type and size of customer, every customer has different needs when it comes to how they define what it takes to keep them operational. For some, it’s merely maintaining Internet access to connect to SaaS applications. For others, it’s manufacturing systems that need to be running. And for others, it’s access to on-prem files and databases.

You also need to be aware that your customer’s needs may vary while your offering remains static. This creates what’s known as a Recovery Gap. Simply put, the recovery gap is the distance between your customer’s recovery needs and your ability to deliver. If your backup offering is static, there is most likely to exist some degree of a gap.

So, how do you define your customer’s backup needs and eliminate that recovery gap?

Below is a simple 4-step plan that starts with the business’ recovery needs and works backward to the backups needed.

The 4 Steps

Step 1: Start with Business Needs – Begin with how the business defines being operational. This should include key services, systems, applications, and data that are deemed anywhere from important to critical. To best ensure you and the customer are looking at this through the same lens, inquire how long the business can be without each key operational element, as well as ask how the loss impacts the business. This could be things like core manufacturing applications for a factory, or a medical office’s patient records program. What does the business NEED to remain operational?

Step 2: Identify Recovery Objectives – Define recovery time (RTO) and recovery point objectives (RPO) for each element identified in Step 1. What you’re doing in this step is putting objective parameters around the somewhat subjective Step 1 definitions of what’s “critical.” Remember, RTO defines how quickly your customer needs to recover, and the RPO defines how much data (usually a period of time) can they lose and still remain functional.

Step 3: Create Recovery Tiers – You’ll begin to see patterns around the recovery objectives that will allow you to group certain parts of the environment into recovery tiers. For example, there may be several applications, data sets, and systems that need to be recovered and operational within an hour, while the remainder of the environment can take as long as 24 hours – giving you 2 recovery tiers. The business owners will start by saying that everything in critical, but you’ll find that after talking with them candidly, they’ll settle pretty quickly on what they’re most critical systems are.

Step 4: Build a Backup Strategy – Build your backup strategy around the recovery needs as defined in Step 3. In a perfect MSP world, this is merely an exercise in properly defining the backups and their frequency. But in some cases, you may learn that your recovery gap requires additional protective measures – such as the use of offsite backup storage to the cloud – to ensure a needed system can recover within the needed timeframe. In this case, you may need to rethink your service definitions and expand them to include additional infrastructure and software in order to meet your customer’s needs. Additionally, what you’ll find working through this exercise is that finding these gaps for one customer may help you later on down the road.

Additional Steps

Not listed here (but should be mentioned in the interest of being thorough) is a Testing step.  It’s great to make a great plan that you believe will work for your customer; to be sure, you need to test whatever changes you make to close the recovery gap.

How this Works in Practice

As an example, let’s imagine a 24/7 medical clinic. They have approached you to provide backup services. To date, you’ve provided simple file-based backups to your customers. Upon talking about the clinic’s recovery needs, you find that any outage the clinic suffers must be resolved within 4 hours (4 hour RTO). The clinic’s patient records database is quite large at 2TBs in size. A traditional file-based recovery would be hard pressed to fill this need. With this realization, you’ve already established a recovery gap. With this information you then procure a backup application that has the ability to boot workloads from the backup storage, thus filling the clinic’s 4-hour requirement.

While this is a very simplistic example and only talks about a single recovery tier, you get the idea of how this process can help you find gaps in your offering at the beginning of the working relationship so you can start off in the right manner. As we have shown in other blog posts here on the MSP Dojo e.g. 4 Common BaaS Pitfalls MSPs Definitely Must Avoid or How to Build a Successful Managed Services Team, getting the foundation right from the start is so important for your future endeavors. By following these tips, you’ll be in a much better position to focus on delivering exactly the service your customers require and delight them in its delivery.

Wrap-Up

Remember, just because you’ve always done backups the same way for as long as you can remember, doesn’t mean it meets your customer’s needs.  The 4 steps above will better define your backups around what the customer requires. More than likely, it won’t impact your service definitions enough that you feel like every customer is a one-off service. But it will impact your ability to make the customer very happy when you recover exactly what they need in the timeframe they need it, should a disaster strike.

What are your thoughts? Do you find it fairly easy to track down recovery gaps in your offerings? We’d like to hear more about your experiences! Let us know in the comments section below!