By Bijoux Mbayo, Senior Solutions Consultant, eLocker
–
By the time an automated collections and returns pilot reaches IT, the business is often already leaning towards yes.
The omnichannel or retail operations lead has identified a process that is becoming too manual. Store teams are spending more time locating orders, managing handovers and resolving exceptions. Customer experience leaders can see the effect of queues, inconsistency and poor collection journeys. Finance wants to know whether the retailer can handle more volume without adding labour at the same rate.
Then IT is asked to approve the pilot.
This is often presented as the final technical hurdle. In reality, IT is being asked to do something more important: turn commercial enthusiasm into a decision the retailer can defend.
The question is not simply whether smart lockers are secure, connected or technically functional. It is whether the retailer can introduce it safely, prove its value in real stores and retain a credible route to scale without creating an unexpected support burden.
That distinction matters.
IT teams are rarely trying to stop useful retail innovation. They are trying to avoid approving a supposedly simple pilot that later becomes a poorly scoped integration project, an unclear supplier dependency or a customer-facing service that nobody has agreed how to support.
IT is not there to make the business case for automated collections and returns. It is there to establish whether the business can test that case safely, proportionately and without creating a future headache.
IT should approve a smart locker pilot when the business problem is clear, the technical scope is contained, the security and support model is credible, the in-store exceptions have been understood, it can be low integration, and there is a sensible route from pilot to rollout.
That is a higher standard than asking whether the equipment works. It is also a more practical standard than demanding the complete architecture for a national deployment before the retailer has proved that customers and stores benefit from the model.
The best pilot sits between those two extremes. It is controlled enough to protect the retailer, but realistic enough to produce evidence that senior leaders can use.
Start with the operational problem
The first IT discussion should not be about compartment sizes, authentication methods or APIs.
It should begin with the process the retailer is trying to change.
A typical store collection journey may involve a customer joining a queue, a colleague leaving the shop floor, locating the order in a crowded storage area, verifying the customer and completing the handover. The process may be manageable at modest volumes, then become slower and more expensive as collections increase.
That is the underlying issue. The retailer is not buying lockers for their own sake. It is considering a different operating model for collections and returns.
The internal champion needs a pilot that shows whether this model can reduce manual effort, improve the customer journey and create evidence for a wider business case. They are also personally exposed. A pilot that fails in stores can damage their credibility, but continued inaction leaves them responsible for a process that is already under strain.
IT should therefore ask a simple question at the outset:
What decision must this pilot allow the business to make?
The answer might be whether self-service collection can materially reduce colleague intervention in high-volume stores. It might be whether customers will adopt a faster collection journey. It might be whether a particular store format can handle more orders without extending the service desk or adding labour.
A pilot should not try to prove everything at once. When the commercial objective is vague, the technical scope expands and the results become harder to interpret.
Keep the first technical scope deliberately small
One of the most common causes of delay is the assumption that a meaningful pilot must begin with deep integration.
It may not.
Some retailers will need an integrated workflow from the start. Others may be able to test the customer and store process with a more contained configuration. The important point is that the choice should be deliberate.
IT should separate what is essential to prove the pilot from what would be required for an eventual rollout.
For example, a retailer may need to test whether customers can collect orders quickly and whether colleagues spend less time on handovers. That does not automatically mean every status update, customer communication and order event must be fully automated in phase one. A good pilot can be low integration while still showing a clear benefit.
A limited amount of manual handling can be acceptable during a pilot, provided it is visible, measured and not used to make an unscalable process look efficient.
The test is proportionality. The integration effort should reflect the value being tested.
This is particularly important because retail IT teams already operate with crowded roadmaps and limited capacity. Their concern is often not the concept itself. It is that a “light-touch pilot” quietly becomes a full project, consuming architecture, security, testing and support resources that were never included in the original conversation.
A pilot should be technically credible, but it should not require the retailer to build the final version of the service before it knows whether the service deserves to exist.
Evaluate the supplier as part of the service
The locker is only the visible part of the proposition.
IT also needs to understand the software, connectivity, support and supplier relationships that allow the service to operate. That makes the smart locker company part of the retailer’s technology supply chain.
This deserves a proportionate supplier review rather than an abstract security interrogation.
The National Cyber Security Centre recommends understanding supplier dependencies and setting appropriate security expectations across the supply chain. It also advises organisations to consider the support required to maintain supplier products and to define how information is returned or deleted when a relationship ends.
For the pilot, this means establishing who operates each part of the service, how incidents are escalated, how changes are controlled and what happens to the retailer’s information when the test ends.
Security review should make the route to approval clearer. It should not become an open-ended exercise in requesting documents that have no bearing on the proposed use.
There is a useful commercial context here. In the UK Government’s 2025 Cyber Security Breaches Survey, 45% of large businesses said they reviewed the cyber risks posed by their immediate suppliers. Supplier scrutiny is therefore normal for an enterprise retailer. The difference between a fast review and a stalled one is usually the clarity of the scope and the quality of the supplier’s answers.
Test the store reality, not just the technology
A technically neat pilot can still fail operationally.
This is one of the strongest concerns in the retail buying group. The operations lead is not asking whether smart lockers can work in a demonstration. They are asking whether it will simplify collections and returns in live stores where space is limited, colleagues are stretched and customer demand is uneven.
They need confidence that the process can cope during busy periods, that loading orders is straightforward and that the change will reduce store effort rather than move it elsewhere.
IT should help make the pilot realistic.
A stronger pilot might include a high-volume site, a store with tighter space and a format that better represents the wider estate. It does not need to cover every condition. It needs enough operational variation to show whether the model is repeatable.
The same discipline applies to infrastructure. Connectivity, power, installation requirements and remote support should be checked at the proposed location rather than assumed centrally.
The objective is not to eliminate every variation before the pilot begins. It is to avoid creating a test environment that bears little resemblance to the estate the retailer may eventually ask to serve.
Make exception handling part of the design
The normal customer journey is easy to present.
The order is loaded. The customer receives a message. They arrive, authenticate, open the correct compartment and leave with the order.
That is not the part of the journey most likely to determine whether stores trust the model.
Confidence is built around what happens when the customer cannot find the collection message, a compartment does not open, the wrong order has been loaded or the item is too large. It also depends on how the retailer handles expired collections, delegated collection, accessibility needs, partial orders and service interruptions.
These are not edge cases to be discussed after approval. They are part of the operating model.
The CX stakeholder will judge the pilot on whether the experience is genuinely easier, faster and intuitive, not just on whether the new process uses less labour. They will also look for evidence of adoption, reduced confusion and lower customer effort.
Be precise about the support burden
A major concern for retail IT is hidden ownership.
When something goes wrong in a store, who takes the first call? Can the issue be diagnosed remotely? Does the store contact the smart locker company directly, or does it go through the retailer’s service desk? Who communicates with the customer? What happens outside standard office hours?
These questions do not require a lengthy operating manual before the pilot. They do require an agreed division of responsibility.
The retailer should understand what support they receive, what remains with store operations and what genuinely requires internal IT involvement.
This is where many apparently simple technologies become difficult to scale. The individual incidents may be minor, but if every issue enters the retailer’s IT queue without enough information or clear ownership, the cumulative burden becomes material.
During the pilot, internal effort should be measured. That includes setup, testing, incident handling and ongoing administration. Otherwise, a project can appear operationally efficient while moving invisible work into IT.
The technical stakeholder’s core concern is whether the solution is supportable in both pilot and production. They want clarity that the business value justifies the effort and that approving the test does not commit IT to an undefined future workload.
Design the pilot to answer the rollout question
A pilot should not end with the conclusion that customers liked it and the equipment generally worked.
It should make the next decision easier.
Management will want to know whether the model has reduced the cost or labour burden of collections and returns, whether the evidence is strong enough to defend and whether the economics could hold across the estate.
Operations will want to know whether the process works in different stores, whether managers support it and whether it remains simple under pressure.
CX will want to know whether the journey is more convenient and whether customers actually use it.
IT should judge whether the architecture, supplier model and support arrangement have a credible path to scale. The question is not whether every rollout detail has already been solved. It is whether success would lead to a manageable next phase rather than a complete technical redesign.
This is where pilot boundaries matter. Approval should make clear what the retailer is committing to now and what will require a new decision later.
That creates the “safe path to yes” the IT stakeholder is looking for. The project can progress without forcing premature agreement to a full estate deployment.
Measure what the wider buying group will need
The best pilot scorecard is not owned by one function.
IT needs evidence on reliability, incidents, security and internal effort. Store operations needs to understand colleague time, loading effort, exception rates and performance at busier periods. CX needs adoption, customer effort and satisfaction. Finance needs a credible comparison with the cost of the current manual process.
The measures should be agreed before launch, while the retailer can still establish a useful baseline.
That baseline matters. A retailer cannot show that the new process is faster if it has never measured the current one. It cannot prove that colleague effort has fallen if store time was not recorded beforehand.
Equally, the business case should not be a generic supplier model. The retail champion and economic buyer both need retailer-specific evidence that can survive internal scrutiny. They are trying to establish whether automated collections and returns can become a commercially credible operating improvement, not simply whether the technology is interesting.
What should stop approval?
IT should pause the pilot when it cannot see the boundaries of what it is being asked to approve.
That may be because the integration requirement is vague, the data flow is unclear, the support model has not been agreed or the pilot is expected to prove benefits that nobody intends to measure.
It should also pause when the proposed store test is unrealistically favourable, when operational exceptions have been ignored or when the supplier cannot explain how the service would remain supportable beyond one location.
A mature supplier should be able to turn each concern into a practical decision. Integration risk becomes a phased scope. Security risk becomes a documented data and architecture review. Operational risk becomes a realistic store workflow. Support risk becomes clear ownership and escalation.
IT adds value by converting general discomfort into specific conditions for approval.
The right approval is conditional, not hesitant
Approving a pilot should not mean that IT believes every future question has been answered.
It should mean that the retailer has a sensible way to learn.
The pilot should address a real store problem, place limited demands on internal technology teams and produce evidence across operations, customer experience and commercial performance. It should be secure enough for the intended scope, supportable during live use and credible enough to expand if the results justify it.
The decision is whether the pilot gives the retailer a controlled, evidence-led route from a manual and increasingly strained process towards a more scalable collection and returns model.
Good IT governance does not slow a retail pilot down. It removes the ambiguity that would otherwise stop the pilot later.
When that clarity is in place, IT is no longer the final blocker. It becomes the team that makes it possible for the business to say yes with confidence.
Planning a retail collection pilot? Try our Collections Readiness assessment to see if your store is ready.