Getting a broken site working again
A customer's website stopped serving after a recent change. Today the client portal shows this as
a quiet grey "Not serving" label with no next step, and the only path back — a restore — is something
only an operator can do, discovered by reading a paragraph on the Backups tab. This proposal makes
that existing path visible at the moment it matters, and gives the operator the one screen they
actually need to act on it safely.
Customer journey — client portal
· handoff ·
Operator journey — ops portal
What's established vs. what's proposed
- Established from the live portals: restores are operator-performed, not self-service; a backup
replaces the web root and keeps the old one so a restore can be undone; backups expire and, once
expired, cannot be restored from even though the record stays listed; a backup job can fail
(an S3 permission error was live on a real environment during this investigation); there is no
existing view of what changed on a site recently.
- Proposed and not built anywhere yet: the alert-style status banner, the guided request
flow, the customer-facing request status/timeline page, and the merged request-detail screen
for operators. These exist only as this prototype.
- Left open: whether "take a backup of the broken site first" should be required or optional
before submitting a restore request, and what a customer is told when the only backups available
have expired. See the note on each relevant screen.
Static prototype. No submit button here calls anything real; states are pre-baked per page.