Una implementación de HubSpot se atrasa casi siempre por la misma causa raíz: el equipo que ejecuta no conoce el negocio del cliente y lo descubre a mitad de camino, a costa del cronograma. No es falta de insumos ni un problema técnico. Es que nadie tradujo las reglas del negocio antes de configurar.
Cómo se ve por dentro un atraso por desconocimiento del negocio
El patrón se repite de forma parecida en la mayoría de los casos. El proveedor configura un pipeline con etapas genéricas de "prospecto, calificado, propuesta, cierre". Semanas después, el equipo comercial del cliente dice que ese flujo no representa cómo vende de verdad, porque su proceso tiene una etapa intermedia de validación técnica que nadie preguntó.
Lo mismo pasa con los reportes. El proveedor arma un dashboard con las métricas que suele usar en otros proyectos. La gerencia del cliente lo revisa y pide otro completamente distinto. El indicador que de verdad le importa a su negocio no estaba entre los genéricos que se configuraron por defecto.
Ninguno de los dos casos es un error técnico. HubSpot funcionó exactamente como se le pidió. El problema es que a quien ejecutó nunca le explicaron, o nunca preguntó, cómo funciona el negocio que estaba configurando.
Por qué el desconocimiento del negocio pesa más que la falta de insumos
La causa estructural es que configurar un CRM parece un trabajo técnico, y por eso se asigna a personas técnicas. Pero las reglas que hay que traducir en propiedades, pipelines y automatizaciones son reglas de negocio, no reglas de software. Un asesor sin ese conocimiento configura lo correcto en la interfaz y lo equivocado para el cliente.
Esto explica por qué el 8.5 por ciento de los tickets de soporte de Progresus, 391 de 4.611 medidos, es sobre workflows y automatización (dato propio, tickets de soporte, agosto de 2026). Un workflow mal configurado casi nunca falla por un error de sintaxis. Falla porque automatiza una regla que no correspondía a como opera el cliente de verdad.
El 9.1 por ciento de los tickets, 420 de 4.611, es sobre reportes y dashboards (dato propio, tickets de soporte, agosto de 2026). Es la segunda señal más frecuente del mismo problema: reportes técnicamente correctos que miden lo que el proveedor supuso, no lo que el negocio necesitaba ver.
Qué cuesta que el desconocimiento aparezca a mitad de proyecto
El costo inmediato es el tiempo de reconfigurar lo que se hizo con supuestos equivocados. Ese tiempo se suma al cronograma original, y es indistinguible desde afuera de un atraso por insumos: el proyecto simplemente no cierra en la fecha pactada.
El costo menos visible es la confianza. Un cliente que ve su pipeline mal representado empieza a dudar de si el proveedor entendió el alcance completo del proyecto, no solo esa parte puntual. Esa duda contamina la relación en el resto del proyecto, incluso en las partes que sí están bien configuradas.
El 1.2 por ciento de las implementaciones de Progresus cierra en conflicto, sobre 1.476 proyectos medidos (dato propio, HubSpot, agosto de 2026). Es una proporción baja, pero el patrón detrás de esos casos casi siempre es el mismo: el desconocimiento del negocio no se corrigió a tiempo, y se acumuló hasta convertirse en una diferencia de expectativas que ya no se resuelve con una simple reconfiguración.
Los dos enfoques para transferir conocimiento del negocio, y cuándo falla cada uno
| Enfoque | Qué exige | Cuándo falla |
|---|---|---|
| Explicar el negocio solo en la reunión de kickoff | Nada adicional del cliente después de esa sesión | Cuando el proyecto dura semanas y el asesor olvida detalles que no volvió a escuchar |
| Documentar las reglas de negocio por escrito antes de configurar | Una sesión dedicada, con el documento revisado por ambas partes | Si el documento queda desactualizado y nadie lo vuelve a mirar durante el proyecto |
Explicar el negocio solo en la reunión de kickoff. Es el enfoque más común porque no exige preparación adicional del cliente. Falla porque una explicación verbal, sin registro escrito, se diluye a medida que avanza el proyecto. El asesor recuerda lo esencial, no los matices que distinguen tu proceso comercial de uno genérico.
Documentar las reglas de negocio por escrito antes de configurar cualquier pipeline. Exige una sesión dedicada solo a esto: quién califica un lead, en qué orden se mueve un negocio, qué reportes necesita cada área. A cambio, ese documento se puede revisar en cualquier punto del proyecto, no depende de la memoria de una sola reunión inicial.
Un tercer elemento reduce el riesgo: pedir que el asesor asignado repita, con sus propias palabras, cómo entendió las reglas del negocio antes de empezar a configurar. Si la explicación no coincide con lo que el cliente dijo, el desconocimiento se detecta antes de que se convierta en trabajo que hay que rehacer.
Cómo verificar que quien ejecuta entendió tu negocio, no solo el brief
No basta con que el proveedor tenga el brief del proyecto por escrito. Importa que la persona que va a configurar el portal haya internalizado esas reglas, y eso se verifica con preguntas puntuales, no con la existencia del documento.
Pide que el asesor te explique, en sus palabras, cómo se mueve un negocio típico por tu pipeline, desde el primer contacto hasta el cierre. Si la explicación coincide con tu proceso real, hay una base sólida. Si suena a un flujo genérico de ventas, todavía no hay comprensión real.
Pregunta también qué reportes va a necesitar cada área de tu empresa, no solo el equipo comercial. El 14.9 por ciento de los tickets de soporte de Progresus, 685 de 4.611, es sobre propiedades, campos y datos duplicados (dato propio, tickets de soporte, agosto de 2026). Buena parte de esos duplicados nace de reglas de captura de datos que no se explicaron bien desde el inicio, no de un error técnico posterior.
Preguntas frecuentes
¿Por qué se atrasan las implementaciones de HubSpot?
La causa más frecuente es que quien ejecuta no conoce el negocio del cliente y lo va descubriendo durante el proyecto. Configura pipelines y reportes técnicamente correctos, pero que no representan cómo opera el cliente de verdad, y hay que reconfigurarlos.
¿Cómo evito que mi implementación se atrase por falta de contexto de negocio?
Documenta por escrito las reglas de tu proceso comercial antes de que arranque la configuración, y pide que el asesor asignado te las repita con sus propias palabras. Si la explicación no coincide con tu negocio real, corrígela antes de avanzar.
¿El desconocimiento del negocio es lo mismo que la falta de insumos del cliente?
No. La falta de insumos es no entregar accesos o decisiones a tiempo. El desconocimiento del negocio es que el proveedor sí tiene la información, pero no la tradujo correctamente a la configuración del portal.
¿Cómo sé si mi proveedor entendió mi proceso comercial?
Pídele que explique, con sus palabras, cómo se mueve un negocio típico por tu pipeline. Si la explicación suena genérica en lugar de específica a tu operación, todavía no hay comprensión real.
¿Qué parte del proyecto revela primero este problema?
Los pipelines y los reportes. Un pipeline con etapas genéricas y un dashboard con métricas estándar son las primeras señales de que el proveedor configuró sin entender el negocio real detrás.
¿Vale la pena documentar las reglas de negocio si el proveedor ya tiene experiencia en mi industria?
Sí. La experiencia en una industria no reemplaza el conocimiento de tu empresa específica. Dos negocios del mismo sector pueden calificar un lead con criterios completamente distintos.
¿El soporte técnico cambia después de que el proyecto cierra?
Debería estar definido antes de firmar. Un proveedor que no separa con claridad el soporte de implementación del soporte posterior deja a tu equipo sin canal de consulta justo cuando más lo necesita.
El NPS de las implementaciones de Progresus es de 76 sobre 46 respuestas, medido con encuesta propia a clientes con proyecto cerrado (agosto de 2026). El patrón detrás de esa cifra no es un proceso distinto en apariencia: es que el equipo asignado invierte tiempo en entender el negocio del cliente antes de tocar el portal, no después de configurarlo mal una vez.
La mediana de duración de una implementación u onboarding de HubSpot entregado por Progresus es de 118 días, sobre 1.473 proyectos cerrados (dato propio, HubSpot, agosto de 2026). Cuando un proyecto se atrasa por desconocimiento del negocio, ese número deja de ser una referencia útil: el atraso no viene del alcance ni del sector, viene de tener que rehacer lo que se configuró con supuestos equivocados.
Antes de que arranque tu proyecto, exige documentar las reglas de tu negocio por escrito y compáralo contra la guía completa de cuánto dura y qué debes entregar .
Oswaldo Medrano