Waarom een salesteam terecht terugdeinst
Een CRM is geen database maar een gedeeld geheugen. Zodra een deel van de velden niet meer door mensen is gevuld, weet niemand welk veld nog te vertrouwen is — en een team dat zijn eigen CRM wantrouwt, gaat naast het CRM werken. Dat is een duurder probleem dan het probleem dat je automatiseerde.
De oplossing is niet "geen automatisering". Het is de opvolging scheiden van de registratie.
Scheid drie dingen die vaak op één hoop liggen
- Signaleren — welke deals staan stil, welke e-mail is niet beantwoord, welke afspraak had een vervolg. Dit is puur lezen en kan volledig automatisch, want er verandert niets.
- Voorbereiden — een conceptmail, een samenvatting van de laatste drie contactmomenten, een voorgestelde volgende stap. Ook dit wijzigt het CRM niet.
- Vastleggen — een veld bijwerken, een fase verzetten, een taak aanmaken. Alleen hier gaat het om schrijven, en alleen hier is goedkeuring nodig.
In de praktijk zit het grootste tijdverlies in signaleren en voorbereiden, niet in het typen van de update. Je kunt dus de meeste winst pakken zonder één schrijfrecht af te geven.
Wat een voorstel moet bevatten
Een voorstel dat een mens in seconden kan beoordelen ziet er altijd hetzelfde uit: het oude veld, het nieuwe veld, en waarom. Die derde kolom is het verschil tussen goedkeuren en gokken. "Fase naar Offerte uitgebracht, omdat er op 12 mei een offerte is gemaild" is te beoordelen. "Fase naar Offerte uitgebracht" is dat niet.
Laat de goedkeuring plaatsvinden waar het werk al gebeurt — in de inbox, in het CRM zelf of in de chat die het team toch al open heeft. Een apart goedkeuringsdashboard wordt na twee weken niet meer geopend, en dan staan er honderd voorstellen te wachten.
Wanneer schrijven wél automatisch mag
Er is een categorie waar goedkeuring alleen ruis toevoegt: feitelijke, controleerbare registraties waarbij niemand een oordeel velt. Een contactmoment loggen dat aantoonbaar heeft plaatsgevonden, bijvoorbeeld. Voorwaarden: de wijziging is omkeerbaar, hij is zichtbaar in de tijdlijn, en er is een logboek van elke stap dat laat zien wat de workflow heeft gedaan.
Alles wat een interpretatie is — fase, kans, bedrag, prioriteit, kwalificatie — blijft een voorstel. Dat zijn precies de velden waar het team op stuurt.
Rollback is een ontwerpeis, geen noodplan
Voordat de eerste automatische write live gaat, moet er antwoord zijn op drie vragen: kun je zien welke wijzigingen door de workflow zijn gedaan, kun je ze per stuk terugdraaien, en kun je ze als batch terugdraaien als er iets structureel misging? Kun je die drie niet beantwoorden, dan is er geen automatische write — alleen voorstellen.
Waar dit niet werkt
Als het CRM nu al onbetrouwbaar is, lost een workflow dat niet op: je automatiseert dan het invullen van velden die toch niemand gebruikt. Begin dan met het snoeien van de velden waarop echt gestuurd wordt. En als het team het CRM vooral als verantwoordingsinstrument ervaart, verandert automatisering niets aan de onderliggende weerstand — dat is een gesprek, geen workflow.
Hoe een koppeling met het CRM praktisch wordt ingericht, staat op de pagina over HubSpot. Welk controleniveau bij welke stap hoort, staat in wat een AI-agent doet in een bedrijfsproces.