A retail AI demo is a remarkably polite place. The customer asks a sensible question. The product is in stock. The policy is current. Nobody has bought the item abroad, lost the receipt and arrived five minutes before closing with a screenshot of a promotion from 2022.
Then the system meets an actual shop.
This is where many AI projects need something less glamorous than another model upgrade: an exception budget. Before handing decisions to AI, decide which mistakes you can tolerate, which situations require a person, and how much human attention you can afford. Otherwise, your automation project may quietly become a recruitment plan for people who apologise.
Budget for decisions, not just software
By exception budget, I mean an operating agreement, not a new accounting standard. It covers three things: the authority given to AI, the consequences of getting a decision wrong, and the capacity available to handle cases outside that authority.
Those limits should be different for different jobs. Suggesting a product description is not the same as issuing a refund. Recommending a substitute is not the same as approving a substitute for a customer with a declared allergy. The interface might look identical. The responsibility is not.
A useful starting question is: “What can this system do without asking anyone?” If the answer requires a long discussion, have that discussion before launch. A cheerful chatbot cannot resolve an unresolved management policy. It can only explain the confusion more fluently.
Start with one inconvenient customer journey
Consider an illustrative scenario, not a reported client result. A retailer wants an assistant to help staff handle returns. The assistant can retrieve the applicable policy, summarise a receipt and suggest the next step. The team is considering letting it approve some refunds.
The easy case is straightforward: a verified purchase, within the return window, with an eligible item. But what happens when the receipt is missing, the promotion involved a bundle, or the customer has already received a partial refund?
Put those cases on the table. Give them names. Decide who owns each decision. Define what information must be available, what action is permitted and what happens when the information conflicts. “Use common sense” is not a specification. It is a request for a future argument.
For an initial pilot, the retailer might allow recommendations while keeping financial authorisation with staff. That is not a disappointing version of AI. It is a way to learn where the system helps before granting it authority that is harder to reverse.
Separate answer quality from permission to act
A response can sound reasonable and still be an unauthorised decision. “Of course, we can refund that” is a promise, even if the application has not yet moved any money.
Define separate permissions for reading information, making recommendations, communicating commitments and executing transactions. Enforce important limits in the surrounding software and approval process, not only in an instruction telling the model to be careful.
When the required evidence is missing, the system should explain what is missing and route the case appropriately. Do not make a model’s confident tone the approval mechanism. Your refund policy deserves a stronger foundation than excellent bedside manner.
A handoff needs somewhere to land
“Escalate to a human” sounds reassuring until you discover the human is also serving a queue, checking a delivery and covering somebody’s lunch.
Estimate the number of referrals, the average handling time and when they will arrive. For example, 300 referred cases at four minutes each create 20 hours of review work. Those are illustrative planning numbers, not a forecast. They make the point: a small percentage can still become a very full afternoon.
A useful handoff includes the customer’s request, verified information, the unresolved issue and any action already taken. The reviewer should not have to interview the chatbot to discover what happened. Also define a fallback when nobody is available. A pending request with an honest explanation is better than a promise the business cannot keep.
Train staff to challenge the assistant
Training should cover more than where to click. Staff need practice recognising when an apparently helpful answer is unsupported, when a policy does not apply and when to stop the process.
Use short role-plays based on difficult situations: conflicting promotions, unclear consent, an unavailable product or a customer asking for an exception. Ask employees to explain their decision, not merely accept the assistant’s recommendation.
This matters for AI-based sales coaching too. A simulated customer can help people rehearse, but a convincing simulation is not proof that its feedback matches your standards. Managers should review examples and calibrate the feedback before using it to assess employees. The training tool needs supervision as much as the trainee does.
Measure the work that moves, not just the work that disappears
Track completed tasks alongside referrals, corrections, repeated contacts and staff review time. An assistant that shortens the first interaction but creates a second one may have improved a dashboard while inconveniencing everyone else.
Compare similar cases before and during the pilot. Inspect a sample of apparently successful interactions as well as reported failures. Customers and employees do not always report a mistake, particularly when correcting it feels like another task.
Agree on stop conditions in advance: a prohibited commitment, an unacceptable error pattern or a review queue the team cannot handle. Identify the person authorised to pause the system and the process for returning to manual service.
Earn the next permission
The goal is not to keep AI permanently on a short leash. It is to expand its authority using evidence. Start with a bounded task, review what happens, improve the process and grant the next permission when the results justify it.
That approach works beyond returns: sales recommendations, loyalty offers and employee learning all contain decisions with different consequences. Start by naming those decisions.
The best question after a brilliant demo is not “How quickly can we roll this out everywhere?” It is “What happens on the awkward Tuesday when the answer is not obvious?” That is where useful retail AI begins.
About the author: Kirill Naumov is a consultant, entrepreneur, AI architect and speaker. His background includes 11 years with Apple, seven years teaching MBA participants and 16 years working across retail, construction, hospitality and other industries. Learn more at Kirill Naumov’s website or explore his live online AI workshop for retail, sales and learning teams.
Website: https://www.kirillnaumovai.com/
Workshop: https://www.kirillnaumovai.com/workshops/ai-retail-november
