La mayoría de las implementaciones de HubSpot no fracasan por la tecnología. Fracasan en la tercera semana, cuando seis stakeholders discrepan sobre si una propiedad debe vivir en el contacto o en la empresa, y nadie en la sala tiene la autoridad para decidir. La construcción se queda en cola. El mismo desacuerdo vuelve en el siguiente sprint reformulado como otra pregunta. Dos semanas de velocidad desaparecen en un hilo de Slack. Ese es el resultado habitual cuando un proyecto con múltiples stakeholders arranca sin una rúbrica de responsabilidades escrita antes del kickoff.
Por qué importa ahora
Los derechos de decisión son el artefacto que sostiene cualquier proyecto transversal, y las implementaciones de HubSpot son transversales por construcción: involucran a marketing, ventas, éxito del cliente, finanzas y datos. El diagnóstico de HBR sobre por qué se estancan las organizaciones de ventas complejas (Adamson, Dixon, Toman, 2012) fue que los compradores se habían convertido en un sistema multi-stakeholder coordinado antes que los vendedores, y que las organizaciones que se adaptaron fueron las que tenían derechos de decisión explícitos y un playbook compartido. Una instancia moderna de HubSpot es el problema inverso trasladado al software. La misma brecha de gobernanza que paraliza una decisión estratégica paralizará una decisión sobre el nombre de una propiedad en la tercera semana.
Por qué «el equipo es responsable» es puro teatro
La forma más común de fallo de responsabilidad es la versión cortés: el deck de kickoff nombra al equipo de implementación, al comité directivo y al grupo de trabajo, y los trata como responsables. No lo son. Un equipo no es dueño de una decisión; un equipo es un foro donde las decisiones salen a la superficie. Cuando el desacuerdo sobre el nombre de la propiedad llega al grupo de trabajo, el grupo debate y se levanta la sesión. La decisión sigue teniendo que tomarla una sola persona, y si esa persona no se ha designado de antemano, se aplaza a la siguiente reunión, y a la siguiente.
La solución no es una gobernanza más pesada. Es nombrar por escrito a la única persona responsable, antes de que surja el desacuerdo. Si se hace en el kickoff, lleva treinta minutos. Si se hace bajo presión en la tercera semana, lleva una semana.
Los cinco dominios
Una implementación de HubSpot que funciona tiene cinco superficies de dominio, y cada una necesita un responsable designado que pueda decidir unilateralmente dentro de su dominio. Los límites siguen las costuras naturales del sistema, no el organigrama.
Marketing operations
Formularios, landing pages, lógica de lifecycle stage, arquitectura de listas, automatización de marketing y los campos que determinan el enrutamiento. El responsable suele ser un líder de marketing operations. Decide qué es obligatorio al enviar un formulario, qué dispara un cambio de lifecycle y cómo se segmentan las listas.
CRM y pipeline
Etapas de deal, propiedades de deal, esquemas de contacto y empresa, etiquetas de asociación y la superficie de workflow de ventas. El responsable suele ser un responsable de sales operations o un líder de RevOps con ventas como stakeholder principal. Decide las definiciones de etapa, los campos obligatorios y las reglas del pipeline.
Datos externos e integraciones
Proveedores de enrichment, la conexión con el data warehouse, el ETL de entrada y salida del CRM, la superficie de agentes de IA y cualquier sincronización de objetos de terceros. El responsable suele ser un ingeniero senior de RevOps o de analítica. Decide qué entra, qué sale y cuál es el sistema de referencia para cada atributo.
Servicio y posventa
Tickets, pipelines de servicio, propiedades de salud del cliente, workflows de renovación y el handoff desde ventas. El responsable suele ser un líder de operaciones de éxito del cliente. Decide los esquemas de tickets, las etapas del pipeline de servicio y la superficie de automatización de posventa.
Reporting
Dashboards, informes personalizados, las definiciones de métricas que aparecen en el deck para el board y las reglas de cómo se reconoce el ingreso dentro del CRM. El responsable suele ser un líder de RevOps o un socio de finanzas. Decide qué cuenta como pipeline, qué cuenta como bookings y cómo se calculan las cifras.
El responsable principal: una persona, no un comité
Por encima de los cinco responsables de dominio hay un responsable principal de la implementación. Es la persona que desbloquea. No la que decide cada nombre de propiedad (eso es trabajo del responsable de dominio), sino la que desempata cuando los dominios entran en conflicto, la que escala al sponsor ejecutivo cuando cambia el scope y la que sostiene la cadencia semanal. A menudo es el responsable de RevOps, a veces un operador fractional o integrado que se incorpora para el proyecto, y en ocasiones un jefe de gabinete. Rara vez es el CEO, y nunca es un comité.
El responsable principal tiene dos facultades innegociables. Puede anular a un responsable de dominio cuando una decisión bloquea a otro dominio. Puede pausar un frente de trabajo cuando falta una dependencia. Si esas dos facultades no figuran de forma explícita en el documento de kickoff, el rol es decorativo.
La lista de aprobadores: corta, con nombres y con fechas
Los aprobadores no son responsables. Son el pequeño grupo de personas que autorizan los cambios que cruzan los límites entre dominios: un nuevo pipeline que afecta al forecast, una propiedad personalizada sobre la que finanzas va a informar, una integración que toca datos financieros. La lista debe ser corta, de tres a cinco personas de toda la organización, y cada una debe tener un plazo de respuesta definido. Una regla práctica habitual: cuarenta y ocho horas; la falta de respuesta una vez vencido el plazo cuenta como aprobación. Sin plazo de respuesta, la lista de aprobadores se convierte en una cola, y el proyecto se queda esperando en ella.
Sin plazo de respuesta, una implementación acumula desacuerdos sin resolver en lugar de decisiones resueltas. La rúbrica es la póliza de seguro más barata que puede contratar antes del kickoff.
Qué se escala y qué se queda con el responsable de dominio
La regla de escalamiento que aplicamos en todas las implementaciones es simple: todo lo que queda por completo dentro de un dominio lo decide el responsable de ese dominio; todo lo que cruza dos dominios pasa al responsable principal; todo lo que cambia el scope o el presupuesto va al sponsor ejecutivo. La mayoría de las decisiones caen en el primer grupo, y es a propósito. La rúbrica existe para que los responsables de dominio puedan avanzar. La trampa que hay que evitar es tratar la coordinación entre dominios como excusa para escalar. Si marketing y ventas necesitan alinear las definiciones de lifecycle, es una decisión del responsable principal, no del sponsor ejecutivo.
Un patrón visto en campo
Un equipo de SaaS B2B en serie B, con sede en DACH, arrancó el año pasado una implementación de HubSpot con siete stakeholders internos involucrados y sin responsabilidades designadas. En la tercera semana, el proyecto tenía tres desacuerdos abiertos: dónde ubicar una propiedad (contacto o empresa), si la definición de lead calificado por marketing debía cambiar en la nueva instancia y si el campo de bookings pertenecía a finanzas o a RevOps. Ninguna era una cuestión técnica. Las tres estaban atascadas por la misma causa de fondo: ningún responsable único designado en ningún dominio. Pausamos la construcción dos días, hicimos el ejercicio de la rúbrica, nombramos a un responsable por dominio, designamos al responsable de RevOps como responsable principal y entregamos una lista de aprobadores de una página con plazos de respuesta. Los tres desacuerdos se resolvieron en una semana. El proyecto salió en producción en la fecha objetivo original. La rúbrica fue lo que desbloqueó el proyecto; el resto de la construcción ya estaba bien dimensionado.
Resolución: el playbook de la rúbrica
Para cualquier implementación de HubSpot que esté a punto de empezar, o que ya esté estancada en la tercera semana:
- Nombre a un responsable principal. Una sola persona, escrita en el documento de kickoff, con autoridad explícita para anular a los responsables de dominio y pausar frentes de trabajo. No un comité, no un cargo: un nombre.
- Nombre a un responsable por dominio. Marketing operations, CRM y pipeline, datos externos e integraciones, servicio, reporting. Un nombre por dominio, ajustado a la etapa de la empresa. En una serie A, la misma persona puede llevar dos dominios; en serie B y posteriores, sepárelos.
- Redacte la lista de aprobadores con plazos de respuesta. De tres a cinco nombres entre finanzas, la dirección comercial y el sponsor ejecutivo. Plazo de respuesta por defecto de cuarenta y ocho horas. La falta de respuesta vencido el plazo cuenta como aprobación.
- Escriba la regla de escalamiento en una página. Las decisiones dentro de un dominio corresponden al responsable de dominio. Las decisiones entre dominios van al responsable principal. Los cambios de scope o presupuesto van al sponsor ejecutivo. Distribúyala en el kickoff.
- Fije una cadencia semanal de revisión de la propia rúbrica. La rúbrica es un artefacto vivo. Revísela cada semana durante el primer mes y cada dos semanas después. Si a un responsable de dominio se lo anula de forma constante, la rúbrica está mal: corríjala, no la esquive.
- Documente las decisiones en un único registro. Una hoja de cálculo, una fila por decisión, con el responsable nombrado y la fecha. El registro es la prueba de que la rúbrica cumple su función, y es el artefacto que usted entregará al siguiente equipo de implementación si alguna vez vuelve a migrar.
Si la rúbrica está en marcha desde el kickoff, la implementación avanza a buen ritmo. Si se añade en la tercera semana, usted recupera el proyecto. Si nunca se añade, la construcción acabará saliendo, pero cada desacuerdo en el camino será una reunión, y cada reunión, una semana.
Dónde entra Checkpoint
La rúbrica es el primer artefacto que dejamos por escrito en cada implementación de HubSpot que ejecutamos. También es lo primero que ponemos sobre la mesa cuando un proyecto de RevOps estancado pregunta por qué una construcción que parecía bien dimensionada lleva dos meses de retraso: la respuesta casi siempre es la responsabilidad, no el scope. Si además el proyecto es una migración de CRM, la rúbrica es imprescindible. Hable con nosotros antes del kickoff, no en la tercera semana.