KoratZwei Betriebstypen teilen sich diese Terminbuchung: service und clinic. Sie laufen auf demselben Code — Leistungen, Termine, Zuweisung, Pakete — und der Typ Praxis benennt die Oberfläche in Termine, Patienten und Behandlungsserien um, weil eine Zahnarztpraxis und ein Nagelstudio dasselbe Buchungsproblem in anderen Worten haben. Die Typwahl ändert das Vokabular und nichts an der Struktur: Ein eigenes Praxisprodukt würde binnen zweier Versionen vom Serviceprodukt abdriften.
Eine Leistung ist eine Dauer und ein Preis, die Sie festlegen
Der Katalog ist eine Liste von Leistungen, jede mit Dauer und Preis. Die Dauer ist keine Zierde — sie macht einen Terminkalender überhaupt erst aussagekräftig, denn eine Behandlung über neunzig Minuten und ein Schnitt über fünfzehn belegen unterschiedlich viel vom selben Tag. Kundschaft stöbert auf der öffentlichen Seite des Betriebs, wählt eine Leistung und bucht sie; diesen Seitenabschnitt liefert das Service-Modul selbst, gebaut aus demselben gemeinsamen UI-Baukasten wie jedes andere Modul, damit er nicht angeklebt wirkt.
Buchen, und die Bestätigung, die der Betrieb selbst drückt
Eine Terminanfrage trägt Namen, Telefonnummer, Datum, Uhrzeit und eine Notiz. Sie kommt offen an, und der Betrieb bestätigt sie. Die Zahl der offenen Termine ist einer der Live-Zähler auf der Übersicht, im Sekundentakt aktualisiert neben laufenden Bestellungen, rufenden Tischen und offenen Urlaubsanträgen — ein Betrieb mit mehreren Modulen hat also eine Stelle, an der alles gezählt wird, was auf einen Menschen wartet.
Der Bestätigungsschritt ist keine Reibung um ihrer selbst willen. Ein System, das automatisch alles annimmt, wofür der Kalender Platz hat, nimmt genau den Termin an, dessen Fachkraft an dem Tag nicht da ist, und die Elf, die nur klappt, wenn die Zehn kürzer wird. Die Annahme zur menschlichen Handlung zu machen hält das Wissen des Betriebs im Ablauf und gibt der Kundschaft eine feste Zusage statt eines Slots, der sich still verschiebt.
Jeder Termin lässt sich einer Person im Team zuweisen. Dieses eine Feld macht aus einer Buchungsliste einen Arbeitstag: Es beantwortet, wer das macht, es gibt Stammkundschaft an dieselbe Person zurück, und es fließt in die Kundenhistorie — der Betrieb weiß also, wegen wem die Leute wiederkommen.
Pakete und vorausbezahlte Serien: N Sitzungen, gültig N Tage
Im Voraus bezahlte Arbeit hat ein eigenes Modell statt eines gewöhnlichen Verkaufs. Ein Paket ist entweder eine Serie aus N Sitzungen, gültig N Tage, oder eine Mitgliedschaft, gültig N Tage. Kundschaft kauft es und löst Sitzung für Sitzung ein; ein Reiter „meine Pakete“ zeigt den Bestand und den Rest. Dieser Restwert ist die maßgebliche Aufzeichnung, auf demselben Backend wie die Termine, die ihn verbrauchen — nicht auf einer gestempelten Karte im Portemonnaie.
Der Kauf eines Pakets zählt außerdem zu den anerkannten Geschäften in der Berechtigungssicht für Bewertungen, wer eine Serie kauft, darf den Betrieb also schon vor der ersten eingelösten Sitzung bewerten.
Es gibt keine SMS-Erinnerungen, weil es kein SMS gibt. Telefonverifizierung und SMS-Versand sind nicht gebaut — der Endpunkt antwortet mit 501 und sagt das auch. Benachrichtigungen erreichen Kundschaft in der App, und E-Mail geht ausschließlich an bestätigte Adressen.
Der Praxistyp ist eine Umbenennung, kein Krankenaktensystem. Er nennt Termine in Patienten und Behandlungsserien um. Er speichert keine Befunde, keine Verordnungen und nichts, was in eine Patientenakte gehört, und ist dafür auch nicht gebaut.
Was der Betrieb drumherum bekommt: Berichte, CRM und Personal
Ein Service- oder Praxisbetrieb bekommt drei Modulkacheln — Termine, Leistungen und Pakete — plus alles, was jeder Betriebstyp bekommt. Berichte decken Umsatz, Anzahl, durchschnittlichen Bon, die Aufteilung auf Bar, PromptPay und Sonstiges, die fünf meistverkauften Positionen, ein Sieben-Tage-Diagramm und die Zeiträume heute, sieben Tage, dreißig Tage oder gesamt, dazu Belegdruck und teilbarer Belegtext. Eine Steuerrechnung kann nicht ausgestellt werden: Nur umsatzsteuerlich registrierte Betriebe dürfen das, und nichts in diesem System erfasst bisher die Registrierung irgendeines Betriebs. Für einen Servicebetrieb liest sich die Bestsellerliste als: Welche Behandlungen zahlen sich wirklich? Meist nicht die vom Plakat.
Die Kundenliste entsteht aus dem Verkaufsjournal, mit Notizen und Tags, Kaufhistorie und Punkten, die zu einer vom Betrieb in der eigenen Währung festgelegten Rate anfallen, gegen einen einstellbaren Mindestumsatz samt Prämie. Die Personalverwaltung deckt die andere Seite ab: Stempeln mit GPS und Notiz, Urlaubsanträge, Schichten und Lohn mit gearbeiteten Minuten und Überstunden ab acht Stunden am Tag, auf Stunden- oder Monatsbasis, dazu Aushänge und zuweisbare Aufgaben. Der Lohn ist abgegrenzt — ein normales Mitglied sieht nur den eigenen, Eigentümer und Manager sehen alle.
Der Zugriff läuft über eine Rechtematrix: dreizehn Kernberechtigungen plus alles, was installierte Module erklären, Rollenvorlagen für Eigentümer, Manager, Service, Küche und Personal sowie Ausnahmen je Person. Kacheln verschwinden bei fehlender Berechtigung, und wer noch keine hat, sieht einen Bildschirm, der genau das sagt, statt einer leeren Liste, die wie ein Fehler aussieht. In der Android-App laufen diese Prüfungen auf dem Gerät; dieselbe Matrix existiert in der Datenbank als has_capability(business_id, capability) und wird für die Row-Level-Security-Regeln serverseitig aufgelöst.
Zwei Nachbarn für Salon und Praxis. Wer ohne Termin bedient, ruft seine Kundschaft über die Warteschlange statt über den Kalender auf — und die Seite für Betriebe fasst zusammen, was alle vier Kerntypen ohnehin gemeinsam haben.
Das Modulsystem darunter und die installierbaren Erweiterungen
Service ist eines von vier Kernmodulen, neben Food, Stay und Retail — die Betriebstypen *sind* die Module. Ein Modul erklärt eine Id, die Betriebstypen, die es beansprucht, eine Bezeichnung, einen Katalogtitel, eine primäre Handlungsaufforderung, eine Katalogansicht und optional Berechtigungen, Konsolenkacheln, einen eigenen Konsolenbildschirm und einen Abschnitt auf der Kundenseite. Wegen dieses Vertrags lässt sich ein Rechteeditor automatisch aus dem bauen, was die installierten Module erklären.
Darüber liegen sieben installierbare Erweiterungen, die für jeden Betriebstyp funktionieren, aus dem Plugin-Store in der Konsole: Teamrechte, Zahlungswege, Mitgliedschaften und Abos, Verlängerungserinnerungen, Projekte und Aufgaben, Material und Fertigung sowie Automatisierung. Die letzten beiden passen naheliegend zu einem Servicebetrieb — ein Tarif, den Kundschaft auf der Ladenseite kauft, und eine Erinnerung, bevor er ausläuft. Das Deinstallieren steht hinter einer Rückfrage, die klar sagt, dass die Daten nicht gelöscht werden, und eine deinstallierte Erweiterung liefert keine Kacheln, keine Rechte und keinen Abschnitt auf der Kundenseite. Plugins von Dritten sind noch nicht offen; der Store sagt das selbst. Heute existiert eine modulare Architektur mit eigenen Erweiterungen, und die Öffnung für Einreichungen ist der nächste Schritt.
Bewertungen, nach dem Termin
Die Nutzung einer Leistung zählt zu den anerkannten Arten in der Berechtigungssicht — wer tatsächlich da war, kann bewerten, alle anderen bekommen eine Schlosskarte mit der Erklärung, warum der Knopf fehlt. Die Sternebewertung wird von einem Datenbank-Trigger aus den Bewertungszeilen berechnet, nie eingetippt. Bewertungen tragen Fotos, eine Verteilung von fünf bis eins, das Ändern und Löschen der eigenen letzten, eine neue beim nächsten Besuch, während die alte bleibt, und öffentliche Antworten des Betriebs.