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