Skip to content

Stage briefs — RETAIN / EXPAND → OFFBOARD → Credibility

Before designing any asset here, read ../00-business-primer.md and ../01-brand-system.md.

Assets in this file: PA22–PA27. This is where the money is made twice. SnowOps's durable revenue is the monthly retainer, and expansion (Baseline → Advanced) is the growth lever. For an automation MSP the danger is that value becomes invisible — the platform quietly works, so the client wonders what they're paying for. These assets make invisible value visible, which drives renewal and upsell. Then a clean offboarding proves the "no lock-in" promise (which paradoxically improves retention and referrals).

PA22 — Client Cloud Posture Report (QBR) ⭐

  • Stage: 8 Retention & expansion — the flagship recurring touch (quarterly business review + ad-hoc retention/upsell).
  • Audience: the client's founder/CTO (exec-facing summary) and their engineers (detail). Often forwarded to their board.
  • Job-to-be-done: make everything SnowOps runs on the retainer — guardrails, backups, DR drills, incident handling, compliance work — visible, in the client's language, organized by deliverable; and tee up the upsell to Advanced.
  • Format & spec: multi-page report, self-contained HTML (safe to attach) + PDF. Generated by apps/posture-report/ (asset V5) — the design job is the report theme/template the generator renders into (it composes several tool outputs). See the delivery guide docs/client-guides/qbr-posture-report.md.
  • Source content / data model (each section lights up from a real tool output, degrades honestly when an input is absent): | Section | Fed by | |---|---| | Your guardrails + overall grade | E0 compliance snapshot (apps/evidence-collector) | | Your compliance posture (Advanced) | S2 dashboard model (apps/compliance-dashboard) | | Executive-summary grade | S4 scorecard model | | Your data is protected (RTO/RPO, DR drills) | L5 RTO/RPO model | | Architecture | V2 diagram (see PA20) | | Incidents we handled (Advanced) | K4 PIR report | | Cost governance | roadmap — states "not yet wired," never fabricates a figure |
  • Content outline: cover (Confidential — prepared for ⟨Client⟩, period) · executive summary with an overall grade (lead the QBR with this) · Baseline sections = "what's already protected" (guardrails, data protection, architecture) · Advanced sections (compliance posture, incidents) · "What else SnowOps can light up" — upsell teasers for any Advanced section the client isn't on yet.
  • Design direction: exec-readable at the top (a big, clear grade/score and a status grid), engineer-readable below. Reuse the audit report (PA08) and dashboard (PA24) visual language — same semantic trio, same chips — so a client sees one coherent SnowOps world from first audit to every QBR. The upsell teasers must be visually distinct but honest — clearly "available on Advanced," never implying it's already active. Confidentiality treatment throughout (this is real posture data). Must render well from generated content of variable completeness.
  • Priority: P0 (retention/expansion depend on it) · Depends on: PA00, PA08 (shared language); coordinate with apps/posture-report. · State: 🟨 (tool exists; needs a designed theme)

PA23 — Client Overview dashboard (live)

  • Stage: 8 Retention (live companion to the periodic PA22 report).
  • Audience: clients who want real-time visibility between QBRs.
  • Job-to-be-done: give the client an always-on, at-a-glance view of their platform's posture, backups, and compliance status.
  • Format & spec: a themed Grafana dashboard (J8 — a client-facing tier extending the internal J5 Grafana dashboards-as-code). The design job is a Grafana theme + panel/layout design aligned to the brand, plus guidance on which panels a client should see (curated, exec-friendly — not the full internal ops view).
  • Source content: J8 (roadmap — see CLAUDE.md "Client-Facing Posture Visibility" plan) building on J5 (modules/azure grafana-dashboards).
  • Design direction: brand-themed Grafana — semantic trio for status, restrained panel design, exec-friendly labels (not raw metric names). Consistent with PA22 and PA24. This is roadmap (J8 not yet built) — the brief exists so design is ready when the tool ships; don't produce final assets until J8 exists.
  • Priority: P2 · Depends on: PA00, J8 shipping. · State: — (roadmap)

PA24 — Compliance dashboard (S2)

  • Stage: 8 Retention (and a delivery artifact for Baseline/Advanced clients).
  • Audience: the client's team tracking compliance posture over time.
  • Job-to-be-done: show compliance posture history and current state as a clean web dashboard the client trusts and enjoys reading.
  • Format & spec: a web-app theme for apps/compliance-dashboard/ (S2 — turns E0 snapshot history into a dashboard, incl. an L4 DR panel). Design job: the dashboard's visual theme (colors, typography, chart style, layout), applied to the existing app.
  • Source content: apps/compliance-dashboard/ (S2).
  • Design direction: follow the repo's data-viz conventions and the brand semantic trio. Trend lines for posture over time, a clear current-grade hero, DR panel. Consistent with PA22/PA23 so all three "posture surfaces" feel like one product. Light + dark.
  • Priority: P2 · Depends on: PA00. · State: 🟨 (app exists; needs themed styling)

PA25 — Expansion / upsell one-pager

  • Stage: 8 Expansion (Baseline → Advanced).
  • Audience: an existing Baseline client who could benefit from Advanced (formal evidence automation, SIEM, vendor/HR controls, trust center).
  • Job-to-be-done: make the case for expanding to Advanced concrete and low-friction — "here's what lights up when you move up."
  • Format & spec: one-page PDF in the PA04 one-pager family.
  • Source content: Y11-cs-expansion.md and the "what else SnowOps can light up" teasers from PA22 / qbr-posture-report.md.
  • Design direction: same one-pager system as PA04/PA05; frame as a progression from what they already have (show the delta, not a from-scratch pitch). Reuse the pricing-ladder visual (PA14) to anchor "you're here → Advanced is the next rung."
  • Priority: P2 · Depends on: PA00, PA04, PA14. · State: ⬜

PA26 — Offboarding / exit pack

  • Stage: 9 Offboarding — a clean, professional exit or handover to the client's own team.
  • Audience: the client's team taking over (or a client winding down the engagement).
  • Job-to-be-done: prove the "code you own, no lock-in" promise with a graceful, complete handover — which protects reputation, earns referrals, and often prevents churn (clients renew when they know they can leave easily).
  • Format & spec: designed multi-page PDF applied to the existing offboarding playbook; same documentation template as PA19.
  • Source content: docs/runbooks/offboarding/ (W4 — Client Offboarding Playbook) and the L3 DR runbook templates.
  • Content outline: what the client owns and where it lives (git repos, modules, docs) · how to operate without SnowOps · how to revoke SnowOps's access (step-by-step) · knowledge-transfer checklist · a clean terraform destroy / removal path where applicable · a warm "door's open" close.
  • Design direction: professional and generous in tone — the last impression matters. Reuse the PA19 documentation template. Make the access-revocation section especially clear (mirrors the reassurance from PA18/PA16 — the access story bookends the whole relationship).
  • Priority: P2 · Depends on: PA00, PA19. · State: 🟨 (content ready)

PA27 — Trust-center page (public credibility)

  • Stage: Cross-cutting (supports prospecting, close, and retention).
  • Audience: any prospect or client doing due diligence on SnowOps itself ("can we trust them with our cloud?").
  • Job-to-be-done: publicly demonstrate that SnowOps practices what it sells — its own security posture, sub-processors, data handling, and how it accesses client environments.
  • Format & spec: a public web page (part of PA01's site). Self-contained, credible, not over-designed.
  • Source content: trust-center/ (currently a placeholder) — content to be written by SnowOps (Nidhi-owned, since it makes claims about SnowOps's own controls).
  • Design direction: clean, factual, "we eat our own cooking." Sections: how SnowOps accesses client tenants (read-only, least-privilege, time-boxed, revocable — the same story it sells), sub-processors, data handling, security practices. Nidhi-gated (public claims about SnowOps's own posture).
  • Priority: P2 · Depends on: PA00, PA01; content authored + Nidhi sign-off. · State: ⬜ (content not yet written)

Stage-4 sequencing note

PA22 (QBR posture report) is the P0 here — it is the retention/expansion engine and should be produced right after the sales cluster. PA24 and PA23 are its live companions (reuse its language). PA25 rides on the one-pager and pricing systems. PA26 rides on the PA19 docs template. PA27 waits on written content. The through-line: the "access story" (read-only, least-privilege, revocable) appears at PA08 → PA16 → PA18 → PA26 → PA27 — design it once and echo it at every touchpoint; it's SnowOps's core trust signal.