Availability Is Not Readiness

One of the stranger things about continuity planning

One of the stranger things about continuity planning is how often we answer the wrong question correctly.

Do we have backup capacity? Yes.

Now what?

If the primary operation failed this afternoon, could that capacity actually accept live work? Could the people sign in? Are they trained for the work that would move? Do the commercial terms allow activation? Does somebody have authority to pull the trigger? Do the routing, quality, escalation and reporting processes still work after the move?

Those are different questions.

A company can have plenty of capacity available in the market and still have no practical way to use it when a real disruption occurs. Technically available. Practically useless.

Availability is not readiness.

Potential, available and ready are three different states

I think it helps to separate three states that often get collapsed into one.

Potential capacity is capacity we believe we could source. There are providers, contractors, internal teams, alternate sites, automation options or other resources that might be able to help.

Available capacity is more concrete. Someone has told us the supply exists, or a contract gives us a right to request it, or a team appears to have room.

Ready capacity can take a defined unit of real work through an approved path under the controls the program requires.

That last sentence is doing a lot of work.

The difference between available and ready is everything that sits between “yes, we have an option” and “customers are being served.” In most customer operations, that gap is not one thing. It is a chain of dependencies.

Readiness behaves more like a minimum than an average

This is where a little math is useful.

Suppose we score eight readiness dependencies from 0 to 100. Seven of them are at 90. One of them - system access - is at zero. The average looks respectable. The operation is still not ready.

For systems like this, readiness often behaves more like a minimum function than an average. The weakest critical dependency can determine whether any of the others matter.

Seven green checks and one red can still equal zero usable capacity.

That is why a provider list, a staffing estimate or even a signed contract can create a false sense of resilience. Those things may be necessary. They are not sufficient.

The validation gates

The exact gates vary by program, but the operating categories are fairly durable.

Capacity. Is there enough real supply to absorb the work? If readiness depends on hiring after the event, that is recruiting capacity, not ready capacity.

Skills. Are the people qualified for the work types that may move - products, languages, channels, customer segments, regulatory requirements and escalation boundaries?

Access. Do the people, sites and systems have the credentials, devices, connectivity, data permissions and security controls required to work?

Workflow. Can the work actually be routed? Are knowledge, quality, case ownership, handoffs and escalation paths defined for the alternate route?

Terms. Are the commercial mechanics understood before urgency arrives - activation rights, pricing, volume limits, minimum commitments, notice, payment and other constraints that can slow a response?

Governance. Who can declare the event, authorize activation, change routing, approve exceptions and communicate with customers, partners and leadership?

Management. Once work moves, who watches performance, reconciles capacity, handles quality drift, adjusts the plan and decides when the temporary operating state should change again?

Activation. Is there a tested mechanism for moving from normal operations to the alternate path, or is the first activation effectively a live experiment?

A readiness plan does not need a perfect score on every imaginable dimension. It does need the critical dependencies for the chosen response path to be good enough for the consequences of failure.

Testing is how theoretical readiness meets reality

Written plans are useful because they force decisions into the open. They are also very good at hiding assumptions.

The cleanest way to find those assumptions is to test the path.

FEMA’s 2024 Continuity Guidance Circular makes this point directly in the continuity context: exercises help validate plans and capabilities, clarify roles, identify gaps, test backup communications and data, and feed corrective actions back into preparedness. The exercise is not theater. It is a diagnostic.

NIST’s 2025 incident-response guidance makes a related point from cybersecurity. Preparation is not just an activity that begins after detection; NIST places broader Govern, Identify and Protect activities underneath the response lifecycle because they support the organization’s ability to Detect, Respond and Recover effectively.

Different domains, same operating lesson: the capability you expect to use under stress should be prepared and improved before the stress test becomes real.

A tabletop can help. A routing test is better. A limited live-work exercise may be better still where risk and controls allow it. The goal is not to perform confidence. The goal is to discover friction while the cost of discovery is still low.

Readiness decays

Even a validated path does not stay validated forever.

People leave. Skills drift. Passwords expire. Security policies change. Systems are upgraded. Knowledge articles move. Queue structures are redesigned. Commercial terms age. Contacts change. A provider that had spare capacity last quarter fills it with another client.

This is why “we tested it once” is not a durable readiness strategy.

The operating question is not whether the path has ever worked. It is whether we have enough recent evidence to believe it works now.

That does not mean running a full-scale exercise every week. It means defining what can expire, what needs periodic validation and what signals should trigger a re-check.

Measure activation, not inventory

Traditional continuity inventories tend to count things: backup vendors, seats, sites, names on a call tree, signed agreements. Those can be useful inputs. They are weak outcome measures.

I would rather know things like: What percentage of alternate capacity has current access? When was the routing path last tested? Which work types can actually move? How long does activation take in a controlled exercise? What defects were found last time, and were they closed? When did the commercial or security assumptions last change?

Those measures tell us something about executable capability. A count of options mostly tells us how many nouns are in the plan.

More vendors is not the objective

None of this is an argument that every program needs multiple BPOs.

A single provider may have genuinely independent sites, networks and workforce pools. An internal team may be the best alternate path. Automation may absorb a defined class of interactions. Multiple providers may make sense when the failure domains are meaningfully different.

The architecture should follow the problem.

What matters is that the alternate path is independent enough to survive the failure you care about and prepared enough to accept the work you intend to move. Vendor count is not readiness.

The practical question

So when somebody says, “We have backup capacity,” I think the next question is simple.

Could we use it now?

Not after a new SOW. Not after two weeks of training. Not after security provisions a new role. Not after somebody decides who owns the escalation. Not after we redesign the routing logic.

Now.

If the answer is no, that does not mean the option is worthless. It means we should describe it accurately. It is potential or available capacity with work still required before it becomes ready.

That distinction is valuable because it tells us what to do next.

Availability tells you supply exists. Readiness tells you the system can use it.

One is an option. The other is an operating capability.