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.

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:

1. Una base de datos unificada de contactos y empresas.
2. Propiedades que identifican a qué BU pertenece cada registro.
3. Múltiples pipelines (uno por BU) en el objeto Deals.
4. Teams y permisos para controlar el acceso.
5. Vistas guardadas pre-filtradas por BU.

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

Configuración de pipelines y etapas

Un pipeline por BU

Cada BU tiene su propio pipeline porque los procesos de venta difieren:

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.

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:

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:

1. Crear un nuevo Deal en la nueva BU.
2. Marcar Deal Type = "Cross-sell".
3. Rellenar "Origin BU" con la BU de origen.
4. Actualizar propiedad "Business Units" (multi-checkbox) en Company.
5. NO cambiar el Deal original de BU.

Pasos para implementar arquitectura multi-BU

Fase 1: diseño (2-3 semanas)

1. Documentar todas las BUs actuales y futuras.
2. Mapear procesos de venta de cada BU.
3. Definir propiedades necesarias.
4. Diseñar estructura de pipelines.
5. Definir jerarquía de equipos y permisos.
6. Planificar reporting necesario.

Fase 2: configuración (3-4 semanas)

1. Crear propiedades en todos los objetos.
2. Configurar pipelines por BU con etapas.
3. Crear teams y asignar usuarios.
4. Configurar permisos por team.
5. Crear workflows de automatización.
6. Configurar vistas guardadas por BU.

Fase 3: migración de datos (2-3 semanas)

1. Auditar deals existentes.
2. Asignar BU a deals históricos.
3. Migrar deals a pipelines correspondientes.
4. Actualizar propiedades de empresas (Business Units multi-checkbox).
5. Validar integridad de datos.

Fase 4: dashboards y testing (2 semanas)

1. Crear dashboard C-level consolidado.
2. Crear dashboards por BU.
3. User Acceptance Testing con cada BU.
4. Ajustes basados en feedback.

Fase 5: go-live y formación (1 semana)

1. Formación a admins de cada BU.
2. Formación a usuarios finales.
3. Activación progresiva por BU.
4. Soporte intensivo la primera semana.

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.