Run launch week as a coordinated release and support period. Verify the published Experience, physical installation and approved destinations, then assign exceptions to the right owner. Review early recorded activity with trading and deployment context. A scan or Session can add evidence of use, but does not replace a physical check or establish a sale.
Set up one launch-week control point
Assign a lead who can bring together account, publishing, field, technical and data owners. Keep the approved store list, range map, current version and support contacts accessible. Agree how urgent errors are raised and who can pause or correct the affected Experience.
The runbook below is a suggested operating rhythm. Adapt it to actual trading days, release conditions and support coverage rather than treating each day as a fixed Retailer requirement.
Use this launch-week runbook
| Window | Main action | Evidence to record | Owner to assign | | --- | --- | --- | --- | | Before opening or release | Verify live state and embargo transition | Published version and exact destinations | Release owner | | First trading day | Check representative installations and incoming data | Physical evidence, route tests and defined Events | Field and data owners | | Early follow-up | Investigate missing or unexpected signals | Precise observation and diagnostic checks | Support owner | | Before the next busy period | Correct confirmed content or operational issues | Approved change and verification | Experience and technical owners | | Through peak trading | Maintain support and colleague guidance | Issue updates and store feedback | Operations owner | | End of first review window | Share status and next actions | Scope, definitions, unresolved issues and useful observations | Launch lead |
Verify three different things
First, confirm the Experience: the right version, Product facts, language and destination. Second, confirm physical deployment using the agreed evidence, including placement and accessibility. Third, check recorded activity and any Device communication available.
Do not collapse these into one “live” percentage without a definition. A Device may communicate while poorly placed; a printed code may record no use despite being correctly installed. Investigate the actual observation before assigning the cause.
Keep the issue log actionable
| Location and version | Observation | Diagnostic evidence | Action and owner | Verification or next review | | --- | --- | --- | --- | --- | | Enter scope | State what was observed | Record checks, not assumptions | Assign responsible team | Record outcome and time |
Use the agreed support process for hardware and installation problems. Store colleagues should only perform authorised checks. For destination or Product errors, identify all affected variants before publishing a correction.
Learn without overreacting to the first sample
Look for broken paths, repeated no-match outcomes and clear usability problems. A small number of Sessions can expose a fault but may not establish a stable preference. Avoid rearranging the whole journey each day in response to sparse counts.
When changing content, record the reason, approval and publication time. Test the correction on actual Touchpoints and retain a recovery version. Keep urgent factual fixes separate from experiments intended to improve navigation.
Share a useful week-one readout
Report planned and verified deployment scope, outstanding operational issues, supported activity by format and questions worth investigating. Include exact definitions and the observation period. Show stock, promotions or store differences that affect interpretation.
Agree what happens next: resolve an installation issue, improve a confusing answer or continue collecting comparable data. Pair Interaction reporting with Retailer sales later where available, without claiming a direct causal link from early clicks.
Launch-week checklist
- Release, destinations and current version verified
- Physical checks and analytics reviewed separately
- Every exception has an owner and follow-up
- Store teams have a usable reference and support route
- Changes are approved, logged and retested
- First readout states evidence, limits and next actions
Support the Experience through launch week
MyPlayer’s platform and Interaction reporting can form part of a coordinated launch process. Agree the actual support and reporting responsibilities before release. Discuss launch-week delivery.
Frequently Asked Questions
What should we check on launch morning?
Verify the published state, Product and Retailer destinations, representative physical installations and the actual reporting setup. Confirm the support team knows the released version.
Should zero-activity stores receive an immediate field visit?
Triage the observation first using scope, tracking, status and current field evidence. Assign a visit where it is the appropriate next diagnostic or corrective action.
Can the first few days show which model will sell best?
Early Interactions show what participants explored. They do not establish a stable sales forecast or demonstrate that one model caused a purchase. ## Related guides - [Use the store diagnostic matrix](/guides/tracking-and-measurement/how-to-spot-and-fix-dark-stores-using-live-engagement-signals) - [Control content corrections](/guides/content-and-experience/how-to-update-launch-content-after-day-one) - [Manage the following weeks](/guides/product-launches/what-to-do-in-the-first-30-days-after-an-in-store-product-launch)
Ready to transform your physical retail experience?
Join the brands driving deeper engagement and measurable ROI at the shelf edge.
Discuss Your Strategy