The Saturday Rush Is the Only POS Demo That Matters: Five Customers in Line, Five Ways a Till Fails

Every POS demo I have ever watched takes place at the same time of day: a quiet morning, one smiling customer, one item, one tap, one receipt. Nobody is waiting. Nothing is out of stock. The barcode works. That demo tells you almost nothing, because your shop does not live in that morning. It lives at noon on Saturday, when the door keeps opening, the queue reaches the biscuits, and four small things go wrong in the space of ten minutes. A till that cannot survive that ten minutes will cost you more than a till that is slow on a Tuesday. It will cost you customers who do not come back, and they will not tell you why. They will simply not be in next Saturday's queue.

So forget the quiet-morning demo. Run this test instead. Picture one queue, five customers, each one carrying a different ordinary problem. You do not need a real shop to run it. You need a trial install, five invented baskets, and the willingness to be awkward on purpose. The script under discussion is ShopPOS, a point-of-sale script for small shops, and I am going to be straight about the limits of this post before the queue even forms: I found no ShopPOS price and no ShopPOS demo link on the shop's front page when I checked, so I will not invent either, and I will not describe features as though I had watched them work. What follows is the test itself — the queue I would run through ShopPOS, or through any other POS script, before letting it near a real counter.

The queue is the test

Why a queue, rather than a checklist of features? Because a queue is where a till's separate weaknesses meet each other. On a checklist, a slow search is one line and a clumsy split payment is another line, and both look minor. In a queue, the slow search makes the second customer wait, the second customer's price argument makes the third customer check their watch, and by the fourth customer you are not testing software any more. You are testing patience, and patience is the thing a small shop cannot buy back. A good till does not just bill correctly. It bills correctly while people are watching, while the next person is already annoyed, and while the person after them is deciding whether to put their basket down and leave.

There is a second reason, and it is less obvious. A queue exposes what a script does when the operator is under pressure, which is the only condition under which mistakes actually happen. A cashier who has all the time in the world will find the right button eventually. A cashier with four people waiting will take the first button that looks right, will skip the step that takes three taps, and will promise the customer something the system has not actually recorded. The script that survives a rush is the script that makes the right action the easy action when nobody has time to think. Keep that sentence in mind through all five customers. It is the standard each one is judged against.

First in line: the barcode that will not scan

The first customer holds out a packet with a barcode that has seen better days. It is creased, or printed small, or the packet is the refill pack whose barcode was never entered properly in the first place. The scanner beeps its failure beep, the cashier tries again, and the queue shifts its weight. This is the most ordinary failure in retail, and it is the one most demos never show, because demo products always scan.

What you are testing here is not the scanner. Scanners fail; that is hardware. You are testing the fallback, and specifically how many seconds the fallback costs. Can the cashier type a few letters of the product name and get the right item at the top of the list, or does the search return twenty near-matches in no useful order? Can they add the item by its shelf code, or by tapping a favourite button for the twenty items the shop actually sells every day? Does the screen stay on the sale while they search, or does the half-finished basket vanish behind a search screen that has to be closed and reopened? Every extra tap here is not a minor inconvenience. It is ten seconds multiplied by every unscannable item, in front of a queue that is counting.

My opinion on this one is blunt: a POS script that makes manual entry feel like a punishment has misunderstood the job. Barcodes are a convenience, not a promise. The till should assume that some percentage of real products will not scan on a real Saturday, and should treat the typed fallback as a first-class path, not as an error screen. If your trial run turns one unscannable packet into a thirty-second hunt through a product list, you have learned something important, and you have learned it before a real customer had to stand there watching you hunt.

Second in line: the shelf price and the screen price disagree

The second customer has picked up an item whose shelf ticket says one price and whose till screen says another. Perhaps the shelf ticket is old. Perhaps the price was changed on the system yesterday and nobody re-ticketed the shelf. Perhaps the customer is simply mistaken. It does not matter who is right yet. What matters is what the till lets the cashier do, in front of a queue, without breaking the sale or breaking trust.

A weak till gives the cashier two bad options: charge the screen price and argue, or abandon the whole basket and start again while the customer stands there feeling accused. A decent till gives a third option: adjust this one line, with a reason, and carry on, so the argument is settled by the time the receipt prints. Watch for the details that decide whether that third option is real. Does the adjustment need a manager to walk over, or can the cashier do it within a limit you set? Is the reason recorded — shelf price, promotion, damaged packaging — or does the adjustment silently change the price with no trace? Does the rest of the basket survive, or does editing one line disturb the totals, the discount, or the stock count for the other items?

Here is the honest tension, and I will not pretend it away: you want price changes to be easy enough that a Saturday argument ends in seconds, and controlled enough that a dishonest cashier cannot quietly sell everything at a discount to friends. Both halves are the same feature, done well. A per-line adjustment with a reason, a sensible cashier limit, and a manager approval above that limit is the shape I would look for. A till with no adjustment at all is not honest. It is rigid, and rigidity in front of a queue turns a two-rupee difference into a lost customer. A till with unlimited, untraced adjustment is not generous. It is an open drawer with extra steps.

Third in line: the last packet, and the customer behind them

The third customer wants the last packet of something. The shelf says there is one left. The system says there are two. Or the shelf is empty and the system says there is one. Either way, the queue is now involved in your stock accuracy, which is a sentence I want you to sit with, because most stock arguments happen in private, at closing time, long after the customer has gone. This one happens in public, with the next customer listening.

Run this test deliberately. Before the rush, set the stock of one invented product to one, sell it to the third customer, and then try to sell it again to the fourth. What does the till do? The good answers are boring, and boring is what you want: it warns before the second sale, it refuses to sell below zero unless you explicitly allow it, and it shows the stock figure to the cashier before the argument starts rather than after it. The bad answers are more interesting and much worse: it sells the second packet happily, takes the money, and leaves you to explain to a customer who has already paid why they cannot have what they bought. That is not a stock error. That is a broken promise with a receipt attached.

There is a softer version of the same test worth running too. When the stock is wrong — and in a real shop it sometimes will be, because deliveries get put away without being booked in, or a packet gets damaged and thrown away without being recorded — can the cashier correct it quickly, with a reason, from the till screen? Or does a stock correction require leaving the till, opening an admin panel, and coming back, while the queue waits? Stock corrections are not a back-office luxury. On a Saturday they are a queue problem, and a script that treats them as one will save you more arguments than any loyalty feature ever will.

Fourth in line: half cash, half card, and the change

The fourth customer pays in the way real customers actually pay when they are in a hurry and slightly short: part cash, part card, and they want the change worked out without a performance. This is where a surprising number of tills reveal that they were designed by people who have never stood at a counter. A till that handles only one payment method per sale is not a till for a real shop. It is a till for a demo, and the difference will announce itself the first time a customer says, "Put twenty on the card and the rest in cash."

Test the arithmetic, not just the buttons. Put a split payment through, then a discount on top of it, then change due on the cash portion only. Does the receipt show, clearly, how much went on each method? Does the change figure belong to the cash part alone, or does the till cheerfully offer change on the whole bill, including the card part, which is how a cashier hands back money the shop never received? Does the day's record split the sale by payment type, or does it lump the whole bill under one method, which is how closing time turns into a mystery later? These are small numbers, but they are the numbers a shopkeeper actually loses money on, one quiet overpayment at a time.

I have a firm view here, and it comes from watching too many small shops absorb small losses without ever naming them: a till that cannot split a payment cleanly is not a minor gap. It is a daily tax on every customer who pays the way real people pay. Test it with the messiest payment you can invent, not the cleanest. A clean card payment will pass on almost any script. A split payment with change and a discount will separate the scripts that were built for counters from the scripts that were built for screenshots.

Fifth in line: hold this sale, serve the next one

The fifth customer is the one who breaks the queue's rhythm entirely. They are halfway through paying when they remember the milk, or they need to check a price with someone at home, or their card is declined and they need a minute. The queue behind them does not need a minute. It needs to move. So the cashier needs to park this sale, serve the next customer, and come back to the parked sale without losing a single line of it.

This is the hold-and-resume test, and it is the one I would rank highest in a rush, because it is the one that decides whether one slow customer ruins five other customers' morning. Park a sale mid-payment, not just mid-basket. Serve a second customer completely, including their receipt. Then resume the first sale and check, line by line, that nothing changed: same items, same prices, same discount, same payment already taken, if any. Then check the harder version: park two sales at once, and make sure resuming the wrong one is difficult, not easy. A parked sale that can be resumed onto the wrong customer is worse than no parking at all, because it creates a billing error wearing the clothes of efficiency.

Watch also for what happens to stock while a sale is parked. If the parked sale has already reduced the stock, the next customer may be told an item is out of stock when it is merely sitting in someone else's parked basket. If it has not reduced the stock, two parked baskets may both claim the last packet. Neither answer is automatically wrong, but the script should have an answer, and it should be visible to the cashier. A script that has never thought about parked stock will give you whichever answer fell out of its code, and you will discover it on a Saturday, in front of a queue, which is the worst possible classroom.

What the queue cannot tell you

A rush test is strong, but it has edges, and naming them is part of using it honestly. A queue tells you whether the till survives pressure. It does not tell you whether the prices were right, whether the products were well chosen, or whether the shop's stock records reconcile at the end of the day. For that, you need the slower test — the closing-time reconciliation this site ran for ShopPOS before, where cash, sales, and stock are made to agree after the rush is over. The two tests are partners, not rivals. The rush test catches what breaks when people are watching. The closing test catches what breaks when nobody is watching. Run both before you buy, and run them on the same trial data if you can, so a failure in one explains a mystery in the other.

A queue also cannot tell you, on its own, whether the script will still be maintained in a year, whether its updates will break your data, or whether you can export your products, customers, and sales history if you decide to leave. Those are questions for the seller's history and for the script's export and backup behaviour, not for the till. Ask them separately, and do not let a till that survived a rush talk you out of asking them. Speed is a virtue, but it is not a warranty.

Who should not buy on rush speed alone

Not every shop needs to optimise for a Saturday queue, and buying for a rush you do not have is a real way to waste money. If you serve a handful of customers a day by appointment, or your sales are almost entirely online with no counter and no cash, then queue speed is the wrong standard and a till built for it may be more complicated than you need. If every sale is a custom quote — a workshop, a repair bench, a consultancy — then what you actually need is invoicing and job tracking, and a fast barcode till will sit unused while the real work happens elsewhere.

The shop that should buy on this test is the one whose Saturdays already hurt: a queue at noon, a cashier who dreads the unscannable packet, a price argument at least once a week, a customer who pays in two ways, and a parked sale that currently lives on a scrap of paper by the till. For that shop, the rush test is not a nice-to-have. It is the whole purchase, because the queue is where the shop's reputation is made and lost, one Saturday at a time. Buy the till that keeps the queue moving without lying to it, and judge every demo by the fifth customer in line rather than the first.

More from this series

This test follows the same habit this site's earlier script posts use: read the thing as a buyer would before trusting it. The closing-time test reads one ShopPOS trading day backwards from the drawer, and the doctor-booking test reads a booking backwards from the waiting room. Both, like this one, are published on the tempomailusa.com blog, alongside the temporary inbox tool itself and its VIP plans.

FAQ

How do I run a rush test without a real shop? Set up a trial with a small set of invented products, five invented baskets, and a stopwatch you do not need to be precise with. Run the five customers in order: one unscannable item, one price disagreement, one last-item sale, one split payment, one parked sale. Write down, for each one, how many taps it took and whether the queue would have had to wait. A script that survives an invented rush has earned a look at your real one.

What is a good time per customer in a rush? There is no honest universal number, because baskets differ, but there is an honest test: time the same five baskets on your current method, whether that is a notebook, an old till, or a different script, and time them on the trial. If the new script is not clearly faster on the awkward baskets — the unscannable item, the split payment, the parked sale — then its speed on clean baskets does not matter. Clean baskets are not where time is lost.

Should a cashier be able to change a price during a rush? Within a limit you set, yes, with a reason recorded. A cashier who cannot fix a shelf-price error without a manager will either argue with the customer or lose the sale. A cashier who can change any price without a trace is a risk you do not need. The limit and the reason are the whole policy, and they should be set before the first Saturday, not discovered during it.

What if my shop never has a queue? Then judge the till by the test that matches your real day, not this one. A quiet shop should weigh closing-time reconciliation, stock accuracy, and simple billing more heavily than queue speed. Buying for a rush you do not have usually means paying for complexity you will never use, and complexity that sits unused still has to be learned and maintained.

Does a held sale affect stock? It should be visible either way, and that visibility is the test. If a parked sale reserves stock, the cashier should see the reservation. If it does not, the cashier should see that the last packet is still sellable and understand the risk. A script that gives no answer to this question has not thought about parked sales at all, and you will find out on a Saturday.

Is rush speed a replacement for good prices and good stock? No. A fast till selling the wrong products at the wrong prices will empty a queue efficiently and still leave a shop failing. Speed keeps customers from leaving in annoyance. It does not bring them in, and it does not choose what they buy. Judge the till on the queue, and judge the shop on everything else, separately.

A queue is the only demo a POS script cannot fake for long, because a queue has five people in it, and each of them has a different problem, and none of them cares how good the dashboard looked in the sales video. Run these five customers through any script before you buy it, run them again in the first week after you install, and keep the habit every time the script updates. A till that passes the queue is not necessarily the best till on the market. It is something better than that: it is a till your customers never have to wait on, and never have to argue with. And a shop, like an inbox, should never be handed to a system you cannot check under pressure.