A grocery store does not need a robot in the abstract. It needs a particular job done reliably: finding shelf gaps, moving a case, cleaning an aisle or handling products at a checkout. Those jobs demand different machines, software and operating arrangements. Starting with a favorite humanoid and searching for work it can do reverses the useful order.
The practical starting point is a task specification. Describe what should happen, the conditions under which it should happen and who takes over when it cannot. Then compare platforms against that specification. This guide gives retail operations and innovation teams a way to build that shortlist without mistaking an impressive demonstration for a complete store solution.
Start with the result, then select the robot type
Break a broad ambition such as “automate replenishment” into observable steps. Detecting an empty shelf position, locating stock in the backroom, opening a case and placing an individual product are four different capabilities. A system that performs the first step should not be evaluated as though it performs all four.
| Store task | Capabilities to evaluate | Useful completion measure |
|---|---|---|
| Find stock or pricing discrepancies | Navigation, shelf imaging, product recognition, useful staff alerts | Correct, actionable discrepancies found and resolved |
| Clean an accessible floor area | Cleaning equipment, coverage, obstacle handling, docking and daily care | Area cleaned to the agreed standard with total staff time recorded |
| Move cases between defined locations | Payload, load stability, route access, loading and unloading method | Correct deliveries per operating hour, including handovers |
| Manipulate mixed grocery items | Reach, grasping, perception, force control, placement and recovery | Correct item cycles without damage, with assistance measured |
| Operate an existing cashier workstation | Item manipulation plus screen-state recognition and controlled interface interaction | Correct completion of the defined checkout workflow and its exceptions |
For each row, ask where the robot’s responsibility ends. An alert that no employee has time to act on is a different outcome from a replenished shelf. A product moved to the scanner is a different outcome from a completed transaction.
Specialist robots and humanoids deserve different evaluations
A specialist platform can be a strong choice when one repeatable task accounts for the value. A mobile manipulator or humanoid becomes more interesting when the work involves physical interaction across fixtures designed for people. That potential flexibility comes with more dependencies to test: hands, arms, balance or base positioning, perception and task logic must work together.
For a bounded checkout workcell, a fixed robot arm or a collaborative robot is also a candidate to evaluate. Combine it with camera-based item perception and suitable tooling, then test reach, barcode presentation and interface access at the actual lane. A stationary workcell can help isolate the manipulation and perception questions before adding mobility. The complete application still needs its own safety assessment and protective measures; the label “collaborative robot” does not establish that a customer-facing task is safe. Compare total project cost and operating effort across the candidate configurations rather than assuming one body type is always cheaper.
Concrete products make this distinction easier to see. Simbe describes Tally as a shelf-scanning inventory robot that identifies issues and delivers actions to store teams. Badger Technologies describes shelf, pricing and hazard-monitoring workflows. These are useful examples of observing store conditions; they are not evidence of physical shelf replenishment.
For humanoid evaluation, NEURA’s 4NE1 is a relevant full-body platform to investigate. Unitree’s G1 and G1 EDU show why configuration matters: the manufacturer distinguishes development access and optional hand equipment between versions. A platform name alone does not specify the robot you can program, the tools supplied or the task it can perform.
These examples are not a ranking or a claim that every listed platform is supplied by FastLane. Obtain the current configuration, documentation, support terms and task evidence from the relevant supplier. Research access, a reservation page and an operational retail service are different procurement propositions.
Build a shortlist around eight questions
- Can it reach the complete task workspace? Test the low shelf, rear product, scanner window and awkward placement point. A reach drawing is a starting point; tooling length, obstacles and usable joint positions also matter.
- Can it handle the object mix? Define weights, dimensions, surfaces and fragile items. Include the weight of the end effector when evaluating the arm’s usable capacity. Read the separate hands and grippers guide before treating a hand option as a solved problem.
- Can your team control and inspect it? Request the necessary APIs, logs, sensor access, operating modes and licensing conditions. Confirm that a development feature belongs to the quoted configuration.
- What happens after a failed attempt? Ask for a demonstrated retry, safe hold, item release and staff handover. Recovery is part of the product, not an optional addition to a success video.
- What does the site need? Record clearances, floor transitions, charging space, network requirements, workstation geometry and customer access. Changes to these can dominate a small pilot.
- How much human work remains? Count setup, replenishing supplies, cleaning, remote assistance, fault recovery and daily checks. Moving the work elsewhere does not make it disappear.
- Who maintains the system? Establish spare-parts availability, field support, response hours, replacement procedures and software responsibility for the intended country.
- Who owns the useful outputs? Clarify access to demonstration data, trained configurations, task logs and performance history, including what happens when a contract ends.
Use pass/fail gates before a weighted score
A weighted spreadsheet is helpful only after essential requirements pass. If a candidate cannot physically fit the lane or the supplier cannot provide the needed control interface, an excellent presentation should not compensate for that failure.
After those gates, score the remaining candidates against the same evidence. One retailer might prioritize product coverage and damage prevention; another might prioritize service availability and intervention time. Record the reason for each weight before seeing the final vendor scores. Mark untested claims as unverified instead of assigning them a convenient middle score.
Hypothetical example: platform A completes 92 of 100 representative item cycles without help, while platform B completes 97. That difference is not enough to select B. If B also requires substantially longer resets, more daily preparation or a specialist operator, the full operating result may reverse the initial ranking. Repeat the test over more sessions and compare like-for-like conditions.
Ask for a representative test, including the difficult items
Build an item set from the intended store workflow. Include common products and exceptions: flexible pouches, reflective packaging, off-center loads and products whose barcode faces away from the camera. Reserve a separate set that the development team has not used for tuning. This reveals whether the solution handles the category or only the rehearsed items.
Vary conditions deliberately. A shopper blocks the view. A product lies farther back. A screen returns to an unexpected state. The network becomes unavailable. The point is not to create a theatrical failure test; it is to establish a clear operating envelope and a predictable response outside it.
Request uncut trial sequences, total attempts and a failure log. Report successful first attempts, successful recoveries, human interventions, product damage and cycle-time distribution separately. The median can look healthy while a small number of long interruptions creates unacceptable queues.
Evaluate the whole workflow cost
Hardware price is only one line. Add task engineering, tooling, integration, site preparation, training, support, spare parts, software and the human time required to operate the system. Then distinguish released staff capacity from actual cash savings. Ten minutes made available during a shift may be valuable without reducing payroll by ten minutes.
For US projects, include delivery, local support arrangements and support-hour coverage explicitly. Do not assume that international sales interest automatically means a local service network exists. The operating arrangement needs to be part of the proposal.
A good shortlist should leave you with two or three candidates and a precise reason each might succeed. The next step is a bounded pilot with agreed acceptance criteria, not an immediate chain-wide commitment.
Your first-page evaluation brief
- The task, starting state and successful finishing state.
- The representative products, fixtures and operating hours.
- The essential constraints and excluded cases.
- The evidence required before supervised store testing.
- The owner of each exception, maintenance step and data flow.
- The business outcome that would justify the next stage.
FastLane focuses on translating retail workflows into a practical robotics deployment plan. Discuss your target task with the store country, item mix and constraints available. A clear problem definition makes that conversation more useful than a request for the “best” robot.
Sources and further reading
Product examples checked in September 2026. Manufacturer descriptions are attributed and do not establish independent performance in your store.
