Waarom elk CRM-opschoningsproject binnen zes maanden terugvalt

Ik heb dit patroon inmiddels bij vijf bedrijven gezien. RevOps bemachtigt een budget voor een CRM-opschoningsproject. Een consultancy of contractor komt binnen, draait een sprint van zes weken, en levert een audit op die 3.000 duplicaten sluit, 60% van de vrije-tekstvelden normaliseert, en een rapport van 40 pagina’s produceert met een kwartaal aan aanbevelingen. Het datateam viert feest. De rapportage verbetert meetbaar. Forecasts worden schoner voor een paar pijplijnevaluaties. Het team gaat door naar het volgende project.

Zes maanden later zijn de duplicaten terug, zijn de vrije-tekstvelden afgedreven, en is de presentatie die wordt gebruikt om uit te leggen waarom de pijplijncijfers niet kloppen dezelfde als die zes maanden eerder werd gebruikt.

Waarom projecten terugvallen

De audit repareert de bestaande data. Hij repareert niet het systeem dat de slechte data in de eerste plaats produceerde.

Imports blijven plaatsvinden met niet-overeenkomende formaten. Webformulieren verzamelen vrije tekst in velden die keuzelijsten zouden moeten zijn. AE’s die tijdens een sprint een deal buiten het platform bewerken, synchroniseren het record nooit terug, en hoe ouder de deal wordt, hoe kleiner de kans dat iemand het opschoont. Marketing operations lanceert een nieuwe campagne met zijn eigen veldconventies omdat niemand hun heeft verteld dat de conventies drie maanden geleden opnieuw zijn gestandaardiseerd. Elk daarvan is een nieuwe bron van drift, en geen ervan werd in de projectscope aangepakt.

De eerlijke framing is dat opschoning onderhoud is en geen project. Projecten hebben een einddatum en het werk stopt met gebeuren. Onderhoud is een continue belasting waarvan iemand voor altijd eigenaar is, en anders doen alsof is wat het volgende opschoningsproject voortbrengt.

Hoe “continu” er werkelijk uitziet

Hygiëne houdt stand tussen opschoningen door wanneer er drie onderdelen aanwezig zijn. Ze ontbreken meestal.

Een regellaag die draait bij het wegschrijven. Hij valideert het formaat, controleert tegen de keuzelijst, voert een fuzzy match uit tegen bestaande accounts, en accepteert ofwel het record ofwel routeert de uitzondering naar een wachtrij. Zonder die laag arriveert nieuwe drift sneller dan oude drift wordt opgelost, en is de wachtrij bodemloos vanaf dag één.

Een wachtrij voor uitzonderingen met een eigenaar, met een aangewezen persoon en een terugkerend tijdslot. Niet “als onderdeel van hun rol” in abstracte zin — werkelijk in iemands agenda, elke dinsdag om 10:00 uur. De bedrijven die hun datakwaliteit tussen opschoningen door behouden, hebben dit allemaal. Degene die terugvallen, behandelen de wachtrij als best-effort, wat betekent dat ze de tijd krijgt die overblijft nadat al het andere is gedaan, wat betekent dat ze geen tijd krijgt.

Datakwaliteit gerapporteerd als een eersteklas metric — duplicaatpercentage, veldvolledigheid, aantal verouderde records — op een dashboard dat de RevOps-lead op een normale cadans bekijkt. Als die cijfers tussen projecten door onzichtbaar worden, bent u de volgende opschoning al aan het scopen tegen de tijd dat iemand er opnieuw naar kijkt.

Onze playbook voor het opschonen van CRM-data is gebouwd rond het duurzaam maken van die drie onderdelen zonder een nieuwe formatieplaats op te tuigen.

De versie van dit werk die niet terugvalt, is die welke drift voorkomt op het punt van invoer. De opschoningsversie valt altijd terug.