Deel de velden in, niet het systeem
Een CRM bevat velden met heel verschillende gevolgen. Ze op één hoop gooien leidt tot het verkeerde antwoord, welke kant je ook kiest: alles automatisch vervuilt de stuurinformatie, alles handmatig levert geen enkele tijdwinst op.
Categorie 1 — Feiten met een bron
Een contactmoment dat aantoonbaar heeft plaatsgevonden, een ontvangen document, een gewijzigd telefoonnummer uit een e-mailhandtekening. De waarde is controleerbaar en de herkomst is aanwijsbaar. Hier kan een automatische update, mits de bron in de tijdlijn zichtbaar blijft en er een logboek van elke stap is.
Categorie 2 — Interpretaties
Fase, kwalificatie, kans, verwacht bedrag, prioriteit, sentiment. Dit zijn oordelen, en het zijn precies de velden waarop gestuurd wordt: een forecast draait erop. Hier hoort menselijke goedkeuring, ook als het model het meestal goed heeft — want de kosten van een stille fout zijn hier hoog en het merken duurt lang.
Categorie 3 — Velden met een gevolg buiten het CRM
Een veld dat een e-mailcampagne start, een factuur triggert, een contract-eindedatum zet of een klant op een andere servicetrap plaatst. Hier is de update geen registratie maar een handeling. Behandel het als een handeling: goedkeuring, expliciete bevestiging, en een logboek dat vermeldt welke vervolgactie erdoor is aangezet.
Hoe goedkeuring eruitziet als ze werkt
Drie eigenschappen maken het verschil tussen een goedkeuring die gebeurt en een die zich opstapelt:
- Het verschil is zichtbaar. Oude waarde, nieuwe waarde, en de aanleiding in één regel.
- Ze staat waar het werk al is. In het CRM, de inbox of het chatkanaal — niet in een apart scherm dat iemand moet onthouden.
- Afkeuren is even makkelijk als goedkeuren, en een afkeuring belandt in hetzelfde logboek. Een workflow waarin afkeuren moeite kost, meet zijn eigen kwaliteit niet.
Rollback is meer dan een ongedaan-knop
Rollback werkt alleen als je drie dingen vooraf hebt ingericht. Ten eerste een herkenbare herkomst: elke wijziging door de workflow is als zodanig gemarkeerd, zodat je ze kunt terugvinden tussen handmatige wijzigingen. Ten tweede de vorige waarde, bewaard bij de wijziging zelf — veel CRM-velden bewaren geen historie, en dan is "terugdraaien" niet mogelijk maar raden. Ten derde een batchpad: als er iets structureel misging, wil je honderd records tegelijk terugzetten, niet één voor één.
En voor categorie 3 geldt iets extra's: het terugzetten van het veld draait de vervolgactie niet terug. Een verstuurde campagnemail komt niet terug. Daarom is dat de categorie waar goedkeuring nooit vervalt.
Twee gevallen waarin je beter niets schrijft
Als het CRM meerdere schrijvende bronnen kent — een importscript, een formulier, een marketingtool én straks een workflow — zonder dat je kunt zien wie wat schreef, dan is het eerste werk het zichtbaar maken van de herkomst. Anders is elke fout onderzoekswerk.
En als niemand de eigenaar is van de veldendefinitie, automatiseer je het vullen van velden waarvan de betekenis per team verschilt. Dat levert consistente vulling van een inconsistent begrip op, wat erger is dan een leeg veld.