Todos los equipos de ingresos han vivido esta reunión. RevOps pide un trimestre para limpiar el CRM. El director financiero pregunta cuánto vale. Alguien cita un estudio de un proveedor según el cual los datos malos cuestan millones al año, el director financiero señala que la empresa no es la del Fortune 500 de ese estudio, y el proyecto vuelve al final de la lista. Seis meses después empieza la misma conversación.
La petición fracasó por un motivo de arquitectura, no de persuasión. Nadie pudo trazar el coste desde un campo concreto de un registro concreto hasta una línea concreta de la cuenta de resultados. "Duplicados" era un recuento de filas. El coste de esas filas vivía en las agendas de los comerciales, en los registros de asignación, en los informes de campañas y en las previsiones de renovación, y ningún sistema los unía. Mientras no construyas esa unión, la calidad de los datos seguirá siendo una opinión.
Esas cifras demuestran que el problema es real. No te dicen cuánto te cuesta a ti. La conocida estimación de Gartner de 2020, según la cual la mala calidad de los datos cuesta a las organizaciones al menos $12,9 millones al año de media, describe a grandes empresas y abarca todos los dominios de datos. La estimación de Thomas Redman en MIT Sloan Management Review en 2017 situó el coste de los datos malos entre el 15% y el 25% de los ingresos para la mayoría de las empresas, un rango tan amplio que invita al director financiero a quedarse con el extremo inferior y rebajarlo aún más. La encuesta de Validity de 2025 a 602 usuarios de CRM encontró que el 76% afirma que menos de la mitad de los datos de su CRM son precisos y completos. Eso confirma el patrón, no tu cifra.
Por eso poner precio al deterioro de los datos es un problema de sistemas. Los datos de entrada ya existen en tu stack: registros de actividad, marcas de tiempo de asignación, miembros de campaña, jerarquía de cuentas, fechas de renovación. Lo que falta es un modelo que una un defecto a nivel de registro con un evento de ingresos, y un pipeline que lo recalcule cada semana, para que la cifra se mueva cuando se mueven los datos. Trata el coste como una métrica derivada con trazabilidad, no como una estadística de diapositiva.
Dónde falla
Los registros duplicados y deteriorados no cuestan dinero por existir. Cuestan dinero cuando un proceso posterior lee el registro equivocado. Cuatro modos de fallo explican la mayor parte de los dólares, y cada uno tiene un objeto concreto en el que se puede medir el coste.
Tiempo comercial perdido por la ambigüedad de los registros
Un comercial encuentra dos contactos con el mismo nombre, uno con un email que rebotó el mes pasado, y un historial de actividad repartido entre dos cuentas. Reconstruye el contexto antes de la llamada y después la registra en el primer registro que encontró, dividiendo de nuevo el historial. El coste aparece en los objetos Task y Event como tiempo sin resultado comercial, y en los campos de rebote de email como secuencias enviadas a personas que ya se fueron. La encuesta State of Sales 2024 de Salesforce encontró que los comerciales dedican el 70% de su tiempo a tareas que no son vender; la ambigüedad de los registros es una de las pocas partes de ese tiempo que se puede medir a partir de los registros del sistema y no de lo que recuerda una encuesta.
Leads entrantes mal asignados
Llega una solicitud de demo de alguien de una cuenta objetivo existente. El emparejamiento de lead a cuenta falla porque el campo de dominio está vacío en el registro con el que trabaja el responsable, o porque el lead coincide con un duplicado que tiene otro responsable. El reparto por turnos lo asigna a un comercial que nunca ha hablado con la cuenta, y el reloj del SLA sigue corriendo mientras se aclara quién es el responsable. El coste vive en los registros de asignación: la regla que se activó, el historial de cambios de responsable y el tiempo entre la fecha de creación y la primera actividad.
Una atribución que divide a un comprador en tres
El análisis de Plauti sobre más de 12.000 millones de registros de Salesforce procesados en 2021, publicado en enero de 2022, encontró que más del 45% de los registros nuevos que entraban en los CRM eran duplicados. Cuando un comprador existe como tres contactos, su asistencia al webinar está en uno, sus descargas de contenido en otro y el rol de contacto en la oportunidad en un tercero. Los informes de influencia de campañas leen los registros Campaign Member vinculados a contactos con un rol en la oportunidad, así que dos tercios del recorrido de ese comprador desaparecen del modelo. Programas que funcionaron parecen no haber funcionado. De dónde salen esos contactos de más, y cómo impedir que se creen, es el tema de por qué tu CRM tiene tres versiones de cada cuenta.
Una deriva de segmentación que oculta el riesgo de baja
Los segmentos de clientes se construyen sobre campos: número de empleados, sector, plan, responsable. Cuando una cuenta se divide en una matriz y un duplicado huérfano, el uso del producto cae en un registro y la asignación del CSM en el otro. La puntuación de salud lee el registro sin uso y marca como en riesgo a un cliente sano, o lee el que no tiene responsable y no marca nada. Las personas también cambian de empresa: la Oficina de Estadísticas Laborales de EE. UU. contabilizó 38,0 millones de bajas voluntarias y 62,8 millones de bajas totales en 2025, así que los contactos promotores se quedan obsoletos de forma continua, no una vez al año. Una previsión de renovaciones construida sobre segmentos obsoletos es una previsión de los clientes equivocados.
Arquitectura de referencia
Un modelo de costes que se recalcula a partir de datos en vivo necesita cinco capas. Ninguna requiere plataformas nuevas, solo un contrato claro entre las que ya tienes. Las herramientas citadas son ejemplos, no recomendaciones.
Componentes: Objetos del CRM (Account, Contact, Lead, Opportunity, Task, Campaign Member), registros de asignación, eventos de rebote y de interacción de email, uso del producto, facturación y fechas de renovación.
Herramientas de ejemplo: Salesforce o HubSpot, una herramienta de asignación, una plataforma de sales engagement, un pipeline de analítica de producto, un sistema de facturación.
Contrato con la capa siguiente: Los registros en bruto llegan con sus ID nativos y sus marcas de tiempo, sin modificar. El modelo de costes debe poder reproducir cualquier semana a partir de los datos de origen.
Componentes: Agrupación de duplicados por dominio y email normalizados, marcas de obsolescencia (rebote duro, sin interacción en un plazo fijado, cambio de cargo o de empresa) y comprobaciones de completitud en los campos que lee cada proceso posterior.
Herramientas de ejemplo: Informes nativos de duplicados, una herramienta de deduplicación o de emparejamiento, o modelos en SQL o dbt en un almacén de datos. Las reglas de emparejamiento que hay detrás de la marca de duplicado se explican en resolución de identidades para RevOps B2B.
Contrato con la capa siguiente: Cada registro lleva un conjunto de marcas de defecto (ID de grupo de duplicados, obsoleto, incompleto, huérfano) con la regla que produjo cada marca.
Componentes: El modelo de costes: cuatro uniones que conectan una marca de defecto con un evento de consumo (una actividad comercial, una decisión de asignación, un contacto de atribución, una renovación), cada una con un supuesto de precio por escrito.
Herramientas de ejemplo: Modelos en el almacén de datos, una capa semántica de BI o una tarea programada en una herramienta de flujos como n8n.
Contrato con la capa siguiente: Cada línea de coste devuelve dólares, los ID de los registros que los generan y la versión de los supuestos utilizada, para que cualquier cifra pueda rastrearse hasta las filas.
Componentes: Una tabla de coste del deterioro con una fila por línea de coste y semana, más una tabla de supuestos aprobada por finanzas.
Herramientas de ejemplo: Una tabla del almacén de datos, sincronizada con un objeto personalizado del CRM si la dirección trabaja en el CRM.
Contrato con la capa siguiente: Las filas históricas nunca se sobrescriben. Cuando cambia un supuesto, se escribe una versión nueva y las semanas anteriores se recalculan una junto a otra.
Componentes: Una tendencia semanal del coste para la dirección, colas de corrección ordenadas por dólares y no por número de filas, y alertas cuando una línea de coste se dispara.
Herramientas de ejemplo: Paneles de BI, vistas de lista del CRM, un agente de monitorización que publica en Slack o Teams.
Contrato con la capa siguiente: Cada elemento de la cola de corrección lleva su peso en dólares, para que el equipo trabaje primero los registros más caros.
El modelo en sí son cuatro líneas. La primera, la segunda y la cuarta son pérdidas. La tercera se reporta aparte como exposición, porque el gasto mal atribuido es un riesgo de decisión y no dinero que ya ha salido de la empresa, y mezclar ambas cosas es la forma más rápida de perder la confianza de un director financiero.
# Four-line data decay cost model (weekly or annualized)
rep_time_cost = reps x hours_lost_per_rep_week x selling_weeks x loaded_hourly_cost
misrouting_cost = inbound_volume x misroute_rate
x (conv_clean - conv_misrouted) x win_rate x avg_acv
segmentation_cost = arr_on_misclassified_accounts x churn_uplift
decay_loss = rep_time_cost + misrouting_cost + segmentation_cost
attribution_exposure = program_spend x share_of_touches_unlinked # report separately
Un ejemplo ilustrativo muestra cómo se suman las líneas. Todas las cifras que siguen son números redondos inventados para mostrar el cálculo, no una referencia del mercado ni el resultado de un cliente. Toma una empresa de SaaS B2B con $15M de ARR y 20 comerciales con cuota. Si los registros de actividad muestran que cada comercial pierde dos horas a la semana por registros duplicados y obsoletos durante 46 semanas de venta, con un coste por hora cargado de $75, el tiempo comercial cuesta $138.000. Si de 1.600 solicitudes entrantes al año se asigna mal el 12%, y los leads mal asignados se convierten en oportunidades al 15% en lugar del 25%, con una tasa de cierre del 20% y un valor medio de contrato de $30.000, la mala asignación cuesta $115.200. Si $1,2M de ARR están en cuentas divididas o mal clasificadas por los duplicados, y esas cuentas se dan de baja cinco puntos más a menudo, la segmentación cuesta $60.000. Eso sitúa la pérdida ilustrativa por deterioro en $313.200, alrededor del 2,1% del ARR, con una exposición de atribución aparte de $90.000 si el 15% de los contactos de un presupuesto de programas de $600.000 no puede vincularse a una oportunidad.
Secuencia de construcción
Construye la cifra antes que la corrección. Cuatro semanas de línea base te dan una lista de correcciones priorizada y el antes y después que financia el siguiente proyecto.
Define las marcas de defecto
Escribe las reglas de duplicado, obsoleto, incompleto y huérfano en lenguaje llano y en SQL. Que sean estrechas: un duplicado son dos cuentas que comparten un dominio corporativo normalizado, no dos con nombres parecidos. El playbook de diagnosticar antes de construir explica cómo hacerlo en modo solo lectura sobre los datos de producción.
Instrumenta los cuatro eventos de consumo
Para cada línea de coste, encuentra el evento que demuestra que se leyó un defecto: una actividad registrada en un registro de un grupo de duplicados, una decisión de asignación sobre un lead cuyo dominio coincidía con una cuenta con otro responsable, un contacto de campaña en un contacto sin rol en la oportunidad, una renovación en una cuenta con el uso dividido. Si un evento no se registra, empieza a registrarlo ya. El modelo es tan bueno como estas uniones.
Acuerda los supuestos de precio con finanzas
El coste por hora cargado, las tasas de conversión, la tasa de cierre, el ACV y el aumento de bajas deben salir de tu propio histórico o de finanzas, no del estudio de un proveedor. Ponlos en una tabla de supuestos versionada. Una cifra que finanzas ha ayudado a construir es una cifra que finanzas defiende en la reunión de presupuesto.
Valida con casos que tu equipo ya haya juzgado
Reúne unos veinte ejemplos pasados por línea de coste, como leads mal asignados que el equipo investigó o renovaciones perdidas tras dividirse un registro, y comprueba que el modelo los marca y les pone un precio verosímil. Nuestro listón para todo lo que lanzamos es un 85 por ciento de coincidencia con lo que habría concluido un operador sénior, o no se pone en marcha.
Publica la tabla semanal de costes
Programa el modelo, escribe una fila por línea y semana y muestra la tendencia. Presenta las tres líneas de pérdida como titular y la exposición de atribución debajo, nunca sumadas.
Ordena la cola de correcciones por dólares
Ordena los grupos de duplicados y los registros obsoletos por el coste que generaron en los últimos 90 días. Lo previsible es que una pequeña parte de los registros genere la mayoría de los dólares, lo que convierte una limpieza sin fin en una con alcance acotado.
Construir o comprar: ventajas y desventajas
Hay tres formas realistas de obtener esta cifra. La mayoría de los equipos empieza por la primera para ganar la discusión y pasa a la segunda o a la tercera cuando la cifra tiene que mantenerse al día.
| Enfoque | Encaje | Coste de propiedad | Riesgo de fallo |
|---|---|---|---|
| Modelo puntual en hoja de cálculo a partir de exportaciones del CRM e informes de duplicados | Un primer caso de presupuesto, un solo CRM, una dirección que necesita una cifra este trimestre | El más bajo. Unos días de trabajo de un analista | Se queda obsoleto la misma semana en que se presenta. Los supuestos viven en celdas que nadie audita, y el modelo no puede demostrar si la corrección funcionó |
| Informes nativos del CRM más los paneles de una herramienta de calidad de datos o de deduplicación | Los duplicados son el defecto principal, y la dirección ya trabaja dentro del CRM | Moderado. Licencia de la herramienta más tiempo de administración | Cuenta bien los defectos, pero rara vez los une con eventos de asignación, atribución o renovación, así que reporta filas y no dólares |
| Modelo de costes en el almacén de datos con supuestos versionados y un agente de monitorización | Varias fuentes, datos de producto y de facturación en juego, un director financiero que quiere trazabilidad | El más alto. Necesita un ingeniero de datos o de GTM que se responsabilice de los modelos y las pruebas | Los fallos silenciosos del pipeline pueden congelar la cifra. Necesita comprobaciones de frescura y un responsable de la tabla de supuestos |
El factor decisivo no son las herramientas, sino que la cifra se recalcule a partir de datos en vivo con supuestos firmados por finanzas. Quién es responsable de ese modelo es una cuestión de diseño organizativo tanto como técnica, y el árbol de decisión GTM engineer frente a RevOps manager es una forma útil de resolverla.
En producción
Vigila cada línea de coste cada semana, no solo el total. Un salto en el coste de mala asignación con un recuento de duplicados estable suele significar que cambió una regla de asignación, no que los datos empeoraran. Vigila también la frescura de las entradas: un registro de asignación que deja de actualizarse parece un coste que baja.
Cuando una fuente está desactualizada o falta un supuesto, el modelo debe devolver "no calculado" para esa línea en lugar de cero. Un cero parece un éxito y acaba capturado en una presentación al consejo. Conserva todas las versiones anteriores de los supuestos para que una cifra recalculada siempre pueda explicarse.
Empieza por la cifra de pérdida y las tres líneas que la componen, y después la línea de exposición por separado. Di qué supuestos aportó finanzas, muestra la tendencia desde que empezó la corrección y nombra los registros que generaron la mayor parte. La dirección necesita ver que la cifra se mueve cuando los datos mejoran, porque eso la convierte en una métrica y no en una afirmación.
Dónde encaja en el sistema
Un modelo de coste del deterioro no es un sistema en sí mismo. Es la capa de precios que te dice qué sistema construir primero y demuestra si funcionó. El Pipeline Hygiene Sentinel es su operador natural: señala los registros duplicados, obsoletos y huérfanos a medida que aparecen, para que la línea de coste baje en lugar de que el histórico crezca entre limpiezas. La línea de mala asignación es de la que depende Speed-to-Lead, porque asignar en minutos solo sirve si el lead se vincula a la cuenta correcta. La línea de segmentación alimenta el Churn Signal Watchtower, que no puede vigilar a un cliente cuyo uso y cuyo responsable están en registros distintos. Y el Board Report Engine es donde la tabla semanal de costes llega a la dirección, junto al pipeline y la retención y no en un informe aparte de calidad de datos que nadie abre. El mapa completo está en la página de sistemas.
Esa secuencia es la lógica del forward-deployed engineering: poner precio a la fuga con tus propios datos, construir el sistema que cierra la línea más cara y dejar el modelo funcionando para que la siguiente petición de presupuesto empiece con una cifra y no con una discusión.
Fuentes: Gartner, investigación sobre calidad de datos (2020), citada en la página temática de Gartner sobre calidad de datos. Validity, The State of CRM Data Management in 2025 (n=602, julio de 2025). Salesforce, State of Sales (n=5.500, julio de 2024). Thomas C. Redman, "Seizing Opportunity in Data Quality", MIT Sloan Management Review (2017). Plauti, "80% of all new integration data in CRMs is duplicate" (análisis de más de 12.000 millones de registros de Salesforce en 2021, enero de 2022; copia archivada, la página original se ha retirado). Oficina de Estadísticas Laborales de EE. UU., Job Openings and Labor Turnover Survey, cifras anuales de 2025 (marzo de 2026).
