Modelo de datos del CRM: cómo diseñarlo en 7 decisiones

El modelo de datos del CRM es el diseño que define qué objetos registra la empresa, como empresa, contacto, negocio, producto y ticket, qué propiedades guarda cada objeto, cómo se conectan los registros y por qué pipelines pasan, y tiene que estar escrito y aprobado por las áreas antes de que alguien abra la pantalla de configuración. El diseño cabe en siete decisiones y en un documento de pocas páginas que dice, para cada información que pesa en una decisión, en qué objeto vive, quién la completa y en qué momento. Saltarse esta etapa sale caro meses después, cuando los informes, las automatizaciones y las integraciones ya dependen de una estructura configurada con prisa y cambiar un objeto obliga al equipo a rehacer lo que construyó encima. La empresa que implementa sin diseño termina con más campos de los que alguien puede explicar y con una dirección que vuelve a la planilla para tener un número.

En los diagnósticos que conduzco en CRMs que llegan para una reestructuración, la primera lista que pido es la de las propiedades del negocio con fecha de creación y porcentaje de llenado, y suele mostrar campos que nadie abre y duplicados con nombres parecidos, creados a pedido, uno por vez, sin un diseño que dijera dónde debía vivir cada información. La disciplina de diseñar antes de construir tiene cincuenta años en la computación: en 1976, Peter Chen propuso el modelo entidad-relación como técnica de diseño de bases de datos, separando las cosas que la organización registra, las relaciones entre ellas y los atributos de cada una (Chen, 1976). El vocabulario del CRM es la versión comercial de esa idea.

¿Qué es el modelo de datos del CRM?

El modelo de datos es el mapa de la información comercial dentro del CRM. Objeto es el tipo de cosa que la empresa registra, con pantalla, lista e informes propios, y registro es cada ocurrencia de él, como una empresa de la base con su identificación fiscal. Propiedad es la información guardada en cada registro, el campo de la pantalla. Asociación es el vínculo entre registros, y la etiqueta de asociación dice qué papel representa ese vínculo, como el contacto que es decisor en un negocio. Pipeline es la secuencia de etapas por la que pasa un registro, con un criterio para avanzar.

Las siete decisiones siguen este orden: objetos estándar, objetos personalizados, propiedades, asociaciones, pipelines, nomenclatura y el documento de diseño. La frontera entre objeto y propiedad es la decisión que más pesa, porque define lo que la empresa puede contar, filtrar y sumar después.

¿Por qué diseñar el modelo antes de implementar o reestructurar?

El orden que protege el proyecto va del diseño al diccionario de datos, después a la configuración, la migración y las integraciones. La integración con el ERP mapea propiedades que tienen que existir con el tipo correcto, la migración necesita una correspondencia entre campo antiguo y nuevo, y el informe de la dirección solo sale si la información está en un formato que pueda agrupar. Corregir en el papel cuesta una reunión, y después de la puesta en marcha cuesta reconfiguración y paneles rehechos.

En la reestructuración, el trabajo empieza por el inventario de lo que existe, con el llenado de cada propiedad y los informes y automatizaciones que dependen de ella. El diseño nuevo nace de las decisiones de negocio, y el inventario entra después, para armar la correspondencia de campos que la migración de CRM va a ejecutar.

¿Qué objetos estándar necesita el CRM?

Casi toda operación B2B empieza con los objetos estándar, los que la plataforma trae listos, con informes y automatizaciones preparados para ellos. Cuando el CRM conversa con el ERP, el código del producto en el catálogo tiene que ser el mismo de la facturación, y el diseño dice cuál de los dos sistemas crea y mantiene el catálogo.

Objeto	Qué representa	Pregunta que responde
Empresa	La organización que compra o puede comprar, identificada por identificación fiscal o dominio	Cuánto representa cada cuenta y cada segmento en el ingreso
Contacto	La persona con la que la empresa se relaciona	Quién decide, quién usa y quién paga en cada cuenta
Negocio	Una oportunidad de ingreso, con valor, etapa y fecha	Cuánto entra, cuándo y con qué probabilidad
Producto y línea de pedido	El catálogo y las líneas de cada negocio, con cantidad, precio y descuento	Qué vende la empresa, a qué precio y con qué descuento
Ticket	Una solicitud del cliente que alguien tiene que resolver	Cuánto pide cada cuenta y qué motivo concentra los problemas

¿Cuándo crear un objeto personalizado?

El objeto personalizado es un tipo de registro que la empresa crea cuando ningún objeto estándar representa algo que necesita seguir. Apruebo su creación cuando la cosa existe por sí misma, una empresa puede tener varias al mismo tiempo y tiene ciclo propio, con fechas, estado y responsable que cambian sin que cambien la empresa o el negocio. Un contrato con vigencia y renovación pasa esta prueba, igual que una sucursal atendida en una red, un equipo instalado en el cliente y una matrícula en una escuela.

Si la información describe un registro que ya existe, como tamaño o región, es una propiedad. Si marca un momento de la venta, como la propuesta enviada, es una etapa o una actividad. Cada objeto personalizado necesita propiedades, permisos, informes y mapeo en las integraciones, y en algunas plataformas depende del plan contratado, por eso la pregunta de negocio tiene que justificar ese costo.

¿Cómo definir las propiedades de cada objeto?

Cada propiedad responde a una pregunta que alguien le va a hacer al CRM, y el diseño registra esa pregunta antes de crearla. La propiedad que nace sin ella se vuelve un campo que nadie explica.

¿Qué tipo de propiedad elegir?

El tipo define lo que la empresa puede hacer con el dato: el texto no suma y una fecha guardada como texto no filtra por período.

Tipo	Cuándo usarlo	Ejemplo
Lista de selección única	Clasificación que se vuelve filtro o agrupación	Segmento, tamaño, motivo de pérdida
Selección múltiple	Más de un valor vale al mismo tiempo, sin entrar en sumas	Productos de interés
Número y moneda	Cantidad o valor que entra en cálculos, con unidad y período en la etiqueta	Valor del negocio, número de empleados
Fecha	Momento que alguien va a filtrar o medir, separando lo previsto de lo realizado	Fecha prevista de cierre, inicio de la vigencia
Sí o no	Condición con dos respuestas y un significado definido para el vacío	Exige registro de proveedor
Usuario	Persona responsable dentro de la empresa, una propiedad por rol	Dueño de la cuenta, CSM
Texto	Identificador único o contexto que nadie agrupa	Identificación fiscal, resumen de la reunión
Calculada	Valor derivado de otras propiedades, con fórmula documentada	Valor anual a partir del mensual

Obligatoriedad en el momento en que la persona tiene la información

La propiedad obligatoria al crear el registro produce datos inventados, porque el vendedor no sabe el valor del negocio en el primer contacto. En el diseño, la obligatoriedad queda atada a la etapa o al evento en que la información existe. La regla de campos por etapa está en calidad de datos en el CRM.

Lista cerrada en lugar de texto libre

Toda información que el liderazgo vaya a filtrar, agrupar o comparar entra como lista, con los valores escritos en la sesión de diseño con las áreas. Cada valor tiene una etiqueta, que el equipo lee, y un valor interno, que usan las integraciones y los informes. La etiqueta puede cambiar con el vocabulario del mercado, y el valor interno se mantiene estable, porque alterarlo rompe filtros guardados y mapeos de integración.

Un único escritor para cada propiedad

Cada propiedad tiene una fuente: una persona, una integración o una automatización. Cuando el ERP manda en el estado financiero del cliente, el CRM muestra el valor en modo de lectura, porque de lo contrario la siguiente sincronización borra la corrección que el vendedor hizo a mano. El diseño marca el sistema maestro y la dirección de cada dato que viene de afuera, y los flujos entre los dos sistemas están en integración CRM y ERP.

Asociaciones y etiquetas de asociación: ¿cómo conectar los registros?

La asociación define qué registros se conectan y cuántos de cada lado. Un negocio se vincula a una empresa principal, a varios contactos y a varias líneas de pedido. Un contacto puede estar vinculado a más de una empresa, como el director que cambió de trabajo, y un ticket se vincula a la empresa y a quien abrió la solicitud. El diseño elige la asociación que manda en los informes, como la empresa principal del negocio, que decide en qué cuenta aparece el ingreso.

La etiqueta dice el papel del vínculo. Entre negocio y contacto, las etiquetas describen el comité de compra, como decisor, influenciador, usuario, compras y jurídico, y el liderazgo pasa a filtrar los negocios en propuesta sin decisor asociado; el mapeo de ese grupo está en comité de compra B2B. Entre empresas, las etiquetas registran matriz y filial, grupo económico, revendedor y cliente final. En una red en la que la matriz firma y las sucursales usan el servicio, el ingreso queda en la matriz, los tickets en las sucursales, y el informe de la cuenta suma las dos puntas por la asociación.

Pipelines y etapas: ¿dónde entran en el modelo?

El pipeline pertenece a un objeto. El negocio tiene el pipeline de venta nueva y, cuando cambia la decisión del cliente, el de renovación y expansión, y el ticket tiene la cola de atención. En el diseño, cada etapa lleva el criterio de salida, las propiedades que pasan a ser obligatorias, quién puede mover el registro y la automatización que dispara el cambio. El método para escribir criterios a partir de la decisión del comprador está en embudo de ventas B2B. Vendedor, región y canal funcionan mejor como propiedad y filtro que como pipeline propio.

¿Cómo nombrar objetos, propiedades y valores?

Cada propiedad tiene dos nombres. La etiqueta aparece en la pantalla y sigue el lenguaje del equipo, y el nombre interno, que usan integraciones, automatizaciones y exportaciones, sigue un patrón técnico y no cambia después de creado, porque la integración apunta a él.

El documento de diseño: objeto, propiedades clave, quién completa y cuándo

El documento de diseño registra las decisiones en una tabla que la dirección lee en pocos minutos y que el administrador usa para configurar. Trae las propiedades clave, las que alimentan un informe, un traspaso entre áreas, una integración o una regla. El modelo de abajo es el punto de partida que adapto con cada operación, con un objeto personalizado de contrato como ejemplo.

Objeto	Propiedad clave	Tipo	Quién la completa	Cuándo	Informe o decisión que la usa
Empresa	Identificación fiscal	Texto con validación	SDR o enriquecimiento	Al crearla	Duplicados y cruce con el ERP
Empresa	Segmento	Lista única	SDR	Antes de la calificación	Conversión por segmento
Empresa	Dueño de la cuenta	Usuario	Liderazgo de ventas	Al distribuir la cartera	Cartera y comisión
Contacto	Nivel del cargo	Lista única	Marketing o SDR	En la calificación	Criterio de lead y cobertura del comité
Negocio	Valor	Moneda, calculada por las líneas	Vendedor	En la propuesta	Forecast
Negocio	Fecha prevista de cierre	Fecha	Vendedor	En la propuesta, revisada cada semana	Reunión de pipeline
Negocio	Motivo de pérdida	Lista única por etapa	Vendedor	Al marcarlo como perdido	Análisis de pérdidas
Ticket	Categoría	Lista única	Atención	Al abrirlo	Volumen por motivo y por cuenta
Contrato	Inicio y fin de la vigencia	Fecha	Integración del ERP	En la firma	Renovaciones del trimestre

El documento tiene dos piezas más: el diagrama de las asociaciones, con una caja por objeto y las etiquetas escritas en cada línea, y la lista de pipelines con etapas, criterios de salida y propiedades obligatorias. El diccionario de datos completa el conjunto, fijando lo que cada término y cada campo de este modelo significa para el negocio, con regla de cálculo, fuente y dueño.

¿Cómo validar el modelo de datos con las áreas?

Las excepciones aparecen cuando alguien intenta registrar un cliente de verdad en el modelo nuevo. En las implementaciones que acompaño, la prueba con casos reales es la que más cambia el diseño, porque el cliente que compró a través de un revendedor o el contrato firmado por la matriz para varias sucursales surge en el caso y no surge en ninguna reunión de levantamiento. La versión que pasa las pruebas recibe número y fecha, la dirección la firma, y solo entonces el administrador configura.

Prueba	Cómo hacerla	Quién participa	Aprobada cuando
Casos reales	Recorrer en papel diez clientes del último año, del primer contacto a la renovación	Ventas, marketing y CS	Cada información del caso tiene objeto y propiedad
Informes de la dirección	Cada liderazgo lista los informes de la reunión mensual	Liderazgos y dirección	Cada informe sale del modelo sin planilla paralela
Traspaso entre áreas	Simular la entrega del lead a ventas y del cliente ganado a CS	SDR, vendedor y CSM	El área siguiente encuentra lo que necesita en una propiedad con dueño
Integraciones	Marcar las propiedades que vienen de otro sistema	TI y operaciones de ingresos	Cada propiedad tiene un único escritor
Datos personales	Revisar la finalidad de cada propiedad con datos personales	Encargado de datos y jurídico	Ningún dato personal sin finalidad escrita

¿Quién es dueño del modelo de datos del CRM?

Rol	Qué hace en el modelo	Qué aprueba
Dirección, como patrocinadora	Define prioridades y arbitra conflictos entre áreas	La versión final y los cambios que afectan informes oficiales
Responsable del modelo, en operaciones de ingresos o en la administración del CRM	Escribe el diseño, mantiene el documento y recibe los pedidos de cambio	Propiedades nuevas, valores de lista y nomenclatura
Liderazgos de marketing, ventas y CS	Dicen qué decisiones necesitan datos y exigen el llenado al equipo	Propiedades, listas y etapas de su propia área
TI	Responde por integraciones, acceso y seguridad	Mapeos de integración y perfiles de acceso
Encargado de datos y jurídico	Revisan la finalidad y la necesidad de cada dato personal	Propiedades con datos personales

El pedido de una propiedad nueva llega al responsable del modelo con la pregunta de negocio, el informe que va a usar el valor, quién lo completa y cuándo. El responsable busca antes una propiedad existente que responda a la misma pregunta y decide en la reunión mensual con los liderazgos.

Errores comunes al diseñar el modelo de datos del CRM

Copiar la planilla antigua

La planilla del equipo se convierte, columna por columna, en el conjunto de propiedades del negocio. Mezclaba empresa, contacto y contrato en una fila, y el CRM hereda la mezcla, con el decisor en texto y el producto escrito a mano. Usa las columnas como lista de requisitos y deja que el diseño decida en qué objeto vive cada una.

Crear un campo para cada pedido

Cada área pide su campo, el administrador lo crea, y en un año el negocio tiene propiedades que solo una persona completa. Cuando el campo guarda datos personales, el exceso tiene peso legal: la ley brasileña de protección de datos (LGPD) exige propósitos “legítimos, específicos, explícitos e informados al titular” y limita el tratamiento “al mínimo necesario para la realización de sus finalidades” (Lei 13.709/2018, art. 6º, incisos I y III).

Texto libre donde el liderazgo va a necesitar un filtro

El campo de texto parece flexible en la configuración y cobra su precio en el primer informe, con el segmento escrito de cinco maneras y un historial que alguien va a tener que estandarizar registro por registro. En la sesión de diseño, pregunta si alguien va a filtrar, agrupar o comparar la información, y si la respuesta es sí, la propiedad nace como lista.

Meter todo dentro del negocio

Contratos, proyectos de implementación y reclamos se vuelven negocios en pipelines improvisados, porque el negocio es el objeto que el equipo conoce. El informe de pipeline empieza a sumar ingreso nuevo con renovaciones y reclamos, y el forecast mezcla cosas que no se suman. Lo que tiene ciclo propio después de la venta pide ticket u objeto personalizado.

Capacitación: quién necesita aprender qué

El responsable del modelo aprende a elegir tipos, armar asociaciones, evaluar pedidos y mantener el documento. Los liderazgos aprenden a leer el diseño, a saber qué propiedad alimenta cada informe que llevan a la dirección y a exigir el llenado en la reunión del equipo. Vendedores, SDRs, marketing y CS aprenden qué completan, cuándo y para quién sirve después ese dato, en el CRM ya configurado con el modelo aprobado, y reciben una actualización corta con cada cambio relevante.

Hoja de ruta de 30 días para el liderazgo

1. Días 1 a 3: nombra al patrocinador y al responsable del modelo. Escribe lo que el responsable aprueba y comunícalo a las áreas.
2. Días 4 a 7: lista decisiones e informes. Cada liderazgo trae los informes de la reunión mensual y las preguntas que hoy no puede responder; en la reestructuración, haz también el inventario de las propiedades.
3. Días 8 a 12: diseña objetos y asociaciones, aplicando la prueba del ciclo propio a cada candidato a objeto personalizado.
4. Días 13 a 17: completa el documento de diseño con las propiedades clave, los tipos, quién las completa, cuándo y los valores de cada lista.
5. Días 18 a 21: escribe pipelines, etapas y nomenclatura, con criterio de salida y propiedades obligatorias por etapa.
6. Días 22 a 26: valida con casos reales y corrige el diseño donde algún caso no entró.
7. Días 27 a 30: aprueba la versión 1 y abre el flujo de pedidos. La dirección firma y el administrador configura a partir del documento.

Si tu empresa va a implementar o reestructurar el CRM y nadie sabe decir dónde debe vivir cada información, ese es el trabajo de la formación in company de adopción de CRM. Conduzco el programa con los liderazgos, el responsable del modelo y cada rol que registra, sobre los casos y los informes de tu operación. El grupo sale con la guía de buenas prácticas de CRM, con objetos, propiedades y nomenclatura diseñados, y con el manual de gestión de cartera y base, que define dueño de cuenta, asociaciones y la rutina que mantiene el modelo en pie.

Preguntas frecuentes

¿Qué es el modelo de datos del CRM?

Es el diseño que define qué objetos registra el CRM, qué propiedades guarda cada uno, cómo se asocian los registros y por qué pipelines pasan. Queda escrito en un documento que las áreas aprueban antes de la configuración y orienta integraciones, migración e informes.

¿Cuándo crear un objeto personalizado en el CRM?

Cuando la cosa que la empresa necesita seguir existe por sí misma, aparece varias veces en la misma cuenta y tiene ciclo propio, con fechas, estado y responsable. Contratos, sucursales atendidas y equipos instalados suelen pasar esta prueba. Si la información solo describe un registro existente, es una propiedad.

¿Cuál es la diferencia entre modelo de datos y diccionario de datos?

El modelo de datos muestra la estructura: objetos, asociaciones, pipelines y las propiedades clave con quién las completa y cuándo. El diccionario fija lo que cada término y cada campo significa para el negocio, con regla de cálculo, fuente y dueño. El modelo viene antes de la configuración, y el diccionario acompaña la operación después.

¿Cuántas propiedades debe tener un objeto del CRM?

Ningún número sirve de regla; el criterio vale más que la cantidad. Cada propiedad necesita una pregunta de negocio, alguien que la complete y un informe o regla que use el valor, y la que no pasa esa prueba sale en la revisión del modelo.

¿Se puede cambiar el modelo de datos cuando el CRM ya está en uso?

Sí, con un costo mayor a cada mes de uso, porque los informes, las automatizaciones y las integraciones dependen de la estructura. El cambio pasa por el responsable del modelo, con análisis de lo que depende de él, un plan para el historial y aviso a los roles afectados.

¿Cómo preparar al equipo para trabajar con el nuevo modelo de datos?

Capacita a cada rol en el CRM ya configurado, mostrando qué completa, en qué momento y qué informe o área usa ese dato. Los liderazgos pasan antes por la formación, porque son ellos quienes exigen el registro en la reunión del equipo. Repite una actualización corta con cada cambio relevante en el modelo.