Skip to content

Stage briefs — CLOSE (Proposal & SOW → Contract)

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

Assets in this file: PA10–PA16. These turn a completed Discovery Audit into a signed engagement. The proposal must feel like the natural conclusion of the audit — reuse its visual language so the client experiences one continuous story from "here's your gap" to "here's the fix, scoped and priced."

PA10 — Proposal / SOW documents (Quick-Win / Baseline / Advanced) ⭐

  • Stage: 4 Proposal & close — the document that gets signed (or gets forwarded to whoever signs).
  • Audience: the economic buyer (founder/CTO) plus any technical evaluator; sometimes finance/legal.
  • Job-to-be-done: convert audit findings into a scoped, priced, credible proposal that makes saying "yes" easy and low-risk.
  • Format & spec: three multi-page PDF templates (A4 + Letter), one per package tier — Quick-Win, Baseline, Advanced — each with editable fields (client name, scope specifics, pricing, dates). Must render cleanly from the existing markdown templates.
  • Source content: Y6-proposal-sow/ — quickwin-proposal.template.md, baseline-proposal.template.md, advanced-proposal.template.md. Structure & content already written.
  • Content outline (typical proposal): cover (Confidential — prepared for ⟨Client⟩) · context & the problem in their words (from the audit) · scope of work (assets delivered, mapped to their findings) · what's explicitly out of scope · timeline / milestones · commercials (fixed project fee + monthly retainer — placeholders, not baked numbers) · assumptions & prerequisites · the SnowOps difference (short) · acceptance / next steps / signature block.
  • Design direction: professional, confident, senior. Reuse the audit report's (PA08) visual language — same cover pattern, finding-chips where findings are referenced, same type and color — so the proposal reads as the audit's sequel. Clear pricing table. Editable-field convention obvious to whoever fills it in. Signature-ready.
  • Priority: P0 · Depends on: PA00, ideally PA08 (visual continuity). · State: 🟨 (content ready)

PA11 — Findings-to-roadmap document

  • Stage: 4 Proposal (the bridge asset between the audit and the proposal).
  • Audience: the technical buyer who wants to see the explicit line from "audit finding" to "the fix, sequenced."
  • Job-to-be-done: translate the raw audit findings into a prioritized remediation roadmap — making the proposal's scope feel derived from evidence, not upsold.
  • Format & spec: multi-page PDF (can also be an appendix to PA10).
  • Source content: findings-to-roadmap.template.md.
  • Content outline: findings grouped by severity/domain → mapped remediation asset → effort/impact → phase (Quick-Win / Baseline / Advanced). A visual roadmap (phased timeline) is the hero.
  • Design direction: a clean phased roadmap graphic (now → weeks → later) plus a findings→fix table using the semantic trio. Reuse PA08 chips. This is a diagram-forward asset — make the roadmap visual genuinely good.
  • Priority: P1 · Depends on: PA00, PA08. · State: 🟨 (content ready)

PA12 — Compliance coverage matrix

  • Stage: 4 Proposal (also slide 9 of the capabilities deck, PA06).
  • Audience: technical buyer and their compliance/security stakeholder — the person who asks "which controls do you actually cover?"
  • Job-to-be-done: honestly show how SnowOps assets map to SOC 2 CC / ISO 27001 Annex A / HIPAA / CIS Azure — with real coverage percentages and process-controls honestly excluded.
  • Format & spec: infographic + 1–2 page reference (PDF), and a compact summary table version sized for a slide (for PA06 slide 9).
  • Source content: Y7-compliance-coverage-matrix.md. ⚠️ Nidhi-gated — coverage claims must be exact; process controls SnowOps does not cover must be visibly excluded, not glossed.
  • Content outline: framework → control family → SnowOps coverage (covered / partial / process-control-not-covered) → the asset that provides it. Honest % per framework.
  • Design direction: a genuinely useful coverage heatmap/matrix using the semantic trio (covered = green, partial = amber, not-covered/process = neutral gray — not red, since "not covered because it's a human process" isn't a failure). Legend must make the "honest exclusion" explicit. This asset's credibility comes from not claiming 100%.
  • Priority: P1 · Depends on: PA00; Nidhi sign-off. · State: 🟨 (content ready)

PA13 — Reference-architecture blueprints (SaaS / FinTech / HealthTech)

  • Stage: 4 Proposal (also slide 10 of PA06); shown as "here's exactly what we deploy for a company like you."
  • Audience: the technical evaluator — this is the asset that earns engineering respect.
  • Job-to-be-done: show the actual target-state platform architecture as a clean, credible diagram + bill-of-materials, tailored to the client's vertical.
  • Format & spec: three blueprint sheets (diagram + BOM), PDF + high-res image for deck/embed. One per vertical.
  • Source content: z/Z1-saas-reference-platform.md, Z2-fintech-reference-platform.md, Z3-healthcare-reference-platform.md, and the framework in Z0-framework.md.
  • Content outline: the reference architecture diagram (network, identity, workloads, CI/CD, monitoring, evidence) + a bill-of-materials table of the modules deployed + which controls each satisfies.
  • ⚠️ Compliance-claim caution: Z2/Z3 (FinTech/HealthTech) include roadmap controls — tag them (roadmap) on the diagram and BOM. Nidhi-gated.
  • Design direction: the definitive SnowOps architecture diagram style (see brand system §5) — this sets the diagram language reused in audits, handovers, and the deck. Azure service iconography where accurate, brand blue for emphasis, mono labels, semantic colors only for status. Harmonize with the V2 (apps/diagram-generator) d2lang/SVG output so generated client diagrams match.
  • Priority: P1 · Depends on: PA00. · State: 🟨 (content ready)

PA14 — Pricing & packaging sheet

  • Stage: 4 Proposal (and PA06 slide 11).
  • Audience: the economic buyer.
  • Job-to-be-done: present the expansion ladder and the fixed-price + retainer model clearly, so pricing feels productized and predictable (not consulting T&M).
  • Format & spec: 1–2 page PDF + a slide version.
  • Source content: Y2-pricing-packaging.md and CLAUDE.md §3.8.
  • ⚠️ Numbers caution: the pricing structure is final but the figures are placeholders until Sagar finalizes against first deals. Design with editable price fields; do not hard-bake dollar amounts into a reusable master.
  • Content outline: the four offers (Discovery Audit free → Quick-Win → Baseline → Advanced) as an ascending ladder, each with what's included, shape (fixed project + retainer), and gate factors; the retainer emphasized as the ongoing engine.
  • Design direction: a clean tiered/ladder layout (think SaaS pricing table, but consultative). Make the progression visual. "Free Discovery Audit" anchors the left as the entry.
  • Priority: P1 · Depends on: PA00. · State: 🟨 (content ready)

PA15 — Case study

  • Stage: 4 Proposal (proof); also referenced in PA06 (slide 7) and PA01.
  • Audience: a prospect looking for evidence that SnowOps has done this before.
  • Job-to-be-done: tell a concrete, credible before→after story (problem, what SnowOps did, outcome/metrics) that de-risks the buying decision.
  • Format & spec: 2-page PDF template (+ web version), reusable per client.
  • Source content: case-study.template.md.
  • Content outline: client context (anonymized if needed) · the trigger/problem · what SnowOps delivered (assets, timeline) · outcome & metrics (deal unblocked, time-to-questionnaire, controls covered) · a pull-quote.
  • Design direction: clean editorial layout, big pull-quote and metric callouts, a small architecture or before/after visual. Until a real first client is public, this template runs on the sanitized sample — mark clearly if illustrative.
  • Priority: P1 · Depends on: PA00. · State: 🟨 (content ready; awaiting first real client)

PA16 — Contract pack (MSA / DPA / NDA / SOW / cloud-access authorization)

  • Stage: 5 Contract — the paperwork that formally starts the engagement.
  • Audience: the client's founder/ops/legal.
  • Job-to-be-done: provide professional, branded, consistent legal document templates so contracting is smooth and signals a serious operation (and reinforces the read-only, least-privilege, no-lock-in posture SnowOps sells).
  • Format & spec: branded document templates for each of: MSA, DPA, mutual NDA, SOW, and the cloud-access authorization. Delivered as designed, fill-in-the-fields documents (DOCX/PDF). These are legal documents — design is a light, consistent letterhead/typographic treatment, not creative layout.
  • Source content: Y12-contract-pack/ — msa-skeleton.md, dpa-skeleton.md, mutual-nda-skeleton.md, sow-skeleton.md, cloud-access-authorization.md.
  • ⚠️ Legal caution: these are skeletons pending counsel review (Y12 owner: Counsel). Do not alter legal wording. The design task is strictly presentation: cover page, letterhead, consistent typography, section numbering, signature blocks, footer with page numbers and confidentiality line.
  • Design direction: restrained, formal, uses the document master's most conservative variant. Consistent across all five so a client receives one coherent pack. The cloud-access-authorization is the one clients read most carefully (it defines exactly what access SnowOps gets) — make it especially clear and reassuring: scope, read-only/least-privilege, time-box, revocation.
  • Priority: P1 · Depends on: PA00; counsel sign-off on wording before any client use. · State: 🟨 (content ready; pending counsel)

Stage-2 sequencing note

Produce PA10 first (it's what gets signed), then PA14 + PA12 + PA13 (they're embedded in both the proposal and the deck, so they pay off twice), then PA11/PA15, then PA16 once counsel clears the wording. Everything here should reuse PA08's visual language for continuity from audit → proposal.