A customer's site stopped working after a recent change. This is a proposal for how they, and the operator who helps them, get it working again on CP26 — built from what the client and ops portals can already do, plus what's missing.
The customer never restores anything themselves. What they can do today is take their own manual backup (up to 3, self-service) and file a free-text support request. What only an operator can do is see the platform-level backup history, run a restore, or import a customer-supplied archive when there's no good backup to restore from. So the journey has to be a hand-off: customer describes the problem well enough to act on, operator does the restore, customer finds out it's done. We considered a fully self-service "one-click restore" for the customer, but nothing in either portal exposes a restore action to a customer login, and inventing one would mean claiming a capability we have no evidence for — so this proposal keeps the restore itself operator-executed and focuses on making the hand-off faster and visible.
Steps 1–3 are mostly copy and layout on top of real screens. Step 4's backups table and actions are real. What's not confirmed to exist anywhere is a link between a client request, a backup/restore job, and a customer-visible status — that's the connective tissue the whole journey leans on, and it's called out on step 4's notes panel as the main build item, not a design decision.