Demo Environment & Sandbox Setup Checklist

A broken sandbox doesn't just cost one demo — it costs credibility for every rep who uses that environment after the story gets around internally. This checklist is for whoever owns the demo environment (RevOps, Enablement, or a rotating rep-champion) to build it right once and keep it right on an ongoing basis.

Section A — Data & Content Hygiene

• All sample data is fictional or explicitly licensed/anonymized — no real customer data in any demo org
• Company/contact names in the sandbox sound plausible, not jokey (buyers notice "Wile E. Coyote Inc.")
• Dashboards and reports show realistic, varied numbers — not all zeros, not all round numbers, not all suspiciously perfect
• No leftover test junk visible (broken records, "test test 123" entries, duplicate accounts)
• Content dates are current or clearly forward-dated — nothing showing "last synced: 14 months ago"

Section B — Persona / Use-Case / Vertical Coverage

• At least one sandbox variant per major buyer persona the team sells to
• At least one sandbox variant per top 3 verticals/segments in the pipeline
• Each variant has industry-plausible terminology, not generic placeholder labels
• A documented map exists of "which sandbox variant for which buyer type" so reps aren't guessing or building their own

Section C — Technical Reliability & Failover

• Sandbox environment is isolated from production — a demo action can never affect a real customer
• A recorded backup video exists for every major demo flow, dated and version-tagged, for use if the live environment fails
• Login credentials are tested and confirmed working on a rolling weekly basis, not just at setup
• Known flaky features/integrations are documented with a workaround or an instruction to avoid them live
• Environment has been tested on the actual network/device conditions reps demo from (VPN, conference wifi, etc.), not just office wifi

Section D — Access & Governance

• Access to sandbox admin settings is restricted to a named owner — reps get demo-user access, not admin access
• A change log exists for any structural change to the sandbox (new fields, new flows) so reps aren't surprised mid-demo
• Departing employees' sandbox access is revoked as part of offboarding, not forgotten
• There's a single source of truth for "which sandbox is current" — no orphaned old copies still in circulation on someone's bookmarks

Section E — Refresh Cadence & Ownership

• Named owner assigned (not "the team," an actual person) with the sandbox as an explicit responsibility, not a side task
• Refresh cadence documented and calendared (recommended: full data refresh monthly, feature/UI parity check bi-weekly against production)
• Process exists for reps to flag sandbox issues (a channel, a form, an inbox) with an SLA for fixes
• New feature releases trigger a sandbox update task automatically, not "whenever someone remembers"

Section F — Day-of Pre-Demo Verification (rep's own 5-minute check)

• Logged in and confirmed environment loads within normal time, 15+ minutes before the call
• Confirmed the specific flow/feature planned for today's demo is working, not just "the environment is up"
• Backup recording pulled up and ready in a second tab
• Screen share tested (correct window/tab, notifications silenced, bookmarks bar hidden)
• Internet connection confirmed stable (hardwired or strong wifi, not mobile hotspot as primary)

If It Breaks Live — Incident Steps

1. Acknowledge it plainly and briefly: "That's a sandbox hiccup on my end, not something your team would ever see — one second."
2. Switch to the backup recording for that specific flow rather than trying to debug live on screen.
3. Note the break in the post-demo debrief and flag it to the sandbox owner same day — silent workarounds mean the same break happens to the next rep.
4. Never blame the product live, even if it's tempting for rapport — the sandbox failing is an internal ops issue, not a product limitation, and buyers shouldn't leave thinking otherwise.

Ownership RACI Template