CRM
Artículos sobre CRM
Auditoría de HubSpot: cómo recuperar el control de un portal desordenado
Un portal de HubSpot con años de uso acumula workflows sin dueño, propiedades duplicadas e informes en los que nadie confía. Una auditoría de HubSpot mide ese deterioro en cinco dimensiones: (dato, automatizaciones, medición, adopción y seguridad) y lo convierte en un plan de saneamiento priorizado. En la mayoría de los casos, el portal se recupera sin empezar de cero. Esta guía explica cómo detectar la pérdida de control, cómo se audita con método y cómo decidir entre sanear, re-onboarding o reconstrucción. La escena se repite en empresas grandes: HubSpot lleva años en producción, ha pasado por varios equipos y quizá una migración y hoy nadie sabe explicar para qué son muchas de las automatizaciones. La plataforma funciona: los emails salen, los deals avanzan, pero la confianza se ha perdido. Cada informe se discute. Cada cambio da miedo. No es un problema de herramienta. Es un problema de gobierno: años de decisiones acumuladas sin un criterio común. Y tiene solución. Señales de que el portal está fuera de control La pérdida de control no llega de golpe; se acumula. Estas son las señales que más se repiten en portales enterprise con años de recorrido: Los informes no cuadran. Marketing y ventas presentan cifras distintas del mismo mes, y la reunión se va en discutir el dato en lugar de la decisión. Nadie conoce el inventario de automatizaciones. Hay decenas o cientos de workflows activos y solo una parte tiene dueño identificable. Desactivar cualquiera da vértigo. Propiedades duplicadas y sin criterio. Tres campos distintos para el mismo dato, formularios que escriben donde no deben, listas que ya no segmentan nada. El equipo comercial ha vuelto a las hojas de cálculo. El CRM existe, pero la operación real vive fuera. La adopción es el primer termómetro del gobierno. Dependencia de una persona. El conocimiento del portal está en una cabeza, no en una documentación. Si esa persona falta, el portal queda huérfano. Las integraciones se conocen por sus fallos. Nadie tiene la lista de qué sistemas están conectados al portal ni de qué escribe cada uno; una integración solo aparece en la conversación cuando rompe algo. Cada conector olvidado es dato entrando sin gobierno. El onboarding quedó a medias. La implantación inicial cubrió lo urgente, nunca lo importante, y el equipo lleva años conviviendo con procesos provisionales [TODO→A3.1: onboarding incompleto]. El coste de estas señales no es cosmético. Según Forrester, el 65 % de los profesionales B2B cita la falta de alineación entre marketing y ventas como problema, y un 53 % sufre «handoffs rotos» entre equipos. Un portal sin gobierno fabrica ambas cosas a diario. Si la compañía reconoce varias de estas señales, lo más útil no suele ser añadir automatizaciones, sino pararse a diagnosticar [TODO→A1.1: señales de pérdida de control, versión ampliada]. Qué es una auditoría de HubSpot (y qué no es) Una auditoría de HubSpot es un diagnóstico sistemático del estado de un portal (datos, automatizaciones, medición, adopción y seguridad) que identifica la deuda técnica acumulada y la convierte en un plan de saneamiento priorizado por impacto y esfuerzo. No es una lista de fallos: es la base para decidir cómo recuperar el control del portal. Conviene delimitar qué incluye, porque el término se usa para cosas muy distintas: No es soporte. El soporte resuelve incidencias; la auditoría explica por qué se producen y qué las evitará. No es un informe de errores automático. Las herramientas de chequeo señalan síntomas genéricos. Un diagnóstico útil cruza el estado técnico con los procesos de negocio de la organización: qué campos importan, qué automatizaciones sostienen ingresos, qué informes usa la dirección. No es un re-onboarding encubierto. La auditoría es lectura y criterio; no cambia nada durante el proceso. Los cambios llegan después, con el plan aprobado. Las cinco dimensiones de un health-check Un health-check aporta más cuando no revisa «HubSpot en general», sino cinco dimensiones concretas con criterios objetivos en cada una. Son las cinco que usamos en Solid al auditar portales Enterprise. Se puntúan por separado, porque un portal puede estar sano en seguridad y crítico en dato, y el tratamiento de cada caso es distinto. Gobierno del dato La pregunta de fondo: ¿el dato es fiable? Se revisan duplicados de contactos y empresas, propiedades redundantes o sin dueño, convenciones de nomenclatura y la integridad de los campos que alimentan el reporting. También lo que no se ve a simple vista: propiedades creadas y nunca rellenadas, campos con formatos inconsistentes entre objetos, formularios que escriben en propiedades equivocadas y asociaciones entre contactos, empresas y deals que ya no reflejan la realidad comercial. Un portal puede tener miles de propiedades creadas y solo unas decenas gobernadas; la diferencia entre ambas cifras es deuda. Automatizaciones Inventario y salud de workflows: cuántos hay activos, cuáles tienen dueño y propósito documentado, cuáles se solapan o compiten entre sí, cuáles tocan datos críticos. El diagnóstico busca patrones concretos: workflows que se disparan unos a otros en cadenas que nadie ha dibujado, criterios de inscripción que se pisan, acciones que sobreescriben campos usados por el reporting y automatizaciones con errores acumulados que llevan meses sin revisarse. La métrica reveladora no es el número de workflows: es el porcentaje de ellos que alguien sabe explicar. Medición Si los dashboards no se usan para decidir, no están cumpliendo su función. Esta dimensión revisa qué informes consume la dirección, si la atribución es consistente, si el embudo está definido igual para marketing y ventas, y si los ciclos de vida del contacto reflejan el proceso real de la compañía. Dos comprobaciones rápidas suelen bastar para dimensionar el problema: pedir el mismo dato a dos equipos distintos y comparar respuestas, y preguntar quién abrió cada dashboard en el último mes. Cuando la medición falla, el origen suele estar aguas arriba, en las dos dimensiones anteriores. Adopción y procesos El mejor portal falla si el equipo no lo usa. Se revisa el uso real por rol: actividad comercial registrada, cobertura del pipeline, notas y tareas frente a operación fuera del CRM, la documentación de procesos y la dependencia de personas concretas. En nuestra experiencia, la adopción baja no siempre es un problema de formación; muchas veces es un síntoma de fricción de diseño. Si registrar una operación cuesta más que apuntarla en una hoja de cálculo, es comprensible que el equipo acabe eligiendo la hoja de cálculo. Seguridad y permisos Usuarios activos frente a usuarios dados de alta, roles y niveles de permiso, integraciones conectadas que nadie recuerda, claves de API huérfanas, exportaciones de datos sin control. En organizaciones con varias unidades de negocio se añade la revisión de particiones y visibilidad: quién ve qué, y si eso responde a una decisión o a la inercia. En Solid esta dimensión se revisa con el marco de la norma ISO/IEC 27001, la misma bajo la que operamos internamente. Cómo auditar un portal de HubSpot paso a paso En nuestra experiencia, la metodología pesa más que la herramienta. Estos cinco pasos son el esqueleto con el que trabajamos; el detalle de criterios varía según los hubs contratados y el negocio [TODO→A1.2: checklist y metodología de health-check]. Definir alcance y objetivos de negocio. Qué hubs, qué unidades de negocio, qué decisiones debe habilitar el diagnóstico. Este paso incluye entrevistas cortas con los dueños del proceso: marketing, ventas, operaciones, para saber qué duele y qué informes se usan de verdad. Sin una pregunta de negocio detrás, el informe corre el riesgo de quedarse en papel. Inventariar. Extraer el censo completo: workflows, propiedades por objeto, listas, formularios, integraciones, usuarios y permisos. El inventario convierte la sensación de caos en cifras contrastables, y suele ser la primera sorpresa del proyecto: la diferencia entre lo que el equipo cree tener y lo que el portal contiene. Diagnosticar por dimensión. Aplicar criterios objetivos a las cinco dimensiones del health-check y puntuar cada una. La puntuación no es un fin: es la forma de comparar dimensiones entre sí, defender prioridades ante dirección y medir el progreso cuando se repita el diagnóstico. Priorizar por impacto y esfuerzo. No todo lo roto merece arreglo inmediato. Se cruza el impacto en negocio de cada hallazgo con su esfuerzo de corrección, y se separan los quick wins de los proyectos de fondo. Empezar por mejoras visibles en semanas ayuda a sostener la confianza interna durante los proyectos de fondo. Convertir en plan de saneamiento. Un hallazgo sin plan se queda a medias. El entregable final ordena las acciones por fases, con responsable y criterio de cierre para cada una: qué se limpia, qué se consolida, qué se rediseña y qué se deja como está, con motivo explícito en los cuatro casos. Para ejecutarla hace falta acceso de administración al portal, idealmente con un usuario dedicado y temporal, y sin realizar cambios durante la fase de lectura [A CONFIRMAR: política de accesos exacta del equipo]. Deuda técnica en HubSpot: el coste de no actuar Cada workflow sin dueño, cada propiedad duplicada y cada integración huérfana es un pequeño préstamo contra el futuro del portal. Esa acumulación tiene nombre: "deuda técnica" y cobra intereses [TODO→A2.1: qué es la deuda técnica en HubSpot]: Decisiones a ciegas. Con el dato degradado, el reporting deja de ser una fuente de verdad y la dirección decide por intuición. Coste creciente de cada cambio. Sobre una base frágil, cualquier automatización nueva exige arqueología previa. Lo que debería costar horas cuesta semanas. Onboarding lento. Incorporar a una persona al equipo exige explicarle excepciones en lugar de procesos. Riesgo operativo y de cumplimiento. Accesos sin revisar e integraciones olvidadas son superficie de riesgo, no solo desorden. La buena noticia: la deuda técnica se paga con método, no con heroicidades. Limpiar workflows, consolidar propiedades y sanear datos es trabajo sistemático una vez que el diagnóstico ha dicho qué tocar y en qué orden [TODO→A2.2: cómo limpiar workflows, propiedades y datos]. Y hay un efecto secundario que pocas veces se anticipa: el propio proceso de saneamiento documenta el portal, y esa documentación es la vacuna contra el siguiente ciclo de desorden. ¿Sanear, re-onboarding o empezar de cero? Es la decisión que sigue a toda auditoría, y conviene tomarla con criterios explícitos: Criterio Saneamiento Re-onboarding Empezar de cero Cuándo aplica La base es válida; el desorden es acumulativo La implantación inicial nunca respondió al negocio El dato original es irrecuperable o el modelo es inservible Qué se conserva Histórico y todo lo que funciona El histórico del dato; se rediseñan procesos y automatizaciones Casi nada Riesgo operativo Bajo: cambios controlados sobre lo existente Medio: rediseño con la operación en marcha Alto: pérdida de histórico y de continuidad Señal típica «No nos fiamos de los informes» «El onboarding se quedó a medias» Casos límite, poco frecuentes Nuestra recomendación: empezar por la auditoría en los tres escenarios, porque es la que determina cuál aplica. En la mayoría de los portales enterprise que hemos analizado, el camino ha sido el saneamiento: la inversión hecha en HubSpot suele ser recuperable [TODO→A3.2: re-onboarding frente a empezar de cero]. Cuando el problema de origen es una implantación incompleta, el re-onboarding es la vía [TODO→A3.1]. Sobre Solid Algunos datos que dan contexto al criterio de esta guía: Única empresa en España con doble acreditación de HubSpot para implementaciones CRM Enterprise e integraciones avanzadas. Certificación ISO/IEC 27001:2022: la seguridad del dato es parte del diagnóstico, no un anexo. Impact Award de HubSpot en 2024 (Platform Migration Excellence) y 2025 (Technical Expertise). Casos que sostienen el criterio: 20.000 deals recuperados en una migración de un mes y un motor de reclamaciones que procesa hasta 60.000 deals diarios sobre una arquitectura de datos multi-business-unit. Ese contexto importa al auditar: los umbrales de lo aceptable en un portal de 2.000 contactos no sirven para uno con varias unidades de negocio, decenas de usuarios y requisitos de seguridad corporativos. Preguntas frecuentes ¿Cada cuánto conviene auditar un portal de HubSpot? Como norma, cada 24 meses, y siempre tras un hito que altere la estructura del portal: una migración, una fusión de unidades de negocio, un cambio de equipo o de agencia. Si los informes ya no se usan para decidir, no hace falta esperar al ciclo: esa señal ya justifica el diagnóstico. ¿Cuánto dura una auditoría de HubSpot? Depende del alcance: número de hubs, volumen de automatizaciones y unidades de negocio. En portales enterprise puede ser dos semanas; en portales pro se hace en pocos días. Un chequeo automático señala síntomas en horas; cruzarlos con los procesos del negocio es lo que lleva tiempo, y ahí está la diferencia de valor. ¿Se puede auditar sin frenar la operación? Sí. La auditoría es fase de lectura: inventario, análisis y criterio, sin modificar nada en producción. La operación diaria no se toca. Los cambios llegan después, con el plan de saneamiento aprobado y por fases controladas. ¿Auditoría o re-onboarding? La auditoría no compite con el re-onboarding: lo antecede. El diagnóstico determina si el portal necesita saneamiento, un re-onboarding que rediseñe lo que nunca se implantó bien, o —en casos límite— una reconstrucción. Decidir el tratamiento antes del diagnóstico suele salir caro. ¿Qué accesos hacen falta para auditar el portal? Un usuario con permisos de administración, idealmente dedicado a la auditoría y de duración limitada, con acceso a los hubs incluidos en el alcance. Ningún dato sale del portal sin acuerdo previo sobre su tratamiento; en Solid ese tratamiento sigue el marco de la ISO/IEC 27001. Recuperar el control es un proyecto Un portal desordenado rara vez se arregla con otra herramienta, y el tiempo no juega a favor. Lo que funciona, en nuestra experiencia, es una auditoría de HubSpot que ponga cifras al deterioro, un plan que ordene las decisiones y un equipo con criterio para ejecutarlo. Estamos preparando el Health-check de HubSpot, un autodiagnóstico del gobierno del portal con puntuación por dimensión y plan de acción. Si el portal muestra varias de las señales de esta guía, programad una conversación de diagnóstico con el equipo. Sin compromiso comercial: 30 minutos para valorar si el diagnóstico aporta en este caso [A CONFIRMAR: formato exacto de la conversación inicial]. Albert Rodríguez es Managing Director de Solid, agencia de CRM y marketing automation especializada en implantaciones HubSpot Enterprise. Solid es Diamond Solutions Partner, opera con certificación ISO/IEC 27001:2022 y es la única empresa en España con doble acreditación de HubSpot para implementaciones CRM Enterprise e integraciones avanzadas.
Onboarding de HubSpot incompleto: cómo detectar que se quedó a medias
Un onboarding de HubSpot incompleto es una implantación que cubrió lo urgente (poner la herramienta en marcha), pero dejó fuera lo importante: los procesos, la medición y el gobierno del dato. El portal funciona, pero nunca llegó a responder al negocio. Reconocerlo es el paso previo a decidir cómo completarlo. Esta guía forma parte del marco sobre cómo recuperar el control de un portal de HubSpot. Muchos portales enterprise arrastran el mismo origen: una puesta en marcha rápida, pensada para empezar a usar HubSpot cuanto antes, que se planteó como provisional y se quedó como definitiva. No es que algo se rompiera; es que nunca llegó a terminarse. Qué es un onboarding incompleto Un onboarding incompleto es una implantación que dejó operativa la plataforma sin llegar a adaptarla al proceso real de la organización. Se activaron los hubs y se cargaron los datos, pero los pipelines, las automatizaciones, la medición y la nomenclatura se dejaron «para una segunda fase» que no llegó. Es distinto de un portal desordenado por acumulación: aquí el problema no es lo que se ensució con los años, sino lo que nunca se hizo [TODO→A2.1: qué es la deuda técnica en HubSpot]. Señales de que el onboarding se quedó a medias Procesos provisionales que se volvieron permanentes. Aquella forma «temporal» de registrar los deals sigue vigente dos años después. Funcionalidades del tier sin activar. Se paga Enterprise pero se opera como Professional: lead scoring, atribución, particiones o custom objects que nunca se configuraron. Adopción baja desde el principio. El equipo nunca terminó de incorporar HubSpot a su día a día, porque la herramienta no se ajustó a cómo trabaja. Sin documentación ni gobierno. No hay convenciones de nomenclatura, ni dueños de los procesos, ni criterio común. Cada persona resolvió a su manera. La medición nunca cuadró. Los informes no se usan para decidir porque nunca se definió el embudo ni la atribución de forma consistente. Por qué pasa Rara vez es negligencia; suele ser una suma de circunstancias razonables. La implantación se hizo deprisa para no frenar la operación. El foco estuvo en lo urgente: enviar, registrar, migrar, y lo importante quedó para después. Hubo un cambio de equipo o de agencia a mitad de camino, y el conocimiento se fue con quien se marchó. O el alcance se dimensionó corto, y lo que se contrató como «puesta en marcha» se confundió con «implantación completa». Qué hacer Lo primero es distinguir el diagnóstico del tratamiento. Un onboarding incompleto y un portal desordenado por acumulación se parecen en los síntomas: informes que no cuadran y adopción baja, pero tienen causas distintas y soluciones distintas. Una auditoría del portal separa una cosa de la otra: si la base es sólida y solo falta terminar procesos, la vía es completar el onboarding; si además hay años de acumulación, se combina con saneamiento. Esa decisión, completar el onboarding, rehacerlo o, en casos límite, reconstruir, tiene sus propios criterios, que desarrollamos en la guía sobre re-onboarding o empezar de cero. Preguntas frecuentes ¿Cómo sé si el onboarding de HubSpot se completó bien? Por el encaje con el proceso, no por si la herramienta funciona. Si los pipelines reflejan el proceso comercial real, la medición se usa para decidir y el equipo adoptó HubSpot en su día a día, el onboarding cumplió. Si esas piezas siguen «pendientes», quedó a medias. ¿Un onboarding incompleto es lo mismo que un HubSpot desordenado? No. El onboarding incompleto es lo que nunca se hizo; el desorden es lo que se acumuló con el uso. Un portal puede sufrir ambos a la vez, y por eso conviene diagnosticar antes de decidir qué hacer. ¿Se puede completar un onboarding años después? Sí. Completar o rehacer el onboarding conserva el histórico del dato y rediseña los procesos y automatizaciones que faltaron. Es una vía habitual y menos disruptiva que empezar de cero. Del síntoma a la decisión Detectar que el onboarding quedó a medias es el primer paso; el segundo es medir el alcance de lo que falta y decidir cómo completarlo. Ese marco está en la guía sobre cómo recuperar el control de un portal de HubSpot. Estamos preparando el Health-check de HubSpot, un autodiagnóstico del gobierno del portal con puntuación por dimensión y plan de acción. Si la sospecha es que el onboarding se quedó a medias, programad una conversación de diagnóstico con el equipo. Enric Rodrigo es HubSpot Consultant en Solid, agencia de CRM y marketing automation especializada en implantaciones HubSpot Enterprise.
Cómo limpiar workflows, propiedades y datos en HubSpot sin romper nada
Limpiar un portal de HubSpot es trabajo de método: primero diagnosticar, luego actuar en un orden concreto (datos, propiedades y workflows) y siempre con la cautela de desactivar antes de borrar. Hecho así, el saneamiento reduce la deuda técnica sin frenar la operación. Esta guía es el procedimiento que sigue al concepto explicado en deuda técnica en HubSpot, dentro del marco de cómo recuperar el control de un portal. La tentación, ante un portal saturado, es empezar a borrar. Es también la forma más rápida de romper algo: un workflow que parecía muerto alimentaba un informe, una propiedad «duplicada» era la que leía una integración. Limpiar sin romper nada consiste, sobre todo, en el orden y en las cautelas. Antes de tocar nada Diagnosticar primero. La limpieza actúa sobre los hallazgos de una auditoría, no sobre corazonadas. Sin ese mapa, se corre el riesgo de retirar lo que funciona y conservar lo que sobra. Trabajar en sandbox cuando esté disponible. Probar los cambios de mayor alcance en un entorno de pruebas antes de llevarlos a producción evita sorpresas. Exportar antes de retirar. Una exportación de las propiedades y los registros afectados es la red de seguridad que permite revertir si algo se comportó de forma inesperada. Congelar la creación nueva. Durante el saneamiento conviene pausar la creación de propiedades y workflows nuevos, para no ampliar la deuda mientras se reduce. Limpiar workflows Inventariar y agrupar. Extraer la lista completa de workflows activos y agruparlos por función. El objetivo es entender el mapa antes de tocar ninguna pieza. Marcar los candidatos. Señalar los que no tienen dueño identificable, los que se solapan con otro y los que llevan meses con errores activos. Esa es la deuda que más pesa. Desactivar antes de borrar. En lugar de eliminar, desactivar y observar durante un periodo (dos o tres semanas suele bastar) para confirmar que nada dependía de ese workflow. Si nadie lo echa en falta, entonces se borra. Documentar y nombrar. Cada workflow que se conserva recibe un nombre que explica su función y una nota de propósito. Una nomenclatura clara y una organización en carpetas es lo que evita que el desorden vuelva. Los workflows de nurturing de ciclo largo, por su complejidad, merecen especial cuidado en este paso, como vemos al hablar de nurturing B2B en ciclos largos. Consolidar propiedades Las propiedades duplicadas o sin uso son la segunda fuente de deuda. El procedimiento evita la retirada en caliente: Detectar duplicadas y sin uso. Operations Hub facilita el análisis de propiedades sin datos; sin él, se aproxima con exportaciones y vistas. El objetivo es una lista de candidatas, no una purga inmediata. Elegir la superviviente. Entre varios campos para el mismo dato, se conserva el que más se usa en formularios, workflows y reporting, y se planifica la migración del resto hacia él. Migrar y luego retirar. Primero se traslada el dato a la propiedad superviviente y se actualizan formularios y automatizaciones; solo después se archiva la propiedad antigua. El gobierno de propiedades entre unidades de negocio tiene sus propias reglas, como explicamos al copiar propiedades entre empresas del portal. Sanear datos Con los workflows y las propiedades ordenados, el saneamiento del dato es más seguro: Deduplicar contactos y empresas con las herramientas del portal, revisando los criterios de coincidencia antes de fusionar. Asignar propietarios a los registros que no los tengan, porque sin owner no funcionan las asignaciones ni las notificaciones. Revisar la base legal de los contactos antes de cualquier campaña, para no arrastrar un riesgo de cumplimiento. Archivar lo residual. Las propiedades de una integración que ya no se usa —Salesforce migrado, por ejemplo— son deuda que conviene archivar una vez confirmado que el sistema de origen está inactivo. El orden importa El saneamiento va de lo más profundo a lo más visible: primero los datos, luego las propiedades, por último los workflows. Tiene lógica: los workflows dependen de las propiedades, y las propiedades describen los datos. Limpiar en orden inverso obliga a rehacer trabajo cada vez que una capa inferior cambia. Preguntas frecuentes ¿Se puede limpiar HubSpot sin frenar la operación? Sí, si se trabaja por fases y con cautela: sandbox para lo de mayor alcance, exportación previa y la regla de desactivar antes de borrar. Los cambios se llevan a producción de forma escalonada, no de una vez. ¿Conviene borrar los workflows que no se usan? No de inmediato. Es más seguro desactivarlos y observar dos o tres semanas. Si en ese periodo nadie los echa en falta y ningún informe se resiente, entonces se eliminan. ¿Cada cuánto hay que limpiar un portal de HubSpot? La limpieza profunda se hace tras una auditoría; el mantenimiento, de forma continua. Un portal con nomenclatura clara y propiedades con dueño acumula deuda mucho más despacio [TODO→A1.1: señales de un HubSpot descontrolado]. De la limpieza al gobierno Limpiar una vez ordena el portal; gobernarlo es lo que lo mantiene ordenado. Cada workflow y cada propiedad que nace con dueño y propósito es deuda que no se genera. Cómo llegar a ese estado es el marco que desarrollamos en cómo recuperar el control de un portal de HubSpot. Estamos preparando el Health-check de HubSpot, un autodiagnóstico del gobierno del portal con puntuación por dimensión y plan de acción. Si el portal necesita una limpieza y no está claro por dónde empezar, programad una conversación de diagnóstico con el equipo. Enric Rodrigo es HubSpot Consultant en Solid, agencia de CRM y marketing automation especializada en implantaciones HubSpot Enterprise.
Deuda técnica en HubSpot: qué es y cómo detectarla
La deuda técnica en HubSpot es la acumulación de configuraciones, automatizaciones y datos que dejaron de tener dueño o propósito, y que encarecen cada cambio futuro del portal. No rompe nada de golpe: degrada poco a poco la fiabilidad del dato y la capacidad de decidir. Detectarla pronto es lo que evita llegar a un portal en el que nadie se fía de los informes. Esta guía forma parte del marco que explicamos sobre cómo recuperar el control de un portal de HubSpot. Todo portal que lleva años en uso acumula decisiones. Un workflow que se creó para una campaña puntual y se quedó activo, una propiedad que se duplicó porque nadie encontró la original, una integración que se conectó y luego se olvidó. Por separado son inofensivas; sumadas, son deuda. Qué se acumula La deuda técnica de un portal se concentra en cuatro sitios. Workflows sin dueño. Automatizaciones activas que nadie sabe explicar, que se solapan entre sí o que llevan meses con errores sin revisar. Cuantos más hay, más difícil es cambiar cualquiera sin efectos colaterales. Propiedades duplicadas o sin uso. Varios campos para el mismo dato, propiedades creadas para una necesidad puntual y nunca retiradas, formularios que escriben donde no deben. Cuando las propiedades de integración superan el 30 % del total de propiedades personalizadas, el modelo de datos está condicionado por un sistema externo que conviene revisar. Datos degradados. Duplicados de contactos y empresas, registros sin propietario, contactos sin base legal, importaciones antiguas con errores heredados. El dato es la materia prima de todo lo demás; cuando se degrada, arrastra al reporting y a las automatizaciones. Integraciones huérfanas. Conectores que siguen escribiendo en el portal aunque el sistema de origen ya no se use, o claves de API que nadie recuerda haber creado. Cada uno es dato entrando sin gobierno. Por qué cuesta La deuda técnica se paga en forma de fricción, y esa fricción tiene consecuencias de negocio concretas. Decisiones sobre dato poco fiable. Cuando el reporting deja de ser una fuente de verdad, la dirección decide por intuición o pide que alguien «revise el número» antes de cada reunión. Coste creciente de cada cambio. Sobre una base frágil, cualquier automatización nueva exige entender antes qué había. Lo que debería costar horas cuesta semanas, y el equipo evita tocar el portal por miedo a romper algo. Onboarding lento del equipo. Incorporar a una persona nueva pasa por explicarle excepciones en lugar de procesos, porque el portal no se comporta como debería sino como acabó comportándose. Riesgo operativo y de cumplimiento. Accesos sin revisar, integraciones olvidadas y contactos sin base legal no son solo desorden: son superficie de riesgo, también ante el RGPD. Cómo detectarla pronto La deuda técnica avisa mucho antes de convertirse en un problema serio. Estas son las señales que suelen aparecer primero: Marketing y ventas presentan cifras distintas del mismo mes. Desactivar un workflow da vértigo porque nadie está seguro de qué depende de él. Aparecen tres campos distintos para el mismo dato en un formulario o un informe. El equipo comercial ha vuelto, en parte, a la hoja de cálculo. Una integración solo entra en la conversación cuando rompe algo. Ninguna de estas señales es grave por sí sola. Juntas indican que el portal ha empezado a acumular más rápido de lo que se ordena [TODO→A1.1: señales de un HubSpot descontrolado]. La forma de ponerles cifra es una auditoría del portal, que cuenta lo que a simple vista no se ve: cuántas propiedades sin uso, cuántos deals sin contacto, cuántos workflows sin dueño. Cómo se paga La buena noticia es que la deuda técnica se salda con método, no con heroicidades. Una vez que un diagnóstico ha dicho qué tocar y en qué orden, limpiar workflows, consolidar propiedades y sanear datos es trabajo sistemático [TODO→A2.2: cómo limpiar workflows, propiedades y datos]. Y tiene un efecto que pocas veces se anticipa: el propio proceso de saneamiento documenta el portal, y esa documentación es lo que evita que la deuda vuelva a crecer al mismo ritmo. El gobierno de propiedades entre unidades de negocio, por ejemplo, es una de las áreas donde una decisión ordenada ahorra deuda futura, como explicamos al copiar propiedades entre empresas del portal. Preguntas frecuentes ¿Qué es la deuda técnica en HubSpot? Es la acumulación de workflows, propiedades, datos e integraciones que perdieron dueño o propósito y que encarecen cada cambio futuro del portal. No provoca un fallo inmediato; degrada poco a poco la fiabilidad del dato y la capacidad de decidir sobre él. ¿Cómo sé si mi portal tiene deuda técnica? Por señales cotidianas: informes que no cuadran entre equipos, miedo a desactivar automatizaciones, campos duplicados para el mismo dato. Para ponerle cifra, una auditoría cuenta las propiedades sin uso, los deals sin contacto y los workflows sin dueño. ¿La deuda técnica obliga a reimplantar HubSpot? Casi nunca. En la mayoría de los casos se resuelve con un saneamiento sobre el portal existente. Reimplantar o rehacer el onboarding solo entra en juego cuando el problema no es la acumulación, sino un diseño que nunca encajó con el negocio. De la deuda al gobierno La deuda técnica no se elimina para siempre; se gestiona. Un portal gobernado acumula más despacio, porque cada workflow y cada propiedad nace con dueño y con propósito. Cómo llegar a ese estado es el marco que desarrollamos en la guía sobre cómo recuperar el control de un portal de HubSpot. Estamos preparando el Health-check de HubSpot, un autodiagnóstico del gobierno del portal con puntuación por dimensión y plan de acción. Si varias de las señales de esta guía suenan familiares, programad una conversación de diagnóstico con el equipo. Irene Sierra es HubSpot Consultant en Solid, agencia de CRM y marketing automation especializada en implantaciones HubSpot Enterprise.
Cómo auditar un portal de HubSpot: checklist por áreas
Auditar un portal de HubSpot consiste en revisar, área por área, si el dato, las automatizaciones, la medición, la adopción y la seguridad responden al negocio. Este checklist recorre las áreas que revisamos en una auditoría enterprise y los criterios que separan un hallazgo crítico de una mejora menor. Es el detalle operativo del marco que explicamos en la guía sobre cómo recuperar el control de un portal de HubSpot. Antes de abrir HubSpot conviene tener una lista de qué mirar. Sin ella, una auditoría se convierte en un paseo por menús que confirma lo que ya se intuía. Con ella, cada área se revisa con el mismo criterio y el resultado se puede comparar y priorizar. Antes de empezar: alcance y accesos Dos decisiones ordenan todo lo demás. La primera es el alcance: qué hubs y tiers entran (Marketing, Sales, Service, Content, Operations) y cuántas unidades de negocio hay. La segunda son los accesos: un usuario con permisos de administración, a ser posible dedicado a la auditoría y de duración limitada. Toda la revisión es de solo lectura. En esta fase no se modifica nada en producción; se inventaría, se analiza y se anota. Los cambios llegan después, con el plan aprobado [TODO→A1.1: señales de un HubSpot descontrolado]. El checklist por áreas Agrupamos las áreas bajo las cinco dimensiones del health-check, para que el resultado encaje con el diagnóstico general del portal. Gobierno del dato Modelo de datos. Propiedades duplicadas o creadas y nunca rellenadas, objetos personalizados y su uso real, normalización de nombres y formatos. Una señal útil: cuando las propiedades de integración superan el 30 % del total de propiedades personalizadas, el modelo está condicionado por un sistema externo y conviene investigar si sigue activo. Contactos y empresas. Duplicados, registros sin propietario y calidad de la base (rebotes, bajas). Los porcentajes ayudan a dimensionar: contactos sin owner por encima del 15 %, o empresas sin owner por encima del 30 %, bloquean asignaciones y workflows de gestión de cuentas. Base legal y GDPR. Contactos sin base legal registrada antes de cualquier campaña de email. Por encima del 10 %, es un riesgo que conviene resolver antes que optimizar nada. Lifecycle y Lead Status. Si ambos campos están alineados o funcionan por separado, y si hay saltos que no deberían existir de Subscriber a SQL sin pasar por Lead o MQL que suelen delatar una automatización mal planteada. Automatizaciones Inventario de workflows. Cuántos hay activos, cuáles tienen dueño y propósito documentado, y cuáles llevan meses con errores activos sin que nadie los revise. Solapamientos y nomenclatura. Workflows que compiten por el mismo dato, listas de exclusión en los envíos automáticos, y una nomenclatura y una organización en carpetas que permitan entender para qué sirve cada uno sin abrirlo. Medición Pipelines y deals. Etapas realmente necesarias frente a etapas heredadas, deals abiertos sin importe (por encima del 25 %, el forecast pierde fiabilidad), deals con fecha de cierre ya pasada y registro de motivos de pérdida. Reporting. Qué dashboards consume la dirección de verdad, y cuáles llevan más de un año sin que nadie los revise. Un informe que nadie abre no está cumpliendo su función. Adopción y procesos Uso real por Hub. Secuencias, tareas, plantillas y playbooks en Sales; formularios, listas y campañas en Marketing; pipeline de tickets y encuestas en Service. La pregunta no es si la funcionalidad existe, sino si el equipo la usa. Aprovechamiento de la licencia. Qué porcentaje de las funcionalidades del tier contratado está realmente en uso. Es habitual pagar Enterprise y operar como Professional; ese hueco suele ser la primera oportunidad de mejora sin coste adicional de licencia. Seguridad y permisos Configuración y accesos. Usuarios inactivos que conservan licencia, roles y niveles de permiso, uso de sandbox para probar antes de producción, y configuración de consentimiento y tracking. Integraciones. Qué sistemas están conectados y si funcionan sin duplicar datos. El caso que más conviene mirar: propiedades de Salesforce en el portal. Si Salesforce sigue activo en paralelo, hay riesgo de datos duplicados y procesos confusos; si fue migrado, esas propiedades suelen ser residuales y toca archivarlas [TODO→A2.2: limpiar workflows, propiedades y datos]. Cómo se prioriza un hallazgo Un checklist produce hallazgos; lo que los hace accionables es priorizarlos con un criterio común. Nosotros usamos tres niveles. Un hallazgo de prioridad alta es el que bloquea el inicio de un proyecto o genera un riesgo legal u operativo crítico: deals sin contacto asociado, Lifecycle y Lead Status desalineados, propietarios faltantes, GDPR sin cubrir o una integración activa sin sistema de referencia definido. La prioridad media agrupa lo que genera deuda técnica o dificulta el reporting (propiedades residuales, duplicados en el pipeline, etapas en desuso, ausencia de lead scoring). La prioridad baja son mejoras de nomenclatura y configuración menor. Con esos niveles, cada área recibe un estado: crítico si tiene al menos un hallazgo de prioridad alta, mejorable si solo tiene medios, y bueno si únicamente quedan mejoras menores. Así, un vistazo al informe basta para saber por dónde empezar. De la checklist al plan de acción El checklist es el diagnóstico; el entregable útil es el plan. Cada hallazgo se cruza en una matriz de impacto y esfuerzo, y se ordena en fases: qué se limpia, qué se consolida, qué se rediseña y qué se deja como está, con un motivo explícito en cada caso. Empezar por las mejoras visibles en semanas ayuda a sostener la confianza interna mientras avanzan los proyectos de fondo [TODO→A2.2]. Hacerlo con checklist o con extracción de datos Buena parte de este checklist se recorre a mano, revisando la configuración pantalla por pantalla. Hay una excepción: los censos completos. Contar propiedades sin uso, deals sin contacto o contactos sin base legal a mano es inviable en un portal grande. Ahí ayuda extraer los datos por la API con Operations Hub, o con un script de solo lectura para obtener las cifras exactas sobre las que aplicar los umbrales anteriores. La revisión manual aporta el criterio; la extracción aporta la escala. Preguntas frecuentes ¿Qué se necesita para auditar un portal de HubSpot? Un usuario con permisos de administración sobre los hubs incluidos en el alcance, idealmente dedicado y temporal, y un checklist por áreas como el de esta guía. Para los censos completos (propiedades, deals, contactos) ayuda extraer los datos por la API en modo solo lectura. ¿Cuántas áreas cubre una auditoría completa? En una auditoría enterprise revisamos hasta once áreas: configuración, modelo de datos, contactos, deals, workflows, lifecycle, integraciones, y las herramientas de Marketing, Sales y Service, más reporting. En esta guía se agrupan bajo las cinco dimensiones del health-check para leer el resultado de un vistazo. ¿Se puede auditar HubSpot sin herramientas de pago? El checklist manual no las necesita. Para los conteos a escala, Operations Hub facilita el análisis de propiedades sin uso; sin él, esos censos se aproximan con exportaciones y búsquedas guardadas, con menos precisión. Del checklist al criterio Una checklist ordena la revisión, pero el valor de una auditoría está en el criterio con el que se interpreta cada hallazgo: qué umbral importa en un portal de varias unidades de negocio, qué integración residual conviene archivar, qué se prioriza primero. Ese es el marco que desarrollamos en la guía sobre cómo recuperar el control de un portal de HubSpot. Estamos preparando el Health-check de HubSpot, un autodiagnóstico del gobierno del portal con puntuación por dimensión y plan de acción. Mientras tanto, si al recorrer este checklist aparecen varios hallazgos de prioridad alta, programad una conversación de diagnóstico con el equipo. Irene Sierra es HubSpot Consultant en Solid, agencia de CRM y marketing automation especializada en implantaciones HubSpot Enterprise. Trabaja en la auditoría e implantación de portales HubSpot para empresas B2B con operaciones complejas.
Señales de que el portal de HubSpot está fuera de control
Un portal de HubSpot rara vez falla de golpe: primero da señales. Informes que no cuadran, workflows que nadie se atreve a tocar, campos duplicados, un equipo comercial que vuelve a la hoja de cálculo. Reconocerlas a tiempo es lo que evita llegar a un portal ingobernable. Esta guía agrupa las señales por dimensión y añade una comprobación rápida para cada una; es la puerta de entrada al marco de cómo recuperar el control de un portal de HubSpot. La pérdida de control es gradual, y por eso cuesta detectarla desde dentro: cada excepción parece razonable en su momento. Vistas juntas, sin embargo, las señales dibujan un patrón reconocible. Señales por dimensión Gobierno del dato Aparecen varios campos para el mismo dato. Cómo comprobarlo: al montar un formulario o un informe, buscar el campo y contar cuántas variantes ofrece el buscador. Si hay tres «teléfonos» o dos «sectores», el modelo de datos ha empezado a duplicarse. Nadie se fía del todo de la base. Cómo comprobarlo: preguntar quién revisa manualmente los datos antes de una campaña. Si esa revisión existe y es habitual, el dato no se considera fiable. Automatizaciones Desactivar un workflow da vértigo. Cómo comprobarlo: elegir un workflow al azar y preguntar quién es su dueño y qué pasa si se apaga. Si no hay respuesta clara, ese workflow es deuda [TODO→A2.1: qué es la deuda técnica en HubSpot]. Hay más automatizaciones de las que nadie recuerda. Cómo comprobarlo: comparar el número de workflows activos con los que el equipo puede explicar de memoria. La distancia entre ambas cifras es el problema. Medición Marketing y ventas presentan cifras distintas del mismo mes. Cómo comprobarlo: pedir el mismo dato a los dos equipos y comparar. Si no coinciden, el embudo no está definido igual en los dos lados. Los dashboards no se abren. Cómo comprobarlo: revisar la fecha de último acceso de los informes de dirección. Un panel que nadie consulta desde hace meses no está cumpliendo su función. Adopción y procesos El equipo comercial ha vuelto, en parte, a la hoja de cálculo. Cómo comprobarlo: preguntar dónde se apunta de verdad la actividad del día. Si la respuesta no es HubSpot, la adopción está cayendo, casi siempre por fricción de diseño. Seguridad y permisos Hay usuarios con licencia que no entran. Cómo comprobarlo: revisar los usuarios activos frente a los dados de alta, y las integraciones conectadas que nadie recuerda haber configurado. Cada acceso o conector olvidado es superficie de riesgo. ¿Cuántas señales son demasiadas? Una señal aislada no significa gran cosa; puede ser un descuido puntual. El patrón preocupa cuando aparecen varias a la vez, o cuando una se ha vuelto crónica; el equipo ya asume que «los informes no cuadran» como parte del paisaje. Cuando se reconocen varias, el siguiente paso no es empezar a arreglar a ciegas, sino poner cifras al desorden con una auditoría del portal, que convierte estas señales cualitativas en hallazgos medibles y priorizables. Preguntas frecuentes ¿Cómo saber si un HubSpot está mal configurado? Por señales cotidianas más que por un fallo evidente: campos duplicados, workflows sin dueño, informes que no cuadran entre equipos y adopción que cae. Una auditoría confirma la sospecha con cifras: propiedades sin uso, deals sin contacto, usuarios inactivos. ¿Un portal desordenado significa que hay que reimplantar HubSpot? Casi nunca. La mayoría de los portales desordenados se recuperan con un saneamiento sobre lo existente. Reimplantar solo entra en juego cuando el diseño de origen nunca encajó con el negocio [TODO→A3.1: onboarding incompleto]. ¿Estas señales aplican a cualquier tamaño de portal? El patrón es el mismo, pero los umbrales cambian. En un portal con varias unidades de negocio y decenas de usuarios, lo aceptable no es lo mismo que en uno pequeño; por eso la interpretación de cada señal necesita contexto. De la señal al diagnóstico Reconocer las señales es el primer paso; el segundo es medirlas. Ese es el trabajo de una auditoría, que ordena estos síntomas por impacto y los convierte en un plan. El marco completo está en cómo recuperar el control de un portal de HubSpot. Estamos preparando el Health-check de HubSpot, un autodiagnóstico del gobierno del portal con puntuación por dimensión y plan de acción. Si varias de estas señales resultan familiares, programad una conversación de diagnóstico con el equipo. Irene Sierra es HubSpot Consultant en Solid, agencia de CRM y marketing automation especializada en implantaciones HubSpot Enterprise.
Re-onboarding de HubSpot o empezar de cero: cómo decidir
Cuando un portal de HubSpot no responde al negocio, hay tres caminos: sanear lo acumulado, rehacer el onboarding que quedó a medias o reconstruir desde cero. La decisión depende del estado del dato, del alcance del daño y de cuánto histórico conviene conservar. Esta guía ofrece los criterios para elegir, dentro del marco que explicamos en la guía sobre cómo recuperar el control de un portal de HubSpot. La pregunta con la que suele llegar el equipo es: «¿esto se arregla o lo tiramos?». Es la pregunta correcta, pero incompleta: entre arreglar y tirar hay una opción intermedia: el re-onboarding, que a menudo es la que encaja. Ordenar las tres vías ayuda a decidir con criterio en lugar de por agotamiento. Las tres vías, en corto Saneamiento. El portal funciona y la base es válida; el problema es la acumulación (workflows sin dueño, propiedades duplicadas, datos degradados Se limpia y se gobierna lo que ya existe, sin rehacer la implantación [TODO→A2.1: qué es la deuda técnica en HubSpot]. Re-onboarding. La implantación inicial nunca respondió al negocio: se configuró deprisa, cubrió lo urgente y dejó fuera lo importante. Se conserva el histórico del dato, pero se rediseñan procesos, pipelines y automatizaciones sobre una base pensada esta vez para la operación real [TODO→A3.1: onboarding incompleto]. Empezar de cero. El dato original es irrecuperable o el modelo es inservible. Se reconstruye el portal. Es la vía menos frecuente, porque implica renunciar al histórico y asumir un periodo de discontinuidad. Cómo elegir: los criterios La elección se apoya en unos pocos factores, más que en una impresión general. Criterio Saneamiento Re-onboarding Empezar de cero Estado del dato Recuperable, con limpieza Recuperable; el problema son los procesos Irrecuperable o sin trazabilidad Origen del problema Acumulación sin gobierno Implantación incompleta o mal enfocada Modelo de datos inservible Qué se conserva Histórico y todo lo que funciona El histórico del dato; se rediseña el resto Casi nada Riesgo operativo Bajo: cambios controlados Medio: rediseño con la operación en marcha Alto: pérdida de histórico y continuidad Esfuerzo relativo Menor Medio Mayor Señal típica «No nos fiamos de los informes» «El onboarding se quedó a medias» «Nada de esto refleja cómo trabajamos» Ningún criterio decide por sí solo. Un portal con dato recuperable pero procesos que nunca encajaron apunta a re-onboarding, aunque la limpieza sea tentadora por barata. Un portal con dato irrecuperable no mejora por mucho que se rediseñen los procesos encima. Qué se conserva y qué se pierde El factor que más pesa en la decisión suele ser el histórico. En el saneamiento y en el re-onboarding se conserva: los contactos, las empresas, los deals cerrados y la actividad quedan donde están, y con ellos la capacidad de comparar con años anteriores. Empezar de cero renuncia a eso, o lo relega a un archivo de solo consulta. La continuidad operativa es el segundo factor. El saneamiento apenas se nota en el día a día. El re-onboarding convive con la operación y exige planificar el corte de procesos por fases. Una reconstrucción implica un periodo en el que el portal antiguo y el nuevo coexisten, con el coste de coordinación que eso añade. El papel de la auditoría en la decisión Esta decisión llega después de un diagnóstico, no antes. Una auditoría del portal mide el estado del dato, el alcance del daño en cada área y el aprovechamiento real de la licencia; con esos datos, la vía adecuada suele volverse evidente. Elegir el tratamiento antes de auditar, empezar de cero «porque esto no hay quien lo arregle», o sanear «porque cambiar da miedo», es lo que suele salir caro. El checklist de esa revisión está detallado en la guía sobre cómo auditar un portal de HubSpot. En la mayoría de los portales enterprise que hemos analizado, la vía ha sido el saneamiento o el re-onboarding; la reconstrucción total queda para casos límite. La inversión hecha en HubSpot suele ser recuperable. Cuando además se cambia de CRM A veces la decisión no es solo qué hacer con HubSpot, sino si migrar desde otro CRM en el proceso. Si el punto de partida es Salesforce u otra plataforma, el re-onboarding se cruza con una migración, y el criterio pasa a ser mover el dato sin pérdida ni parón operativo. Ese caso tiene su propio método, descrito en la guía de migración de Salesforce a HubSpot. Preguntas frecuentes ¿Cuándo no merece la pena sanear un portal de HubSpot? Cuando el problema no es la suciedad acumulada, sino el diseño: pipelines que no reflejan el proceso comercial, un modelo de datos que nunca encajó o un histórico sin trazabilidad. Limpiar sobre una base mal planteada mejora poco; ahí encaja el re-onboarding o, en casos límite, la reconstrucción. ¿Se pierde el histórico en un re-onboarding? No. El re-onboarding conserva el histórico del dato: contactos, empresas, deals, actividad y rediseña los procesos, las automatizaciones y los pipelines por encima. La pérdida de histórico solo entra en juego al empezar de cero. ¿Cuánto dura un re-onboarding de HubSpot? Depende del alcance y del número de hubs y unidades de negocio [A CONFIRMAR: rango típico del servicio]. Es más largo que un saneamiento y más corto que una reconstrucción, y se planifica por fases para no frenar la operación. De la decisión al plan Elegir la vía es el principio; lo que la hace ejecutable es el plan de saneamiento o de rediseño que sale de la auditoría, ordenado por impacto y esfuerzo. Ese marco lo desarrollamos en la guía sobre cómo recuperar el control de un portal de HubSpot. Estamos preparando el Health-check de HubSpot, un autodiagnóstico del gobierno del portal con puntuación por dimensión y plan de acción. Si la duda es qué hacer con un portal que no acaba de responder, programad una conversación de diagnóstico con el equipo. Albert Rodríguez es Managing Director de Solid, agencia de CRM y marketing automation especializada en implantaciones HubSpot Enterprise. Solid es Diamond Solutions Partner y opera con certificación ISO/IEC 27001:2022.
Arquitectura de datos para múltiples business units en HubSpot
Cuando tu empresa opera con múltiples líneas de negocio, divisiones geográficas o marcas independientes, necesitas una arquitectura de datos que mantenga la separación operativa sin sacrificar la visión consolidada. Guía técnica para diseñar e implementar un modelo multi-BU en HubSpot Enterprise. El desafío de múltiples business units Una business unit (BU) es una división semi-autónoma dentro de una organización con sus propios productos, clientes, equipos y objetivos. Ejemplos típicos: Por producto/servicio: División Software vs División Consultoría. Por geografía: España vs Francia vs LATAM. Por marca: marca Premium vs marca Low-cost. Por segmento: B2B vs B2C. Por canal: venta directa vs Partners. El problema Cada BU necesita: Su propio pipeline de ventas con etapas específicas. Equipos independientes que solo vean sus datos. Reporting separado por BU. Procesos de nurturing diferenciados. Workflows específicos por línea de negocio. Pero la dirección necesita: Visión consolidada del pipeline total. Comparativas entre BUs. Clientes que compran en múltiples BUs identificados. Reportes C-level agregados. Error común Muchas empresas crean portales separados de HubSpot por BU. Esto fragmenta los datos, imposibilita el cross-sell, duplica costes de licencias y genera silos de información. Solo tiene sentido si las BUs son realmente empresas independientes. Tres enfoques para arquitectura multi-BU Opción 1: portales separados (NO recomendado) Cómo funciona: un portal de HubSpot independiente para cada BU. Ventajas: Separación total garantizada. Cada BU puede tener su propio admin y configuración. Sin riesgo de ver datos de otras BUs. Desventajas: Imposible consolidar datos a nivel grupo. Clientes duplicados si compran en múltiples BUs. Costes multiplicados (licencias × número de portales). Integraciones por duplicado. No hay visión 360º del cliente. Cuándo usarlo: solo si las BUs son legalmente entidades separadas con cero overlap de clientes. Opción 2: un portal con objetos custom por BU (complejo) Cómo funciona: crear objetos custom como "Opportunity BU A", "Opportunity BU B", etc. Ventajas: Separación estructural de pipelines. Cada BU tiene su propio objeto. Desventajas: Extremadamente complejo de mantener. Reporting consolidado muy difícil. Workflows duplicados por cada objeto. Experiencia de usuario confusa. Cuándo usarlo: casi nunca. Solo si necesitas estructuras de datos radicalmente diferentes por BU. Opción 3: un portal con segmentación por propiedades (RECOMENDADO) Cómo funciona: un solo portal con propiedades que identifican la BU y múltiples pipelines. Ventajas: Base de datos unificada. Visión 360º del cliente. Reporting consolidado y por BU. Un solo coste de licencias. Integraciones centralizadas. Cross-sell visible. Desventajas: Requiere configuración cuidadosa de permisos. Necesitas disciplina en gobernanza de datos. Cuándo usarlo: en el 90% de los casos multi-BU. Modelo de datos recomendado Arquitectura general El modelo se basa en: Una base de datos unificada de contactos y empresas. Propiedades que identifican a qué BU pertenece cada registro. Múltiples pipelines (uno por BU) en el objeto Deals. Teams y permisos para controlar el acceso. Vistas guardadas pre-filtradas por BU. Ejemplo: empresa con 3 BUs Acme Corp tiene: BU Software (SaaS B2B). BU Consultoría (servicios profesionales). BU Training (cursos y certificaciones). Arquitectura en HubSpot: 1 portal único. Contactos y empresas compartidos (pueden comprar en múltiples BUs). 3 pipelines de Deals: "Pipeline Software", "Pipeline Consultoría", "Pipeline Training". Propiedad "Business Unit" en Deals (dropdown: Software / Consultoría / Training). 3 equipos: Team Software, Team Consultoría, Team Training. Propiedades clave para multi-BU En objeto Company Business Units (Multi-checkbox) └─ Permite marcar múltiples BUs si la empresa es cliente de varias Primary Business Unit (Dropdown) └─ BU principal si hay múltiples Company Segment (Dropdown) └─ Segmento: Enterprise / Mid-market / SMB └─ Puede ser global o específico por BU En objeto Contact Business Unit Interest (Multi-checkbox) └─ En qué BUs ha mostrado interés el contacto Primary BU Contact (Dropdown) └─ Con qué BU interactúa principalmente Contact Role by BU (Text) └─ Ejemplo: "Decision maker en Software, Influencer en Consultoría" En objeto Deal Business Unit (Dropdown) [CRÍTICO] └─ Software / Consultoría / Training └─ Obligatorio, autocompletado por el pipeline Deal Type (Dropdown) └─ New Business / Cross-sell / Upsell / Renewal Origin BU (si es cross-sell) └─ De qué BU vino el cliente original En objeto Ticket (opcional) Ticket BU (Dropdown) └─ Qué BU debe resolver este ticket Product/Service Line (Dropdown) └─ Qué producto específico de la BU Regla de oro La propiedad "Business Unit" en Deals debe autocompletarse basándose en el pipeline seleccionado. Esto evita errores humanos y asegura consistencia de datos. Configuración de pipelines y etapas Un pipeline por BU Cada BU tiene su propio pipeline porque los procesos de venta difieren: Pipeline Software (ciclo corto, 60 días avg) Demo solicitada. Demo realizada. Trial activo. Propuesta enviada. Negociación. Cerrada ganada / perdida. Pipeline Consultoría (ciclo largo, 120 días avg) Reunión discovery. Assessment realizado. Propuesta técnica. Propuesta económica. Due diligence cliente. Negociación contrato. Aprobación legal. Cerrada ganada / perdida. Pipeline Training (ciclo muy corto, 14 días avg) Info solicitada. Presupuesto enviado. Cerrada ganada / perdida. Automatización de Business Unit Crea workflows para autocompletar la BU basándose en el pipeline: Workflow: "Set BU from Pipeline" Trigger: Deal created or Pipeline changed Actions: IF Pipeline = "Pipeline Software" → Set Business Unit = "Software" IF Pipeline = "Pipeline Consultoría" → Set Business Unit = "Consultoría" IF Pipeline = "Pipeline Training" → Set Business Unit = "Training" Estructura de equipos y permisos Jerarquía de equipos Acme Corp (Parent team — C-level y management) ├── BU Software │ ├── Software Sales │ ├── Software Marketing │ └── Software CS ├── BU Consultoría │ ├── Consultoría Sales │ └── Consultoría Delivery └── BU Training ├── Training Sales └── Training Ops Configuración de permisos Equipo Ve datos de Edita datos de Acme Corp (C-level) Todas las BUs Todas las BUs BU Software (Managers) Solo BU Software Solo BU Software Software Sales Solo sus deals de Software Solo sus deals de Software Consultoría Sales Solo sus deals de Consultoría Solo sus deals de Consultoría Vistas guardadas por BU Crea vistas pre-filtradas para cada equipo: All Software Deals: Business Unit = Software. All Consultoría Deals: Business Unit = Consultoría. My Software Deals: Business Unit = Software AND Owner = Me. Cuidado con los contactos y empresas En un modelo multi-BU, contactos y empresas deben ser visibles por todas las BUs (o tendrás duplicados). La segregación se hace a nivel de Deals, no de contactos. Solo restringe acceso a deals según la BU. Reporting consolidado y por BU Dashboards por audiencia Dashboard C-level (visión consolidada) Pipeline total por BU (gráfico de barras). Revenue por BU (tendencia mensual). Win rate por BU (comparativa). Deals cerrados este mes (tabla con columna BU). Cross-sell rate (% de empresas que compran en >1 BU). Dashboard por BU (ejemplo: BU Software) Pipeline total de Software. Forecast de Software (weighted). Deals por etapa en Pipeline Software. Top reps de Software por revenue. Velocidad de pipeline en Software. Reports multi-dimensionales Ejemplos de reports útiles: Revenue por BU y por Rep. Pipeline por BU y por Fuente (Inbound/Outbound). Win rate por BU y por Segmento de empresa. Tiempo hasta cerrar por BU. Empresas activas en múltiples BUs (cross-sell analysis). Integraciones con arquitectura multi-BU ERP/Contabilidad Tu ERP probablemente tiene la BU como dimensión. En la integración HubSpot ↔ ERP: Mapea la propiedad "Business Unit" de HubSpot al campo equivalente en el ERP. Sincroniza solo los deals cerrados ganados. Asegúrate de que el revenue se contabiliza en la BU correcta. Marketing Automation Si cada BU tiene campañas separadas: Usa listas de contactos filtradas por "Business Unit Interest". Workflows separados por BU. Templates de email con branding por BU. BI/Analytics (Power BI, Tableau) Exporta datos de HubSpot con la dimensión BU incluida: Tabla Deals debe incluir columna "Business Unit". Crea vistas separadas en el BI por BU. Dashboards consolidados usando filtros de BU. Gobernanza de datos en multi-BU Reglas de asignación Define claramente cómo se asigna un deal a una BU: Reglas de Acme Corp Si el contacto rellena el formulario de "Request Demo Software" → Deal en BU Software. Si el contacto llega vía partner de Consultoría → Deal en BU Consultoría. Si un cliente de Software pide Consultoría → Deal en BU Consultoría con campo "Origin BU" = Software. Si hay duda, Sales Ops decide manualmente. Prevención de duplicados Contactos y empresas son únicos globalmente (un solo registro). Una empresa puede tener múltiples deals, cada uno en su BU correspondiente. Propiedad "Business Units" (multi-checkbox) en Company muestra en qué BUs es cliente. Cross-sell y cambio de BU Qué hacer cuando un cliente de una BU compra en otra: Crear un nuevo Deal en la nueva BU. Marcar Deal Type = "Cross-sell". Rellenar "Origin BU" con la BU de origen. Actualizar propiedad "Business Units" (multi-checkbox) en Company. NO cambiar el Deal original de BU. Pasos para implementar arquitectura multi-BU Fase 1: diseño (2-3 semanas) Documentar todas las BUs actuales y futuras. Mapear procesos de venta de cada BU. Definir propiedades necesarias. Diseñar estructura de pipelines. Definir jerarquía de equipos y permisos. Planificar reporting necesario. Fase 2: configuración (3-4 semanas) Crear propiedades en todos los objetos. Configurar pipelines por BU con etapas. Crear teams y asignar usuarios. Configurar permisos por team. Crear workflows de automatización. Configurar vistas guardadas por BU. Fase 3: migración de datos (2-3 semanas) Auditar deals existentes. Asignar BU a deals históricos. Migrar deals a pipelines correspondientes. Actualizar propiedades de empresas (Business Units multi-checkbox). Validar integridad de datos. Fase 4: dashboards y testing (2 semanas) Crear dashboard C-level consolidado. Crear dashboards por BU. User Acceptance Testing con cada BU. Ajustes basados en feedback. Fase 5: go-live y formación (1 semana) Formación a admins de cada BU. Formación a usuarios finales. Activación progresiva por BU. Soporte intensivo la primera semana. Caso de éxito: S&P Global S&P implementó una arquitectura multi-BU para sus 5 divisiones de negocio (Ratings, Indices, Platts, Market Intelligence, Mobility). Consolidaron de 3 portales separados a 1 portal único con 5 pipelines. Resultado: la visibilidad cross-sell aumentó un 240%, el TCO se redujo un 35% y el tiempo de implementación de cambios pasó de 3 semanas a 2 días. Conclusión Una arquitectura multi-BU bien diseñada en HubSpot te permite: Mantener la autonomía operativa de cada BU. Obtener visibilidad consolidada para dirección. Identificar oportunidades de cross-sell. Evitar duplicación de costes y esfuerzos. Escalar cuando añades nuevas BUs. La clave está en encontrar el balance entre separación (equipos y procesos independientes) y unificación (datos y reporting consolidados). Con el modelo de propiedades + pipelines + teams que hemos descrito, logras ambos objetivos. Empieza con un diseño sólido, involucra a stakeholders de cada BU desde el inicio, y planifica para el futuro (nuevas BUs, cambios en estructura). Una arquitectura flexible te ahorrará refactorings costosos más adelante.