Today the client portal's Backups tab already ends in a dead-end "Request a restore" link with no context attached. This prototype fills that gap: the customer picks the exact backup and scope they want, an operator gets full context to safely execute it, and both sides track the same request to completion. Nothing here is self-service for production — a human still approves and runs every restore, matching the product's existing "carried out by our team" copy.
Instead of a blind "Request a restore" button, the Backups tab lists every available backup (automated + manual) so the customer picks the point in time they need, not just guesses.
Open: Backups tab →Target environment (staging recommended first), scope (files / database / both), and a short note on what went wrong — sent straight to the ops queue with no separate support ticket to fill in.
Open: New restore request →The restore shows up in Support requests with a status and a timeline, so the customer isn't left wondering if anything happened.
Open: Support requests list → · Open: Request detail →Same Client Requests screen operators already use — now populated with a real "Restore" type instead of the untyped placeholder rows.
Open: Client Requests queue →Full context: which backup, what's changed on the live site since then, and an explicit typed confirmation before the restore is allowed to start — this is the one irreversible step in the whole flow.
Open: Restore request detail →Reuses the existing Jobs concept from the ops dashboard so a restore is observable and retryable the same way a failed backup already is.
Open: Jobs queue →