I insist on 99.9% uptime for non‑revenue automations and 99.95% for revenue‑critical flows; contract a tested failover (hot, warm or delegated), require vendor and independent monitoring, scale service credits to minutes of outage, demand mitigation reimbursements, and keep short termination rights after repeat breaches.
- Percent uptime alone is useless unless paired with failover, objective measurement and financial remedies.
- I use 99.9% for routine flows and 99.95% for anything that touches revenue or customer commitments.
- Require a contractual standby or a right to delegate to a backup provider and make the vendor pay reasonable standby and test costs.
- Measure with vendor reports plus your independent checks and insist on a health API or open telemetry for objective evidence.
- Service credits must scale with minutes of downtime and be paired with mitigation reimbursements and short termination rights for repeat failures.
Signs this is happening in your business
- An automation stalls during peak hours and ops manually clears a backlog for days.
- Support agents read every model reply because they don't trust the outputs, adding hours per ticket.
- The vendor reports 99.x% uptime while your flows experience frequent slow responses and incorrect answers that still 'count' as up.
- Maintenance windows are announced with little notice and customers see delays.
- You have no access to raw health metrics and must rely on vendor emails for incident details.
If several of these are true at the same time, the problem is usually the process rather than the people running it.
What this is costing you a year
(Team hours per week x hourly cost of employees x 52) = annual payroll loss
- People doing this work4
- Hours each per week6
- Hourly cost of employees$45
- Weeks52
The annual payroll cost of four people spending six hours each week on work the automation should do.
Find the number before you spend anything
Run the formula above on your three most repetitive processes. If any of them clears a year of a salary, that is the one to bring to a call.
What LLM uptime SLA I recommend
I put clear minimums in every vendor contract: 99.9% for baseline automations and 99.95% for flows that touch revenue or customer commitments. Pick a percent, then pair it with contractual failover, objective measurement, scaled service credits, mitigation payments and short termination rights after repeated breaches.
- Baseline flows (reporting, low-value notifications): 99.9% uptime.
- Revenue‑critical flows (checkout, billing, contract acceptance): 99.95% uptime.
- Mission‑critical customer-facing flows (SLA-backed promises): consider 99.99% plus active failover.
What those percentages mean in calendar time
I always translate percentages into allowed minutes per month and per year so the risk is tangible in negotiations. Negotiators understand minutes; percentages hide impact. Quote minutes per month and minutes per year during redlines to make the cost of a missed SLA visible and negotiable.
- 99.5% ≈ 216 minutes allowed downtime per month.
- 99.9% ≈ 44 minutes allowed downtime per month.
- 99.95% ≈ 22 minutes allowed downtime per month.
- 99.99% ≈ 4.4 minutes allowed downtime per month.
How I pick the right SLA for each automation
I pick SLAs by mapping downtime to dollars or human hours. Identify failure modes, estimate weekly hours lost per outage, convert to annual payroll cost, then choose the SLA whose expected downtime risk you can accept or back it with failover and larger credits.
- If outages force manual work for multiple hours and affect customers, aim for 99.95%.
- If outages are a temporary inconvenience without revenue impact, 99.9% is reasonable for small teams.
- If the flow underpins a contractual promise, demand 99.99% or a fully separate, tested backup.
A vendor percentage without tested failover and objective evidence transfers outage risk to you.
Define outage, degradation and measurement precisely
I require precise definitions of 'outage' and 'degradation', explicit measurement windows, narrow excluded events, and a neutral dispute mechanism. Without those definitions vendors and customers argue when it matters; clear language prevents gamesmanship and speeds credits and remediation.
- Outage: inability to receive any valid response for a given call‑type or flow for more than 30 seconds.
- Degradation: responses exceed an agreed latency threshold or correctness falls below a stated acceptance rate.
- Scheduled maintenance: vendor must give at least 72 hours' notice and limit combined windows per quarter to an agreed cap.
- Measurement window: rolling 30‑day and 12‑month windows that match credit calculations.
- Dispute mechanism: neutral technical auditor or third‑party log review if vendor reports and your checks disagree.
Failover options you can insist on
I push for one of three failover models: hot standby, warm standby, or a delegated right to switch to a backup provider. Each option trades vendor cost, your testing burden, and recovery time. Pick the model that matches the business risk and require regular, documented tests.
- Hot standby: vendor runs an alternate model ready to accept traffic immediately; vendor bears standby cost.
- Warm standby: alternate model needs minimal configuration to switch; vendor pays keep‑ready costs and tests quarterly.
- Delegated backup: contract grants you the right to route traffic to a named alternative provider if the vendor misses SLA; vendor must assist transfer and reimburse switch costs up to an agreed cap.
Who should pay for failover and testing
I require the vendor to fund the failover capabilities they promise, including periodic testing and reasonable warm‑standby charges. You can accept modest caps, but portability or delegated backup requires vendor assistance with data, configuration and a documented runbook within agreed timelines.
- Vendor pays for quarterly failover tests and the time to run them.
- Vendor funds warm‑standby compute costs up to an agreed cap.
- If you switch to a backup provider because of vendor breach, vendor reimburses documented switch costs (engineering hours, paid alternatives) up to an agreed cap.
You pay for reliability twice: vendor fees and the engineering hours your team spends when the vendor fails.
Remedies: credits, mitigation payments and termination
Service credits are necessary but insufficient. I make credits scale with minutes of downtime, add mitigation reimbursements for your engineering hours, and keep a short termination right after repeated breaches. That combination makes the vendor internalise outage costs and speeds remediation.
- Service credit formula tied to minutes of downtime in a rolling 30‑day window, proportional to the monthly fee.
- Mitigation payments: vendor reimburses documented engineering hours at an agreed hourly rate or a capped total.
- Termination right: after an agreed number of breaches in a rolling period you can terminate with a pro‑rata refund and no exit fees.
Operational visibility and incident response I demand
I require real‑time alerts, clear priority response targets, and a post‑mortem within a set window. Without incident visibility you cannot trust credits or measure impact. The contract must force timely detection, updates, and a technical post‑mortem with corrective actions and owners.
- Incident notifications: immediate alert on detection, follow‑ups at defined intervals, and final incident report within seven business days.
- Post‑mortem: root cause, timeline, corrective actions with ownership and deadlines.
- Support response times: P1 acknowledgement within 1 hour, P1 resolution target within 4 hours, P2 acknowledgement within 4 hours.
- RTO/RPO: stateful automations must define restore time and acceptable data loss in plain language.
Identify your biggest operational bottleneck
Most owners already know which process is the problem. What they do not have is the annual figure attached to it. That is a 15-minute conversation, not a project.
How to measure and budget the risk (worksheet)
I convert downtime into dollars by pricing the human hours the automation replaces and use that to decide whether to demand a higher SLA, stronger failover, or larger credits. The worksheet sequence below is repeatable in ten minutes and produces a negotiable number you can use in redlines.
Service credits that do not fund mitigation or enable termination are insurance you will never be able to cash when you need it.
Worksheet: where time and money go
Count people covering the process during outages, estimate hours per outage, multiply by their hourly cost and annualise. Convert the SLA's expected downtime into an expected annual exposure and compare it to the credits and failover cost. If exposure exceeds tolerance, raise SLA or force vendor compensation.
- Count how many people handle the process when automation fails and hours each spends per outage.
- Multiply weekly hours per person × hourly cost × 52 to get annual payroll loss.
- Estimate expected annual downtime from the SLA and multiply by the payroll loss to get expected risk exposure.
- If expected exposure exceeds your tolerance, demand higher SLA, failover, or larger credits.
Negotiation playbook and contract language I use
Negotiation is packaging: uptime percentage, failover obligations, measurement, credits, mitigation payments and exit. I trade price for operational terms and bring concrete redline clauses. Start from specific definitions and force the vendor to accept measurable, testable obligations rather than vague promises.
- "Uptime" means availability of the vendor's model to accept and return valid responses within the agreed latency threshold for defined flows, measured in rolling 30‑day windows.
- "Failover" clause: Vendor will maintain a standby model capable of accepting production traffic within an agreed time of failover initiation and will fund standby costs up to an agreed cap.
- "Service credits" clause: For each minute of outage beyond the permitted monthly allowance, the vendor will credit the customer a pro‑rata amount equal to a stated percentage of the monthly fee, scaling with downtime and up to full refund for sustained outages.
- "Mitigation reimbursement": Vendor will reimburse documented engineering hours incurred by the customer to mitigate an outage at an agreed hourly rate, up to an agreed cap per incident.
- "Termination for repeated breaches": If the vendor fails to meet the uptime target more than an agreed number of times in any rolling period, the customer may terminate immediately without termination fees.
How this typically fails in practice
Most SLAs fail because teams sign them without ops and then lack telemetry or budget to enforce the terms. The vendor's percentage looks good on paper while critical flows degrade. Credits are slow or disputed and by the time the post‑mortem arrives customer trust is lost.
- Failure mode: vendor claims 'no outage' because some calls succeed while a critical flow intermittently fails.
- Operational consequence: ops manually reroutes traffic, increasing payroll cost and error risk.
- Contract consequence: credits do not cover mitigation and you lose customers or revenue before remedy arrives.
When to accept a lower SLA
Accept lower uptime only when the vendor provides stronger failover, portability, larger mitigation payments, or a price difference that funds your backup. If a vendor's model quality is unique, get short termination windows, exportable data and binding assistance for switching providers.
- Lower SLA plus vendor‑paid hot standby = acceptable for many midmarket buyers.
- Lower SLA plus delegated backup and vendor‑assisted porting = acceptable if vendor bears defined switch costs.
- No failover and low SLA = accept only if price funds your own mitigation team.
What to do next to protect your automation
Run the cost worksheet, pick an SLA for each flow, add failover and mitigation language to your vendor redline, and insist on a tested failover before production. If you want help I offer scoped calls and drafting — see how I work, my services, and the automation stability guide.
- Immediate step: run the cost worksheet in the next 24 hours and pick a target SLA for each flow.
- Second step: add failover, measurement and mitigation clauses to your vendor redline and request a quarterly test obligation.
- Optional: book a scoped call so I can draft a targeted vendor schedule or review portability with your team; see cto services and build services.
Sources and further reading
- 😺 Claude crossed a paywall on its own — Google News
Where businesses waste the most time
- Re-keying customer dataTime copying details between systems and introducing errorsAutomate the transfer so the receiving system gets the fields filled while keeping both systems intactA person still checks: Person verifies flagged mismatches and approves uncertain records
- Manual ticket routingAgents read every ticket to decide who handles it, causing delaysUse automated routing to assign tickets to the right queue while keeping existing support softwareA person still checks: Team lead reviews edge cases and reassigns when needed
- Slow invoice approvalsApprovers wait for attachments and clarifications, extending payment cyclesAuto‑extract invoice data into the approval queue so approvers see a single structured requestA person still checks: Approver checks high‑value invoices and unusual vendors
How this compares with what you already run
| Operational area | The manual way | The automated way | Annual business impact |
|---|---|---|---|
| Support triage | Agents read every ticket | Automation flags routine cases | Saves tens of thousands in agent hours |
| Invoice processing | Finance re‑keys line items | System extracts and suggests entries | Reduces temporary staff costs |
| Customer replies | Agents craft each reply | Automation drafts replies for edit | Frees agent hours, lowering churn risk |
| Compliance checks | Manual review of each record | Automated pre‑filter with human exceptions | Cuts review time and late penalties |
What the end-to-end workflow looks like
- Ticket arrivesA customer message lands in the support system and is visible to the teamAutomation reads the message and extracts intent and entities
- Initial classificationThe system classifies the ticket into a category and severityAutomation proposes a queue and assigns a priority
- RoutingThe ticket moves to the suggested team or agentAutomation routes to the correct queue
- Draft responseAn initial reply is created for common questionsAutomation drafts a reply for agent review
- Agent reviewAn agent edits and approves the reply before sendingStays human
- Follow up and closureIf the customer responds, the loop repeats; otherwise the ticket closesAutomation flags reopen risk and proposes follow‑up timing
The metrics that tell you it worked
| Metric | What it tells you |
|---|---|
| Average manual hours per outage | Measures human hours spent each time the automation fails; rises when the vendor is unreliable |
| Time to detection | How long it takes your team to notice a failure; lower times reduce damage and mitigation cost |
| Time to recovery (hand‑over to fallback) | Time from detection to switching to the fallback plan; shorter times reduce downtime minutes |
| Number of SLA breaches per 12 months | Counts distinct outage breaches; use it to trigger termination rights or escalations |
| Mitigation hours billed | Hours your team records fixing vendor failures; use this to claim reimbursement |
| Customer-facing delay minutes | Minutes customers wait because the automation is down; tracks business impact directly |
| Post-mortem delivery time | Days between outage and vendor post‑mortem; late reports indicate poor incident practices |
When this is the wrong move
- If the automation is experimental and you expect regular instability during model tuning.
- If the vendor's model is uniquely valuable and no backup can match quality — accept lower uptime but demand portability and exit assistance.
- If the process is low value and manual work costs less than building complex failover; accept a modest SLA and handle outages manually.
The mistakes that cost the most
- Relying on vendor reports aloneThe vendor reports uptime from its perspective, you see outages, and there is no independent evidence; the dispute drags on while your team clears backlog.
- No failover runbookYou have a contractual right to failover but never practiced it; when the model fails the incomplete runbook makes switches take hours and you lose customers.
- Weak credits, no mitigation reimbursementThe vendor offers small credits that never cover mitigation costs, so you pay for both vendor unreliability and the recovery.
- Treating percentage as the whole SLANegotiators focus on 99.x% and ignore latency, correctness and scheduled maintenance; the automation is 'up' but ineffective and business impact continues.
Frequently asked questions
Is 99.9% uptime good enough for customer-facing automations?
99.9% is a reasonable baseline for many customer-facing automations, but not for flows that affect billing or contractual SLAs. If customer trust or revenue is at risk, push to 99.95% or require a tested hot standby and stronger mitigation reimbursements.
Can I enforce an SLA if the vendor blames third parties?
Yes. Define excluded events narrowly and require the vendor to prove third‑party causes with logs. Also demand documentation of third‑party dependencies and a tested mitigation plan for those dependencies.
How much should service credits be?
Credits must be proportional to the monthly fee and scale with minutes of outage; include mitigation reimbursements for engineering time. Avoid flat nominal credits that do not cover your recovery costs.
What does a delegated right to use a backup provider look like?
It is a clause giving you the right to route traffic to a named alternative when the vendor misses SLA thresholds. It should include vendor assistance, access to configuration, and reimbursement for reasonable switch costs.
Should I rely solely on my own monitoring?
No. Use both vendor reports and independent checks. Vendor data is necessary for credits; your checks detect failures early and provide evidence in disputes.
When should I accept lower uptime for a lower price?
Accept lower uptime only if the price difference funds a backup plan you control or if the flow's failure cost is lower than the savings. Always exchange uptime reductions for stronger portability or mitigation terms.
Stop paying salary for robotic work
Bring your messiest process to a 15-minute audit and we will map where the hours actually go, live on screen. You leave with the number whether or not you work with me.