Anyone who has walked into a fast-food chain in recent years knows the kiosk: a tall screen, a menu with photos, and the order paid for before you reach the counter. What you don't see is the rest of the system, and that is where the work is. I built a complete demo, with a fictional brand and a sample menu, where the kiosk, the kitchen display and the pickup screen work together. This post walks through it end to end and draws a clear line between what the demo simulates and what a real install needs.
The three screens
A kiosk on its own is just a nice form. The system has three screens, each with a job:
- Kiosk. A portrait touchscreen, 1080×1920. The customer picks a language, says whether they are eating in or taking away, builds the order and pays.
- Kitchen. A landscape screen, 1920×1080, with three columns: New, In preparation and Ready. Each order shows its number, the changes highlighted, and how long it has been waiting. The timer turns amber at 5 minutes and red at 10. It is always in Portuguese, even when the customer ordered in English.
- Pickup. The screen customers watch while they wait. When the kitchen marks an order as ready, its number appears in large type with a chime.
Numbers run on their own (A001, A002, A003), and a screen opened later shows the orders that already exist. On the demo page you can place an order on the kiosk and follow it through: tap Começar (start) and then Pronto (ready) on the kitchen screen, and the number moves to the pickup screen. There is also a "Simular pedidos" (simulate orders) button that sends in sample orders for two minutes, so you can see the kitchen busy.
How they stay in sync
In the demo, all three screens run in the same browser. Orders are stored in localStorage, and a BroadcastChannel tells the other screens something changed. Every change reads the latest state and writes it back in one step, because three screens writing at once would drop orders if each saved the copy it held in memory.
That is enough to show the flow, but it only works on one computer. In a restaurant the kiosk, the kitchen and the pickup screen are separate devices, so they need a small server that holds the orders and pushes them to each screen live. It is not a big piece, but it is the first thing that changes between the demo and an install.
Ordering at the kiosk
The path is short: tap to start, language, eat in or take away, menu, basket, tax number, payment, and a confirmation with the order number. A few parts deserve a closer look.
Suggesting the meal and the dessert
Every prego (steak roll) or burger asks whether you want to make it a meal with chips and a drink, and before payment the kiosk suggests a dessert. It is the suggestion a member of staff would make if they had the time. The kiosk makes it every time, without rushing and without pushing. I have no figures of my own on how much this raises the average order, and I am wary of anyone who quotes one without knowing the restaurant.
Allergens
Each item shows its allergens with an icon and a name, in Portuguese and English. The list is based on the 14 substances in Annex II of Regulation (EU) No 1169/2011, and according to DGAV, the Portuguese food authority, allergen information must be given to the consumer for non-prepacked food too, such as a restaurant's. A kiosk is a good place to show it, but the information is only as reliable as the recipe sheet behind each dish.
Tax number
The customer's NIF, the Portuguese tax number, is typed on a numeric keypad and checked before payment: nine digits, a valid prefix and a check digit. That catches typos. It does not confirm the number belongs to the person typing it, and it isn't meant to.
Payment
Three options: Multibanco card payment on the terminal next to the kiosk, MB WAY with a mobile number, or paying at the counter. Choosing MB WAY opens a keypad for the number and then a screen asking the customer to approve the payment in the app.
The small things that prevent problems
- Idle reset. After 45 seconds without a touch, the kiosk asks "Are you still there?" and counts down 15 seconds before starting over. It never happens on the payment screens, so a payment is never cancelled halfway.
- Accessibility mode. Moves every button to the bottom half of the screen, within reach of someone seated or shorter.
- Sound on the pickup screen. Browsers only allow sound after someone has interacted with the page, so the pickup screen has a button to turn the chime on. In an install, that is handled once when opening for the day, or in the device setup.
What the demo simulates
It is worth being explicit, because a convincing screen easily hides what is missing:
- Payment. There is none. Choosing Multibanco or MB WAY shows the waiting screen for a few seconds and then treats the payment as accepted. The MB WAY number is not sent anywhere.
- Invoice. The tax number is validated and stored with the order, but no document is issued.
- Sync. Only between tabs of the same browser, as described above.
- Menu and brand. The brand is fictional, and the menu and prices are examples.
What a real install needs
Hardware
A portrait touchscreen on a stand or kiosk enclosure, a screen in the kitchen, another where customers wait, and a reliable network. The system runs in the browser with nothing to install, which leaves room in choosing the hardware. The specific choice depends on the space, the volume and the budget, and is made case by case. One question to answer early: what happens when the internet drops in the middle of lunch.
Payments
Real MB WAY goes through a payment provider, which sends the request to the customer's app and tells the system when it is approved. Cards go through the payment terminal, and how that connects to the kiosk depends on the terminal and whoever supplies it. Paying at the counter is the simplest, but it forces a decision: does the order go to the kitchen straight away, or only once the till confirms payment?
Certified invoicing
There are no shortcuts here. The Portuguese tax authority's FAQ on Decree-Law 28/2019 puts it plainly: if you use invoicing software, it must be certified. The list of certified programs is published on the Portal das Finanças.
So the route I suggest is not for the kiosk to issue invoices itself. It is to hand the order, the tax number and the payment to the certified invoicing software the restaurant already uses, and let that software issue the document. That depends on the software offering some way to integrate, which is one of the first things I ask. Check with your accountant what applies to you; this is not tax advice.
When it pays off, and when it doesn't
Pays off
- Queues at the counter at peak times, with customers giving up or waiting too long.
- Menus with lots of changes (no onion, extra cheese), where mistakes in taking the order cost food and time.
- Foreign customers, who order better in their own language than by pointing at a board.
- Takeaway and quick service, where customers collect their order at the counter.
Doesn't pay off
- Table service with waiting staff, where orders are already taken at the table.
- A handful of orders a day: the counter is not the bottleneck.
- Customers who would rather talk to someone and see the screen as a barrier.
- Invoicing software with no way to integrate, which means entering everything twice.
A kiosk does not replace the staff. It takes the repetitive part, taking orders and payment, off their hands and leaves them in the kitchen and at the pickup counter, where they are needed.
In short
The screen the customer touches is the easy part. What decides whether a kiosk works is the link between the three screens, the payment and the invoicing software. The demo shows the full flow; an install connects it to what the restaurant already has. If you would like to see how it would look with your menu, get in touch.