Skip to content

SnowOps Sales & Presentation Layer

Everything sales-, brand-, and GTM-facing for SnowOps, kept in its own repo — separate from the snowops-automation engineering codebase so the sales workstream can be reviewed, edited, and shipped on its own cadence by non-engineers.

It publishes to a gated website (sales.snowops.net) and mirrors finished deliverables to Google Drive. Folder names are numbered for a stable, predictable sort order across GitHub, the website nav, and Drive.

How this is meant to be used (the content model)

Git (this repo) is the single source of truth. Everything else is a published view of it.

You want to… Go to…
Read / browse / search the sales content sales.snowops.net — the rendered site (login required), always current
Comment on / share finished deliverables (PDF, deck, docs) Google Drive — a one-way mirror produced by stage-for-drive.sh
Edit wording The "edit this page" pencil on the site → GitHub web editor (small fixes), or tell Sagar and it goes into the repo

⚠️ Edits made in Google Drive do not flow back and will be overwritten the next time deliverables are re-staged. Drive is for reviewing and sharing, not authoring. If you change something in Drive, tell Sagar so it goes into the repo source.

Structure

Folder Contents
01-business-context/ Company mission & ICP, service packages & pricing tiers. Read this first — the business grounding an AI or a new team member needs before writing any sales asset.
02-brand-and-presentation/ Brand system, logo assets, Office/Drive templates (deck + doc masters), and all client-facing deliverables (one-pagers, capabilities deck, sample audit) organized by sales stage.
03-gtm-sales/ GTM playbook: positioning & messaging, pricing/packaging, target account list, cold outreach kit, discovery script, proposal/SOW pack, compliance coverage matrix, capabilities deck source, case studies, contract pack, CRM pipeline config, reference-architecture one-pagers (z/).
04-client-guides/ Client-facing handover guides used post-sale (onboarding, brownfield adoption, QBR posture reports, quickstart) — sales/CS reuses them in proposals and renewals.

The website (sales.snowops.net)

Built with MkDocs Material and deployed to Cloudflare as a Worker serving static assets — the exact same setup as the engineering docs.snowops.net. It is access-gated — only invited email addresses can open it.

Where this came from

Split out of snowops-automation on 2026-07-17 (decision D66 in that repo's decisions log):

  • docs/presentation/ → 02-brand-and-presentation/
  • docs/gtm/ → 03-gtm-sales/
  • docs/client-guides/ → 04-client-guides/
  • docs/context/{01-company-mission,02-service-packages}.md → 01-business-context/

The asset glossary and asset catalog stayed in snowops-automation — they're the developer's index to the codebase and change when the code does. Sales-side AI can still read them across the sibling folder (../snowops-automation/docs/context/) when it needs the full engineering picture.

Using this with AI tools

Point an AI assistant at 01-business-context/ first for company/product grounding, then the relevant subfolder for the asset you're generating (a proposal → 03-gtm-sales/Y6-proposal-sow/, a one-pager → 02-brand-and-presentation/deliverables/). For the full engineering asset catalog, also give it ../snowops-automation/docs/context/03-asset-catalog.md. Keep brand assets (02-brand-and-presentation/brand/) as the single source of truth for logos, fonts, and templates — don't regenerate these from scratch.