Multimodale bestellingen: QR, bediening en telefoon aan een tafel

Vrijdagavond in Eskisehir: vijf gasten aan tafel. Twee bestellen via QR, twee via de POS van de bediening, de vijfde belt voor een afhaalbestelling. Drie kanalen, een tafel, een rekening — en 2.300 bestellingen per maand komen netjes uit in een enkele table_session.

Een sessie, meerdere bronnen

Elke tafel opent een table_session met 1-uur TTL. QR, POS en telefoon delen dezelfde session_token; het veld order_source registreert de herkomst.

De afsluitafstemming daalde van 40–50 minuten naar 3 minuten.

Atomic writes

Gelijktijdige POSTs worden afgehandeld via een Idempotency-Key van crypto.randomUUID() en een atomic db.batch() in D1.

• QR en POS schrijven zonder botsing.
• Server forceert canonieke prijs.
• Shadowban per bron afzonderlijk.

Technisch antwoord op "Unified Orders"

Concreet: een order_source enum, gedeelde FK table_session_id en kleurgecodeerde KDS-kaarten per bron. Telefoon blauw, QR groen.

Oudere gasten verkiezen de bediening en vangen zo 18% gebruik dat QR alleen zou missen.

FAQ

Hoe komt een telefoonbestelling in de juiste sessie? De bediening kiest het tafelnummer; bestaande open sessie wordt hergebruikt, anders nieuw aangemaakt.

Twee QR-gebruikers voegen tegelijk hetzelfde item toe? Twee order_item-rijen, twee KDS-kaarten — bedoeld.

Wat bij 1-uur TTL? Openstaande tabs blijven; de 04:00 UTC cron ruimt alleen gesloten sessies.

Was dit nuttig? Deel het.