Diseñando Su Modelo de Datos de CRM Antes de Tocar el Software

Un equipo de ventas SaaS de 40 personas reconstruyó su modelo de datos de CRM dos veces en 12 meses. La primera construcción tardó tres semanas en configurarse. La segunda reconstrucción ocurrió porque descubrieron, a mediados del Q2, que su modelo de contactos no podía admitir múltiples contactos por deal con diferentes roles. El tercer intento, hecho en papel antes de tocar el CRM, ha funcionado sin cambios estructurales durante 18 meses.

Ese tercer intento comenzó con una pizarra, no con un portátil.

La lección principal: toda implementación de CRM que se desmorona lo hace porque alguien empezó a hacer clic antes de pensar. Contactos vs. Leads vs. Cuentas vs. Deals: las relaciones entre estos objetos determinan lo que puede reportar, lo que puede automatizar y cómo funciona su Pipeline. Equivóquese y pasará el Q3 migrando datos que ingresó en el Q1.

Esta guía le lleva a través del diseño de un modelo de datos de CRM en papel antes de configurar un solo campo.

Paso 1: Liste Sus Objetos de Negocio Principales

Comience con los cuatro objetos predeterminados con los que viene cada CRM:

  • Contactos: Las personas individuales con las que su equipo interactúa
  • Empresas (Cuentas): Las organizaciones a las que pertenecen los contactos
  • Deals (Oportunidades): Movimientos de ventas activos con fecha de cierre y valor
  • Actividades: Llamadas, correos, reuniones, tareas (el registro de interacciones)

Antes de agregar cualquier otra cosa, valide que estos cuatro cubren el 90% de su movimiento de ventas. Usualmente lo hacen. La tentación de agregar objetos personalizados es fuerte. Resístala hasta que haya comprobado que los objetos estándar no pueden manejar el caso de uso.

Los objetos personalizados solo valen la complejidad cuando:

  • Está haciendo seguimiento de algo que no es una persona, empresa o deal (p. ej., activos físicos, entregables de proyectos, instalaciones de productos)
  • La estructura de relaciones es fundamentalmente diferente del esquema contacto-empresa-deal
  • Tiene 3 o más campos que se aplican exclusivamente a esta entidad

En Salesforce, los objetos personalizados son potentes pero añaden gastos de licencia y mantenimiento. En HubSpot, los objetos personalizados están disponibles en planes Enterprise y son cada vez más capaces. En Pipedrive, los objetos personalizados no existen de la misma manera. En cambio, se usan campos personalizados en los objetos existentes.

Si no está en Salesforce Enterprise o HubSpot Enterprise, no diseñe su modelo alrededor de objetos personalizados. Diseñe para lo que el CRM puede soportar.

Paso 2: Mapee las Relaciones

Dibuje esto antes de abrir el CRM. Necesita entender la cardinalidad: cuántos de un objeto pueden relacionarse con cuántos de otro.

Relaciones estándar a definir:

Relación Tipo Notas
Contacto → Empresa Muchos a uno Un contacto pertenece a una empresa (predeterminado)
Contacto → Empresa Muchos a muchos Un contacto trabaja con múltiples empresas (función Account de Salesforce, Asociaciones de HubSpot)
Contacto → Deal Muchos a muchos Múltiples contactos pueden estar en un deal (compra por comité)
Deal → Empresa Muchos a uno Un deal pertenece a una empresa
Actividad → Contacto Muchos a uno Las actividades se registran contra un único contacto
Actividad → Deal Muchos a uno Las actividades se registran contra un único deal

La pregunta no obvia: ¿puede un contacto pertenecer a múltiples empresas? En la mayoría de las ventas B2B, se encuentra con esto cuando alguien es miembro de la junta directiva de dos empresas, o cuando está vendiendo a una empresa holding con múltiples subsidiarias.

Salesforce maneja esto con Account Relationships y Contact Roles. HubSpot agregó soporte de asociaciones múltiples en 2022. Pipedrive lo maneja de manera menos elegante. Puede asociar una persona con múltiples deals, pero la empresa primaria es singular.

Si su movimiento de ventas implica regularmente contactos que abarcan múltiples cuentas, diseñe su modelo considerando eso antes de configurar. Si es raro, trátelo como un caso excepcional en sus notas en lugar de construir complejidad en el modelo de datos para ello.

Paso 3: Defina lo que Vive en Cada Objeto

Para cada objeto, liste los campos. No saltee este paso en favor de "lo resolveremos durante la configuración". No lo hará. Agregará campos de forma reactiva y terminará con 80 campos al tercer mes.

Para cada campo, defina:

  1. Nombre: Cómo se llama. Sea consistente con las convenciones de nomenclatura y decida ahora entre Title Case y minúsculas.
  2. Tipo: Texto, lista de selección, número, fecha, casilla de verificación, fórmula, búsqueda
  3. ¿Requerido?: Sí o No. Mantenga esta lista corta.
  4. Propósito: Reportar sobre él, segmentar por él, activar automatización con él, o mostrarlo a los representantes

Una definición de objeto Contacto podría verse así:

Campo Tipo Requerido Propósito
Nombre Texto Sí Visualización
Apellido Texto Sí Visualización
Correo Texto Sí Sincronización de correo, automatización
Teléfono Texto No Visualización
Cargo Texto No Visualización
Fuente del Lead Lista de selección Sí Reportes, automatización
Estado del Lead Lista de selección Sí Enrutamiento, reportes
Ajuste al ICP Lista de selección No Segmentación
Fecha de Última Actividad Fecha (sistema) — Generado por el sistema
Propietario del Contacto Búsqueda → Usuario Sí Enrutamiento

Y un objeto Deal:

Campo Tipo Requerido Propósito
Nombre del Deal Texto Sí Visualización
Etapa del Pipeline Lista de selección Sí Pipeline, pronóstico
Fecha de Cierre Fecha Sí Pronóstico
Valor del Deal Moneda Sí Reportes
Tipo de Deal Lista de selección Sí Segmentación
Razón de Pérdida Lista de selección No (requerido al cerrar como perdido) Reportes
Cuenta Búsqueda → Empresa Sí Relación
Contacto Principal Búsqueda → Contacto Sí Relación
Categoría de Pronóstico Lista de selección No Pronóstico

Este es exactamente el trabajo que evita que la conversación sobre campos personalizados se salga de control. Consulte la guía de campos personalizados para el framework de decisión para cada solicitud de campo.

Paso 4: Construya Sus Valores de Lista de Selección Como Equipo

Aquí es donde comienzan los datos de mala calidad: un representante escribe "Servicios Financieros" en el campo de industria, otro escribe "Fintech", otro escribe "Banca y Finanzas". Ahora su reporte de industria es inútil.

Las listas de selección imponen consistencia. Pero solo funcionan si los valores están diseñados para reportes, no solo para entrada de datos.

Listas de selección principales a definir antes del lanzamiento:

Fuente del Lead: De dónde ingresan los contactos al CRM. Valores de muestra: Web Inbound, SDR Outbound, Referencia, Partner, Evento, Descarga de Contenido, Anuncio de Pago, Registro de Trial. Manténgalos a nivel de fuente, no "Anuncio de Facebook - Nombre de Campaña - Marzo 2026".

Industria: Use una taxonomía consistente. Comience con 10 a 12 valores y resista las solicitudes de agregar más en los primeros 90 días. SaaS, Servicios Financieros, Salud, Manufactura, Servicios Profesionales, Retail, Medios, Educación, Sin Fines de Lucro, Otro.

Razón de Pérdida: Son críticos para aprender pero casi siempre están desordenados. Buenas razones de pérdida son honestas y accionables: Sin Presupuesto, Eligió Competidor (nombrado), Sin Decisión, Momento Inadecuado, Perfil Incorrecto, Desapareció. Evite opciones vagas como "Otro" como comodín.

Etapa del Pipeline: Defínalas con cuidado. Consulte la guía de etapas de Pipeline para saber cómo construir etapas alrededor de los hitos del comprador.

Tipo de Deal: Nuevo Negocio, Expansión, Renovación, Reactivación. Si solo vende un tipo, omita este campo. Si tiene múltiples movimientos, este campo separa su Pipeline en Funnels distintos.

Paso 5: Diseñe Pensando en los Reportes, No Solo en la Entrada de Datos

Esta es la prueba para cada campo: si no puede consultarlo o agrupar por él en un reporte, no lo almacene como texto libre.

"Notas del cliente" como campo de texto es útil para que un representante lea contexto antes de una llamada. Es inútil para cualquier análisis agregado. "Pain Point" como campo de texto libre significa que nunca sabrá que el 60% de sus deals mencionan "procesos manuales" como el problema central. Nadie puede analizar 2.000 entradas de texto.

Cuando alguien pida un campo de texto libre, pregúntele: ¿alguna vez querrá contar cuántos deals caen en diferentes categorías de este campo? Si es sí, debería ser una lista de selección. Si es verdaderamente narrativa contextual, el texto está bien. Pero solo pertenece en la sección de notas o en el registro de actividad.

Paso 6: Documente el Modelo en una Hoja de Esquema

Antes de configurar cualquier cosa, documente su diseño en una hoja de cálculo simple. Una pestaña por objeto, columnas para: nombre del campo, tipo de campo, requerido, valores (para listas de selección) y propósito.

Una hoja de esquema básica tiene:

  • Pestaña de Definiciones de Objetos: Lista de todos los objetos, su propósito y si son estándar o personalizados
  • Pestaña de Relaciones: Cada relación objeto a objeto con la cardinalidad anotada
  • Pestañas de Definiciones de Campos: Una por objeto con el formato de tabla anterior
  • Pestaña de Valores de Lista de Selección: Cada lista de selección y cada valor, con una nota sobre quién es su propietario

Este documento se convierte en su especificación de implementación. Su administrador de CRM configura a partir de él. Su equipo lo revisa antes del lanzamiento. Su manager puede leerlo sin abrir el CRM.

Mantenga la hoja de esquema en una carpeta compartida, no solo en su cabeza. Los administradores de CRM cambian. Su yo futuro se lo agradecerá.

Cómo Difiere Esto por CRM

Salesforce: El modelo de datos de Salesforce es el más potente y el más complejo. Los objetos estándar son Leads, Contactos, Cuentas y Oportunidades. El proceso de conversión de Lead a Contacto requiere un diseño deliberado. ¿Cuándo se convierte un Lead en un Contacto con una Cuenta y Oportunidad asociadas? Esta transición es una fuente común de confusión. Los objetos personalizados y las relaciones personalizadas están disponibles en la mayoría de los niveles de licencia, pero requieren experiencia de Administrador o Desarrollador para configurarlos correctamente.

HubSpot: El modelo predeterminado de HubSpot es Contactos, Empresas, Deals y Tickets. La función Asociaciones (disponible en todos los niveles de pago) permite relaciones multi-objeto pero tiene límites en los tipos de asociación en los niveles inferiores. HubSpot no tiene un objeto Lead de forma predeterminada. Los Contactos llenan ese rol, lo que simplifica el modelo pero requiere campos claros de Estado del Lead y Etapa del Ciclo de Vida para rastrear la progresión. Los objetos personalizados son solo para Enterprise.

Pipedrive: Pipedrive mantiene el modelo simple: Personas, Organizaciones, Deals, Actividades. No admite objetos personalizados. Las relaciones son sencillas y hay menos flexibilidad pero también menos posibilidades de error. Si su movimiento de ventas es relativamente estándar, la simplicidad de Pipedrive es una ventaja. Si necesita jerarquía de cuentas compleja o roles de contacto en deals, encontrará sus límites.

Close: Close usa Leads como el objeto de nivel superior, con Contactos debajo de ellos. Esto difiere de la mayoría de los CRMs y requiere ajuste si está migrando desde Salesforce o HubSpot. El modelo es adecuado para ventas internas pero menos flexible para estructuras de cuentas enterprise complejas.

Errores Comunes

Demasiados campos personalizados desde el primer día. El promedio de un CRM tiene el 80% de los campos sin uso a los 6 meses. Comience con pocos, 15 a 20 campos por objeto, y agregue solo cuando haya una necesidad demostrada de reporte o automatización. Siempre puede agregar campos. Limpiar 60 campos sin usar y los datos malos en ellos es un proyecto.

Proliferación de listas de selección. Cuando múltiples personas pueden agregar valores de lista de selección sin un proceso de gobernanza, obtiene 12 versiones de "Servicios Financieros" en su campo de industria. Defina la propiedad de las listas de selección antes de salir en vivo. Una persona aprueba nuevos valores.

Construir para el caso excepcional. Un representante tiene un deal con cuatro contactos, cada uno con un rol diferente. Eso es real, pero no es el caso común. No diseñe todo su modelo de datos alrededor de la excepción. Maneje el caso común de forma limpia y documente cómo manejar el caso excepcional manualmente.

No involucrar a las personas correctas en la revisión del esquema. La hoja de esquema debe ser revisada por al menos un representante (¿esto coincide con cómo trabajo?), un manager (¿puedo construir los reportes que necesito?) y una persona de finanzas (¿los datos del deal soportan nuestros pronósticos?). RevOps construyendo el modelo de forma aislada es cómo se obtiene un modelo que satisface a la herramienta pero no al negocio.

Qué Hacer a Continuación

Tome la hoja de esquema que ha construido y muéstresela a tres personas: un representante, un manager y una persona de finanzas u operaciones. Déle a cada uno una pregunta a responder: "Basándome en este modelo, ¿puedes hacer lo que haces con más frecuencia en tu flujo de trabajo de CRM?" Si alguien dice no, corrija el modelo antes de abrir el software.

Después de eso, lea la guía de campos personalizados para obtener un framework de decisión para cada solicitud de campo que llegue durante la implementación.

Aprenda Más