A table code that takes the order and the payment, so nobody walks twice

A printed code on the table opens your live menu in the guest's own browser, takes the order, takes the payment, and puts a ticket in front of the kitchen without anyone carrying it there. It removes the two trips that cost a venue most — the walk to take the order and the walk to fetch the bill — and the guesswork that follows, because every item is attached to a table, a time and a person.

Autonomous QR ordering ecosystem
Sector
Hospitality & retail

The operational problem this was built for

In a full venue the constraint is rarely the kitchen; it is how many trips a waiter can make in an hour. A table waits to be noticed, waits again for the bill, then waits for change or a mobile money confirmation, while the waiter is at the till keying an order from memory. At close, the till roll, the wallet statement and the chit book are three accounts of the same evening.

What was already on site, and what we used

Nothing here starts with new hardware for the guest: it starts with the phone in their pocket, the venue Wi-Fi or their own mobile data, and a laminated code that survives being wiped down twice a shift. On the venue side we use the point of sale and kitchen printer already installed, the handsets the team already carries, and your existing card and mobile money arrangements. Where a venue has no till the system is the till; where the till works, we integrate rather than replace it mid-season.

What we built on top of it

Every table, room, sun lounger or counter gets its own code, so the system knows where an order came from without anyone typing a table number. The menu is a web page with nothing to install, priced in the currencies you actually accept, with items that grey out as stock runs down. Behind it sits an order router that sends each line to the right printer, a stock ledger that decrements as orders are accepted, and an exception queue for anything unusual.

A day on the floor

Orders arrive as timed tickets at the section they belong to — drinks to the bar, starters to the cold section — so a waiter carries food out instead of walking in to collect a request. Staff keep a screen for their own tables and can add an item or pull a bill back for correction. At close the manager reads one report by department, currency and payment method.

Where it connects to the rest of the business

The ordering layer earns its place by posting into the systems that already hold your money and your guests. Sales write to the point of sale or the accounting package, room service and poolside bills post to the guest folio in Hotel OS, and recipe-level consumption goes to the stock ledger so purchasing follows what was sold. A phone number given at payment, with consent, flows into InOne CRM — our customer relationship platform.

What it covers

No application to install

The code opens a web page in the guest's own browser, and behaves the same on an inexpensive Android handset as on a new iPhone.

Priced in the currencies you trade in

The conversion rule is yours and is printed on the bill. A payment split across cash, card and mobile wallet still closes as one settled ticket.

Stock that tells the truth at the table

Items grey out as the kitchen or bar marks them down, so the disappointment happens once rather than on every table all evening.

Waiters keep the relationship

Staff come out of the queue at the till, not off the floor. Every table keeps a named server who can correct an order or handle a complaint.

One close of business

Sales by department, currency and payment method, with voids, comps and discounts attributed to whoever authorised them, and variances listed.

How it works

01

Site assessment, week zero

We work a service with you — floor, pass, bar, till and back office — recording your menu and recipes, existing till and printers, payment arrangements and Wi-Fi coverage at the furthest table. Codes are planned from that walk, not from a floor plan.

02

Integration, weeks one to three

Menu, modifiers, recipes, currencies and staff roles are loaded, and the till, printers, payment rails and accounting package connected. The system observes real service alongside your current method before it may post a sale or print a ticket.

03

Rules and guardrails, week four

Discount limits, unpaid tables at the cut-off, when an order is held for a supervisor, and how refunds and room charges are authorised are configured, then tested against your own historical trade before the system may act.

04

Go live and optimise, week five onward

One section goes live first, usually the hardest to serve, and the rest follows once the team is comfortable. A first system typically takes four to six weeks, with weekly reviews afterwards to tune menu layout and ticket routing.

Questions buyers ask

Do we have to get rid of our waiters?

No, and venues that try it usually regret it. The point is to take ordering and payment trips off the floor so the same team can look after more tables properly; the system assumes a named server still owns every table.

What about guests who will not scan a code?

A waiter takes the order on a handset and it joins the same queue, so the kitchen, the stock ledger and the close of business report do not care which route it came in by. Running both is the normal state, not a transitional one.

Our Wi-Fi does not reach the garden. Is that fatal?

Usually not — most guests order on their own mobile data, and the staff side runs on equipment inside the building. Where coverage genuinely matters we find the dead spots at the site assessment and quote the access points separately.

How does the money actually reach us?

Through your own merchant and mobile money arrangements, in your own name. We integrate with the rails you already use rather than becoming a payment processor, so settlement times, fees and the bank relationship stay as they are.

Is it running anywhere we can look at?

QR ordering ships as part of the Hotel OS build now in progress at Highlands House, a boutique guest lodge in Harare with thirty-six en-suite rooms, gardens, a pool and a garden restaurant. It is a useful test because the restaurant serves residents and outside diners, and the poolside and garden are the hardest places for a waiter to cover.

Platform briefing

Book a platform briefing

Fifteen minutes with an engineer who will ask how orders reach your kitchen today, how bills are settled and in which currencies, and where your team loses the most trips. Email sales@eigenstatesystems.com or WhatsApp +263 77 636 6999.

sales@eigenstatesystems.com · +263 77 636 6999 · Harare