Agency rollout checklist for in-scope WooCommerce consumer-goods journeys

Define responsibility per client

First record how the client assessed the product, buyer, transaction, target market and applicable national law, and identify only the consumer-goods journeys determined to be within scope. Then record the client’s legal reviewer, technical approver, supported storefronts and deployment owner. Keep each client’s source and screenshot record separate. An agency licence seat is a software allowance, not delegated legal approval.

Pair staging deliberately

Associate one development or staging identity with each production domain. Normalise apex and www as the same production site, but do not let arbitrary staging domains become free production seats. Record transfer approvals and cooldown overrides.

Standardise without hiding variation

Use a common checklist for official files, language mapping, classic versus Blocks, mobile review, QR scanning and accessibility. Add client-specific rows for themes, checkout extensions and multilingual plugins. Preserve evidence after handoff and schedule source reviews.

Provide the client with product documentation, privacy payloads, rollback steps and a clear statement that Notice27 is independent implementation software rather than legal advice or EU certification.

At handoff, name the person who owns plugin updates and source monitoring. Record the installed version and checksum, keep the paid ZIP private, and verify that removing agency access does not remove the client’s implementation evidence.

Run a client-level release gate

A portfolio dashboard should not reduce evidence to a single green status. For each client, record the official source access date, file checksum, Notice27 version, WordPress and WooCommerce versions, active theme, cart/checkout mode, storefront languages, reviewed placements and rollback owner. Keep screenshots and approval records in the client’s own retention boundary.

Schedule the rollout in waves. Start with one representative low-risk staging store, refine the matrix, then move through clients with similar templates. A failure on one client should pause only the affected cohort. Never solve rollout pressure by changing payment configuration, disabling checkout validation or testing with real customer data.

Give every wave an exit criterion: approved source file, clean staging journey, zero serious or critical accessibility findings, no console or first-party request failure, documented unsupported surfaces and a rehearsed rollback. A calendar date alone is not an exit criterion.

• No client moves to production without an identified rollback owner.
• No WPML or Polylang claim without that client’s actual package test.
• No shared credential, customer export or paid ZIP in general project notes.
• No stable 1.2 handoff that promises private 2.0 licensing features.

Handoff is part of the implementation

Give the client the installed version, checksum, supported-placement list, known gaps, language-resolution choice, retest triggers and source-review date. Explain where evidence is stored and who can request support without exposing store credentials.

The Agency plan shown on the Notice27 site is a private 2.0 preview and is not publicly available. This operational checklist is useful regardless of purchasing model and does not imply that a multi-site licence, trial or customer portal is active today.

Close access cleanly when the engagement ends. Remove temporary staging users and tunnels, transfer the evidence record through the client’s approved channel, and retain only the minimum agency record required by contract. Do not leave reusable credentials, exports or customer data in a generic rollout workspace.

Ask the client to acknowledge the known gaps, including unsupported stable surfaces and unverified extension combinations. That acknowledgement is not a waiver or legal approval; it is a practical record that the technical handoff did not silently expand the tested scope.