CES-WE study materials
CES-WE study resources

The 99.9% Availability Claim and a Contractor's Backhoe

CES-WE · Put your knowledge to work in context.

All case studies

The 99.9% Availability Claim and a Contractor's Backhoe

A managed WAN contract guarantees 99.9% monthly availability per site, measured as 1 minus (unplanned downtime ÷ total minutes), excluding scheduled maintenance and customer-caused outages. Credits are 5% of monthly recurring charge per full 60 minutes of downtime beyond the threshold, capped at 30%. Site MRC is $4,000. Last month (30 days) the site had: a 45-minute scheduled maintenance window; a 150-minute outage caused by a third-party contractor cutting the building's fibre; and a 60-minute outage traced to a misconfigured customer firewall rule. The customer is demanding a 30% credit and threatening to churn.

1. Calculate the credit owed and state whether the 30% demand is supported contractually.

Read the worked answer

Minutes in the month: 30 × 1,440 = 43,200. Threshold at 99.9% = 0.1% × 43,200 = 43.2 minutes.

Classify each event:

  • 45-min maintenance → scheduled, excluded outright; not unplanned downtime.
  • 60-min firewall event → customer-caused, excluded by the stated carve-out.
  • 150-min fibre cut → counts. A third-party contractor cutting the fibre is not excluded by a clause that excludes only scheduled maintenance and customer-caused outages; availability commitments of this shape are fault-agnostic.

Credit: billable downtime 150 min; beyond threshold 150 − 43.2 = 106.8 min. Credits accrue per full 60 minutes beyond threshold → 1 unit (a second requires 120 min). 5% × $4,000 = $200.

The 30% demand is not supported. The cap is irrelevant because the schedule never approaches it: 30% would require 6 full units, i.e. 403.2 minutes of billable downtime. The correct contractual answer is $200, and saying so clearly is more defensible than a vague partial concession.

2. The customer says the fibre cut "wasn't your fault." How do you handle the commercial conversation and the technical one separately?

Read the worked answer

Separate the two answers and never blend them in the same sentence.

Contractual: fault is not the test. The credit is $200 under the schedule, and the fibre cut counts. Argue the schedule, not the blame - arguing fault invites the customer to argue it back, and the clause is not written that way.

Commercial: a $200 credit against a $4,000 MRC will not retain an account that is threatening to leave. If retention justifies it, offer a goodwill gesture - a month's credit or a funded diversity survey - explicitly documented as a discretionary retention decision. Do not present it as a correction to the calculation, or every future credit discussion starts from the assumption that the schedule is negotiable under pressure.

Technical: the 150-minute outage is the more important signal. A single fibre path into a site with a 24×7 dependency is a single point of failure, and the clause that gives the customer only $200 of protection is the same clause that gives you no incentive to fix it. Propose diverse entry or a 5G/LTE failover with a stated failover time, and separately review the customer firewall change process so the 60-minute self-inflicted event stops recurring and inflating next month's numbers.

3. What single change would most reduce next quarter's risk, and how do you cost-test it?

Read the worked answer

Change: eliminate the single path - diversity or automated failover.

Cost test: the customer's own downtime cost is the missing input, and it dominates. One 150-minute event already occurred. If the site's cost of downtime is $2,000/hour, that single cut cost $5,000 - more than a month's MRC. A failover circuit at ~$600/month then pays back on one event per year, which is a far easier business case than the $200 credit implies.

Contract change to propose alongside it: the present schedule (5% per full 60 minutes, capped at 30%) gives almost no protection at this MRC and no incentive to harden the path. Move to step credits starting at 15 minutes for a 99.9% commitment, and measure per site rather than per network - per-network averaging is how a single-site 150-minute outage disappears into a passing monthly figure.

Sequence: fix the exposure first (failover), then fix the incentive (credit schedule). Doing them in the other order means paying for protection you have already promised not to need.