QR-Bestellung im Restaurant: Zeigt der Code nur die Karte oder löst er einen Auftrag aus?

Ein QR-Code auf dem Tisch kann eine Speisekarte öffnen. Daraus folgt noch nicht, dass Gäste darüber bestellen können oder dass eine Auswahl bereits beim Service angekommen ist. Klären Sie vor einer Einführung, ob Sie Informationen bereitstellen oder einen zusätzlichen Bestellkanal betreiben wollen. Der zweite Fall verändert die Arbeit im Restaurant, nicht nur die Darstellung der Karte.

Dieser Beitrag hilft beim Briefing für eine Gästeoberfläche. Er behandelt keine Lebensmittelsicherheit, Allergenberatung oder rechtliche Prüfung des Bestellabschlusses. Solche Anforderungen brauchen eine gesonderte fachkundige Klärung. Prüfen Sie zuerst, was Ihr vorhandenes Kassensystem bereits zuverlässig unterstützt.

Drei Angebote nicht unter demselben Namen verkaufen

Beschreiben Sie den gewünschten Ablauf in einem Satz: Gäste lesen die Karte, Gäste übermitteln eine Bestellung vom eigenen Telefon oder Gäste bestellen an einem bereitgestellten Terminal. Diese Angebote brauchen unterschiedliche Bedienung, Betreuung und Abnahme.

Die Odoo-19-Dokumentation zur Selbstbestellung unterscheidet entsprechend zwischen „QR menu“, „QR menu + Ordering“ und „Kiosk“. Die erste Variante öffnet die Karte beziehungsweise den Katalog. Die zweite ermöglicht zusätzlich Bestellung und Zahlung. Das belegt konkrete Produktvarianten, nicht den Leistungsumfang jedes beliebigen QR-Angebots.

Lassen Sie die gewählte Variante von einem normalen Gastgerät aus vorführen. Eine Vorschau im Verwaltungsbereich genügt nicht. Wer eine reine Karte öffnet, sollte keine Schaltfläche sehen, die eine tatsächliche Bestellung nur vortäuscht. Wer bestellen kann, braucht einen klaren Unterschied zwischen ausgewählten Positionen und dem übermittelten Auftrag.

Tischbezug ist noch kein Identitätsnachweis

Für Restaurants beschreibt Odoo beim Erzeugen der Codes einen Code je verfügbarem Tisch. Bei Geschäften entsteht dagegen ein allgemeiner Code. Deshalb muss Ihr Projekt festlegen, ob der Link bereits einen Tischkontext mitbringt oder ob Gäste einen Ort auswählen müssen.

Ein abfotografierter oder weitergegebener Link beweist nicht, wer gerade am Tisch sitzt. Beschreiben Sie daher, ob Bestellungen nur während eines Besuchs möglich sein sollen und wie die Lösung unpassende Fernbestellungen behandelt. Eine notwendige Bestätigung durch den Service, ein begrenzter Besuchskontext oder andere Schutzmaßnahmen sind zu prüfende Gestaltungsmöglichkeiten, keine hier behaupteten Odoo-Funktionen.

Klären Sie außerdem, wer die aufgestellten Codes kontrolliert und einen falschen oder beschädigten Aufsteller ersetzt. Nach Änderungen an Tischplan oder Anbindung muss der tatsächlich ausliegende Code zur richtigen aktuellen Oberfläche führen. Die Pflege des gedruckten Materials gehört zur Übergabe des Systems.

Bedienort und Zahlungszeitpunkt getrennt festlegen

Soll der Service an den Tisch bringen oder sollen Gäste in einer Abholzone warten? Diese Entscheidung beeinflusst, welche Information Küche und Ausgabe benötigen und welche Rückmeldung Gäste sehen müssen. Eine korrekt gespeicherte Tischnummer hilft wenig, wenn der Betrieb eigentlich eine Abholnummer ausgeben wollte.

Odoo dokumentiert Einstellungen für Bedienort und Zahlungszeitpunkt. Die verfügbaren Kombinationen hängen dort von Bestelltyp, Betriebsart und Bedienort ab. Bei QR-Bestellungen im Restaurant beschreibt die Anleitung für Tischservice Zahlung nach der Mahlzeit oder nach jeder Bestellung; bei Abholung ist die Zahlung nach jeder Bestellung vorgesehen. Das ist keine Zusage, dass jede Zahlungsart in jeder Variante verfügbar ist.

Lassen Sie genau Ihre Kombination zeigen. Wenn am Kassentresen bezahlt wird, darf die Gästeoberfläche nicht aus dem bloßen Absenden einen bezahlten Auftrag machen. Wenn vorab online bezahlt werden soll, braucht die Umsetzung einen geklärten Umgang mit ausstehender oder fehlgeschlagener Zahlung. Die Existenz eines QR-Codes löst diese Zustandsfragen nicht.

Geöffnetes Menü bedeutet nicht geöffnete Bestellannahme

Die Odoo-Anleitung nennt eine konkrete Voraussetzung: Die Kasse muss geöffnet sein, damit Gäste bestellen können. Für Ihr Briefing folgt daraus die Frage, was außerhalb der Bestellannahme noch angezeigt wird. Darf die Karte lesbar bleiben? Wie erfahren Gäste, dass gerade niemand neue Bestellungen annimmt?

Verlangen Sie auch eine Regel für eine bereits geöffnete Seite, wenn die Annahme inzwischen geschlossen wurde. Der verbindliche Schritt muss die aktuelle Berechtigung zur Bestellung prüfen. Eine alte, noch bedienbare Browserseite darf keine falsche Erfolgsmeldung erzeugen. Das ist eine vorgeschlagene Zuverlässigkeitsanforderung und kein geprüfter Bericht über die interne Umsetzung des Anbieters.

Für nicht verfügbare Gerichte und geänderte Preise braucht es ebenfalls eine erneute verständliche Prüfung. Zeigen Sie Gästen die notwendige Änderung und lassen Sie sie ihre Auswahl überdenken, statt unbemerkt einen Ersatz oder einen anderen Betrag zu übernehmen.

Gäste brauchen einen Auftrag, den der Service wiederfindet

Vereinbaren Sie die Bestätigung nach dem Absenden: Welche Referenz kann ein Gast nennen, was wurde bestellt und an welchem Ort soll die Ausgabe stattfinden? Trennen Sie „Auftrag gespeichert“ von „vom Team bestätigt“, wenn Ihr Betrieb tatsächlich eine Bestätigung vorsieht. Zeigen Sie keine Kenntnisnahme, die das System nicht beobachtet hat.

Bei einem Verbindungsabbruch müssen Gast und Service einen vorhandenen Auftrag wiederfinden können. Sonst führt die Aufforderung „einfach noch einmal bestellen“ möglicherweise zu doppelter Arbeit. Der Entwickler soll den Umgang mit ungewissem Übermittlungsergebnis erklären und vorführen. Eine bloße Rückkehr zur leeren Karte ist keine ausreichende Klärung.

Bieten Sie außerdem einen erkennbaren Weg zum persönlichen Service an. Ein leerer Akku, ein unpassendes Gerät oder eine nicht bedienbare Oberfläche darf nicht als stillschweigende Entscheidung gegen eine Bestellung behandelt werden.

Den echten Besuch abnehmen

Nehmen Sie diese Fälle mit fiktiven Bestellungen in Ihre Abnahmekriterien auf:

• Ein Gast erkennt den Unterschied zwischen Karte und Bestellkanal.
• Der ausliegende Code führt zum richtigen Betrieb und vorgesehenen Tischkontext.
• Tischservice und Abholung erzeugen die jeweils vereinbarte Ausgabeinformation.
• Eine geschlossene Annahme verhindert eine irreführende Erfolgsbestätigung, auch auf einer vorher geöffneten Seite.
• Preisänderung und nicht mehr verfügbares Gericht werden vor dem maßgeblichen Abschluss verständlich behandelt.
• Ein unklarer Sendeversuch lässt sich mit dem vorhandenen Auftrag abgleichen, statt blind eine zweite Bestellung anzulegen.
• Zahlungsstand und tatsächliche Bestätigung durch das Team bleiben unterscheidbar.

Bringen Sie zu einem Gespräch über die Restaurantanbindung Ihren Ablauf für Annahme, Zubereitung und Ausgabe mit. Die entscheidende Frage lautet nicht, wie schnell sich ein Code drucken lässt, sondern ob Gäste und Team denselben bestellten Vorgang erkennen und wissen, was als Nächstes geschieht.