Meerdere locaties voor kleine ketens: structureer vestigingen, personeelsrollen en gedeelde klanten zodat elke locatie alleen de gegevens ziet die het nodig heeft.
Een multi-locatieopzet voor kleine ketens begint vaak met een simpel idee: één systeem voor iedereen. Problemen beginnen wanneer elke vestiging dezelfde schermen, dezelfde lijsten en dezelfde knoppen gebruikt, terwijl ze niet dezelfde verantwoordelijkheden delen.
De meest voorkomende fout is gemengde zichtbaarheid. Een baliemedewerker van Vestiging A kan afspraken, notities of facturen van Vestiging B zien. Of een manager probeert een lokaal probleem op te lossen en verandert per ongeluk een globale instelling die elke vestiging raakt. Het voelt eerst handig, maar verandert snel in ruis en risico.
"Elke vestiging ziet wat het zou moeten zien" is eenvoudig: medewerkers zouden alleen de klanten, orders, roosters, voorraad en rapporten moeten zien die bij hun taak en vestiging horen. Als iemand op twee vestigingen werkt, moet die beide zien. Als iemand regionaal beheer is, moet die alles zien — maar alleen omdat je dat bewust hebt gekozen.
Als je niets doet (of vertrouwt op informele afspraken), verschijnen een paar voorspelbare problemen:
Het doel is niet alles op slot te gooien. Het doel is bewust te zijn over wat gedeeld wordt en wat gescheiden blijft. Veel ketens willen een gedeelde klantendatabase (zodat een terugkerende klant overal herkend wordt), terwijl ze vestiging-specifieke data zoals lokale roosters, interne notities en personeelsresultaten gescheiden houden.
Als je een no-code builder gebruikt, beslis deze regels voordat je schermen en workflows bouwt. Anders plak je permissies vast nadat mensen het systeem al gebruiken.
Multi-locatieopzetten werken beter wanneer je het eens bent over een paar basisprincipes voordat je schermen, formulieren of rapporten bouwt. Als je dit overslaat, worden permissies rommelig en wordt data onbetrouwbaar.
Begin met het benoemen van je bouwstenen. De meeste kleine ketens hebben vestigingen, gebruikers (personeelsaccounts), rollen (functietypes), klanten (gedeelde identiteit) en transacties (bestellingen, afspraken, tickets, retouren).
Bepaal daarna welke records globaal zijn en welke eigendom van een vestiging. Globale records worden bedrijfbreed gedeeld, zoals een klantprofiel, een productcatalogus of corporate prijsregels. Vestiging-eigendom records horen bij één vestiging, zoals een dagelijkse kasstaat, een lokaal rooster of een vestiging-specifieke voorraadtelling.
Permissies hebben twee dimensies, niet één:
Lezen en bewerken moeten gescheiden zijn. Een regiomanager kan alle vestigingen lezen maar alleen het personeelsrooster van zijn eigen vestiging bewerken. Een baliemedewerker kan klantprofielen lezen maar alleen afspraken voor zijn eigen vestiging aanmaken en bewerken.
Beslis tot slot hoe rapportage moet werken. De meeste teams hebben zowel prestaties per vestiging voor dagelijks beheer nodig als cross-locatie rapportage voor eigenaren en finance. Spreek hier vroeg over af zodat je geen rapporten bouwt die data op verwarrende wijze mengen.
Een multi-locatieopzet begint met één beslissing: wat betekent een "vestiging" in jouw bedrijf? Voor sommige teams is het een winkel die klanten bezoeken. Voor anderen is het een kliniek, een magazijn of een franchise-eenheid die apart moet blijven.
Kies één betekenis en houd je eraan in je datamodel. Als je later afdelingen of servicegebieden nodig hebt, voeg die dan toe als aparte concepten in plaats van de vestiging te overladen.
Geef elke vestiging een stabiele identificatie die nooit verandert, zelfs als de naam van de vestiging verandert. Een korte code (zoals "NYC-01") is meestal makkelijker dan adres of naam als sleutel.
Sla op waarop je dagelijkse werk afhangt: vestigingscode en weergavenaam, adres, tijdzone (cruciaal voor openingstijden, boekingen en rapporten), openingstijden (plus uitzonderingen voor feestdagen indien nodig) en een status zoals actief, tijdelijk gesloten of gearchiveerd.
Bepaal nu hoe personeel zich verhoudt tot vestigingen. Sommige bedrijven zijn strikt (één persoon, één vestiging). Anderen verplaatsen personeel tussen locaties. Beide benaderingen werken, maar het verandert hoe je werk toewijst en hoe je records filtert.
Een praktische aanpak is het modelleren van een aparte Staff-Vestiging toewijzing zodat je één-op-veel kunt ondersteunen zonder later alles om te hoeven bouwen.
Behandel nieuwe vestigingen als data, niet als speciale gevallen. Een eenvoudige test is: "Kunnen we vestiging #7 toevoegen zonder logica te veranderen?" Idealiter betekent het toevoegen van een locatie het aanmaken van een nieuw vestigingsrecord, het instellen van tijdzone en uren, en het toewijzen van personeel. Als je veel regels moet aanpassen, is het model te sterk gekoppeld.
Een nette permissie-opzet begint met één idee: scheid wat iemand kan doen (rol) van wat iemand kan zien (scope). Als je die door elkaar haalt, geef je uiteindelijk "behulpzame" toegang die ongemerkt over-sharing wordt.
De meeste kleine ketens kunnen rollen simpel houden: eigenaar, regiomanager, vestigingsmanager, medewerker en support. Definieer standaardpermissies per rol en hou ze saai. Voor elk gebied (klanten, afspraken of orders, voorraad, notities, rapporten) bepaal je wat bekijken, aanmaken en bewerken betekent. Benoem ook welke acties nooit standaard zijn, zoals exports of admin-wijzigingen.
Een checklist die verwarring voorkomt:
Scope is de tweede helft van het slot. De meeste teams hebben maar drie scopes nodig: eigen vestiging alleen, toegewezen vestigingen, of alle vestigingen. Een vestigingsmanager kan bewerkrechten hebben maar alleen in zijn eigen vestiging. Een regiomanager kan meerdere vestigingen bekijken maar alleen personeels- en roosterwijzigingen doen waar je hem voor hebt toegewezen.
Plan uitzonderingen voordat je ze nodig hebt. Tijdelijke toegang moet automatisch verlopen, niet afhankelijk zijn van iemands geheugen. Trainingsaccounts moeten nepdata of een beperkte sandbox gebruiken. Aannemers krijgen de kleinste scope mogelijk, en geen exports standaard.
Een gedeelde klantendatabase is vaak het punt van een multi-locatieopzet, maar het is ook de snelste manier om data tussen vestigingen te laten lekken. Bepaal wat echt "één klant, overal" is en wat lokaal moet blijven.
Gedeelde data omvat meestal het klantprofiel (naam, contactgegevens), loyaliteitsstatus en brede voorkeuren zoals "geen oproepen" of "voorkeur e-mail". Deze helpen elke vestiging de persoon te herkennen en consistent te bedienen.
Locatiespecifieke data moet verbonden blijven aan een vestiging: bezoeken, aankopen, afspraken, servicenotities en lokale tags zoals "VIP voor Vestiging A" of "follow-up volgende week nodig." Deze lokaal houden vermindert ruis en voorkomt dat medewerkers details lezen die ze niet hoeven te weten.
De eenvoudigste policy is: iedereen kan de klant vinden, maar niet iedereen kan alles zien.
Baliemedewerkers zien mogelijk profieldetails en contactvoorkeuren, plus hun eigen vestiging's bezoeken. Managers zien mogelijk cross-vestiging totalen (zoals lifetime spend) zonder gedetailleerde notities van andere vestigingen. HQ of supportrollen kunnen de volledige geschiedenis zien wanneer dat nodig is voor escalaties. Marketing krijgt toegang tot opt-in status en segmenten, niet tot privé servicenotities.
Dat houdt de gedeelde klantendatabase nuttig zonder er een gedeeld dagboek van te maken.
Gevoelige data (privénotities, documenten, klachten, medische of juridische details) moet gescheiden worden van algemene notities en achter strengere permissies worden gezet. Als je documenten opslaat, maak toegang expliciet: wie mag uploaden, wie mag bekijken, en of bekijken beperkt is tot dezelfde vestiging.
Voorbeeld: een klant bezoekt Vestiging 1 voor een knipbeurt en Vestiging 2 voor een productaankoop. Medewerkers van Vestiging 2 moeten de loyaliteitstier en een "allergisch voor geur" voorkeur zien, maar niet Vestiging 1's gedetailleerde klachtennotitie.
Een belangrijke beslissing is of je data scheidt door het te taggen of fysiek te splitsen. De meeste kleine ketens kunnen eenvoudig blijven met één database en duidelijke regels.
Dit is de gebruikelijke keuze. Orders, afspraken, voorraadstanden en handelingen van medewerkers staan in dezelfde tabellen, maar elke rij bevat een Vestigings-ID (of LocationID). Het ondersteunt gedeelde klanten, cross-locatie rapportage en personeel dat op meerdere vestigingen werkt.
Dit voelt soms "veiliger", maar verhoogt de dagelijkse kosten. Migraties gebeuren meerdere keren, rapporten worden lastiger en gedeelde klanten worden een synchronisatieprobleem.
Een praktische regel:
Welke pattern je ook kiest, maak vestigingsfiltering automatisch. Vertrouw niet op elk scherm of rapport om de filter te onthouden. Behandel de locatie als onderdeel van de gebruikerssessie en handhaaf die op één plek zodat elke lijst en actie standaard gescopeerd is.
Plan ook globale items versus lokale overrides. Houd definities globaal (catalogusitems, servicetemplates, prijsregels) en voeg optionele per-vestiging overridevelden toe waar nodig (vestiging-specifieke prijs, voorraad-drempel, openingstijden). Dat voorkomt het kopiëren van de hele catalogus per locatie.
Voeg audit-trails vroeg toe. Je moet kunnen antwoorden "wie heeft dit veranderd, en waar?" Vang minimaal user ID, vestigings-ID, timestamp, actie (create, update, delete) en voor-na waarden voor gevoelige velden.
Het doel is eenvoudig: mensen moeten alleen zien wat ze nodig hebben om hun werk te doen, en verder niets. De makkelijkste manier om daar te komen is beslissen wat bij een vestiging hoort, wat gedeeld is en hoe personeel door schermen beweegt.
Begin op papier (of in een simpele spreadsheet) voordat je je database of app-builder aanraakt.
Sla testen niet over. De meeste permissieproblemen verschijnen pas als je inlogt als een echte rol en probeert dagelijkse taken snel uit te voeren.
De meeste multi-locatieproblemen zijn geen grote fouten. Het zijn kleine defaults die ongemerkt data lekken of mensen blokkeren in hun werk. Ga ervan uit dat elk scherm, rapport en export een locatie-regel nodig heeft.
Rapporten en exports zijn een veelgemaakte miss. Teams filteren zorgvuldig in schermen per vestiging, maar exporteren dan "alle klanten" of "verkoop vorige maand" en nemen per ongeluk andere vestigingen mee. Behandel exports als aparte functies met eigen filters en tests. Als een medewerker een record niet in de app kan zien, mag die het ook niet kunnen exporteren.
Een ander probleem is de manager-rol die ongemerkt admin wordt. Dat gebeurt als je acties groepeert per scherm in plaats van per risico. Managers hebben mogelijk refunds, dienstwisseling of klantnotities nodig, maar geen gebruikersaanmaak, permissiewijzigingen of vestigingsinstellingen. Splits "operaties beheren" van "systeem beheren".
Gedeelde klanten raken ook rommelig wanneer je alles in één set velden stopt. Als je locatiespecifieke notities (zoals "vraagt hier altijd om korting") in een globaal veld zet, creëer je oversharing. Houd gedeelde klantfeiten gescheiden van vestigingsspecifieke notities en bezoekgeschiedenis.
Het ontbreken van een audit-trail veroorzaakt verwijten en extra werk. Als twee vestigingen dezelfde klant bewerken, heb je basis "wie heeft wat en wanneer veranderd" nodig. Zelfs simpele created_by, updated_by en timestamps helpen.
Plan ook voor personeel dat floatt tussen vestigingen. Als je hen verplaatst tussen vestigingen in plaats van multi-vestigings toegang te geven, breken roosters en zichtbaarheid.
Praktische fixes om vroeg in te bouwen:
Voordat je toegang naar elke vestiging opent, doe een nep-dag met testaccounts. Maak minimaal één medewerker per vestiging en één regiomanager. Doe vervolgens normaal werk: boek een afspraak, maak een order, update een klant, draai een rapport.
Gebruik deze checklist om problemen te vangen die de meeste verwarring veroorzaken:
Test vervolgens één edge-case: een klant koopt in Vestiging A en belt vervolgens Vestiging C voor support. Medewerkers in Vestiging C moeten het gedeelde klantprofiel zien, maar niet Vestiging A's interne notities of beperkte records.
Stel je een kleine kappersketen voor met drie vestigingen: Downtown, Riverside en Mall. Ze delen één klantenlijst zodat een klant overal kan boeken, maar elke vestiging houdt zijn eigen rooster, personeel en dagelijkse notities.
Maya (baliemedewerker bij Downtown) opent het systeem. Ze ziet alleen Downtown's agenda, Downtown personeel en de afspraken van vandaag. Ze kan klanten doorzoeken over alle vestigingen, maar ziet alleen basisprofielinfo: naam, telefoon, allergieën en loyaliteitsstatus. Ze ziet niet Riverside's rooster, personeelsresultaten of privénotities.
Alex (de eigenaar) logt in. Alex kan alle drie agenda's, omzetrapporten per vestiging en personeelsrollen beheren zien. Alex kan ook uitzonderingen goedkeuren zoals grote kortingen.
Jordan komt meestal naar Downtown, maar boekt deze week last-minute bij Mall. Wanneer Mall Jordan incheckt, zien ze Jordan's kernprofiel en servicegeschiedenis (wat is gedaan, wanneer en door wie). Na de behandeling voegt Mall de nieuwe service toe aan Jordan's geschiedenis. Downtown kan dat later zien, zodat ze geen vragen herhalen of een verkeerde vervolgactie aanbevelen.
Een lastig moment gebeurt bij de kassa. Jordan vraagt 30% korting vanwege lange wachttijd. De baliemedewerker van Mall kan een kortingsaanvraag invoeren, maar mag niet meer dan 10% toepassen. De aanvraag gaat naar Alex ter goedkeuring. Alex keurt het goed, het bonbedrag wordt aangepast en de auditlog toont wie vroeg en wie goedkeurde.
Gevoelige notities worden anders behandeld. Als een stylist een privénotitie toevoegt zoals "klant ervaart medische problemen, voorzichtig met hoofdhuidbehandelingen," kunnen alleen stylisten en de eigenaar die zien. Baliepersoneel ziet een veiliger vlaggetje zoals "speciale behandeling vereist" zonder de details.
Wat dit laat werken zijn een kleine set duidelijke regels: roosters en personeel per vestiging, gedeelde klantbasis, beperkte gevoelige notities en goedkeuringslimieten voor kortingen.
Een multi-locatieopzet blijft netjes alleen als je regels op papier zet en test als een feature, niet als een gevoel. Zet je "wie ziet wat" beslissingen om in simpele zinnen.
Streef naar 10 tot 15 korte statements die alledaagse gevallen dekken: boekingen, klantprofielen, betalingen, terugbetalingen, notities en rapporten. Bijvoorbeeld:
Bepaal welke schermen en rapporten altijd moeten standaardiseren op vestigingsscope. Als een scherm alle vestigingen kan tonen, maak het dan een expliciete filter, niet de default. Een goede test: kan een kassamedewerker per ongeluk het dagrapport van een andere vestiging openen zonder het te proberen? Zo ja, verscherp de standaard.
Test met echte rollen, niet met admin-accounts. Maak drie testgebruikers (kassa, manager, HQ) en doorloop een realistische flow: een klant belt Vestiging A, bezoekt volgende week Vestiging B en vraagt een terugbetaling bij Vestiging C. Bevestig dat elke persoon alleen ziet wat die nodig heeft.
Plan een maandelijkse permissiecontrole om drift te voorkomen: nieuwe rollen, functiewijzigingen, nieuwe vestigingen en report-access creep.
Als je een aangepast intern gereedschap bouwt, kan AppMaster (appmaster.io) je helpen vestigingen, rollen en bedrijfsregels in één plek te modelleren en vervolgens schone code te regenereren als requirements veranderen zodat permissieregels consistent blijven naarmate je groeit.
21 jan 2026
8 min
20 jan 20268 min
20 jan 20267 minExperimenteer met AppMaster met gratis abonnement.
Als je er klaar voor bent, kun je het juiste abonnement kiezen.
