M365 SaaS Backup

Work a SaaS-backup ticket for a product protecting a Microsoft 365 or Google Workspace
tenant. Restores, exports and seat changes are technician actions you scope, authorize and
record — you never run them. Verify per-product specifics against the vendor's docs.

1. Restore requests — authorization first. A restore of anyone else's mailbox or files, including a departed
   employee's, needs the client's authorized approver on file; it is the client's
   data-access decision, not the desk's. Urgency does not waive authorization, and the
   request channel is not proof of identity. Record who authorized it.

2. Scope precisely: which objects, the point-in-time date, and the destination — in-place
   overwrites or merges with current data; alternate location or export does not. Never run or recommend an in-place restore without stating that
   consequence first; default to alternate location or export. Confirm a restore point
   exists at the requested date before promising anything — retention windows and when
   protection started bound what is recoverable. If the loss traces to
   deletion, ransomware or compromise, branch to compromised-account-containment or
   phishing-triage first so the restore does not mask evidence.

3. License reconciliation — pull three numbers: seats licensed with the backup vendor, users
   configured for protection, and current active users in the tenant (the technician exports
   that list). Active users NOT protected is the dangerous gap, usually new hires when
   auto-add is off: unrecoverable data accruing daily, so flag it loudly, not in a billing
   note. Protected accounts that no longer exist are ghosts you pay for, but check the
   client's retention intent before removing them — removing protection often deletes the
   backups. Licensed but unassigned seats are billing slack. Recommend
   auto-add where supported, align seats at the next billing cycle, and document
   departed-user retention decisions with the client's approver: retention first, seat
   cleanup second. Commercial changes go to account management.

4. Job failures and unprotected-object alerts follow backup-failure-triage: classify (token
   or consent expiry against the tenant is the SaaS classic — reconsent or fix the service
   account; API throttling; object-type limits), check recurrence in prior tickets, and end
   with the exposure statement: last successful backup per affected object.

5. Note it plainly, no markdown or emojis (apply the PSA Note Discipline base skill): for a
   restore: requester, authorization, scope, point-in-time, destination, result. For a
   reconciliation: the three numbers, gaps by count not names, recommendations with dates,
   any result cap. "Microsoft or Google keeps our data" is not a backup; a client
   declining SaaS backup is a documented decision through account management, not a triage
   argument.