Fallstudie
Dieses Projekt ist unser eigenes Produkt. Das sagen wir dazu, weil es den Unterschied macht: Wir haben es nicht nur entwickelt, wir betreiben es und stehen dafür gerade, wenn etwas nicht funktioniert.
Kassensysteme für die Gastronomie gibt es reichlich. Das Problem ist selten die Funktionsliste, sondern die Rechnung darunter: Lizenzkosten pro Gerät und Monat, Zusatzmodule für Selbstverständlichkeiten, und Verträge, aus denen ein Saisonbetrieb im Winter nicht herauskommt. Dazu kommt eine Bedienung, die auf Vollzeitpersonal ausgelegt ist — nicht auf die Aushilfe, die am Wochenende zum zweiten Mal hinter der Theke steht.
Ein eigenes Kassensystem zu entwickeln ist keine Entscheidung, die man leichtfertig trifft — die Registrierkassenpflicht allein macht aus einem überschaubaren Projekt ein reguliertes. Wir haben es trotzdem getan, weil wir zwei Dinge wollten, die sich nicht zukaufen lassen: volle Kontrolle darüber, wie sich das System im Servicealltag anfühlt, und ein Produkt, an dem sich unsere Arbeitsweise überprüfen lässt, ohne dass ein Kunde seine Zustimmung geben muss.
Die wichtigste Entwurfsentscheidung war, den Gästen nichts zu installieren zu geben. Genau daran scheitern die meisten Bestellsysteme: Wer erst eine App aus dem Store laden, sich registrieren und Berechtigungen bestätigen soll, bestellt lieber beim Personal — und dann war die ganze Investition umsonst. Bei ScanOrderPay öffnet der QR-Code die Karte direkt im Browser des Telefons. Das schließt einige technische Möglichkeiten aus, die eine native App hätte, aber es ist der Unterschied zwischen einem System, das benutzt wird, und einem, das installiert werden müsste.
Die österreichische Registrierkassensicherheitsverordnung schreibt vor, dass Barumsätze signiert und lückenlos protokolliert werden. Das lässt sich nicht nachträglich anflanschen, ohne das Datenmodell umzubauen — deshalb war die Signatur Teil des ersten Entwurfs, nicht des zweiten. Dieselbe Logik wenden wir in Kundenprojekten an: Anforderungen, die aus Gesetzen kommen, gehören in die Architektur, nicht in die Nachbesserung.
ScanOrderPay läuft im Restaurant mit Tischservice, beim Feuerwehrfest, am Messestand und beim Ab-Hof-Verkauf. Das sind vier grundverschiedene Abläufe: Im Restaurant gibt es feste Tische und eingeschultes Personal, beim Vereinsfest wechseln die Freiwilligen stündlich und niemand hat Zeit für eine Einweisung. Ein System, das beides bedienen soll, muss in der Grundeinstellung so einfach sein, dass es ohne Erklärung funktioniert — und trotzdem genug hergeben, wenn ein Betrieb mehr braucht. Diese Spannung aufzulösen war aufwendiger als jede einzelne Funktion.
Ein Kassensystem ist nicht fertig, wenn es ausgeliefert ist. Steuerliche Vorgaben ändern sich, Geräte werden getauscht, Betriebssysteme aktualisiert. Wir betreuen das System laufend — und weil wir es selbst betreiben, treffen uns Fehler direkt statt über ein Ticket. Das prägt, wie sorgfältig man baut.
ScanOrderPay hat eine eigene Marke und eine eigene Website. Dort finden Sie Funktionsumfang, Konditionen und Einsatzbeispiele im Detail.
Ergebnis
Das System ist im Einsatz und wird laufend weiterentwickelt.
Für Sie als Auftraggeber ist die interessantere Zahl ohnehin eine andere: Wir halten ein Produkt am Laufen, dessen Ausfall uns unmittelbar trifft. Wer das tut, baut anders — sorgfältiger an den Stellen, die im Betrieb wehtun, und zurückhaltender bei Funktionen, die niemand braucht.
Übertragbar
Stoßzeit, wechselndes Personal, Gäste ohne Vorkenntnis. Die Frage ist nicht, ob das System unter Idealbedingungen funktioniert, sondern ob es jemand bedienen kann, der es zum ersten Mal sieht.
Registrierkassenpflicht, DSGVO, Aufbewahrungsfristen — wenn das erst am Ende kommt, wird es teuer.
Eine Schicht mitlaufen bringt mehr Erkenntnis als drei Workshops. Deshalb ist die Konzeptphase bei uns kein Papierprozess.
Wenn Sie ein System brauchen, das im Echtbetrieb bestehen muss — erzählen Sie uns davon. Im Erstgespräch sagen wir Ihnen, wo die Fallstricke liegen.
