Modelo de datos del cliente en HubSpot
Llevamos años implementando y optimizando CRM en Latinoamérica y otra regiones, y el mismo problema se repite en casi todas las empresas: nadie entiende el modelo de datos que ofrece la plataforma, y mucho menos el del propio negocio.
Cuando reemplazamos Salesforce por HubSpot, Zoho por HubSpot, o arrancamos HubSpot desde cero, el 80% del trabajo real no consiste en encender botones y usar la configuracion out of the box. Es diseñar y proteger el modelo de datos de la empresa.
Y si no lo haces, no importa cuánto pagues por licencia. Vas a terminar con un Excel glorificado dando vueltas entre departamentos por que no hay un modelo de datos comun. Tendras el modelo de datos de HubSpot, y el modelo de datos de cada marca y/o departamento.
El modelo de datos es sobre el contacto: el contacto en el centro, y un proceso de cuatro pasos para que ese modelo funcione de verdad.
Tip: Aunque este post sea especifico sobre HubSpot, el post puede aplicar a cualquier CRM.
Este blog post es basado en el video: Protege el modelo de datos de HubSpot. Accede al video al final de este post.
El contacto en el centro (una persona, múltiples roles)
En HubSpot todo gira alrededor del contacto. No de la cuenta, como en otros CRM. Esto cambia la forma de pensar el diseño, sobre todo si vienes de Salesforce.
El contacto es la persona. Y una persona tiene muchos roles al mismo tiempo: es contacto de su familia, de su empresa, de una otra empresa; es cliente, proveedor, influenciador, sponsor, el que firma, el que decide. Todo lo demás cuelga de ese contacto a través de asociaciones:
→ Empresa / Familia → B2B y B2C
→ Negocios e intereses → deals y pipelines
→ Tickets y servicio → casos, SLA, knowledge base
→ Actividades → correos, llamadas, reuniones, notas
→ Campañas + UTM → de dónde vino cada contacto
Esa es la gran ventaja: un solo contacto, un solo modelo en todo el CRM, sin depender de otros sistemas y/o modelo de datos. No son dos o tres modelos separados como cuando tienes marketing automation por un lado, ventas por otro y servicio en un tercer sistema.
Los 4 pasos para que el modelo funcione
Un buen modelo de datos no se “configura una vez”. Se diseña, se integra, se mantiene y se activa — en ese orden. Y lo mas importande es que luego de esto pasos tienes que proteger el modelo de datos con un gobierno, reglas, auditorias, reportes, procedimientos para que la calidad de los datos se buena y el modelo siga funcionando con los cambios del negocio. O sea el mantener el modelo de datos es un proceso continuo.
Nota: Es post esta escrito sobre la premisa que tienes HubSpot Enterprise Edition.
Antes de tocar un workflow, define tu plano: objetos, propiedades, IDs y reglas.
Ponlo por escrito. Arma el catálogo. Usa un trial o un sandbox solo para representar el modelo de datos —valida los datos con los procesos del negocio. Y ojo con los custom objects: son una decisión de diseño, no un atajo. Más abajo les dedico una sección completa.→ ¿Qué objetos usas de caja y cuáles necesitas de verdad?
→ ¿Cuáles son tus llaves únicas? Email, order ID, matrícula, tax ID, RFC, RUT, seguro social… según el país
→ ¿Qué formatos y validaciones aplican a teléfono, direcciones, email y ahora WhatsApp?
→ ¿Qué picklists, categorías y nomenclaturas usamos, y quién los aprueba?
Tu modelo de datos no vive solo en HubSpot. Vive conectado con:
→ Tu e-commerce
→ Facebook y Google (para las campañas)
→ El ERP (SAP, Oracle, Microsoft Dynamics)
→ El sistema estudiantil, si eres universidad
→ Tu scoring, RFM o customer lifetime value
No todo tiene que estar dentro del CRM. Con el Data Hub (antes Operations Hub) puedes traer y acceder a datos externos sin convertir todo en custom object.
Y algo crítico: la integración empieza en la forma. Cuando alguien llena un formulario, valida ahí mismo el email y el teléfono, y —si tienes Data Hub— usa un webhook para averiguar si esa persona ya es cliente. Porque estás trabajando en una sola base de datos.
Puedes tener el mejor diseño del mundo. Si no lo cuidas, en tres meses tienes deuda técnica. Mantener es: calidad de datos, formatos, duplicados y salud general del modelo.
Por eso la mejor estrategia no es limpiar duplicados a mano cada mes, sino detenerlos en el origen: formas e integraciones que reconozcan registros existentes en lugar de crear nuevos, y reglas de match claras (email, dominio, teléfono).
Solo cuando el modelo está diseñado, integrado y mantenido, lo activas: workflows, journeys, alertas, reportes, atribución e inteligencia artificial.
Aquí es donde el modelo de datos te devuelve la inversión:
→ Segmentos basados en lifecycle stage y buyer persona
→ Workflows y journeys para upsell, cross-sell y retención
→ Reportes y Dashboards confiables sin exportar a Excel ni usar PowerPoint
→ Atribución para saber qué campaña realmente vendió
Y ojo con la inteligencia artificial: la IA solo sirve si el dato, el proceso y el modelo operativo la soportan. Sin un modelo de datos limpio y protegido, la IA amplifica el desorden.
Custom objects: parte del modelo de datos
Los objetos estándar de HubSpot —contactos, empresas, negocios (deals), tickets y algunos más— cubren la gran mayoría de los casos B2B y B2C. Pero a veces necesitas guardar un tipo de dato que no encaja en ninguno: suscripciones, pólizas, vehículos, propiedades, matrículas, envíos. Para eso existen los custom objects.
Un custom object tiene la misma funcionalidad que uno estándar: propiedades, asociaciones (con etiquetas), pipelines, workflows y reportes. La diferencia es que le pones tu propio nombre y tus propias reglas.
La señal clara de que necesitas uno es cuando te encuentras metiendo un dato donde no va: suscripciones dentro de propiedades del deal, o eventos manejados con un sistema de tags que ya no se sostiene. Son muchos mas ejemplos.
Y aquí viene la disciplina, que es lo que de verdad importa:
→ La mayoría de los negocios necesitan entre 1 y 3 custom objects. Tienes has 20 de ellos con el HubSpot Enterprise Edition.
→ Si estás planeando más de 5, párate y revisa tu modelo — probablemente un objeto estándar ya resuelve el caso
→ Un custom object mal pensado no es flexibilidad, es deuda técnica
Cada custom object que creas es parte de tu modelo de datos, y hay que diseñarlo como tal: nombre, propiedades, asociaciones y etiquetas, pipelines, permisos y mantenimiento continuo. No es “créate un objeto y ya”.
Mi regla: acóplate primero a lo que HubSpot trae de caja. Y si el dato vive en otro sistema, muchas veces conviene traerlo con el Data Hub en lugar de inflar tu portal con custom objects que después nadie mantiene.
B2B y B2C en una sola instancia
En Latinoamérica casi nunca compramos 2 o 3 CRM para separar B2B de B2C. Un banco te vende una cuenta a ti como persona (B2C) y una línea de crédito a tu empresa (B2B). Es el mismo contacto.
La clave está en cómo usas el objeto de cuenta (account) y las etiquetas de asociación en relacion al Contacto y su rol:
→ Para B2B → la cuenta representa la empresa
→ Para B2C → usas la cuenta para representar la familia (household), con una clasificación
Ejemplo real: yo le vendo a Jesús Hoyos, pero quiero conocer a la familia Hoyos completa. Mi esposa y mis hijas son contactos adicionales, asociados a esa cuenta-familia. No inventes un custom object para la familia: usa el objeto de cuenta y dale una clasificación. va a ver la historia incompleta.
Lead vs. Contacto
El objeto lead como lo conocemos en Salesforce o Zoho —prospecto que luego “conviertes” en contacto— está obsoleto.
Un lead es un interés. Un contacto puede tener muchos intereses a lo largo del tiempo.
Mi recomendación práctica:
→ Contacto nuevo → clasifícalo como “nuevo”
→ Primera etapa del pipeline → prospección
→ ¿Cerró y volvió a entrar? → nueva oportunidad, y usas leads como intereses
Y aquí está el pecado más común: entra una persona por una forma, el sistema mira el email, hace un merge y sigue el proceso… sin validar primero si esa persona ya es cliente. Si ya es cliente, ese contacto debería ir por un workflow distinto, con otro score, sabiendo qué producto tiene y cómo están su NPS y su CSAT. Y de paso, dejas de pagar de más por marketing contacts.
Gobierno: la base de todo
Nada de lo anterior sobrevive sin un dueño del modelo de datos. Alguien que diga: “este campo no va aquí”, “esta es la llave única, no inventes otra”, “para esto usa el objeto de cuenta, no un custom object”.
Yo lo comparo con Excel: en toda empresa hay esa persona que domina los pivot tables. En HubSpot necesitas a esa persona protegiendo el modelo, en marketing, ventas y servicio. Lo que necesitas montar:
Un dueño de la arquitectura: decide asociaciones, objetos y llaves únicas.
Nomenclaturas: campos, campañas, objetos, dropdowns, knowledge base.
Gobierno de propiedades: quién aprueba un campo o picklist nuevo.
Un CoE o PMO de CRM: sandboxes, betas, release management, estándares.
Revisión continua: duplicados, formatos y salud del modelo como rutina, no como bombero.
Conclusión
El modelo de datos es tuyo, no de HubSpot. Diséñalo, intégralo, mantenlo y actívalo, y protegelo con gobierno de por medio.
Ahí es donde tu CRM deja de ser un Excel glorificado y se convierte en el corazón de tu ecosistema, y en un input real para tu estrategia de inteligencia artificial.
Video: Protege el modelo de datos de HubSpot
¿Tu modelo de datos está diseñado y protegido, o estás dando vueltas con hojas de Excel dentro de tu CRM?
