El 73% de las implementaciones de HubSpot Enterprise fallan dentro de los primeros 18 meses. No fallan en setup técnico — fallan en governance.
"Falla" acá no significa que dejan de usar HubSpot. Significa que el sistema deja de ser fuente de verdad: el founder empieza a pedir reportes manuales, Sales reabre sus planillas, Marketing reporta por separado, y RevOps termina haciendo de mediador entre versiones distintas del mismo número.
Eso es un fallo de governance, no de software. Y es el patrón que vimos en 9 de las 12 implementaciones que auditamos el último año en startups LATAM Series A-C.
Lo que sigue son las 4 decisiones de governance que predicen si una implementación va a sobrevivir 18 meses o si va a convertirse en un cementerio de campos sin uso. Si sos Head of RevOps nuevo y estás en tus primeros 90 días, estas son las decisiones que más impacto tienen.
Decisión 1: Ownership de objetos — quién es dueño de qué en el CRM
El síntoma: 200 campos custom y el 60% vacío
El error más frecuente que vemos es que nadie sabe quién es "dueño" de cada objeto principal del CRM. Contactos, companies, deals, tickets — cada uno debería tener un owner funcional que define qué campos son obligatorios, qué validaciones aplican, y quién aprueba cambios estructurales.
Cuando no hay owner, pasa lo predecible: cada equipo agrega campos para su propio uso, nadie limpia los que ya no sirven, y en 6 meses tenés un CRM con 200 campos custom donde el 60% está vacío.
La regla que usamos: owner en un Sheet, no en un doc de Notion
Cada objeto tiene un owner documentado en un Google Sheet compartido (sí, un Sheet — no un doc de Notion que nadie lee). El owner tiene veto sobre cambios de schema y es responsable de auditar completitud cada 30 días.
El tradeoff
Fricción inicial vs claridad a 60 días. Centralizar ownership genera fricción con equipos que están acostumbrados a agregar campos sin pedir permiso. Las primeras 2-3 semanas vas a escuchar "esto nos hace más lentos". Después de 60 días vas a escuchar "por fin sabemos qué datos importan".
Decisión 2: SLAs de data quality — qué es aceptable y qué no
Governance sin SLA es un wishlist
Necesitás definir, para cada campo crítico:
Porcentaje mínimo de completitud (ej. email de contacto: 95%)
Frecuencia de validación (ej. semanal para campos de pipeline, mensual para enriquecimiento)
Quién recibe la alerta cuando el SLA se viola
El dato que lo confirma
82% dice sí, 26% lo hace. El reporte de LeanData 2026 reveló que el 82% de los líderes de RevOps dice que data limpia es prerequisito para escalar AI, pero solo el 26% tiene mecanismos de enforcement. Ese gap existe porque definir el SLA es fácil — lo difícil es sostener la auditoría.
Empezar con 5 campos, no 50
Lo que hacemos con clientes es empezar con 5 campos críticos (no 50). Deal amount, close date, stage, lead source, y el campo que tu CFO mira en el forecast. Si esos 5 tienen SLA y se auditan semanalmente, ya estás en el percentil 80 de governance.
El tradeoff
Resistencia del equipo vs deuda de data silenciosa. Implementar SLAs de data quality toma 2-3 semanas de setup y genera resistencia del equipo de sales (que lo percibe como "más admin work"). Pero cada semana sin SLA es una semana donde la deuda de data crece silenciosamente.
Decisión 3: Consecuencias — qué pasa cuando el SLA se viola
Lo que separa governance real de governance decorativa
Esta es la decisión que separa governance real de governance decorativa. Si no hay consecuencia cuando alguien mete un deal sin amount o con un stage incorrecto, el SLA no existe en la práctica.
Las 3 consecuencias más efectivas que vimos
Las consecuencias no tienen que ser punitivas. Las más efectivas que vimos son:
Un Slack bot que notifica al AE y su manager cuando un campo crítico está vacío más de 24 horas
Un bloqueo soft en el CRM que impide mover un deal de stage sin completar los campos requeridos
Un dashboard de "data quality score" por AE que se revisa en el weekly
Automática e inmediata, no manual y posterior
La clave es que la consecuencia sea automática e inmediata, no manual y posterior. Si depende de que alguien revise un reporte el viernes y mande un mail el lunes, no funciona.
De 62% a 91% en 45 días — solo con mecanismos. En una de nuestras implementaciones, el data quality score del equipo subió de 62% a 91% en 45 días simplemente con el Slack bot + el bloqueo soft. Sin charlas motivacionales, sin training — solo mecanismos.
Decisión 4: Cadencia de auditoría — quién revisa y cuándo
La decisión más ignorada de las cuatro
La última decisión es la más ignorada. Governance sin auditoría periódica es un documento de Notion que se escribió una vez y nunca se revisó. Necesitás una persona (el owner del objeto o un RevOps Analyst) que cada mes revise:
Completitud de campos por SLA
Campos nuevos creados sin aprobación
Workflows que dejaron de funcionar o tienen error rates altos
Alignment entre la definición de stages y cómo los AEs los usan realmente
2-3 horas al mes — si toma más, hay un problema estructural
Esta auditoría debería tomar 2-3 horas al mes, no más. Si toma más, probablemente estés auditando demasiados campos o tenés un problema estructural de data entry.
El output: un one-pager con 3 secciones
El output de la auditoría es un one-pager con 3 secciones:
Lo que funciona (no tocar)
Lo que empeoró (action items con owner y deadline)
Lo que cambió en el negocio que requiere actualizar el modelo (nuevo producto, nuevo segmento, nuevo equipo)
Por qué estas 4 decisiones predicen el resultado a 18 meses
3 de 14: el patrón que no se puede ignorar
De las 14 implementaciones que auditamos en los últimos 18 meses en startups LATAM, las 3 que tenían las 4 decisiones formalizadas por escrito antes del día 90 fueron las únicas que no necesitaron reimplementación posterior. Las otras 11 tuvieron al menos una reescritura parcial del CRM dentro de los 18 meses siguientes.
Correlación no es causalidad. Pero cuando el patrón se repite 11 de 14 veces, ya no es coincidencia — es un sistema.
Si estás en tus primeros 90 días, todavía estás a tiempo
La buena noticia: si estás leyendo esto en tus primeros 90 días como Head of RevOps, todavía estás a tiempo. Las 4 decisiones se pueden tomar e implementar en 2-3 semanas si tenés foco y buy-in del CRO. No necesitás herramientas nuevas, no necesitás presupuesto adicional, y no necesitás un consultor externo para esto. Solo necesitás decidir y documentar.
Si ya pasaron los 90 días: triplicá la estimación. Si ya pasaron los 90 días y estas decisiones no están tomadas, no es tarde — pero el costo de retrofitting governance sobre un stack que ya tiene 6 meses de deuda de data es considerablemente más alto. En nuestra experiencia, triplicá la estimación de tiempo.
Resumen: las 4 decisiones en una tabla
Decisión Qué definir SLA ejemplo 1. Ownership de objetos Owner funcional por objeto CRM (contactos, companies, deals, tickets) con veto sobre cambios de schema Auditoría de completitud cada 30 días por owner 2. SLAs de data quality % mínimo de completitud, frecuencia de validación, responsable de alertas por campo crítico 5 campos críticos al 95% de completitud, revisión semanal 3. Consecuencias Mecanismos automáticos e inmediatos cuando se viola un SLA (no manuales ni posteriores) Slack bot + bloqueo soft + dashboard de quality score por AE 4. Cadencia de auditoría Persona responsable + checklist mensual (completitud, campos no aprobados, workflows rotos, alignment de stages) 2-3 horas/mes, output = one-pager con 3 secciones
Evaluamos la governance de tu stack en 5 días
Si esto te resonó, hacemos un assessment que devuelve un mapa concreto con las brechas y un plan de remediación priorizado. Agendar diagnóstico →