09. Mai 2025·8 Min
Multi‑Standort‑Salon‑Web‑App bauen: Rotation & Analysen
Lernen Sie, wie man eine Web‑App für Multi‑Standort‑Salons plant und baut: Buchung, Personalrotation, Zugriffsrechte und Umsatz‑Analysen mit praktischen Schritten.
Lernen Sie, wie man eine Web‑App für Multi‑Standort‑Salons plant und baut: Buchung, Personalrotation, Zugriffsrechte und Umsatz‑Analysen mit praktischen Schritten.
Bevor Sie Bildschirme entwerfen oder Tools wählen, werden Sie konkret, was „besser“ für Ihre Salons bedeutet. Eine Multi‑Standort‑App kann viele Probleme lösen, aber ohne klare Ziele liefern Sie womöglich Funktionen, auf die niemand angewiesen ist.
Wählen Sie 3–5 Ergebnisse und hängen Sie Zahlen dran. Häufige Beispiele für Salons sind:
Diese Ziele werden zu Abnahmekriterien für Ihr MVP: Bewegt die App diese Metriken nicht, ist sie nicht fertig.
Multi‑Standort‑Betriebe involvieren meist unterschiedliche Rollen:
Für jede Rolle notieren Sie, was sie täglich tut — und was sie nicht ändern dürfen sollte.
Dokumentieren Sie sowohl den „Happy Path“ als auch die unordentliche Realität:
Multi‑Standort ist nicht nur „ein Standortfeld hinzufügen“. Entscheiden Sie vorab:
Frühzeitige Antworten verhindern teure Umbauten später — besonders in Buchungsregeln und Reporting.
Bevor Sie Kalender oder Dashboards designen, brauchen Sie eine gemeinsame „Quelle der Wahrheit“ für Ihr Salonbusiness: wo Sie arbeiten, wer dort arbeitet, was Sie verkaufen und wen Sie bedienen. Gute Kerndaten sorgen dafür, dass Multi‑Standort‑Buchung, Rotation und Reporting konsistent bleiben.
Jeder Standort sollte praktische Betriebsdetails speichern:
Tipp: Modellieren Sie „Ressourcen“ explizit (Stuhl 1, Color‑Raum) statt als Notiz. Das ist der einfachste Weg, spätere Doppelbuchungen zu verhindern.
Ein Mitarbeiterprofil sollte mehr enthalten als Name und Telefonnummer. Zur Unterstützung von Rotation und korrekter Buchung:
Design‑Hinweis: Speichern Sie Skills als strukturierte Tags (mit Level), sodass Services z. B. „Skill: Color Level 2+“ verlangen können und die Buchungsmaschine nur geeignete Mitarbeiter filtert.
Erstellen Sie einen einzelnen Kunden‑Datensatz, der standortübergreifend funktioniert. Enthalten sein sollten:
Das verhindert Duplikate, wenn jemand in einer neuen Filiale bucht, und hält Reporting (Wiederkehrerquote, Lifetime Value) sauber.
Definieren Sie Services als buchbare Items mit:
Behandeln Sie Services als Katalog statt Freitext, dann bekommen Sie sauberere Buchungen, weniger Fehler am Empfang und verlässlichere Analysen.
Ihre Buchungsengine ist die „Source of Truth“ für Verfügbarkeit über Standorte, Personal, Räume und Serviceregeln. Betrachten Sie die Kalender‑UI als View auf dieser Engine, nicht als Engine selbst.
Online‑Buchung und Empfangsbuchung müssen dieselbe API und dieselben Regeln ansprechen. Sonst entstehen zwei Kalender, die widersprüchliche Daten zeigen.
Mindestens sollte Verfügbarkeit berücksichtigen:
Definieren Sie Konfliktregeln klar und wenden Sie sie konsistent an:
Um Kalender in Echtzeit akkurat zu halten, nutzen Sie optimistische Concurrency (Versionsnummern) oder kurzfristige Reservierungen (z. B. 5–10 Minuten „Pending“ während des Checkouts). Das reduziert Race‑Conditions, wenn zwei Personen dieselbe Zeit wählen.
Puffer (Vorbereitung/Reinigung), Pausen und Mittag sollten erste‑Klasse‑Terminblöcke sein — keine Notizen. Service‑Bundles (z. B. Schnitt + Farbe) sollten als eine Buchung behandelt werden, die sich in mehrere zeitlich abgestimmte Segmente aufteilt und ggf. unterschiedliche Ressourcen benötigt.
Vermeiden Sie harte Codierung von Policies. Speichern Sie sie als Einstellungen pro Standort (und manchmal pro Service), z. B.:
Wenn Policies datengetrieben sind, können Sie sie ohne Codeänderungen anpassen — und Verhalten über Web, Mobile und Empfang konsistent halten.
Rotation ist der Punkt, an dem Multi‑Standort‑Betrieb entweder fair und vorhersehbar wirkt — oder chaotisch und politisch. Behandeln Sie Planung als Kombination aus klaren Regeln und einem sicheren Weg, Ausnahmen zu handhaben.
Die meisten Salons profitieren davon, mehrere Rotations‑Templates zu unterstützen, weil ein Standort sehr planbar sein kann und ein anderer stark nachfragegesteuert.
Praktisch ist es, Muster als wiederverwendbare Zeitpläne zu speichern (z. B. „Downtown Woche A“) und für einen Datumsbereich Schichten zu generieren, statt jede Woche manuell zu erstellen.
Fairness heißt nicht, dass alle exakt dieselben Schichten bekommen. Es heißt: die Regeln sind sichtbar und konsistent. Entscheiden Sie, wie Sie verteilen:
Integrieren Sie diese als weiche Ziele (Präferenzen) versus harte Regeln (Constraints). Beispiel: „Jeder Stylist soll mindestens einen Prime‑Slot pro Woche haben“ (Ziel) gegenüber „Senior Colorist muss samstags anwesend sein“ (Regel).
Ihr Scheduler ist nur so schlau wie die Constraints, die er kennt. Gängige Constraints:
Modellieren Sie diese als strukturierte Daten, nicht als Notizen, damit das System vor Veröffentlichung vor Konflikten warnen kann.
Selbst der beste Plan braucht Ausnahmen. Bieten Sie Werkzeuge für:
Das hält den Schichtplan flexibel, ohne Verantwortlichkeit zu verlieren — wichtig bei Streitfällen, Lohnfragen oder Compliance‑Prüfungen später.
Wenn Sie mehrere Standorte betreiben, wird „wer darf was“ genauso wichtig wie Funktionen wie Buchung. Berechtigungen schützen Kundendaten, reduzieren teure Fehler und machen Zahlen vertrauenswürdig — besonders wenn Manager, Empfang und Stylisten dasselbe System nutzen.
Starten Sie damit, was jede Rolle ansehen und bearbeiten darf:
Fügen Sie dann standortübergreifende Regeln hinzu. Beispiel: Ein Rezeptionist darf nur für seinen Standort buchen, ein Area Manager kann Kalender aller Standorte einsehen, aber keine Payroll‑Daten bearbeiten.
Statt einer großen „Admin“‑Rechtegruppe, splitten Sie nach Features, damit Sie spezifisch sein können:
Das hält das Tagesgeschäft glatt und beschränkt sensible Aktionen auf die richtigen Personen.
Genehmigungen verhindern stille Margenverluste und Planchaos. Übliche Genehmigungs‑Trigger:
Machen Sie Genehmigungen schnell: zeigen Sie Grund, Auswirkung (Betrag, betroffener Termin) und wer genehmigen muss.
Ein Audit‑Log sollte beantworten: was hat sich geändert, wer hat es geändert, wann und von wo. Tracken Sie Änderungen an Terminen, Auszahlungen/Provisionsanpassungen, Rückerstattungen und Inventaränderungen. Fügen Sie durchsuchbare Filter nach Standort, Mitarbeiter und Datum hinzu, damit Eigentümer Streitfälle schnell klären können, ohne lange Nachrichtenverläufe zu durchsuchen.
Der Checkout ist der Punkt, an dem Termine zu Umsatz werden — er muss schnell am Empfang und präzise fürs Reporting sein.
Starten Sie mit einer „erbrachte Services“‑Zusammenfassung aus dem Termin: Services, Dauer, Mitarbeiter und Standort. Ermöglichen Sie dann, dass der Empfang schnell Zusatzposten hinzufügt: Add‑ons, Retail‑Produkte, Rabatte (Promo‑Code oder manuell), Trinkgelder und Steuern.
Halten Sie die Berechnung vorhersehbar, indem Sie eine Reihenfolge der Operationen früh festlegen (z. B.: Rabatte auf Services, dann Steuern, Trinkgelder post‑tax). Was auch immer Sie wählen — machen Sie es standortübergreifend konsistent, damit Reports vergleichbar bleiben.
Entscheiden Sie, was erlaubt sein soll:
Definieren Sie auch das Verhalten offener Rechnungen: Kann eine Rechnung mit Rest offen bleiben, oder muss ein Termin am gleichen Tag vollständig bezahlt sein? Wenn Sie Restbeträge erlauben, legen Sie fest, wann ein Service für Provisionen und Umsatzberichte als „bezahlt“ gilt.
Rückerstattungen und Voids sollten einen Grund verlangen (Dropdown + optionale Notiz), dokumentieren, wer die Aktion durchgeführt hat, und im Audit‑Trail landen. Unterscheiden Sie klar:
Sperren Sie sensible Aktionen hinter Rollen (siehe /blog/permissions-and-audit-logs), damit Mitarbeiter Regeln nicht leichtfertig umgehen.
Wählen Sie Zahlungsanbieter und Belegversand (E‑Mail/SMS) früh, denn sie beeinflussen Ihr Datenmodell. Selbst wenn Sie Buchhaltung erst später integrieren, speichern Sie saubere Finanzdaten: Rechnung, Positionen, Zahlungsversuche, erfolgreiche Zahlungen, Trinkgelder, Steuern und Rückerstattungen. Diese Struktur erleichtert spätere Exporte und ein verlässliches Umsatz‑Analytics‑Dashboard.
Ihre Analysen sollten zwei Fragen schnell beantworten: „Wie viel haben wir verdient?“ und „Warum hat sich das geändert?" Starten Sie mit einer kleinen, konsistenten Menge an Umsatzmetriken, damit jeder Standort gleich berichtet.
Mindestens standardisieren:
Dokumentieren Sie Edge‑Cases (Split‑Payments, Teilrückerstattungen, Geschenkkarten, Anzahlungen), damit Dashboards nicht zur Debatte werden.
Ermöglichen Sie Vergleiche nach:
Ein praktisches Pattern: oberste Zeile mit Kennzahlen‑Kacheln (Nettoumsatz, Termine, durchschnittlicher Umsatz), gefolgt von Drill‑down‑Tabellen, in denen man auf Standort oder Mitarbeiter klicken kann.
Umsatz ist das Ergebnis; Betrieb ist der Hebel. Fügen Sie hinzu:
Diese KPIs erklären das „Warum“ ohne komplizierte Analysen.
Halten Sie Filter simpel und immer sichtbar: Datumsbereich, Standort, Mitarbeiter, Service. Vermeiden Sie, Essentielles hinter „Erweitert“ zu verstecken.
Jeder Bericht sollte als CSV exportierbar sein mit denselben Spalten wie die Tabelle auf dem Bildschirm (plus IDs und Timestamps). So lässt sich leicht an Buchhaltung, Payroll oder BI‑Tools weitergeben, ohne die App umzubauen.
Provisionen sind der Punkt, an dem Vertrauen gewonnen oder verloren wird. Mitarbeiter wollen transparente Zahlen, Manager schnelle Genehmigungen, Eigentümer lohnfertige Summen ohne Tabellenchaos.
Unterstützen Sie gängige Regeln und machen Sie sie im Service‑Setup sichtbar:
Für Multi‑Location‑Teams erlauben Sie, Provisionspläne nach Standort, Rolle oder Individuum zuzuweisen. Ein Stylist, der eine andere Filiale abdeckt, kann entweder nach seinem Home‑Plan oder dem Filialplan bezahlt werden — das System sollte beides unterstützen.
Machen Sie Payroll‑Inputs einfach, aber flexibel:
Hier definieren Sie auch, ob Provision auf Brutto (vor Rabatten) oder Netto (nach Rabatten) berechnet wird und wie Rückerstattungen behandelt werden.
Das echte Leben erzeugt Edge‑Cases: Nacharbeit, Chargebacks, Goodwill‑Rabatte und manuelle Boni. Fügen Sie einen Adjustment‑Eintragstyp hinzu, der verlangt:
Diese Audit‑Spur reduziert Streitigkeiten und erklärt Summen später leichter.
Erzeugen Sie Auszüge, die das widerspiegeln, wie Mitarbeiter ihre Arbeit sehen:
Manager sollten eine Zusammenfassung pro Standort sehen und Exportoptionen haben, die Payroll‑Tools füttern. Wenn POS‑Integration geplant ist, stimmen Sie Kategorien mit dem Checkout‑Setup ab (siehe /blog/build-salon-pos-payments).
Inventar ist optional, aber wenn Sie Retail verkaufen (oder Verbrauchsmaterialien wie Farbe, Developer, Handschuhe kontrollieren wollen), verhindert Basis‑Stocktracking Überraschungen und macht Umsatzreports sauberer.
Starten Sie mit einem einfachen Produktkatalog, der mehrere Standorte unterstützt. Jedes Item sollte haben: SKU/Barcode (optional), Name, Kategorie (Retail vs Verbrauch), Einkaufskosten, Preis und aktuelle Menge pro Standort. Für Verbrauchsmaterialien denken Sie an ein Flag „nicht zum Verkauf“, damit sie intern genutzt werden können, ohne im Retail‑Menü aufzutauchen.
Multi‑Standort‑Salons brauchen Transfers. Halten Sie es schlank: „Von Standort“, „Zu Standort“ und Mengen wählen — dann einen Transfer‑Eintrag erzeugen, sodass beide Standorte richtig aktualisieren.
Für Inventurzählungen unterstützen Sie Quick‑Cycle‑Counts (Teilzählung) und Full‑Counts (Monatsende). Speichern Sie Anpassungen mit einem Grund (Zählung, beschädigt, abgelaufen), damit Muster erkennbar sind.
Low‑Stock‑Alerts sollten pro Standort sein. Lassen Sie Mitarbeiter einen Nachbestell‑Schwellenwert setzen und optional einen bevorzugten Lieferanten und Packgröße anhängen. Vermeiden Sie ein komplettes Beschaffungssystem — die meisten Salons brauchen nur: „was ist niedrig und wo?".
Retail‑Artikel müssen über denselben Checkout wie Services verkauft werden, damit Inventar und Umsatz konsistent bleiben. Wenn ein Produkt zum Ticket hinzugefügt wird, sollte das System:
So bleiben Reports mit der Realität synchron, ohne zusätzliche Schritte am Empfang.
Eine Salon‑App lebt oder stirbt an Geschwindigkeit am Tresen und Übersichtlichkeit auf dem Telefon. Streben Sie eine kleine Menge Kernbildschirme an, die schnell laden, auf Touchgeräten gut aussehen und das Personal auf den nächsten Kunden fokussieren.
Designen Sie die Navigation um die stündlich vorkommenden Aktionen:
Alles andere sollte einen Tap entfernt sein, nicht Teil des Hauptflusses.
Empfangspersonal sollte drei Aktionen in unter 10 Sekunden erledigen können:
Der Kalender sollte standardmäßig eine Tagesansicht mit großen Touch‑Targets und minimalem Scrollen zeigen. Nutzen Sie einen Sticky‑Header (Datum, Standort, Filter), damit Personal sich nie „verirrt".
Status sollen kommunizieren, was als Nächstes zu tun ist, nicht nur den Zustand. Praktische Status:
Farbe hilft, aber immer auch Textlabels aus Accessibility‑Gründen einblenden.
Beschäftigte Teams tappen falsch. Bauen Sie sanfte Sicherheitsnetze ein:
Wenn Sie ein MVP planen, priorisieren Sie diese Kernflüsse vor Einstellungen und erweiterten Reports. Für eine saubere Rollout‑Abfolge siehe /blog/rollout-plan-mvp-pilot-training.
Eine Salon‑App lebt oder stirbt an Zuverlässigkeit: Buchungen dürfen nicht verzögern, Personal darf während der Schicht keinen Zugriff verlieren und Eigentümer brauchen vertrauenswürdige Zahlen. Wählen Sie bewährte, wartbare Tools.
Die meisten Multi‑Standort‑Salon‑Apps funktionieren gut mit klassischem Setup:
Wenn Sie Zahlungen verarbeiten, wählen Sie einen Anbieter mit guten Docs und Webhooks (z. B. Stripe) und entwerfen Sie Ihr System so, dass Zahlungsereignisse sicher wiederholt werden können.
Wenn Sie beim ersten brauchbaren Release schneller vorankommen wollen, kann ein vibe‑coding‑Ansatz helfen. Beispiel: Koder.ai ermöglicht Teams, aus einem strukturierten Chat eine React‑App mit Go‑Backend und PostgreSQL zu generieren, mit Planungsmodus vor dem Build und Export des Quellcodes, wenn Sie die Entwicklung intern übernehmen wollen.
Betreiben Sie von Anfang an drei Umgebungen. Staging sollte Produktion spiegeln, damit Booking und POS‑Änderungen getestet werden können ohne Risiko für Live‑Daten.
Planen Sie für:
Wenn Sie eine Plattform‑Workflow nutzen (inkl. Koder.ai), priorisieren Sie Snapshots und Rollbacks, damit Zeitplan‑ und Zahlungsänderungen in Spitzenzeiten schnell zurückgenommen werden können.
Nutzen Sie TLS überall, verschlüsseln Sie sensible Daten at rest und speichern Sie Secrets in einem gemanagten Vault (nicht im Code). Erzwingen Sie Least‑Privilege mit rollenbasierten Rechten und bevorzugen Sie MFA für Admins und Eigentümer. Fügen Sie Audit‑Logs für Aktionen wie Rückerstattungen, Terminänderungen und Rechteänderungen hinzu.
Rechnen Sie mit Traffic‑Spitzen zur Mittagszeit und am Abend. Nutzen Sie Caching für leseintensive Ansichten (Dashboards), Queues für langsame Tasks und isolieren Sie Reporting‑Workloads, damit Analytics Buchung und Checkout nicht ausbremst.
Einen Multi‑Standort‑Salon‑Manager zu veröffentlichen ist weniger ein großes Launch‑Event als eine kontrollierte Einführung, die den Empfang schützt und Eigentümer Vertrauen in die Zahlen lässt.
Die erste Version sollte den täglichen Loop Ende‑zu‑Ende abdecken:
Ziel des MVP ist Geschwindigkeit und Genauigkeit am Empfang — nicht perfekte Automatisierung. Wenn der Kalender schnell wirkt und Umsatzzahlen zur Kasse passen, steigt die Akzeptanz.
Wenn es schnell gehen muss, erwägen Sie ein MVP‑Prototype auf Koder.ai, dann iterieren Sie mit Stakeholdern in kurzen Feedback‑Zyklen. Die Möglichkeit, schnell zu deployen, eine Custom‑Domain anzuhängen und sicher zurückzurollen ist bei Piloten sehr nützlich.
Führen Sie einen Pilot mit einem „Champion“‑Manager und einer kleinen Gruppe aus Empfang, Stylisten und Managern durch. Halten Sie den Pilot kurz (2–4 Wochen) und definieren Sie Erfolgsmessgrößen vorab:
Ändern Sie Kernregeln nicht mitten in der Woche. Loggen Sie Probleme und bündeln Sie Updates.
Bieten Sie rollenbasiertes Training an: Empfang, Manager, Stylisten, Eigentümer. Nutzen Sie kurze Checklisten und Szenario‑Übungen (Walk‑in, verspäteter Kunde, Wechsel des Mitarbeiters). Eine einseitige „Was tun wenn…“‑Anleitung in der App (z. B. /help/front-desk) reduziert Panik in Stoßzeiten.
Sammeln Sie wöchentlich Feedback: Empfangsgeschwindigkeit, Schichtklarheit, Report‑Nützlichkeit. Priorisieren Sie dann Upgrades in einer sichtbaren Roadmap:
Dieser Rhythmus verbessert die App, ohne das Tagesgeschäft zu stören. Wenn Sie Ihre Erkenntnisse veröffentlichen, bieten Plattformen wie Koder.ai oft Credit‑Programme fürs Erstellen von Inhalten oder Empfehlungen — praktisch, wenn Sie Ihren Build öffentlich dokumentieren wollen.
Beginnen Sie mit 3–5 messbaren Zielen und geben Sie ihnen Zahlen (z. B. No-Shows von 12 % → 7 %). Nutzen Sie diese Kennzahlen als Abnahmekriterien für das MVP.
Praktische Salon‑Ziele sind oft:
Listen Sie jede Rolle auf und notieren Sie deren tägliche Aufgaben; definieren Sie außerdem, was sie nicht ändern dürfen.
Typische Rollen:
Behandle Multi‑Location als Geschäftsregeln, nicht nur als ein zusätzliches „Standort“-Feld.
Treffen Sie früh Entscheidungen:
Diese Entscheidungen beeinflussen Buchungslogik und Reporting stark; spätere Änderungen sind teuer.
Modellieren Sie Kern‑Entitäten als strukturierte Daten (nicht als Freitext), damit Planung und Reports zuverlässig bleiben:
Bauen Sie eine einheitliche Verfügbarkeits‑Engine, die von allen Kanälen (Empfang + Online) genutzt wird.
Mindestens sollte Verfügbarkeit berücksichtigen:
Verwenden Sie für Race‑Conditions kurze Reservierungen (5–10 Minuten) oder optimistische Concurrency, wenn Buchungen gespeichert werden.
Unterstützen Sie wiederverwendbare Rotationstemplates und generieren Sie Schichten für einen Zeitraum, statt jede Woche manuell zu bauen.
Gute Muster:
Machen Sie Overrides kontrolliert mit Genehmigungen und einer Audit‑Spur für Tauschvorgänge und kurzfristige Änderungen.
Verwenden Sie rollenbasierte Rechte nach Standort und nach Funktion, und fügen Sie Genehmigungen für wirkungsvolle Aktionen hinzu.
Gängige Auslöser für Genehmigungen:
Führen Sie durchsuchbare Audit‑Logs (wer/was/wann/von wo) für Rückerstattungen, Terminänderungen und lohnrelevante Aktionen.
Gestalten Sie den Checkout um eine vorhersehbare Rechnung aus dem Termin herum, und erlauben Sie schnelle Ergänzungen:
Legen Sie früh Regeln für Teilzahlungen und für das Verhalten von Void vs Refund fest; verlangen Sie Gründe und Rechteprüfungen.
Standardisieren Sie Definitionen, damit alle Standorte gleich berichten.
Mindestmetriken:
Fügen Sie operative KPIs hinzu, die Änderungen erklären:
Machen Sie Provisionsregeln explizit und prüfbar; stimmen Sie sie mit der Checkout‑Berechnung ab.
Gängige Modelle:
Für Multi‑Location erlauben Sie Pläne pro , oder . Definieren Sie, ob die Provision auf (vor Rabatten) oder (nach Rabatten) berechnet wird und wie Rückerstattungen die Auszahlung beeinflussen. Ergänzen Sie Anpassungen mit Begründung und Genehmigung und stellen Sie leicht verständliche Mitarbeiterauszüge bereit.
Jeder Bericht sollte als CSV exportierbar sein mit stabilen Spalten (inkl. IDs und Timestamps).