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

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.