Design for Degraded Operation
A reliability review covers loss of connectivity, repeated requests, delayed uploads, conflicts, clock drift, unavailable dependencies and partial recovery. The agreed behaviour is validated during acceptance.
Service evaluation
Define the Service Your Operation Actually Needs
Set availability, recovery, maintenance, monitoring, support and escalation requirements from the workflows that matter most to your operation.
Describe the service needTranslate Operational Risk Into Testable Requirements
The assessment should distinguish web availability from offline field work, delayed synchronisation, third-party dependencies and customer-controlled systems. One percentage cannot describe all of those failure modes.
| Requirement area | Customer input | Evidence behind the commitment |
|---|---|---|
| Workflow criticality | Which actions cannot wait, for how long, and what safe fallback exists? | Failure-mode review, dependency map and approved service boundary |
| Data recovery | What loss window is tolerable for each record class and attachment? | Backup coverage, restoration test and record-level reconciliation evidence |
| Service restoration | Which functions must return first and who can declare recovery complete? | Runbook exercise, measured restoration result and accountable owners |
| Maintenance | Which operating windows, time zones and field campaigns constrain changes? | Change process, notice method, rollback test and exclusion wording |
| Support and escalation | Who can raise each severity, through which channel, and with what evidence? | Coverage model, triage exercise, escalation roster and contractual targets |
Renew the Evidence
Recovery and support evidence becomes stale when architecture, providers, staffing or dependencies change. The assurance pack names the evidence date, owner, scope and next review point.