Por qué todo proyecto de limpieza del CRM retrocede en seis meses

He visto este patrón ya en cinco empresas. RevOps consigue un presupuesto para un proyecto de limpieza del CRM. Una consultoría o un contratista entra, hace un sprint de seis semanas y entrega una auditoría que cierra 3.000 duplicados, normaliza el 60% de los campos de texto libre y produce un informe de 40 páginas con recomendaciones para un trimestre entero. El equipo de datos lo celebra. El reporting mejora de forma medible. Las previsiones se vuelven más limpias durante un par de revisiones de pipeline. El equipo pasa al siguiente proyecto.

Seis meses después los duplicados han vuelto, los campos de texto libre se han ido a la deriva, y la presentación que se usa para explicar por qué los números del pipeline no cuadran es la misma que se usó seis meses antes.

Por qué los proyectos retroceden

La auditoría arregla los datos existentes. No arregla el sistema que produjo los datos malos en primer lugar.

Las importaciones siguen sucediendo con formatos que no coinciden. Los formularios web recogen texto libre en campos que deberían ser listas desplegables. Los AE que trabajan un acuerdo fuera de la plataforma durante un sprint nunca sincronizan el registro de vuelta, y cuanto más viejo se hace el acuerdo, menos probable es que alguien lo limpie. Las operaciones de marketing lanzan una nueva campaña con sus propias convenciones de campos porque nadie les dijo que las convenciones se habían re-estandarizado hace tres meses. Cada una de esas es una fuente nueva de deriva, y ninguna de ellas se abordó en el alcance del proyecto.

El planteamiento honesto es que la limpieza es mantenimiento, no un proyecto. Los proyectos tienen una fecha de fin y el trabajo deja de suceder. El mantenimiento es una carga continua de la que alguien es dueño para siempre, y fingir lo contrario es lo que produce el siguiente proyecto de limpieza.

Cómo se ve «continuo» de verdad

La higiene se mantiene entre limpiezas cuando tres piezas están en su sitio. Normalmente faltan.

Una capa de reglas que se ejecuta al escribir. Valida el formato, comprueba contra la lista desplegable, hace coincidencia difusa contra las cuentas existentes, y o bien acepta el registro o enruta la excepción a una cola. Sin ella, la nueva deriva llega más rápido de lo que se resuelve la vieja, y la cola es un pozo sin fondo desde el primer día.

Una cola de excepciones con dueño, con una persona designada y un espacio recurrente. No «como parte de su rol» de forma abstracta —de verdad en el calendario de alguien, cada martes a las 10 de la mañana. Las empresas que mantienen su calidad de datos entre limpiezas tienen todas esto. Las que retroceden tratan la cola como algo de buena voluntad, lo que significa que recibe el tiempo que sobra después de todo lo demás, lo que significa que no recibe tiempo.

La calidad de datos reportada como una métrica de primera clase —tasa de duplicados, completitud de campos, recuento de registros obsoletos— en un dashboard que el responsable de RevOps revisa con una cadencia normal. Si esos números se vuelven invisibles entre proyectos, ya estás dimensionando la siguiente limpieza para cuando alguien vuelva a mirar.

Nuestro playbook de limpieza de datos del CRM está construido en torno a hacer que esas tres piezas sean sostenibles sin levantar una nueva línea de plantilla.

La versión de este trabajo que no retrocede es la que previene la deriva en el punto de entrada. La versión de limpieza siempre retrocede.