Warum jedes CRM-Bereinigungsprojekt innerhalb von sechs Monaten zurückfällt

Ich habe dieses Muster mittlerweile bei fünf Unternehmen gesehen. RevOps sichert sich ein Budget für ein CRM-Bereinigungsprojekt. Eine Beratung oder ein Auftragnehmer kommt herein, führt einen sechswöchigen Sprint durch und liefert ein Audit, das 3.000 Duplikate schließt, 60 % der Freitextfelder normalisiert und einen 40-seitigen Bericht mit einem Quartal voller Empfehlungen produziert. Das Datenteam feiert. Das Reporting verbessert sich messbar. Die Forecasts werden für ein paar Pipeline-Reviews sauberer. Das Team geht zum nächsten Projekt über.

Sechs Monate später sind die Duplikate wieder da, die Freitextfelder sind abgedriftet, und das Deck, mit dem erklärt wird, warum die Pipeline-Zahlen nicht zusammenpassen, ist dasselbe, das schon sechs Monate zuvor verwendet wurde.

Warum Projekte zurückfallen

Das Audit behebt die bestehenden Daten. Es behebt nicht das System, das die schlechten Daten überhaupt erst produziert hat.

Importe finden weiterhin mit nicht übereinstimmenden Formaten statt. Webformulare erfassen Freitext in Feldern, die Auswahllisten sein sollten. AEs, die während eines Sprints einen Deal außerhalb der Plattform bearbeiten, synchronisieren den Datensatz nie zurück, und je älter der Deal wird, desto unwahrscheinlicher ist es, dass ihn jemand bereinigt. Das Marketing-Operations-Team liefert eine neue Kampagne mit eigenen Feldkonventionen aus, weil ihnen niemand gesagt hat, dass die Konventionen vor drei Monaten neu standardisiert wurden. Jede davon ist eine frische Quelle von Drift, und keine davon wurde im Projektumfang adressiert.

Die ehrliche Einordnung ist, dass Bereinigung Instandhaltung ist und kein Projekt. Projekte haben ein Enddatum, und dann hört die Arbeit auf zu geschehen. Instandhaltung ist eine kontinuierliche Last, die jemand für immer besitzt, und so zu tun, als wäre es anders, ist genau das, was das nächste Bereinigungsprojekt hervorbringt.

Wie „kontinuierlich” tatsächlich aussieht

Hygiene hält zwischen den Bereinigungen, wenn drei Bausteine vorhanden sind. Sie fehlen in der Regel.

Eine Regelschicht, die beim Schreiben ausgeführt wird. Sie validiert das Format, prüft gegen die Auswahlliste, führt einen Fuzzy-Abgleich gegen bestehende Accounts durch und akzeptiert entweder den Datensatz oder leitet die Ausnahme an eine Warteschlange weiter. Ohne sie kommt neue Drift schneller an, als alte Drift gelöst wird, und die Warteschlange ist vom ersten Tag an bodenlos.

Eine in Verantwortung übernommene Ausnahme-Warteschlange, mit einer namentlich benannten Person und einem wiederkehrenden Zeitfenster. Nicht abstrakt „als Teil ihrer Rolle” — tatsächlich im Kalender von jemandem, jeden Dienstag um 10 Uhr. Die Unternehmen, die ihre Datenqualität zwischen den Bereinigungen halten, haben das alle. Diejenigen, die zurückfallen, behandeln die Warteschlange als „nach besten Kräften”, was bedeutet, dass sie die Zeit bekommt, die nach allem anderen übrig bleibt, was bedeutet, dass sie keine Zeit bekommt.

Datenqualität, die als erstklassige Kennzahl berichtet wird — Duplikatrate, Feldvollständigkeit, Anzahl veralteter Datensätze — auf einem Dashboard, das der RevOps-Leiter in normaler Kadenz überprüft. Wenn diese Zahlen zwischen den Projekten unsichtbar werden, planen Sie das nächste Bereinigungsprojekt bereits, bevor jemand wieder hinschaut.

Unser Playbook für die CRM-Datenbereinigung ist darauf ausgerichtet, diese drei Bausteine nachhaltig zu machen, ohne eine neue Stelle aufbauen zu müssen.

Die Version dieser Arbeit, die nicht zurückfällt, ist diejenige, die Drift am Eingabepunkt verhindert. Die Bereinigungsversion fällt immer zurück.