Rolling out technology across stores

Roll store technology out in controlled waves. Use a pilot to learn which store conditions matter, check each location before installation, and release the next wave only when the intended task works and the team can support it. A successful pilot does not prove every store is ready.

Define what must work

Write down the customer or staff task the technology must support. For a stock lookup, that could mean giving a shopper an answer for the correct variant and knowing what to do when the record disagrees with the shelf. Identify the systems, devices, information and people needed to complete it.

Set an acceptance check for an ordinary case, a likely exception and loss of service. A device that reports online is useful technical information, but it does not show staff can finish the task.

Agree the actual acceptance rules with the retailer and supplier before installation.

Acceptance Criteria for Technology Rollout

Govern the change across the estate

Set out the desired outcome, the reasons for the change and its expected benefits in a rollout plan. List the work to be done, name the person responsible for each task, and define measurable goals, targets or milestones so progress can be checked across stores.

Tell staff about the change as early as possible, with leaders explaining the reasons, process and end goal. Give colleagues a way to ask questions and share concerns, and communicate regularly through channels that reach different staff groups.

Involve store colleagues in planning and design by inviting suggestions and concerns about the change process. Allow time for people to process its impact; productivity might drop during a change period, so avoid treating an early slowdown alone as proof that the technology or rollout has failed.

Carry pilot limits into the rollout plan

For detailed pilot-location selection, see the supporting article. Record what the pilot tested and what it did not, and carry those limits into the rollout plan.

Keep results tied to the configuration used; for detailed hardware variation planning, see the supporting article.

Set gates between deployment groups

Treat each wave as a defined group of stores moving through a shared timeline. A deployment group (sometimes called a ring) is a group of stores or devices that receive the change concurrently, with criteria set for deferral or completion before deployment advances to the next, broader group.

There is no fixed number or naming scheme for deployment groups. One example is Preview, Limited and Broad; choose groups that suit the rollout, and set the evidence required at each gate before the next group proceeds.

Use operational needs to shape the sequence: mission-critical sites can sit in their own group, while a large estate might group stores by geography or group size to make helpdesk resources more available. Record the advance criteria before a wave starts, then use the agreed checks to decide whether it can move forward or should pause.

Prepare each location

Confirm the proposed equipment position, power, connection, mounting and maintenance access. Check permissions, data handling and any customer access needs relevant to the task. Match delivered equipment to the approved site plan, and give installers a contact who can approve a change when conditions differ.

For detailed staff-training design, see the supporting article; store readiness checks should confirm that the required training is complete before launch.

Make a store-level decision to launch, launch with an approved limitation or hold. An approved limitation must say which task remains available, what staff should do, who owns the gap and when it will be reviewed. Hold a store when a critical task or its safe alternative cannot be supported.

Release waves at a manageable pace

Group stores for an operational reason, such as a shared layout or installation method, and inspect the result before starting the next group. There is no universal wave size. Set the pace from installation capacity, training coverage, support capacity and the time needed to correct a defect that may affect other sites.

Keep a central view of each store's state and any approved limitation; for detailed central issue-register operation, see the supporting article.

Key Metrics to Track During Rollout

Close on a working service

After launch, have store staff perform the intended task and confirm the exception route. Record task failures separately from devices that merely report online. Retest affected stores after a correction.

At each wave review, update installation, training and support instructions. Transfer the final configuration and open issues to the normal store and service owners when rollout work ends. A later performance review can assess whether the technology delivered its intended benefit.