Perché ogni progetto di pulizia del CRM regredisce entro sei mesi
Il RevOps ottiene il budget, una consulenza fa uno sprint di sei settimane, i duplicati si chiudono, il reporting migliora. Sei mesi dopo i duplicati sono tornati. Una nota sul perché la pulizia è manutenzione, non un progetto, e su cosa richiede davvero un'igiene continua.
Ho visto questo pattern ormai in cinque aziende. Il RevOps ottiene un budget per un progetto di pulizia del CRM. Arriva una consulenza o un contractor, fa uno sprint di sei settimane e consegna un audit che chiude 3.000 duplicati, normalizza il 60% dei campi a testo libero e produce un report di 40 pagine con un trimestre di raccomandazioni. Il data team festeggia. Il reporting migliora in modo misurabile. I forecast diventano più puliti per un paio di pipeline review. Il team passa al progetto successivo.
Sei mesi dopo i duplicati sono tornati, i campi a testo libero sono andati alla deriva, e la slide usata per spiegare perché i numeri della pipeline non tornano è la stessa usata sei mesi prima.
Perché i progetti regrediscono
L’audit sistema i dati esistenti. Non sistema il sistema che ha prodotto i dati cattivi in primo luogo.
Le importazioni continuano ad arrivare con formati non allineati. I web form raccolgono testo libero in campi che dovrebbero essere picklist. Gli AE che lavorano un deal fuori dalla piattaforma durante uno sprint non sincronizzano mai il record indietro, e più il deal invecchia, meno è probabile che qualcuno lo ripulisca. Le operations di marketing lanciano una nuova campagna con le proprie convenzioni di campo perché nessuno ha detto loro che le convenzioni erano state ri-standardizzate tre mesi prima. Ognuna di queste è una nuova fonte di drift, e nessuna è stata affrontata nel perimetro del progetto.
L’inquadramento onesto è che la pulizia è manutenzione, non un progetto. I progetti hanno una data di fine e il lavoro smette di avvenire. La manutenzione è un carico continuo che qualcuno possiede per sempre, e fingere il contrario è ciò che produce il prossimo progetto di pulizia.
Come appare davvero il “continuo”
L’igiene regge tra una pulizia e l’altra quando tre pezzi sono al loro posto. Di solito mancano.
Un layer di regole che gira in scrittura. Valida il formato, controlla rispetto alla picklist, fa un fuzzy match con gli account esistenti, e o accetta il record o instrada l’eccezione a una coda. Senza di esso, il nuovo drift arriva più in fretta di quanto il vecchio drift venga risolto, e la coda è senza fondo fin dal primo giorno.
Una coda di eccezioni con un proprietario, con una persona nominata e uno slot ricorrente. Non “come parte del loro ruolo” in astratto — davvero sul calendario di qualcuno, ogni martedì alle 10. Le aziende che mantengono la qualità dei loro dati tra una pulizia e l’altra hanno tutte questo. Quelle che regrediscono trattano la coda come un best-effort, il che significa che riceve il tempo che resta dopo tutto il resto, il che significa che non riceve tempo.
La qualità dei dati riportata come una metrica di prima classe — tasso di duplicati, completezza dei campi, conteggio dei record obsoleti — su una dashboard che il responsabile RevOps esamina con cadenza regolare. Se quei numeri diventano invisibili tra un progetto e l’altro, stai già definendo il perimetro della prossima pulizia prima che qualcuno torni a guardarli.
Il nostro playbook di pulizia dei dati CRM è costruito attorno al rendere sostenibili quei tre pezzi senza aprire una nuova posizione di organico.
La versione di questo lavoro che non regredisce è quella che previene il drift nel punto di ingresso. La versione “pulizia” regredisce sempre.