Een recruitment CRM voor meerdere vestigingen wordt pas echt belangrijk zodra kandidaten, vacatures en opvolging niet meer binnen één lokale queue blijven. Dan gaat het niet meer alleen over opslag van data. Het gaat over ownership. Als het systeem niet direct laat zien welke vestiging nu eigenaar is, waarom dat zo is en wat er gebeurt als die vestiging niet kan handelen, ontstaan dubbele belpogingen, losse notities en minder pipeline-zichtbaarheid.
Dat is ook de kern van de zoekintentie achter dit onderwerp. Een bruikbaar multi-vestigingen CRM draait niet vooral om meer dashboards, maar om een werkmodel dat laat zien waar een record thuishoort, wie het reviewt en wanneer het mag verplaatsen. Als jullie al werken aan pipeline-zichtbaarheid voor staffingbureaus of beter takenbeheer in recruitment CRM, dan gaat dit artikel over de vestigingslaag die daarboven ligt.
Waarom multi-vestiging staffing zo snel onduidelijk wordt
Het begint meestal klein:
- een kandidaat kan zowel in Rotterdam als in Eindhoven passen
- de ene vestiging belt al, terwijl de actieve vacature bij een andere vestiging zit
- een taaldesk kwalificeert de lead, maar ownership verhuist niet goed mee
- er is een gedeelde kandidatenpool, maar niemand weet wie hem mag trekken
- teamleads zien aantallen, maar geen duidelijke vestigingsverantwoordelijkheid
Het CRM kan er dan nog steeds gevuld uitzien, terwijl de operatie minder beheersbaar wordt. Kandidaten krijgen dubbele opvolging. Recruiters gaan uit van elkaar. Vestigingsmanagers optimaliseren hun eigen desk, maar verliezen overzicht op bureauniveau.
Vier regels die een multi-vestigingen CRM bruikbaar maken
Een zwaar enterpriseproject is meestal niet nodig. Vaak zijn vier regels genoeg.
1. Eén actief record, niet één record per vestiging
Als dezelfde live kandidaat in meerdere vestigingspipelines wordt gekopieerd, verdwijnt de waarheid uit beeld. Niemand ziet nog welke status actueel is.
Een beter model houdt vast aan:
- één primair kandidaatrecord
- één actuele eigenaar
- één zichtbare vestiging of desk
- één overdrachtsspoor als het record verhuist
Zo blijft zichtbaarheid intact zonder vestigingscontext te verliezen.
2. Altijd één zichtbare eigenaar
Gedeeld ownership klinkt handig, maar eindigt vaak als ownership van niemand. Elke actieve kandidaat, vacature of follow-upactie hoort één verantwoordelijke persoon of desk te tonen.
Dat kan zijn:
- een naam van een recruiter
- een intakequeue van een vestiging
- een meertalige desk
- een centrale overflowfunctie
Het belangrijkste is dat het systeem direct antwoord geeft op de vraag wie nu moet handelen.
3. Eén set routeringsregels
Multi-vestigingsteams raken vast wanneer iedere vestiging zijn eigen intakelogica verzint. De velden moeten gedeeld blijven. De regels bepalen daarna waar het record landt. Denk aan:
- regio of reisafstand
- type werk
- taalvoorkeur
- urgentie
- actuele capaciteit van de vestiging
Als de ene vestiging op geografie routeert en de andere op persoonlijke voorkeur van recruiters, wordt overdracht een onderhandeling in plaats van een proces.
4. Eén overflowregel
Zelfs een goed ontworpen model heeft een back-up nodig. Definieer dus wat er gebeurt wanneer:
- de eigenaar niet op tijd reageert
- een andere vestiging een duidelijk betere vacature heeft
- één desk overbelast raakt
- intake buiten kantooruren voor ochtenddruk zorgt
Zonder overflowregel belanden uitzonderingen alsnog in losse chats.
Wat het CRM zichtbaar moet maken bij elke vestigingskeuze
Zodra een record wordt toegewezen of verplaatst, moet de logica zichtbaar blijven. Minimaal wil je kunnen zien:
- huidige vestiging of desk
- huidige eigenaar
- reden van toewijzing
- volgende actie met deadline
- vorige vestigingsbeweging als de case is overgedragen
Dat is belangrijk, want iedere overdracht verhoogt follow-uprisico. Een zichtbare, tijdgebonden overdracht is beheersbaar. Een overdracht in vrije notities niet.
Een praktisch kader voor vestigingsrouting
Veel bureaus krijgen al meer grip met een simpele reviewvolgorde.
Stap 1: Bepaal het standaard-thuis
Elke nieuwe kandidaat hoort eerst één logisch startpunt te krijgen:
- lokale vestiging op basis van regio
- centrale intake desk
- taaldesk bij meertalige flow
- gespecialiseerde desk per rolfamilie
Dat standaard-thuis moet zijn bedacht voordat volume piekt.
Stap 2: Leg override-triggers vast
Verplaats pas als er iets inhoudelijks verandert, bijvoorbeeld:
- een betere vacature zit bij een andere vestiging
- de taalfit vraagt om een andere recruiter
- de kandidaat kan niet reizen naar de oorspronkelijke regio
- de eerste vestiging reageert niet binnen de afgesproken tijd
Dit zijn voorbeelden, geen vaste wet.
Stap 3: Verplaats ownership samen met de taak
Een vestigingsoverdracht is niet klaar als alleen het record van queue verandert. Ownership, volgende actie en deadline moeten meeverhuizen.
Stap 4: Beoordeel vestigingsdrift wekelijks
Let bijvoorbeeld op:
- één vestiging houdt te veel records vast zonder actie
- dezelfde kandidaat wordt herhaaldelijk doorgeschoven
- overdrachten blijven te vaak zonder eigenaar
- centrale intake blijft werk doen dat lokaal thuishoort
Daar zie je of het model helder is of alleen druk oogt.
Veelgemaakte fouten
In één CRM toch per vestiging aparte mini-systemen bouwen
Als iedere vestiging eigen stages, velden en verhuisregels gebruikt, is het gedeelde CRM in de praktijk niet meer gedeeld.
Wel aan een vestiging toewijzen, maar niet aan een persoon
Een vestigingsqueue kan prima werken, maar een live follow-up heeft nog steeds één concrete eigenaar nodig.
Overdrachten alleen in comments of WhatsApp zetten
Dan zijn reden, timing en volgende actie meteen minder zichtbaar voor teamleads.
Alleen op vestigingsautonomie sturen
Vestigingen hebben speelruimte nodig, maar geen tegenstrijdige recordlogica. Lokale vrijheid mag niet ten koste gaan van bureau-brede controle.
Korte checklist
- Houd één actief kandidaatrecord aan voor het hele bureau
- Maak huidige eigenaar, vestiging en volgende actie verplicht
- Gebruik één gedeelde set routeringsvelden voor alle vestigingen
- Leg een escalatieregel vast als een vestiging niet tijdig handelt
- Registreer waarom records tussen vestigingen verhuizen
- Evalueer wekelijks overbelasting en dubbele opvolging
FAQ
Moet iedere vestiging een eigen pipeline hebben?
Vaak wel een eigen werkweergave, maar niet een eigen kopie van hetzelfde record. Gescheiden kopieën zorgen meestal voor verwarring.
Hoe voorkom je dubbele kandidaatcontacten tussen vestigingen?
Werk met één live eigenaar, één gedeeld record en één zichtbare overdrachtsregel. Dubbele opvolging ontstaat meestal door onduidelijk ownership.
Kan een taaldesk boven vestigingsownership hangen?
Ja. Veel bureaus gebruiken eerst een intake- of taaldesk en zetten daarna pas door naar de uitvoerende vestiging.
Wat als twee vestigingen de kandidaat allebei kunnen plaatsen?
Spreek vooraf een beslisregel af, bijvoorbeeld standaard-thuisvestiging, vacatureprioriteit of responstijdvenster. Het CRM moet daar niet per geval opnieuw over debatteren.
Is hier zware software voor nodig?
Nee. Kleinere bureaus winnen vaak meer met betere velden, ownershipregels en overdrachtslogica dan met extra tooling.
Als jullie bureau groeit over meerdere vestigingen, desks of regio's, bekijk dan de oplossingen, vergelijk de prijzen of gebruik contact om te bespreken waar vestigingsownership nu precies vastloopt.