Warum die meisten Kassensysteme Gastronomen im Stich lassen

Freitagabend. 180 Reservierungen, jeder Tisch besetzt, Warteliste an der Tür. Die Küche läuft auf Hochtouren, der Barkeeper hat drei Cocktails gleichzeitig in der Hand, das Serviceteam gibt alles. Dann passiert es: Der Router setzt für drei Sekunden aus.

Drei Sekunden. Mehr braucht es nicht.

Das Kassensystem friert ein. Der Barkeeper kann keine Tabs schließen. Die Servicekraft kann die Rechnung nicht splitten. Die Küche bekommt keine neuen Bestellungen mehr. Und plötzlich stehst du da und schreibst Bestellungen auf Servietten, wie im Jahr 1995.

Ich habe das erlebt. Nicht einmal, nicht zweimal, sondern so oft, dass ich irgendwann aufgehört habe zu zählen. Jahre in der Gastronomie, in Restaurants und Brauhäusern, später in Hostels und Hotels auf drei Kontinenten. Und überall das gleiche Bild: Kassensysteme, die im Alltag versagen, wenn es drauf ankommt.

Das Problem ist nicht, dass es keine Kassensysteme gibt. Es gibt Hunderte. Das Problem ist, dass die meisten nicht für die Gastronomie gebaut wurden. Nicht wirklich. Sie wurden für Demos gebaut, für Pitch-Decks und für Messestände. Und wenn dann Freitagabend ist und 200 Gäste gleichzeitig bestellen wollen, zeigt sich, was diese Systeme tatsächlich wert sind.

Das Versprechen vs. die Realität

Jedes Kassensystem sieht in der Demo großartig aus. Saubere Oberfläche, hübsche Animationen, alles reagiert sofort. Der Vertriebler klickt sich durch ein paar Bestellungen, zeigt die Berichte, macht vielleicht eine Tischreservierung auf. Sieht gut aus. Kauf ich.

Aber Demos haben keine 200 Gäste. In Demos verschüttet niemand ein Bier auf das Terminal. In Demos ist kein neuer Kellner, der gerade seinen ersten Abend hat und unter Stress die falschen Buttons drückt. In Demos klemmt kein Bondrucker, fällt kein WLAN aus und schreit kein Küchenchef, weil seine Bons nicht ankommen.

Genau in dieser Lücke zwischen Demo und Samstagabend-Service machen die meisten Kassensysteme Probleme. Und diese Lücke ist riesig.

Ein System, das unter Laborbedingungen funktioniert, ist wertlos, wenn es unter realen Bedingungen zusammenbricht. Gastro ist kein Einzelhandel. Gastro ist Chaos, das du in Echtzeit managst. Jede Sekunde, die dein System braucht, um zu reagieren, kostet dich Geld und Nerven. Jeder zusätzliche Klick, den ein gestresster Kellner machen muss, ist ein Fehler, der passieren wird.

Ich habe Systeme gesehen, die auf einem brandneuen iPad wunderschön liefen. Und dann hast du sie sechs Monate im Einsatz, das iPad hat Kratzer, der Speicher ist voll, das WLAN hat Interferenzen von drei Nachbarnetzen. Plötzlich braucht jede Bestellung vier Sekunden statt einer. Vier Sekunden klingt nach nichts. Multiplizier das mit 300 Bestellungen am Abend. Das sind über 20 Minuten verlorene Zeit. Pro Schicht.

Offline-Modus, der keiner ist

„Unser System funktioniert auch offline." Diesen Satz höre ich auf jeder Messe und in jedem Verkaufsgespräch. Es ist der Satz, der am häufigsten gelogen wird.

Was die meisten Anbieter als „Offline-Modus" verkaufen: Das System friert nicht komplett ein, wenn das Internet wegfällt. Das war's. Kein Absturz. Aber auch kein funktionierender Betrieb.

Was in der Realität passiert, wenn das WLAN ausfällt und dein System angeblich offline kann:

• Bestellungen gehen verloren, sobald die Verbindung zurückkommt. Das System weiß nicht, wie es lokale und Server-Daten zusammenführen soll. Ergebnis: fehlende Bestellungen oder Duplikate.
• Kartenzahlungen funktionieren nicht. Das Terminal braucht Internet. Der Gast steht an der Bar und will mit Karte zahlen, und du musst sagen: „Nur Bargeld gerade." Im Jahr 2026.
• Daten laufen auseinander. Zwei Terminals haben während des Ausfalls unterschiedliche Bestellungen aufgenommen. Wenn das Netz zurückkommt, hat das System zwei verschiedene Versionen der Wahrheit. Welche stimmt? Keine. Du darfst den Rest des Abends manuell abgleichen.
• Oder, am schlimmsten: Das System zeigt einfach einen Ladebildschirm. Kein Offline-Modus, kein Fallback, keine Fehlermeldung. Einfach ein drehender Kreis, während sich die Schlange an der Kasse bis zur Tür staut.

Ein echter Offline-Modus bedeutet: Das System läuft komplett lokal weiter. Du kannst Bestellungen aufnehmen, Tische verwalten, Bons drucken, Rechnungen erstellen. Alles wird lokal gespeichert. Und sobald die Verbindung zurückkommt, synchronisiert sich alles automatisch im Hintergrund. Ohne Datenverlust, ohne Duplikate, ohne dass du irgendetwas tun musst.

Das ist kein Nice-to-have. Für einen Gastro-Betrieb ist das eine Grundvoraussetzung. Dein Internet wird ausfallen. Die Frage ist nicht ob, sondern wann. Und wenn es soweit ist, muss dein System einfach weiterlaufen.

Hardware-Lock-in und versteckte Kosten

Du unterschreibst einen Vertrag für ein Kassensystem. Die monatliche Gebühr sieht fair aus. Und dann kommt die Hardware-Liste.

Ein proprietäres Terminal, das dreimal so viel kostet wie ein Standard-Tablet. Ein Kartenleser, der nur mit diesem einen System funktioniert. Ein Drucker, der nicht von einem normalen Hersteller kommt, sondern ein umgelabeltes Gerät ist, das du nur über den Anbieter nachbestellen kannst, natürlich mit Aufschlag.

Und dann bist du eingeschlossen. Du kannst nicht einfach wechseln, weil du Hardware für tausende Euro hast, die mit keinem anderen System funktioniert. Du kannst nicht mal den Zahlungsanbieter wechseln, weil das Terminal nur einen Prozessor unterstützt. Du bist an einen Anbieter gekettet, nicht weil er der beste ist, sondern weil der Wechsel zu teuer wäre.

Dann sind da die versteckten Kosten. Das System startet bei 29 Euro im Monat. Klingt gut. Aber dann brauchst du die Tischverwaltung: Aufpreis. Dann brauchst du mehrere Terminals: Aufpreis pro Gerät. Dann willst du Berichte exportieren: Aufpreis. Dann brauchst du eine API-Anbindung an deine Buchhaltung: auch Aufpreis. Nach einem Jahr zahlst du 150 Euro im Monat für Funktionen, die du von Tag eins gebraucht hättest.

Und die Transaktionsgebühren. „Kostenlos" steht auf der Website. Kein monatlicher Preis. Was dort nicht steht: 1,9 Prozent pro Transaktion. Bei einem Restaurant, das 30.000 Euro im Monat über Kartenzahlung abwickelt, sind das 570 Euro. Jeden Monat. Das „kostenlose" System kostet dich fast 7.000 Euro im Jahr allein an Transaktionsgebühren.

Rechne immer die Gesamtkosten über 12 Monate. Hardware, Software, Transaktionsgebühren, Add-ons. Der echte Preis ist fast immer deutlich höher als das, was auf der Website steht. Und wenn du dich für einen transparenten Anbieter entscheidest, bei dem du von Anfang an siehst, was du zahlst, sparst du dir böse Überraschungen, und meistens auch echtes Geld. In unserem Kassensystem-Ratgeber für 2026 gehen wir im Detail auf diese Kostenfallen ein.

Retail-Software im Gastro-Gewand

Hier liegt das eigentliche Problem vieler Kassensysteme: Sie wurden nicht für die Gastronomie entwickelt. Sie wurden für den Einzelhandel gebaut, und dann hat jemand ein Restaurant-Icon auf die Website gesetzt und ein paar Felder umbenannt.

Du erkennst diese Systeme an einer ganzen Reihe von Symptomen.

Die Tischverwaltung fühlt sich angebaut an. Statt dass der Tischplan das Herzstück des Systems ist, wirkt er wie ein Nachgedanke. Du kannst vielleicht Tische anlegen, aber die Interaktion ist umständlich: Tisch öffnen, Bestellung aufnehmen, speichern, zurücknavigieren, nächsten Tisch. Was in einem guten Gastro-System zwei Wischgesten braucht, kostet hier fünf Klicks.

Es gibt kein Konzept von Gängen. In einem Restaurant bestellen Gäste einen Vorspeise-Gang und einen Hauptgang. Die Küche muss wissen, wann sie was zubereiten soll. Retail-Systeme kennen das nicht. Für sie gibt es nur eine Bestellung, eine Liste von Artikeln. Gangreihenfolge? Fehlanzeige. Du musst es entweder im Kommentarfeld vermerken oder dem Koch zurufen.

Split-Rechnungen sind ein Krampf. Vier Leute sitzen am Tisch, jeder will seine eigenen Getränke und den Nachtisch anteilig zahlen. In einem guten System: drei Klicks. In einem umgewidmeten Retail-System: sechs Bildschirme, fünf Bestätigungsdialoge und am Ende stimmt der Betrag trotzdem nicht, weil das System Trinkgeld und Rabatte beim Splitten falsch verrechnet.

Modifier sind ein Nachgedanke. „Steak medium rare, ohne Soße, mit extra Beilagensalat statt Pommes." Das ist eine normale Gastro-Bestellung. In Retail-Systemen sind Modifier, also die Anpassungen an einem Gericht, meistens eine Notlösung. Entweder es gibt nur ein Freitextfeld, oder die Modifier sind so umständlich zu konfigurieren, dass dein Team sie gar nicht erst nutzt und die Anpassungen mündlich an die Küche weitergibt.

Kitchen Routing existiert nicht oder funktioniert kaum. In einem richtigen Gastro-Betrieb geht die Vorspeise an den Kalte-Posten, das Steak an den Grill, das Dessert an die Pâtisserie und die Getränke an die Bar. Ein gutes System routet die Bestellung automatisch an die richtige Station. Ein Retail-System druckt einfach alles auf einen Bon, und dein Team sortiert es von Hand.

Und dann ist da das Thema offene Tabs. Ein Gast setzt sich an die Bar, bestellt über den Abend verteilt fünf Drinks und zahlt am Ende. Das ist ein offener Tab. Für Gastro völlig normal, für Retail-Software ein Fremdwort. Stattdessen musst du jede Bestellung als eigenen Vorgang abschließen oder dir mit Workarounds helfen, die niemand verstehen will.

Wenn du das nächste Mal ein System evaluierst, frag dich: Wurde das für meinen Betrieb gebaut, oder wurde es für einen Schuhladen gebaut und dann umlackiert?

Updates, die niemand gefragt hat

Montagmorgen, 9 Uhr. Du öffnest das System, um den Tag vorzubereiten. Die Oberfläche sieht anders aus. Die Buttons sind nicht mehr da, wo sie gestern waren. Das Farbschema hat sich geändert. Irgendein Menü-Punkt heißt jetzt anders.

Was ist passiert? Ein automatisches Update. Über Nacht. Ohne Vorwarnung, ohne Changelog, ohne die Möglichkeit, es abzulehnen.

Dein Team hat wochenlang gelernt, wo welcher Button ist. Die neue Kellnerin hat endlich den Ablauf drauf. Der Koch weiß genau, wo er seine Bestellungen sieht. Und jetzt ist alles anders. Nicht grundlegend, nur genug, um jeden zu verwirren und den ganzen Tag Fehler zu produzieren.

Das Schlimmere: Manchmal verschwinden Funktionen. Ein Feature, das du täglich nutzt, ist plötzlich weg. Nicht kaputt, sondern weg. Weil der Anbieter entschieden hat, dass es nicht mehr ins Produkt passt. Oder weil es jetzt nur noch im Premium-Paket enthalten ist.

Ich kenne Betriebe, bei denen ein Update mitten im Service kam. Nicht morgens, nicht nachts, sondern während des Abendgeschäfts. Das System hat sich für zwei Minuten aktualisiert und war nicht verfügbar. Zwei Minuten um 20 Uhr an einem Samstag. Rechne dir aus, was das kostet.

Software-Updates sind notwendig. Keine Frage. Aber in der Gastronomie müssen sie planbar, transparent und kontrollierbar sein. Du musst entscheiden können, wann du aktualisierst. Du musst vorher wissen, was sich ändert. Und du musst die Möglichkeit haben, ein Update zu verschieben, wenn es nicht in deinen Betriebsablauf passt.

Support, der erst ab Premium antwortet

Es ist Samstagabend, 20:30 Uhr. Dein Kassensystem zeigt einen Fehler, den du noch nie gesehen hast. Bestellungen werden nicht an die Küche gesendet. Du hast 25 Tische, die warten. Du brauchst jetzt Hilfe.

Du öffnest das Support-Portal. „Bitte beschreiben Sie Ihr Problem. Durchschnittliche Antwortzeit: 48 Stunden."

48 Stunden. Dein Abendservice ist in drei Stunden vorbei. In 48 Stunden ist der Schaden längst passiert: schlechte Google-Bewertungen, frustrierte Gäste, frustriertes Team, verlorener Umsatz.

Aber du hast ja den Basis-Tarif. Support per E-Mail, Antwort innerhalb von zwei Werktagen. Für telefonischen Support musst du upgraden. Für Priority-Support nochmal. Und der „Premium-Support mit garantierter Reaktionszeit"? Nochmal 50 Euro im Monat obendrauf.

Das ist, als würde dir eine Versicherung verkauft, die nur zahlt, wenn du die teurere Versicherung kaufst.

Guter Support in der Gastronomie bedeutet: Da geht jemand ran. Nicht morgen, nicht in 48 Stunden, sondern jetzt. Und die Person am anderen Ende versteht, was „Rush Hour" bedeutet. Sie schlägt nicht vor, das Gerät neu zu starten, während du 50 wartende Gäste hast. Sie versteht, dass jede Minute zählt und dass dein Problem nicht bis Montag warten kann.

Wenn ein Anbieter seinen Support hinter Bezahlschranken versteckt, sagt dir das etwas über seine Prioritäten. Und die liegen nicht bei dir.

Wie ein System aussieht, das für Gastro gebaut wurde

Ich werde dir jetzt keine Feature-Liste vorlesen. Stattdessen will ich dir beschreiben, woran du erkennst, dass ein System wirklich für die Gastronomie entwickelt wurde. Nicht für eine Messe, nicht für einen Investor, sondern für den Freitagabend mit 200 Gästen.

Es wurde von Leuten gebaut, die selbst in der Gastro gearbeitet haben. Nicht von Leuten, die mal in einem Restaurant gegessen haben und dachten, „das könnte man besser machen." Sondern von Leuten, die selbst Tische geräumt, Bons geschrieben, unter Stress kassiert und nach Feierabend den Boden gewischt haben. Leute, die wissen, wie es sich anfühlt, wenn das System im falschen Moment nicht macht, was es soll.

Offline-Funktionalität ist kein Feature, sondern die Architektur. Das System wurde von Grund auf so gebaut, dass es ohne Internet funktioniert. Nicht als Notfall-Modus, nicht als abgespeckte Version, sondern als vollwertiger Betrieb. Internet ist ein Bonus für Synchronisierung, nicht eine Voraussetzung für den Betrieb.

Es läuft auf normaler Hardware. Kein proprietäres Terminal, kein spezieller Drucker, kein Kartenleser, der nur mit diesem einen System funktioniert. Normales Tablet, Standard-Peripherie. Wenn ein Gerät kaputtgeht, gehst du in den nächsten Laden und kaufst ein neues. Kein Anruf beim Anbieter, kein Warten auf Lieferung, kein Lock-in.

Transparente Preise. Was auf der Website steht, ist das, was du zahlst. Keine versteckten Aufpreise für Basisfunktionen, keine Gebühren, die sich nach sechs Monaten ändern, keine „Starter"-Pakete, bei denen die Hälfte fehlt. Du siehst den Preis, du kennst den Preis, du zahlst den Preis.

Support behandelt deinen Samstagabend-Ausfall als Notfall. Weil er einer ist. Nicht als Ticket mit niedriger Priorität, nicht als E-Mail, die am Montag bearbeitet wird. Als das, was er ist: ein akutes Problem, das deinen Betrieb lahmlegt und sofort gelöst werden muss.

Das sind keine unrealistischen Erwartungen. Das sind Grundlagen. Und wenn dein aktuelles System diese Grundlagen nicht erfüllt, ist es vielleicht an der Zeit, zu fragen, warum du es noch benutzt.

Wir bauen Kotao, weil wir es leid waren, mit Systemen zu arbeiten, die nicht für uns gemacht sind. Wenn du wissen willst, woher wir kommen und warum wir das anders angehen, lies unsere Geschichte.