Self-checkoutHow-to guide
Is a supervised self-checkout pilot right for your store?
A supervised self-checkout pilot is a way to test a specific shopping journey, not simply to add another payment screen. For a small store, the useful decision is whether one well-supported lane helps customers complete suitable purchases and helps staff resolve exceptions. Define that journey and its boundaries before deciding how many lanes or devices to buy.
Choose the shopping journey the pilot will serve
Observe basket sizes, product types and the questions customers ask at the staffed checkout. Select a journey that can be explained clearly and supported by the equipment under consideration. A small basket of labelled goods presents different interaction needs from products requiring additional selection, measurement or staff intervention. The pilot scope should reflect those differences instead of assuming every purchase belongs in the first release.
Write down which transactions remain with a staffed cashier and how customers find that route. Clear boundaries make the pilot easier to operate and evaluate. Include the people who greet shoppers, maintain product data and resolve pricing questions in the planning conversation. Their work determines whether the lane feels straightforward when the interface encounters something outside its ordinary path.
Plan supervision as part of the service
Identify who responds when a shopper needs help and how that person learns which lane is waiting. Supervision is a workflow with its own capacity, permissions and priorities. A staff member already handling another customer cannot also provide immediate attention everywhere, so observe the actual workload before choosing the number of lanes they will support.
Define the interventions the supervisor may perform and the cases requiring another authority. A price question, an uncertain payment and a device fault are not interchangeable. The shopper should see that help has been requested, while the supervisor receives enough context to prepare a response. Test the walk between the service position and the lane, including busy periods and the need to keep customer information from being visible to unrelated shoppers.
Make the physical sequence understandable
Arrange scanning, bagging, payment and receipt collection around the way a person moves with their goods. Text instructions cannot compensate for a confusing physical layout. Test reach, screen readability, reflections, sound and the space available for a basket or mobility aid. The interface should offer a clear way to correct an accidental scan or ask for assistance without requiring the customer to restart.
Use consistent feedback for an accepted item, an action awaiting confirmation and a request for help. Avoid relying on colour alone. Show the basket and total in a way that lets the shopper check what was entered before payment. When the system pauses, explain the next step using ordinary language instead of exposing technical errors or silently leaving the person at an unresponsive screen.
Confirm the equipment and transaction boundaries
The pilot must use the actual payment and fiscal arrangements agreed for the store. Confirm device models, supported interfaces and supplier responsibilities before treating the software flow as complete. Keep card collection within the approved provider environment and design the application around transaction references and confirmed outcomes. A working visual prototype does not establish compatibility with every terminal or fiscal device.
Create a readiness checklist for the limited lane. Review it with the store operator and relevant providers so everyone agrees what will be exercised, what evidence proves completion and who handles an interrupted step. Include recovery and supervision, not only the normal purchase sequence.
- Confirm the product group and transaction types included in the pilot.
- Verify item identifiers, prices and permitted quantity changes.
- Assign a supervisor and define their allowed interventions.
- Confirm payment and fiscal-device interfaces with their providers.
- Rehearse an interrupted transaction and the staffed alternative.
Measure completion and intervention without predicting savings
Record how many suitable shopping journeys begin and complete, where people request help and what staff must do to resolve each case. Distinguish product-data problems from interaction problems and equipment failures. A high intervention count can have several causes; the reason matters more than the headline number when deciding what to improve.
Measure waiting for assistance as well as time spent at the lane. Include abandoned journeys and purchases transferred to a staffed checkout. Observe whether the shopper understands the final payment and receipt state before leaving. These measures help the store judge the pilot using its own customers and staffing conditions. They should not be turned into promised labour savings or revenue gains before the process has been evaluated in operation.
Decide expansion from the problems the pilot reveals
Review the pilot with the staff who operated it. Separate issues that need catalogue cleanup, a different screen, provider work or more supervision. Resolve the highest-impact causes and repeat the relevant tests before adding more lanes. Expansion should follow an operating model the store can support, including opening checks, device maintenance and a clear incident handoff between shifts.
RDC can design the shopper and supervisor interfaces and connect them to stock, payment status and receipt handling. Scope EU-hosted or company-managed services alongside local equipment, store connectivity, access controls and support ownership. Agree licence costs and responsibility for updates before committing to a wider rollout. Bring a typical basket mix, store layout and the current checkout process to the discussion; these determine whether a supervised pilot is a sensible next step for your store.
Inside the product
Self-checkout
Follow the references
Sources & inspiration
goCart
Devpost project by Raj Bhanushali, Tarun Sreedhar, avallabhani, Vishal Vinjapuri, Ryan Gomes
Independent inspiration for workflow design.
This independently created project is credited as inspiration. The workflow and implementation guidance in this article are RDC’s analysis.
Put the guide to work
Start with your workflow.
Tell us what your team needs to do, which systems are involved and where the current process slows down.

