Mehrere Standorte für kleine Ketten: Filialen, Mitarbeiter, Kunden

Was bei Multi-Standort-Setups meist schiefgeht

Ein Multi-Standort-Setup für kleine Ketten beginnt oft mit einer einfachen Idee: ein System für alle. Die Probleme fangen an, wenn jede Filiale dieselben Bildschirme, Listen und Buttons nutzt, obwohl die Zuständigkeiten unterschiedlich sind.

Das häufigste Versagen ist vermischte Sichtbarkeit. Ein Empfangsmitarbeiter in Filiale A sieht Termine, Notizen oder Rechnungen aus Filiale B. Oder ein Manager versucht, ein lokales Problem zu lösen und verändert versehentlich eine globale Einstellung, die alle Filialen betrifft. Anfangs wirkt das praktisch, aber schnell wird es unübersichtlich und riskant.

„Jede Filiale sieht nur das, was sie sehen sollte“ heißt: Mitarbeiter sollten nur die Kunden, Bestellungen, Schichten, Bestände und Berichte sehen, die zu ihrem Job und ihrer Filiale passen. Arbeitet jemand in zwei Filialen, sollte er beide sehen. Ist jemand Regionaladministrator, sieht er alles, aber nur weil du das bewusst so eingestellt hast.

Wenn du nichts tust (oder auf informelle Regeln vertraust), treten einige vorhersehbare Probleme auf:

• Mitarbeiter bearbeiten den falschen Datensatz, weil Listen andere Filialen enthalten.
• Kundendaten, Notizen oder Zahlungsstatus gelangen zwischen Filialen.
• Berichte sind falsch, weil Summen ohne klare Filter vermischt werden.
• Der Support verbringt den Tag mit „Warum sehe ich das?“ und „Ich finde es nicht“.

Das Ziel ist nicht, alles zuzumachen, sondern bewusst zu entscheiden, was geteilt und was getrennt wird. Viele Ketten möchten eine gemeinsame Kundendatenbank (damit ein wiederkehrender Kunde überall erkannt wird), gleichzeitig sollen filialspezifische Daten wie lokale Termine, interne Notizen und Mitarbeiterleistung getrennt bleiben.

Wenn du einen No‑Code‑Builder verwendest, lege diese Regeln fest, bevor du Bildschirme und Workflows baust. Sonst flickst du Berechtigungen, nachdem Leute das System schon nutzen.

Die Kernbausteine, die du zuerst definieren solltest

Multi‑Standort‑Setups funktionieren besser, wenn du ein paar Grundlagen vor dem Erstellen von Bildschirmen, Formularen oder Berichten einigst. Wenn du das überspringst, werden Berechtigungen unübersichtlich und Daten verlieren an Vertrauen.

Beginne damit, deine Bausteine zu benennen. Die meisten kleinen Ketten brauchen Filialen (Standorte), Benutzer (Mitarbeiterkonten), Rollen (Aufgabentypen), Kunden (gemeinsame Identität) und Transaktionen (Bestellungen, Termine, Tickets, Rückgaben).

Als Nächstes entscheide, welche Datensätze global und welche filialgebunden sind. Globale Datensätze werden unternehmensweit geteilt, z. B. ein Kundenprofil, ein Produktkatalog oder firmenweite Preisregeln. Filialgebundene Datensätze gehören zu einer Filiale, z. B. Tageskassenbericht, lokaler Dienstplan oder filialspezifische Bestandszählung.

Berechtigungen brauchen zwei Dimensionen, nicht nur eine:

• Umfang: welche Filiale(n) eine Person sehen kann.
• Aktion: was sie mit den Datensätzen, die sie sehen kann, tun darf.

Lese- und Schreibzugriff sollten getrennt sein. Ein Regionalleiter kann alle Filialen lesen, aber nur die Mitarbeiterliste seiner eigenen Filiale bearbeiten. Ein Empfangsmitarbeiter kann Kundenprofile lesen, aber nur Termine für seine Filiale erstellen und bearbeiten.

Zuletzt entscheide, wie Reporting funktionieren soll. Die meisten Teams brauchen sowohl Performance pro Filiale für das Tagesgeschäft als auch Unternehmensberichte für Eigentümer und Finanzen. Treffe diese Entscheidung früh, damit du keine Berichte baust, die Daten verwirrend mischen.

Filialen modellieren, ohne sich einzuschränken

Ein Multi‑Standort‑Setup beginnt mit einer Frage: Was bedeutet „Filiale“ in deinem Geschäft? Für manche ist es ein Ladengeschäft, das Kunden besuchen. Für andere eine Klinik, ein Lager oder eine Franchise‑Einheit, die getrennt bleiben muss.

Mit einer klaren Definition starten

Wähle eine Bedeutung und bleibe dabei im Datenmodell. Wenn du später Abteilungen oder Servicebereiche brauchst, füge sie als eigene Konzepte hinzu, statt das Filial‑Objekt zu überladen.

Gib jeder Filiale eine stabile Kennung, die sich nie ändert, auch wenn der Name wechselt. Ein kurzer Code (z. B. „NYC‑01“) ist meist einfacher als Adresse oder Name als Schlüssel.

Speichere, worauf dein Tagesgeschäft angewiesen ist: Filialcode und Anzeigename, Adresse, Zeitzone (wichtig für Öffnungszeiten, Buchungen und Berichte), Geschäftszeiten (inkl. Feiertagsausnahmen) und einen Status wie aktiv, vorübergehend geschlossen oder archiviert.

Entscheide dann, wie Mitarbeiter zu Filialen gehören. Manche Unternehmen sind strikt (eine Person, eine Filiale). Andere verschieben Personal zwischen Standorten. Beides funktioniert, verändert aber, wie du Arbeit zuweist und Datensätze filterst.

Ein praktischer Ansatz ist, eine eigene Zuordnung Mitarbeiter‑Filiale zu modellieren, damit du One‑to‑Many unterstützt, ohne später alles umzubauen.

Wachstum soll keine Sonderregel sein

Behandle neue Standorte als Daten, nicht als Sonderfälle. Ein einfacher Test: „Können wir Filiale #7 hinzufügen, ohne Logik zu ändern?“ Idealerweise bedeutet ein neuer Standort: neuen Filialdatensatz anlegen, Zeitzone und Öffnungszeiten setzen und Mitarbeiter zuweisen. Wenn du viele Regeln ändern musst, ist das Modell zu eng gekoppelt.

Mitarbeiterzugriff: Rollen, Scope und Zuständigkeiten

Eine saubere Berechtigungsstruktur beginnt mit einer Idee: Trenne, was jemand tun darf (Rolle), von dem, was er sehen darf (Scope). Wenn du das vermischst, gibst du schnell „hilfreichen“ Zugriff, der unbemerkt zum Oversharing wird.

Die meisten kleinen Ketten können Rollen einfach halten: Inhaber, Regionalleiter, Filialleiter, Mitarbeiter und Support. Definiere Standardberechtigungen pro Rolle und halte sie unaufgeregt. Für jeden Bereich (Kunden, Termine/Bestellungen, Bestand, Notizen, Berichte) lege fest, was Anzeigen, Erstellen und Bearbeiten bedeutet. Dann schreib auf, welche Aktionen niemals Standard sind, z. B. Exporte oder Admin‑Änderungen.

Eine Checkliste, die Verwirrung verhindert:

• Datensätze anzeigen
• Neue Datensätze anlegen
• Bestehende Datensätze bearbeiten
• Daten exportieren oder herunterladen
• Admin‑Aktionen (Benutzer verwalten, Regeln ändern, löschen)

Scope ist die zweite Hälfte des Schlosses. Die meisten Teams brauchen nur drei Scopes: nur eigene Filiale, zugewiesene Filialen oder alle Filialen. Ein Filialleiter darf in seiner Filiale bearbeiten. Ein Regionalleiter darf mehrere Filialen einsehen, aber nur bestimmte Dinge bearbeiten.

Plane Ausnahmen bevor du sie brauchst. Zeitlich begrenzter Zugriff sollte automatisch ablaufen, nicht von persönlichem Erinnern abhängen. Testaccounts sollten mit Testdaten oder in einer eingeschränkten Sandbox arbeiten. Externe Dienstleister sollten die kleinste nötige Berechtigung bekommen und standardmäßig keinen Exportzugriff.

Gemeinsame Kunden nutzen, ohne zu viel zu teilen

Eine gemeinsame Kundendatenbank ist oft der Sinn eines Multi‑Standort‑Setups, kann aber auch schnell Daten zwischen Filialen leaken. Entscheide, was wirklich „ein Kunde, überall“ ist und was lokal bleiben sollte.

Geteilte Daten sind meist das Kundenprofil (Name, Kontaktdaten), Loyalitätsstatus und grobe Präferenzen wie „keine Anrufe“ oder „bevorzugt E‑Mail“. Das hilft jeder Filiale, die Person zu erkennen und konsistent zu bedienen.

Filialspezifische Daten gehören zur Filiale: Besuche, Käufe, Termine, Service‑Notizen und lokale Tags wie „VIP für Filiale A“ oder „Folgetermin nächste Woche“. Diese lokal zu halten reduziert Rauschen und verhindert, dass Mitarbeiter Details sehen, die sie nicht brauchen.

Klare Sichtregeln festlegen

Die einfachste Richtlinie lautet: Jeder kann den Kunden finden, aber nicht jeder sieht alles.

Empfangsmitarbeiter sehen Profilangaben und Kontaktpräferenzen sowie die Besuche ihrer eigenen Filiale. Manager sehen möglicherweise filialübergreifende Summen (z. B. Lifetime‑Umsatz) ohne detaillierte Notizen anderer Standorte. Zentrale oder Support‑Rollen sehen bei Bedarf die vollständige Historie zur Eskalation. Das Marketing hat Zugriff auf Opt‑In‑Status und Segmente, nicht auf private Service‑Notizen.

So bleibt die gemeinsame Kundendatenbank nützlich, ohne in ein geteiltes Tagebuch zu verkommen.

Sensible Felder standardmäßig schützen

Sensible Daten (private Notizen, Dokumente, Beschwerden, medizinische oder rechtliche Details) sollten von allgemeinen Notizen getrennt und hinter strengeren Berechtigungen verborgen werden. Wenn du Dokumente speicherst, mache den Zugriff explizit: wer hochladen darf, wer ansehen darf und ob Ansicht auf dieselbe Filiale begrenzt ist.

Beispiel: Ein Kunde war in Filiale 1 für einen Haarschnitt und in Filiale 2 für einen Produktkauf. Mitarbeiter in Filiale 2 sollten die Loyalitätsstufe und eine Präferenz wie „allergisch gegen Duftstoffe“ sehen, aber nicht die detaillierte Beschwerdenotiz aus Filiale 1.

Daten‑Trennungsmuster, die einfach bleiben

Eine zentrale Entscheidung ist, ob du Daten per Tagging trennst oder physisch aufteilst. Die meisten kleinen Ketten bleiben einfach mit einer Datenbank und klaren Regeln.

Muster 1: Eine Datenbank, jeder Datensatz hat eine BranchID

Das ist die übliche Wahl. Bestellungen, Termine, Bestandszählungen und Mitarbeiteraktionen liegen in denselben Tabellen, aber jede Zeile enthält eine BranchID (oder LocationID). Das unterstützt gemeinsame Kunden, filialübergreifende Berichte und Mitarbeiter, die in mehreren Filialen arbeiten.

Muster 2: Separate Datenbanken pro Filiale

Das fühlt sich manchmal „sicherer“ an, erhöht aber die laufenden Kosten. Migrationen müssen mehrfach durchgeführt werden, Berichte werden schwieriger, und gemeinsame Kunden müssen synchronisiert werden.

Eine praktische Regel:

• Verwende eine Datenbank mit BranchID, wenn du gemeinsame Kunden, geteilte Reports und flexible Mitarbeiterabdeckung willst.
• Nutze separate Datenbanken nur, wenn rechtliche oder vertragliche Vorgaben Isolation erzwingen.

Egal welches Muster du wählst: mache Filialfilter automatisch. Verlass dich nicht darauf, dass jeder Bildschirm oder Bericht den Filter manuell setzt. Behandle den Standort als Teil der Benutzersession und setze den Filter zentral, sodass jede Liste und Aktion standardmäßig gescoped ist.

Plane außerdem globale Elemente vs. lokale Überschreibungen: Halte Definitionen global (Katalogartikel, Service‑Vorlagen, Preisregeln) und füge optional filialspezifische Override‑Felder hinzu (filialspezifischer Preis, Mindestbestand, Öffnungszeiten). So vermeidest du, den ganzen Katalog pro Filiale zu kopieren.

Füge früh Protokolle zur Nachverfolgung hinzu. Du musst später beantworten können: „Wer hat das geändert und wo?“ Mindestens sollte erfasst werden: Benutzer‑ID, Filial‑ID, Zeitstempel, Aktion (Erstellen, Aktualisieren, Löschen) und Vorher‑/Nachher‑Werte für sensible Felder.

Schritt‑für‑Schritt: Filialen, Berechtigungen und Sichtregeln einrichten

Das Ziel ist einfach: Menschen sollen nur das sehen, was sie für ihre Arbeit brauchen — und nichts anderes. Der leichteste Weg dorthin ist, vorher festzulegen, was zur Filiale gehört, was geteilt wird und wie Mitarbeiter durch die Bildschirme wechseln.

Eine praktische Einrichtungsreihenfolge

Fange auf Papier (oder einem einfachen Spreadsheet) an, bevor du die Datenbank oder den App‑Builder anfasst.

1. Liste jeden Datentyp auf, den du speicherst (Termine, Bestellungen, Bestand, Mitarbeiternotizen, Kundenprofile). Markiere jeden als global (geteilt) oder filialgebunden.
2. Definiere Rollen in Alltagssprache (Empfang, Techniker, Filialleiter, Zentrale). Schreibe für jede Rolle den Filial‑Scope: eine Filiale, zugewiesene Filialen oder alle Filialen.
3. Lege Regeln für gemeinsame Kunden fest: was filialübergreifend sichtbar ist und was lokal bleibt. Entscheide, wer globale Felder bearbeiten darf.
4. Entwerfe getrennte Bildschirme und Berichte für Mitarbeiter vs. Manager. Mitarbeiteransichten sollten standardmäßig auf „meine Filiale“ stehen. Manageransichten können Filter und Vergleiche anbieten.
5. Teste mit Musterdatenkonten aus verschiedenen Filialen. Führe reale Aufgaben durch (Termin anlegen, Rückerstattung, Kunde aktualisieren, Bericht ansehen) und bestätige, dass das System blockiert, was es blocken soll.

Überspringe das Testen nicht. Die meisten Berechtigungsprobleme tauchen erst auf, wenn du dich mit einer echten Rolle einloggst und schnell arbeiten musst.

Häufige Fehler und wie man sie vermeidet

Die meisten Multi‑Standort‑Probleme sind keine großen Katastrophen. Es sind kleine Defaults, die still Daten leaken oder Menschen an ihrer Arbeit hindern. Gehe davon aus, dass jeder Bildschirm, Bericht und Export eine Standortregel braucht.

Berichte und Exporte werden oft übersehen. Teams filtern Bildschirme genau nach Filiale, exportieren dann aber „alle Kunden“ oder „Umsatz letzten Monat“ und schließen versehentlich andere Standorte ein. Behandle Exporte als eigene Funktion mit eigenen Filtern und Tests. Wenn ein Mitarbeiter einen Datensatz in der App nicht sehen kann, darf er ihn auch nicht exportieren.

Ein weiteres Problem ist die Managerrolle, die sich heimlich zur Adminrolle entwickelt. Das passiert, wenn du Aktionen nach Bildschirm statt nach Risiko gruppierst. Manager brauchen vielleicht Rückerstattungen, Schichtänderungen oder Kundennotizen, aber nicht Benutzeranlage, Berechtigungsänderungen oder Filialsetup. Trenne „Betrieb managen“ von „System verwalten“.

Gemeinsame Kunden werden chaotisch, wenn alles in einem globalen Notizfeld landet. Schreibt filialspezifische Hinweise nicht ins globale Feld. Halte gemeinsam nutzbare Fakten getrennt von filialspezifischen Notizen und Besuchshistorie.

Fehlende Protokolle verursachen Schuldzuweisungen und Nacharbeit. Wenn zwei Filialen denselben Kunden bearbeiten, brauchst du ein einfaches „Wer hat was und wann geändert“. Selbst einfache Felder wie created_by, updated_by und Zeitstempel helfen enorm.

Plane außerdem für Mitarbeiter, die zwischen Filialen wechseln. Wenn du sie „verschiebst“ statt ihnen Multi‑Filialzugang zu geben, brechen Pläne und Sichtbarkeit.

Praktische Maßnahmen, die du früh einbauen solltest:

• Schreibe für jeden Datentyp eine Regel: global (geteilt) vs. filial‑only.
• Definiere Rollen nach Aktionen und ergänze einen Standort‑Scope (eine Filiale vs. mehrere).
• Baue Filialfilter in jede Liste, jeden Bericht und jeden Export ein.
• Trenne Filialnotizen und geteilte Kundendaten.
• Zeichne Änderungen auf (Benutzer + Zeit) für Kunden‑ und Bestelländerungen.

Schnellchecks vor dem Livegang

Bevor du jeder Filiale Zugang gibst, spiele einen Tag mit Testkonten durch. Erstelle mindestens einen Mitarbeiter pro Filiale und einen Regionalleiter. Mache normales Tagesgeschäft: Termin buchen, Bestellung anlegen, Kunde aktualisieren, Bericht ausführen.

Nutze diese Checkliste, um die häufigsten Verwirrungen zu finden:

• Logge dich als Filialmitarbeiter ein und bestätige, dass nur Bestellungen, Termine und Aufgaben der eigenen Filiale sichtbar sind. Suche, Filter und jüngste Elemente dürfen keine anderen Standorte zeigen.
• Logge dich als Manager mit mehreren Filialen ein. Er soll mehrere Filialen sehen, aber Bearbeitungen nur in zugewiesenen Filialen durchführen dürfen.
• Öffne dasselbe Kundenprofil aus zwei Filialen. Name und Kontaktdaten müssen überall übereinstimmen, und Updates dürfen keine Duplikate erzeugen.
• Wechsle im Admin‑ oder Reporting‑Bereich die aktive Filiale und vergleiche Summen. Zahlen sollten sich beim Wechseln ändern; die Ansicht „alle Filialen“ sollte der Summe entsprechen.
• Sperre ein Mitarbeiterkonto und bestätige, dass der Zugriff sofort entzogen ist (App‑Zugang und API‑Zugänge).

Teste zudem eine typische Randlage: Ein Kunde kauft in Filiale A und ruft Filiale C wegen Support an. Filiale C sieht das gemeinsame Kundenprofil, aber nicht die internen Notizen aus Filiale A.

Beispiel: ein Kunde, drei Filialen

Stell dir eine kleine Friseurkette mit drei Filialen vor: Innenstadt, Riverside und Einkaufszentrum. Sie teilen eine Kundenliste, damit Kunden überall buchen können, aber jede Filiale behält ihren eigenen Dienstplan, ihr Personal und die täglichen Notizen.

Maya (Empfang in der Innenstadt) öffnet das System. Sie sieht nur den Kalender, das Personal und die Termine der Innenstadt. Sie kann Kunden übergreifend suchen, sieht aber nur Basisinformationen: Name, Telefon, Allergien und Loyalitätsstatus. Sie sieht weder den Kalender noch Leistungsdaten oder private Notizen der Riverside‑Filiale.

Alex (der Inhaber) loggt sich ein. Alex sieht alle drei Kalender, Umsätze pro Filiale und kann Mitarbeiterrollen verwalten. Er kann außerdem Ausnahmeregelungen wie große Rabatte genehmigen.

Jordan besucht normalerweise die Innenstadt, bucht diese Woche aber spontan im Einkaufszentrum. Das Einkaufszentrum sieht Jordans Basisprofil und Servicehistorie (was, wann und von wem gemacht wurde). Nach dem Termin fügt das Einkaufszentrum die Leistung zur Historie hinzu. Die Innenstadt sieht das später, sodass nicht dieselben Fragen erneut gestellt werden.

Ein kritischer Moment an der Kasse: Jordan verlangt 30 % Rabatt wegen langer Wartezeit. Das Einkaufszentrum kann eine Rabattanforderung eintragen, aber nur bis zu 10 % sofort gewähren. Die Anfrage geht an Alex zur Genehmigung. Alex genehmigt, die Quittung aktualisiert sich und das Protokoll zeigt, wer angefragt und wer genehmigt hat.

Sensible Notizen werden anders gehandhabt. Wenn ein Stylist eine private Notiz anlegt wie „Kunde hat medizinisches Problem, beim Kopfmassage vorsichtig sein“, sehen nur Stylisten und der Inhaber die Details. Empfangsmitarbeiter sehen stattdessen eine neutrale Markierung wie „besondere Behandlung erforderlich“ ohne Details.

Was das System funktionieren lässt, sind klare Regeln: dienstplan‑ und personalbezogene Daten filamentiert, gemeinsame Kundenbasis, eingeschränkte sensible Notizen und Genehmigungslimits für Rabatte.

Nächste Schritte: Regeln dokumentieren, Zugriffe testen, dann bauen

Ein Multi‑Standort‑Setup bleibt ordentlich, wenn deine Regeln aufgeschrieben und getestet werden — wie ein Feature, nicht ein Gefühl. Formuliere deine „Wer darf was sehen“-Entscheidungen als kurze Sätze.

Ziele für 10–15 kurze Aussagen, die Alltagssituationen abdecken: Buchungen, Kundenprofile, Zahlungen, Rückerstattungen, Notizen und Berichte. Zum Beispiel:

• Ein Mitarbeiter sieht Kunden und Bestellungen seiner Filiale.
• Kontaktdaten eines Kunden sind für alle Filialen sichtbar, Notizen sind filialgebunden.
• Manager sehen Filialberichte; nur Inhaber sehen Gesamtsummen aller Filialen.
• Rückerstattungen brauchen Managerfreigabe und müssen in derselben Filiale erfolgen.
• Nur die Zentrale darf Preislisten und globale Einstellungen ändern.

Entscheide, welche Bildschirme und Berichte immer standardmäßig auf Filiale scopen sollen. Wenn ein Bildschirm alle Filialen zeigen kann, mache das zu einem expliziten Filter, nicht zur Standardeinstellung. Ein einfacher Test: Könnte ein Kassenmitarbeiter versehentlich den Tagesumsatz einer anderen Filiale öffnen, ohne es zu versuchen? Wenn ja, engere Voreinstellungen wählen.

Teste mit realen Rollen, nicht mit Admin‑Accounts. Erstelle drei Testnutzer (Kasse, Manager, Zentrale) und simuliere: ein Kunde ruft Filiale A an, besucht nächste Woche Filiale B und fordert in Filiale C eine Rückerstattung an. Überprüfe, dass jede Person nur das sieht, was nötig ist.

Plane eine monatliche Berechtigungsprüfung ein, um Drift zu verhindern: neue Rollen, Jobwechsel, neue Filialen und schleichende Berichtsrechte.

Wenn du ein internes Tool baust, kann AppMaster (appmaster.io) dir helfen, Filialen, Rollen und Geschäftsregeln an einem Ort zu modellieren und bei Bedarf sauberen Code zu regenerieren, damit Berechtigungsregeln beim Wachsen konsistent bleiben.