From menu to kitchen, in five steps
Platea runs one order record from the moment a diner opens your page to the moment the shift closes. This is the whole path.
The five steps
Each step is a real surface of the product. The panel beside it is the state you would actually be looking at.
Step 1 of 5
Set up the restaurant and the menu
Country, currency and timezone, then your first location with its hours and service modes, then the menu: categories, items, modifiers and prices.
Setup checklist
Restaurant, location, menu
The checklist names what is still missing, and publishing stays closed until the minimum is in place.Step 2 of 5
Share your ordering page or a table QR
Your storefront lives at one path on this instance. Print a table QR for dine-in, or send the link for pickup and delivery.
Your storefront address
platea.saascode.ai/r/your-restaurant
One branded path per restaurant. A table QR carries a signed token, so the table is confirmed before the diner orders.Step 3 of 5
The diner pays online, or on delivery
The cart is priced by the server at every step, and the fee lines are itemised before payment.
Online payment is included in every plan.
Delivery operations and the managed printer bridge are plan-gated. Browser printing stays available everywhere.
Checkout
Priced by the server
Payment methods are listed only when they are proven for this instance. Nothing is offered speculatively.Step 4 of 5
The kitchen prepares, the driver delivers
A paid order becomes an active kitchen ticket. Delivery orders pick up a driver assignment; pickup and dine-in orders end at the counter or the table.
Tickets print from the browser in every plan. The managed bridge requires a compatible workstation; no managed mobile client.
Kitchen display
Active tickets in sequence
On reconnect the board recovers its full active set from the database before it trusts live events, and shows a stale state until it does.Step 5 of 5
A consenting diner can hear from you again
The order record stays with your restaurant. A marketing email goes only to a diner who gave consent, and that consent is checked again at send time.
Campaigns are email. Diner records arrive with Operación; email campaigns are a Grupo capability.
Diner consent
Recorded, then re-checked
Transactional messages about an order travel separately and are never merged into a campaign.
What you can offer depends on what is proven
Payment methods are not a menu of possibilities. A method appears at checkout only when this instance has a ready provider account and the country, currency and method combination has been tested.
- Country
- Currency
- Method
Fail closed
Unsupported country, currency and method combinations are not shown.
An untested combination is hidden rather than offered and then refused at the last step. Cash on delivery is a separate setting and is never an implicit fallback.
Walk the same five steps yourself
The demo runs on sanitised data, from the storefront through to the shift close.