Why events break tills
Four conditions combine at an event that rarely combine in a shop. The network is shared with thousands of phones in one field, so the connection you tested at 9am is unusable by 7pm. Power is a generator or a battery. The demand is not spread across a day but concentrated into the twenty minutes after a match ends or a set finishes. And the people serving are temporary, so nothing can rely on familiarity.
Each of those is survivable alone. Together they punish any system that assumes a connection, assumes mains power, assumes a calm counter, or assumes a trained operator. Most tills assume all four, which is why so many event traders end up back on a cash box and a notebook, and then cannot reconcile the day.
The cost of falling back to paper is not the paper. It is that you finish the event with takings, a pile of stock, and no way to connect the two. You cannot tell whether the shortfall was theft, breakage, undercharging or a cashier who lost count in a rush. Every one of those needs a different response, and without a record you cannot tell which you had.
Speed deserves particular attention because it is the constraint that is easiest to underestimate. At a bar during an interval, the difference between a two-tap sale and a six-tap sale is the difference between serving the queue and watching half of it leave. Event menus should be short, priced in round figures, and reachable without scrolling.
None of this is exotic software. It is ordinary point-of-sale set up for a hostile environment, which mostly means choosing a system that genuinely works offline and then configuring it for the day rather than the year.
There is a second reason to get the record right that traders often miss. An event is the cheapest market research a business ever gets: a few hundred customers, compressed into hours, choosing between a small number of products at prices you set that morning. Which lines sold out and which came home, what people asked for that you did not have, how fast the queue moved at different prices -- that is genuinely useful information about your range, and it only exists if the sales were recorded rather than remembered. Traders who run events on a cash box learn nothing from them except the total.
It is also worth being clear that a sale at an event is a sale. The obligation to issue a compliant receipt does not pause because the counter is a trestle table in a field, and the practical answer is the same as the answer to everything else here: a system that queues the tax record offline and transmits when a signal returns lets you meet the obligation without a connection at the point of sale.
Want to see it running in your own business first?
Sign UpAn event does not need a more powerful till than a shop. It needs one with fewer things that can fail.
Setting up so it holds
In order. The first two are the ones that actually decide whether the day works.
- 1
Prove it sells with everything switched off
Before the event, turn off WiFi and mobile data and complete a full sale: item, payment, printed receipt. Then switch the connection back on and confirm the sale transmits by itself. A system that cannot do this will fail you at the exact moment the field fills up, and that is not the moment to find out.
- 2
Charge everything, then bring a way to charge it again
Terminals, phones, and a power bank per device. A generator you do not control is not a plan. Handheld terminals that run a day on one charge are the reason they suit events at all, but only if they started the day full.
- 3
Build a short event menu, not your full catalogue
Twenty items, priced in round numbers, on one screen with no scrolling. Round prices remove change arithmetic at the counter, which is where errors and delays come from. Your full catalogue is a liability here; set up a separate short list for the day.
- 4
Give every server their own login
Even if they are with you for one afternoon. Shared logins mean that when the count is short you have a number and no explanation. Individual logins turn a mystery into a specific conversation with a specific person.
- 5
Count stock out, in writing
Count what leaves for the event and record it before you go. Without an opening count there is nothing to compare the closing count against, and the whole reconciliation becomes an opinion.
- 6
Decide the payment mix before the gate opens
M-Pesa prompts are fast and leave a record; cash is faster still and leaves none. Decide which you are taking, brief the staff, and keep a float in small denominations if you are taking cash. Deciding this at the counter during a rush is how prices get rounded down by whoever is serving.
- 7
Rehearse with the actual staff
Fifteen minutes the morning of: each person rings up three sales, takes a payment, prints a receipt, and handles one refund. People who have done it once are dramatically faster than people who have been told about it, and the rehearsal surfaces the confusing item before three hundred customers do.
- 8
Agree what happens when something goes wrong
A device dies, a payment fails, a customer disputes a price. Decide the answer in advance and tell everyone, because at volume staff will improvise otherwise, and every improvisation is a hole in your record.
- 9
Count stock back and reconcile the same day
Count what returns, compare against what went out and what the till says sold, and do it before everyone disperses. A variance you investigate that evening is answerable; the same variance on Tuesday is not.
What goes wrong at events
Trusting the venue’s network
It works during setup because the field is empty. It stops working when several thousand phones arrive, which is also when you start trading. Plan for no connection and treat any connection as a bonus.
Using the full shop catalogue
Hunting for an item through four hundred products at a busy counter costs seconds per sale, and seconds per sale is the whole queue. Build the short list beforehand.
One shared login for everyone
It feels efficient in the morning and leaves you with an unexplainable shortfall at night. This is the single change that most improves what you learn from an event.
No opening stock count
Without it, the closing count means nothing. You will know how much stock came back and have no way to say whether that is right.
Learning the system on the day
An event is the worst environment in which to discover how a till behaves. Whatever you are using, use it in a calm room first.
Taking only one payment method because it is simpler
Cash-only loses the customer who has money on their phone and no notes; M-Pesa-only loses the one whose transaction is timing out because the whole field is on the same tower. Both cost you sales at exactly the moment volume is highest, and the customer who cannot pay does not come back later.
Treating the event as separate from the business
Event stock is usually shop stock, and money taken at an event is business income. Running the day outside your normal system means two sets of records that have to be married up afterwards, which in practice means one of them never is.
A bar at a two-day festival
A bar operator takes four staff and a stocked trailer to a festival outside Nakuru. Day one is run on the shop’s normal till setup: the full catalogue, one shared login, and the venue WiFi. By the second band the connection is gone, the till will not complete a sale, and the team moves to cash in a box with a running total on a phone.
They take good money and finish the night unable to explain a shortfall of several thousand shillings against the stock that left the trailer. It could be undercharging in the rush, it could be free drinks for friends, it could be simple miscounting. With one shared login and no opening count, all three look identical.
Day two is set up differently. A short menu of twelve drinks at round prices, one login per server, a full stock count before opening, and the network switched off deliberately so nobody is relying on it. The takings are similar. The difference is that when the closing count is short by a smaller amount, it is short on one server’s line and on one product, which turns the conversation from a suspicion into a question with an answer.
When M-Pesa payments are not matched to sales, a missing payment, a staff shortfall or a double charge can slip past you until the money is already gone.
Veira reconciles M-Pesa Till and Paybill against every sale, so a mismatch surfaces the same day instead of at month end.
Built for the conditions events actually have
Veira keeps selling with no connection. Sales complete, receipts print and eTIMS records queue on the device, transmitting when a signal returns, so a dead network is a delay rather than a stop.
It runs on a handheld terminal or the phone in a server’s pocket, on battery, which is the only power an event reliably has. Each person signs in as themselves, so the closing variance points at a line rather than at the whole team.
And because the sales are recorded rather than remembered, the reconciliation against what you carried out is arithmetic you can do that night, not a reconstruction you attempt on Tuesday.
Frequently asked questions
What is an event POS?
Does an event POS need internet?
Can I use my normal shop till at an event?
How do I take payments at an event?
How many devices do I need?
How do I stop losses at an event?
What about refunds during an event?
Do I still need to issue compliant receipts at an event?
What is the most common event POS mistake?
Should I take cash, M-Pesa, or both at an event?
Should event sales go through my normal business records?
What can I learn from an event beyond the takings?
How long should setup take on the day?
Selling at an event is ordinary retail under hostile conditions, and the system that survives it is the one with the fewest dependencies: no network, no mains power, a short menu, a login per server and a stock count at both ends. Set that up in a calm room before the day, rehearse it once with the people who will use it, and you will finish the event knowing what you sold rather than guessing at it.
Need help, or want to talk it through first? Chat with us on WhatsApp