La mayoría de las implementaciones de HubSpot que salen mal no fallan porque el equipo eligiera la herramienta equivocada o al consultor equivocado. Fallan porque alguien comprimió una fase. El arco de implementación tiene cinco: Discovery, Design, Build, Launch, Optimize, y cada una termina con un artefacto que el equipo defenderá. Si se omite el artefacto, la fase siguiente descansa sobre la conversación y no sobre un compromiso. El coste aparece dos meses después, cuando Build reabre decisiones que debieron cerrarse en la semana dos.
Por qué importa ahora
El informe de HBR sobre por qué las inversiones digitales no generan valor lo dijo con claridad: el fallo no está en la tecnología, sino en no rediseñar cómo la organización comercial genera información, toma decisiones y coordina la acción. Una implementación de HubSpot es uno de los pocos momentos dentro de una empresa B2B SaaS en que ese rediseño sale a la luz: esquema, pipelines, responsables y reporting, todo sobre la mesa a la vez. La metodología de cinco fases existe porque el rediseño es el trabajo. La configuración de la plataforma es el artefacto final.
Discovery
Discovery es la fase que los equipos comprimen con más frecuencia y donde la compresión sale más cara. El objetivo no es hablar con la gente. El objetivo es salir con un artefacto escrito que todo el equipo haya aprobado: definiciones de pipeline, responsables designados para cada objeto, un mapa de integraciones, casos de uso dentro y fuera del scope, y los criterios de éxito con los que se medirá la implementación. Dos semanas es un presupuesto razonable. Con una semana se obtiene una fase de Design que habrá que rehacer.
Así se ve lo malo: un deck de Discovery que enumera las herramientas en uso, algunas citas de entrevistas y un conjunto vago de objetivos. Nadie discrepa porque nada es lo bastante concreto como para discrepar. Design acaba descubriendo los desacuerdos uno a uno, decisión por decisión, frente a un desarrollador que espera indicaciones.
Design
Design es donde viven las decisiones de esquema. Cada objeto que existirá en el portal de producción: Contact, Company, Deal, el custom object de suscripción, el objeto de portafolio si lo hay, se define aquí, por escrito, antes de construir nada. Las propiedades reciben un tipo de dato, una lista de opciones si corresponde, un responsable y una definición de una frase. Las etapas del pipeline reciben criterios de entrada, criterios de salida y una definición de lo que la etapa significa realmente. Las etiquetas de asociación se detallan. El entregable al final de Design es un documento de esquema más un inventario de workflows que el equipo pueda leer de principio a fin sin hacer preguntas.
Así se ve lo malo: un Design que ocurre dentro de la interfaz de HubSpot, a base de clics. Las propiedades se añaden sobre la marcha. Las etapas del pipeline se renombran tres veces. El documento de esquema, si existe, va una semana por detrás de la construcción. Tres meses después, nadie recuerda por qué existe la etapa de deal «Verbal», y la única persona que podría responder se ha ido.
Build
Build es la fase de sprints. Bien hecha, es una secuencia de dos a seis semanas de entregables pequeños, acotados y revisables: esquema desplegado en un sandbox, workflows conectados, integraciones activas, reportes montados, conjuntos de permisos configurados. La cadencia que funciona es semanal: una sesión de trabajo para confirmar la siguiente porción, un sprint de construcción a mitad de semana y una demo al final. La cadencia que no funciona es el seguimiento quincenal en el que el equipo de construcción desaparece y reaparece con un portal terminado que nadie ha visto.
Build solo funciona si Discovery y Design se sostuvieron. Si fue así, Build es ejecución contra una lista. Si no, Build son discusiones disfrazadas de standups. La prueba de diagnóstico, en cualquier semana de Build: ¿cuántas decisiones se están reabriendo? Si la respuesta es más de una o dos, el trabajo previo no se terminó.
Launch
Launch es el cutover, la capacitación y los primeros diez días. El cutover se hace un viernes, preferiblemente antes de una semana tranquila, y se ensaya en un sandbox antes de ejecutarlo en producción. La capacitación se imparte sobre el sistema posterior a la construcción, no sobre el heredado, y se dirige a quienes realmente usarán el sistema, no solo a los líderes que definieron el scope. Los primeros diez días son una ventana de hypercare: el equipo de construcción está de guardia, los problemas de los usuarios se clasifican en horas y no en días, y los pequeños ajustes que surgen con el uso real se resuelven antes de que el equipo cree hábitos en torno a soluciones provisionales.
Así se ve lo malo: un Launch en miércoles porque el calendario así lo exigía, un deck de capacitación grabado una vez y distribuido como video, y un equipo de construcción que se desmovilizó al día siguiente del cutover. En la tercera semana las soluciones provisionales ya son hábitos, ya son el sistema, y la fase de Optimize tendrá que deshacerlas en lugar de mejorar sobre ellas.
Optimize
Optimize es la fase para la que nadie planifica presupuesto. La implementación se define hasta Launch; Optimize se trata como trabajo de administración a tiempo parcial de alguien. Ese es el error. Toda instancia de HubSpot acumula cambios: se piden nuevas propiedades, los workflows reciben casos límite, las necesidades de reporting evolucionan, el equipo aprende qué quiere ver realmente frente a lo que creía que querría. Optimize es la fase en la que esas señales se clasifican con una cadencia, mensual es lo adecuado para la mayoría de las empresas, en lugar de ser absorbidas por el ruido diario.
Así se ve lo malo: Optimize es lo que la persona senior de operaciones logra atender entre urgencia y urgencia. A los seis meses, el sistema se ha desviado del esquema documentado, nadie ha auditado los workflows desde el lanzamiento y la siguiente persona que se incorpore al equipo hereda una instancia que es dos tercios diseño original y un tercio improvisación. El presupuesto de optimización que nadie planificó es ahora el proyecto de migración que nadie quería.
Un patrón del campo
Un equipo B2B SaaS en la recta final de su Serie A llegó para una implementación de HubSpot con un plazo de seis semanas. Discovery estaba planificado en cuatro días. Lo discutimos y lo ejecutamos en dos semanas. El artefacto fue un documento con las definiciones de pipeline, los responsables, el scope de integraciones, los criterios de éxito y una lista de casos de uso que el equipo acordó dejar fuera de la v1. Design tomó tres semanas y produjo un documento de esquema más un inventario de workflows. Build fue un sprint limpio de cuatro semanas: demos semanales y ninguna decisión reabierta. Launch fue un cutover en viernes con una semana de hypercare atendida por el equipo de construcción. Optimize arrancó treinta días después del lanzamiento con cadencia mensual y sigue en marcha. Lo que vale la pena destacar: la primera revisión trimestral del negocio sobre el nuevo sistema no requirió una limpieza manual de datos. Eso es lo que compra un Discovery que no se comprimió, diez meses después.
Resolución: elegir el modelo de engagement que corresponde a cada fase
Las cinco fases no tienen que vivir dentro de un único tipo de engagement. Cada fase se beneficia de una forma distinta de apoyo. La correspondencia que se sostiene en la mayoría de los engagements B2B SaaS:
- Discovery es un taller o un proyecto de scope muy acotado. Necesita atención senior, una perspectiva externa y un entregable que el equipo interno apruebe. No necesita un retainer de larga duración.
- Design es un proyecto. El entregable es un documento de esquema y workflows, el presupuesto es fijo y el plazo es de dos a cuatro semanas. Trátelo como tal.
- Build es un proyecto o un engagement integrado, según cuánto del trabajo de configuración pueda absorber el equipo interno. Si ya tiene un administrador de HubSpot, el formato de proyecto funciona. Si no, incorpore a alguien durante todo el período.
- Launch es un proyecto con una cola de hypercare. Defina el scope del cutover, la capacitación y los primeros diez días como un solo bloque. No dependa de la buena voluntad del equipo de construcción para cubrir esa cola.
- Optimize es donde el retainer o el apoyo fractional demuestra su valor. Cadencia mensual, horas acotadas y un backlog definido. Un error es contratar un retainer antes de terminar Discovery; el otro es dejarlo caducar al día siguiente de Launch.
- Transversal: si el equipo interno aún no cuenta con una función senior de RevOps, un rol fractional integrado a lo largo de Discovery, Design y Optimize suele ser el formato adecuado. Build sigue siendo un proyecto.
- Verificación por etapa: en seed y pre-Serie A, el formato de proyecto casi siempre es el correcto, ya que el equipo interno aún no está listo para absorber un retainer. A partir de la Serie B, el modelo de retainer o fractional suele recuperar la inversión en dos trimestres, porque Optimize deja de ser el trabajo secundario de alguien.
Dónde interviene Checkpoint
La metodología de cinco fases es la columna vertebral de cada engagement de HubSpot y CRM que ejecutamos en Checkpoint. Las implementaciones greenfield recorren las fases en orden. Las migraciones brownfield comienzan Discovery con la auditoría. Los rediseños alargan Design y acortan Build. Las fases se mantienen; cambian las proporciones. Si usted está definiendo ahora el scope de una implementación y el cronograma no nombra las cinco, hable con nosotros antes del kickoff. Realizamos este trabajo como implementación de HubSpot, como parte de la estrategia de GTM y como apoyo de RevOps integrado en todo el stack.
Fuentes
- Sinha, Shastri, Lorimer. «Why Your Digital Investments Aren't Creating Value.» Harvard Business Review, 16 de febrero de 2026. hbr.org
- Lemkin, Jason. «Which CRM Should You Use in 2026/2027? Follow the Agents.» SaaStr, 6 de abril de 2026. saastr.com