Your RTO Is a Lie: Ask This Better Question Instead

Every MSP worth its managed services contract has sat across from a client and walked through an RTO conversation. Recovery Time Objective. The number of hours before your systems are back online. Eight hours. Four hours. Two hours if you're running hot standby.

Here's the problem: your clients don't actually care about RTO.

They care about whether their business survives the outage. Those are two very different questions, and most RTO conversations in the industry are answering the wrong one.

What RTO Actually Measures

RTO is a technical target. It answers: how quickly can we restore IT systems after a failure?

It does not answer: how long can this business actually function before the wheels come off?

That's a business continuity question - and it's the one your vCIO should be asking in every TBR, every risk review, and every BCDR conversation. We call it the Business Survival Threshold, and it has three distinct layers most MSPs never document:

1. Manual Operations Limit
How long can the business function using workarounds - manual processes, phones, paper, spreadsheets - before it starts degrading seriously? For a manufacturing floor or a law firm mid-discovery, that number might be two hours. For a professional services firm with flexible processes, it might be a full day.

2. Revenue-at-Risk Threshold
After how many hours of downtime does the business start losing real money - missed SLAs, voided contracts, lost sales opportunities, or regulatory violations? This isn't a hypothetical. It's a number with a dollar sign attached, and your clients' CFOs absolutely know it.

3. Point of No Return
After how many days of sustained outage would business recovery become genuinely unlikely? Staff start leaving. Clients churn. Credit lines tighten. Reputation damage compounds. This is the number nobody wants to say out loud, but it exists for every business.

The Gap That Nobody Is Measuring

Survival window: the number that changes the conversation

Here's where it gets uncomfortable for a lot of MSPs.

Most BCDR conversations go like this: "Your estimated RTO with our current solution is 9 hours. With an upgraded backup solution, we could get that to 2 hours." That's a fine conversation. But it's incomplete.

Imagine a client whose team can only function manually for 4 hours before the business starts degrading - orders stop processing, customer calls go unanswered, compliance obligations start slipping. Their current RTO is 9 hours. Even with a "solid" recovery posture by industry benchmarks, there's a 5-hour gap where the business is operating without IT capability.

That gap doesn't show up in a standard RTO report. It doesn't show up in any vendor-provided downtime calculator. And it absolutely does not show up in a backup-focused review that leads with "here's what your downtime would cost per hour."

The gap between RTO and Manual Operations Limit is where businesses actually die during an outage. Not because IT failed - because the business had no plan for the window between failure and recovery.

Why Vendors Don't Ask This Question

According to Datto's Global State of the MSP Report, downtime costs SMBs an average of $10,000 per hour in lost productivity, revenue, and recovery costs. That figure is what makes the survival window conversation land - it converts an abstract technical metric into a dollar amount the business owner already understands.

The major BCDR vendors - Datto, Axcient, Veeam - all provide RTO calculators. They're well-built tools. They're also fundamentally sales instruments. Every one of them is designed to produce a scary downtime cost number, then show you how much cheaper that number gets with their product.

The Business Survival Threshold is a question that can only come from your vCIO or account manager. No vendor will ever ask it, because the answer might reveal that the real problem isn't backup frequency - it's that the client needs a documented manual operations playbook, a succession plan for key roles, or a remote working arrangement that kicks in before IT is restored. Solving that problem doesn't sell more backup seats. Identifying it builds the kind of trust that makes your MSP irreplaceable.

How to Run This Conversation

The three questions that replace the RTO discussion

The Business Survival Threshold conversation doesn't require a sophisticated tool. It requires the right questions and a willingness to sit with the answers. Here's the sequence we use at vCIO Framework:

Open with the manual ops question:
"If every system went down right now - email, ERP, everything - how long could your team realistically keep operating using phones, paper, or manual workarounds before things started breaking down?"

Move to the revenue question:
"At what point - what specific hour - would an outage start costing you clients, breaching contracts, or creating compliance exposure?"

Close with the PONR question:
"If I told you the business was offline for 5 days - not 5 hours, 5 days - what happens? Is there a recovery path, or is that a different kind of conversation?"

That last question, delivered calmly and professionally, is one of the most powerful things a vCIO can say in a room. It reframes the entire BCDR discussion from a technology problem to a business continuity strategy - which is exactly where it belongs.

Turning the Answer Into Action

Connecting survival window to a project proposal

Once you have the three threshold numbers from your client, you can do something meaningful with them. If their RTO exceeds their Manual Operations Limit, that is a Red - immediate action required. The conversation pivots to: what do we do in those hours? If RTO falls within the Manual Ops window but exceeds the Revenue-at-Risk threshold, that is a Yellow - a risk to document and remediate. If the RTO is comfortably inside all three thresholds, that is Green - but document it, because it changes with every acquisition, system migration, or headcount shift.

We've built the Business Survival Threshold directly into our free RTO/RPO Risk Calculator. It takes 5 minutes. The conversation it starts can change the entire tone of your next TBR.

Your clients aren't paying you to recover their servers. They're paying you to keep their business alive. Ask the question that measures whether you're actually doing that.

Frequently Asked Questions

What is the difference between RTO and survival window?

RTO (Recovery Time Objective) measures how fast your systems come back online. Survival window measures how long a specific business process can be offline before the business itself is at risk - through lost revenue, contractual breach, regulatory penalty, or reputational damage. RTO is a technical metric. Survival window is a business metric. They are not the same thing, and only one of them is what the client's CEO actually cares about.

How do you calculate a client's survival window?

Ask three questions: Which business process generates the most revenue or carries the most operational risk? How long can that process be offline before real damage occurs? What is the financial exposure per hour of downtime? The answers define the survival window. For a law firm, it might be 2 hours before they miss a filing deadline. For a manufacturer, it might be 4 hours before a production line stops. For a financial services firm, it might be 30 minutes before a regulatory threshold is breached.

Should every client have a different BCDR plan?

Every client should have a BCDR plan calibrated to their survival window, not a generic template. An MSP that sells the same backup solution to a law firm and a construction company is not doing BCDR advisory - they are selling a product. The survival window conversation is what forces the plan to reflect the actual business risk rather than a default configuration.

See also how vendor RTO calculators compare to this framework, and use the client health scoring model to identify which accounts need this conversation most urgently.