The sound of a queue going quiet
Walk into any busy store at six in the evening and listen. A healthy checkout lane has a rhythm: beep, beep, a short pause, the receipt printer, a thank you. The rhythm breaks when the till disagrees with the shopper. A price on the shelf does not match the price on screen. A coupon is rejected. A card is approved but the terminal shows an error. The cashier stops, looks up, and the whole line waits.
I have spent more than twenty-one years around retail systems, checkout, payments and, lately, practical AI. In that time I have watched teams spend years perfecting the happy path of a sale and almost no time on the moment the happy path ends. That moment is where customers decide whether they trust a store. It is also where margin leaks, where shrink hides, and where the most junior person in the building is asked to make a judgment the system could not.
This essay is about that moment. I want to describe how to design exception handling so that a store team can run it without calling head office, without guessing, and without leaving a mess for the back office to clean up on Monday.
What an exception actually is
An exception is not an error. An error is the system saying it broke. An exception is the system saying the world does not match what it expected, and a human must decide which of the two is right.
That distinction matters. If you treat every exception as an error, you build error messages. If you treat it as a decision, you build a decision flow: what is known, what is in doubt, who may decide, and what gets recorded.
Three kinds of disagreement
Almost every till exception I have seen falls into one of three families.
Data disagreement. The item, the price, the tax rule or the promotion in the system differs from what is physically in front of the cashier. A barcode scans as the wrong product. A shelf label was updated but the price file was not. A bundle is advertised but the rule is not configured.
Money disagreement. The tender does not match the transaction. A card authorization comes back unclear. A gift card balance is wrong. Cash counted does not equal cash expected. A refund is requested against a sale the system cannot find.
Authority disagreement. The customer asks for something the cashier is not allowed to grant: a price match, a return outside the window, a discount to save a sale. The system is not wrong. The permission is missing.
Naming these families is useful because each wants a different design. Data disagreements need fast correction and a feed back to whoever owns the data. Money disagreements need strict reconciliation and a clear rule about what the cashier must never do. Authority disagreements need a quick path to someone who can say yes.
Why the happy path hides them
Most project plans measure success by transactions completed. A till that completes a transaction looks healthy, even if one in many of those completions involved a quiet workaround: a manual price key-in, a voided and re-rung item, a note on paper. The workaround completes the sale and erases the signal. The system never learns that its price file was wrong, because the cashier fixed the symptom by hand.
This is why exception handling is an information problem as much as a customer-service problem. Every exception is a free sensor reading about the quality of your data, your rules and your training. Throw it away and you pay for the same fault again tomorrow.
A story about a gatekeeper
Let me tell a parable, in the spirit of the teaching stories I grew up with, about a king’s gatekeeper. It is a story I tell, not a record of history. The kingdom had a rule: no cart enters the city without paying the toll. One day a farmer arrived with a cart of straw, and the gatekeeper, being careful, poked the straw and found nothing but straw. The cart passed. Weeks later the king learned that the farmer had been smuggling, but never in the straw. He was smuggling the carts.
I think of this story whenever someone proposes a new control at the till. A gatekeeper who checks only what he was told to check will be fooled by anyone who understands the rule. A good gatekeeper keeps asking what the rule was for.
The rule at the till exists to protect two things: the customer’s right to a correct, fair price, and the store’s right to be paid correctly. A control that protects neither is theatre. A control that protects one at the expense of the other will be bypassed by the people who feel the cost, which is the cashier and the customer, in front of a growing line.
So when you design an exception flow, start with the question the old gatekeeper forgot to ask: what is this check for, and what will a reasonable person do when it gets in the way?
The five questions every exception must answer
When a till throws an exception, five questions should have clear answers inside the system, not inside someone’s memory.
- What do we know? Show the facts the system has: the scanned item, the price it expected, the source of that price, the time it was last updated. A cashier who can see why the till disagrees makes better calls than one who sees only “price mismatch”.
- What is in doubt? State plainly what the system cannot confirm. “Card approved, receipt not confirmed” is a very different situation from “card declined”, and the cashier must not have to guess.
- Who may decide? Name the role that can resolve this exception. If the cashier can, say so and offer the options. If not, show how to reach the person who can, and how long that usually takes.
- What are the allowed outcomes? A small list. Accept the system price. Apply a correction within a limit. Escalate. Park the item. Stop the sale. Every option should have a known effect on stock, money and the customer’s receipt.
- What gets recorded? Who decided, what they saw, what they chose, and why, in one line that a person can read months later.
If any of the five is missing, the exception becomes a conversation, and conversations do not scale across hundreds of stores and thousands of shifts.
Designing for the person at the till
The person at the till is rarely the person who designed the system. They are often new, sometimes seasonal, always watched by a customer. Design for that person on their worst hour.
One screen, one decision
A common failure is the exception that opens a menu of eight actions, three of which are rarely right. The cashier, under pressure, picks the one they have used before. Over time, the least risky-looking action becomes the habit, whether or not it is correct.
Reduce the choice. Put the most likely correct action first and explain it in plain words. Hide rare and risky actions behind a role that understands them. Where there are really two sensible outcomes, show two buttons and say what each does to the customer’s total.
Also resist the urge to educate during the transaction. A long help message in the middle of a queue is not read. Short wording, a clear next step, and a link to the longer explanation for the quiet hour afterwards works better.
Override rights and the paper trail
Every store lives with the tension between trust and control. Too tight, and managers spend their day walking to tills to type a code. Too loose, and overrides become a quiet way to leak margin.
The approach I prefer has three parts. First, set limits by role and by amount, so that small, common corrections are fast and large ones need a second person. Second, make every override leave a record that includes the reason chosen from a short list, not free text typed in a hurry. Third, review the pattern, not the individual event. One override means little. A cluster of overrides on one item, one lane or one shift tells you something real.
When people know the trail exists and know it is read for patterns rather than for blame, behaviour tends to improve without a speech.
Offline is a normal state
Stores lose connectivity. Terminals lose power. Payment links drop. If your exception design assumes a live connection to head office, it will fail at exactly the moment a store most needs it, such as a busy weekend or a regional outage.
Design an offline mode as a first-class state. Decide in advance which items, tenders and discounts are allowed offline, what limits apply, and how the transactions are held and replayed when the connection returns. Make the till say clearly that it is offline and what that changes. And plan for the replay: duplicates, out-of-order records and prices that changed in between are the exceptions you will meet the next morning.
Routing exceptions that leave the store
Not every exception can be closed at the till. Some belong to someone else, and the quality of that handoff is what separates a tidy operation from a noisy one.
A price mismatch belongs to whoever owns the price file. A repeated card error belongs to the payments team or the acquirer. A stock discrepancy discovered during a return belongs to inventory control. If the cashier’s workaround is the end of the story, none of these owners ever hears about it.
The pattern I recommend is simple. Each exception type has an owner. When an exception is closed at the till, the system raises a lightweight ticket to that owner, with the item, the store, the time, the evidence and the cashier’s action attached. The owner sees a queue, not a flood of emails. They fix the root cause, and the fix is visible back to the store that raised it.
Two small details matter a great deal. First, the ticket should be created automatically, because asking a busy cashier to report a problem after the sale is asking for it to not happen. Second, the store should see when its report led to a change. People keep reporting problems when they can see that someone listened.
Measuring the exception queue
You cannot manage what you cannot see, and exceptions are easy to hide inside a general sales report. A few measures give a useful picture without drowning anyone.
- Exception rate by type. What share of transactions hit each family of exception? A rising price-mismatch rate points at data. A rising authority rate points at policy or training.
- Time to resolve. How long does the line wait? Separate the time at the till from the time waiting for a person with authority.
- Repeat offenders. Which items, lanes, stores or tender types produce the same exception again and again? These are your best fixes.
- Override concentration. Are overrides spread evenly, or clustered around a handful of users or times? Clusters deserve a conversation, not an accusation.
- Close-the-loop rate. Of the exceptions routed to an owner, how many led to a root-cause fix? This is the measure that tells you whether the system is learning.
I would keep this to a one-page view for a store manager and a deeper view for an operations lead. If the manager cannot read it in two minutes, it will not change what happens on the floor.
A starting playbook
For a team that wants to begin without a large programme, here is a sequence that has worked in the shape I have described.
- Collect a month of reality. Before designing anything, gather what actually happens: the voids, the manual price entries, the refunds without receipts, the offline periods. Group them into the three families.
- Pick the top five. Do not try to design for every case. Choose the five exceptions that cost the most time or money and write the five-question answer for each.
- Fix the data you can fix. Many data exceptions disappear when the price file and the item master are cleaned. This is the cheapest improvement and often the largest.
- Set the override ladder. Agree who can do what, up to what limit, and what reason codes exist. Write it on one page that a new cashier can understand.
- Wire the routing. Make sure each exception type has an owner and that the ticket is raised without asking the cashier to do extra work.
- Train on stories, not screens. Teach new staff with real situations: the customer with the mismatched shelf label, the card that approved but did not print. People remember stories long after they forget menus.
- Review monthly. Look at the measures above, pick one root cause, fix it, and tell the stores you did.
None of this needs exotic technology. It needs the discipline to treat the exception as a first-class citizen of the design.
Where to go from here
Where artificial intelligence enters, I would be careful and practical. A model can help classify exceptions, suggest the likely cause of a mismatch, or summarise a cluster of overrides for a manager. It should not be the one deciding whether a customer is refunded or a price is changed without the same limits and records a person would have. The most useful decision an automated helper can make is often to stop and hand the case to the right human with the facts attached.
The till will always disagree with the world sometimes. The question is whether your store treats that moment as a failure to be hidden or as information to be used. The stores that do the second one tend to have shorter queues, cleaner data and calmer teams.
If you run stores, a checkout platform or a retail operations team and want a second pair of eyes on how your exceptions are handled today, I am happy to talk it through. The first conversation is a free 20-minute call: https://topmate.io/raja_jeevan_kumar_maduri