Multi‑Standort‑Setup für kleine Ketten: Filialstruktur, Rollen, Berechtigungen und gemeinsame Kunden so einrichten, dass jede Filiale nur die nötigen Daten sieht.
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:
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.
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:
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.
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.
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.
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.
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:
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.
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.
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 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.
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.
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.
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:
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.
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.
Fange auf Papier (oder einem einfachen Spreadsheet) an, bevor du die Datenbank oder den App‑Builder anfasst.
Überspringe das Testen nicht. Die meisten Berechtigungsprobleme tauchen erst auf, wenn du dich mit einer echten Rolle einloggst und schnell arbeiten musst.
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:
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:
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.
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.
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:
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.
10. März 2026
6 Min
08. März 20268 Min
07. März 202610 MinExperimentieren Sie mit AppMaster mit kostenlosem Plan.
Wenn Sie fertig sind, können Sie das richtige Abonnement auswählen.
