The problem with paper coupons at scale
For decades, the standard mechanism for subsidised employee canteen meals in large manufacturing organisations was the paper coupon. HR would issue a book of coupons each month. The employee handed over a coupon at the canteen counter. The contractor collected and counted coupons to generate a billing claim at month end. It worked, in the same way that any sufficiently entrenched workaround works: imperfectly, but consistently enough that no one was motivated to change it.
At a scale of several thousand employees across multiple canteen facilities, the cracks became structural. Coupon printing, distribution, and reconciliation consumed significant administrative time each month. Coupons were transferable — an employee could give or sell their coupons to contractors, visitors, or colleagues not entitled to the subsidy. There was no mechanism to prevent a coupon from being used by anyone who held it. Contractor billing was based entirely on coupon counts, with no independent verification of whether meals were actually served to eligible employees.
The lunch rush was a specific operational pain point. A single canteen serving 800–1,000 employees in a 30-minute window required multiple counters, a small army of staff, and still produced queues. The coupon exchange itself — employee hands over coupon, operator tears and deposits it, move along — took several seconds per person. In aggregate, those seconds represented real throughput constraints. Employees were spending a significant fraction of their lunch break in the queue rather than eating.
HR had a separate concern: the data vacuum. They were paying canteen subsidies that represented a meaningful line item in the employee benefits budget, but had virtually no information about how that benefit was being consumed. Which facilities had high uptake? Which meals — lunch versus dinner versus night shift — drove the most cost? Were there patterns that would inform decisions about capacity, menu, or subsidy structure? The coupon system offered none of this. It produced a monthly billing number, and that was all.
The hardware: purpose-built for the environment
The solution required custom hardware. Off-the-shelf POS terminals designed for retail are built for temperature-controlled, clean environments. A factory canteen is neither. The terminal needed to survive heat, humidity, and the kind of physical treatment that happens when the lunch rush hits and operators are under pressure to move the queue.
The terminal design centred on a Raspberry Pi single-board computer housed in a custom anodized aluminium enclosure. The choice of Raspberry Pi was deliberate: it offers sufficient processing power for the application, runs Linux natively, has a mature ecosystem, and the compute module form factor allowed the enclosure to be designed around it rather than around a bulky off-the-shelf board. The aluminium enclosure provided the ruggedisation needed for the environment and gave the terminals a professional appearance appropriate for customer-facing deployment.
Key hardware specifications:
- Dual touchscreen displays: One facing the operator (transaction controls, employee entitlement details, daily count) and one facing the employee (confirmation of meal type, deduction acknowledgement, remaining entitlement). The dual-screen approach eliminated a common source of disputes — employees questioning whether the correct meal type had been charged.
- Integrated RFID reader: Reads the same card format used for attendance and access control. No new cards issued. Employees tap the card they already carry.
- Battery backup: The terminal continues operating through power interruptions. In a factory environment, brief power fluctuations during the lunch rush cannot be allowed to halt canteen operations.
- POS software on Raspbian Linux: Custom application managing transaction processing, offline queuing, display output, and local data storage.
The software layer: entitlements, sync, and reporting
The hardware solved the throughput problem. The software layer solved the accountability problem. When an employee taps their card, the terminal queries local cached data to validate entitlement — the employee's grade, shift, which meals they are eligible for on that day, and whether they have already consumed the meal in question. The transaction is recorded locally and synced to the central web portal over the facility's network.
The entitlement engine handles the complexity that made the coupon system unwieldy to administer: different employee grades attract different subsidies; shift workers are entitled to different meals than day workers; visitors and contractors may be permitted to purchase meals at full cost rather than the subsidised rate. All of this is configured once in the web portal and pushed to every terminal automatically. There is no manual configuration at the terminal level.
The web portal gave three distinct stakeholder groups what they needed:
- Canteen contractors: Daily and monthly transaction reports by meal type and count. Billing is generated from the system rather than from coupon reconciliation. No disputes over whether 847 or 863 coupons were collected — the system records exactly which employee ate what, at what time, at which terminal.
- HR and industrial relations: Aggregate reports on meal uptake by facility, shift, and employee grade. Subsidy cost broken down by beneficiary category. Year-over-year trend analysis for budget planning.
- Employees: Self-service portal showing individual meal history, remaining entitlements for the month, and deduction details. Eliminated a category of queries to HR that previously occupied administrative time.
The subsidy leakage problem resolved entirely. The system will not process a transaction for a card that does not match an eligible employee for that meal at that time. There is nothing to hand to someone else, nothing to accumulate and sell, nothing to misuse. The card is bound to the person.
Results: throughput, accuracy, and data
The throughput improvement was the most immediately visible outcome. Three seconds per transaction — card tap, validation, confirmation, move on — compared to the eight to twelve seconds of the coupon exchange. At a high-volume canteen counter processing 400 employees in a 30-minute window, this difference is the gap between an orderly queue and a bottleneck that bleeds into working time.
Transaction accuracy reached 100% in the sense that matters operationally: every recorded transaction corresponds to a specific eligible employee consuming a specific meal at a specific time. The contractor billing discrepancies that had previously required monthly reconciliation meetings ceased entirely. The billing figure from the system is the billing figure — there is no alternate count to argue against.
For HR, the data dividend arrived quickly. Within two months of going live, the organisation had meal uptake patterns they had never seen before: which facilities were under-serving their employee population (long queues, insufficient capacity), which shifts had low uptake suggesting scheduling mismatches between canteen hours and shift end times, and the distribution of subsidy cost across employee grades. The data did not produce immediate policy changes, but it gave HR a factual basis for decisions they had previously been making by intuition or not making at all.