En este paso defines qué datos comerciales existen, dónde vive cada uno, quién lo escribe y cómo se llama. El objetivo es una sola fuente de verdad: que el "ingreso anual del cliente" sea un número, no tres, y que cualquier reporte se pueda armar sin exportar a Excel para "arreglarlo".

El dato comercial se diseña, no se acumula

Un CRM sin gobierno acumula propiedades como un garaje acumula cajas. Auditamos portales con 300 propiedades de contacto de las cuales el equipo usaba 40; el resto eran experimentos de campañas viejas, campos duplicados con nombres casi iguales ("Industria", "industria_2", "Sector") y datos que alguien pidió una vez y nadie volvió a mirar.

El problema no es estético. Cada campo redundante es una oportunidad de inconsistencia, y cada inconsistencia es una discusión futura sobre qué número es el verdadero. El modelo de datos único es la respuesta anticipada a esa discusión.

Los cuatro objetos y qué vive en cada uno

La regla madre: cada dato vive en el objeto donde se decide sobre él.

• Contacto: la persona. Cargo, rol en la compra, canal preferido, consentimiento. Nada de datos de la empresa acá.
• Empresa: la cuenta. Industria, tamaño, facturación, país, tier. Si mañana el contacto renuncia, este dato tiene que quedar.
• Negocio: la oportunidad. Monto, etapa, fecha de cierre, motivo de pérdida. Un negocio nuevo por cada ciclo de compra: no recicles deals viejos.
• Ticket: el servicio. Casos, incidencias, onboarding. Es lo que le da a servicio la misma vista que tienen marketing y ventas.

Ejemplo del error clásico: guardar "facturación anual" en el contacto. Cuando la empresa tiene cuatro contactos, tienes cuatro facturaciones potencialmente distintas. El dato es de la cuenta; vive en Empresa, punto.

Catálogo de propiedades: la regla del dueño único

Arma una hoja con todas las propiedades que van a existir, y para cada una: nombre, objeto, dueño (el equipo que la escribe), origen (manual, formulario o integración), y en qué etapa se vuelve obligatoria. Tres reglas que hacen la diferencia:

• Un dueño por dato. Si marketing y ventas pueden pisar el mismo campo, el campo no es confiable. El que lo escribe responde por él.
• Obligatorios por etapa, no todos al inicio. Pedir 15 campos para crear un contacto garantiza campos inventados. Pide 3 al crear, y el resto cuando el negocio avanza y el dato realmente se conoce.
• Convención de nombres. Prefijo por área o proceso (por ejemplo mkt_origen_campana, vta_motivo_perdida) para que cualquiera sepa de quién es un campo con solo leerlo.

Y una regla de higiene permanente: si a los 90 días una propiedad está vacía en más del 80% de los registros, se archiva. Sin duelo.

Cada campo del CRM es una promesa: alguien lo va a llenar y alguien lo va a usar. Si no puedes nombrar a esas dos personas, borralo.

Cuando el dato vive en varios sistemas

Si tienes ERP, ecommerce o sistemas propios, define el "maestro" de cada dato: el ERP manda en facturación y crédito, el CRM en pipeline y actividad comercial, el CDP en comportamiento. La sincronización respeta esa jerarquía: el maestro escribe, los demás leen. El detalle fino de mapeo y sincronización está en la guía de integración de datos, en particular el paso de modelado y mapeo. Y si vienes arrastrando años de datos sucios, no los migres tal cual: mira cómo migrar sin heredar el desorden.

Errores comunes en este paso

• Crear campos a pedido individual. "¿Me agregas un campito para...?" es el inicio del garaje. Todo campo nuevo pasa por el dueño del catálogo, con caso de uso.
• Duplicar el mismo dato en dos objetos. Dos copias, dos versiones, cero confianza. Se guarda una vez y se muestra donde haga falta.
• Migrar la basura histórica. Importar 40.000 contactos sin correo válido para "no perder nada" solo traslada el problema de casa.
• No nombrar un gobernador. Sin una persona que apruebe cambios al catálogo, el modelo dura tres meses. No es un rol de tiempo completo; es una responsabilidad explícita.

Checklist antes de pasar al siguiente

• Catálogo de propiedades con dueño y origen por campo.
• Convención de nombres definida y aplicada.
• Campos obligatorios asignados por etapa, no en bloque.
• Sistema maestro definido para cada dato compartido con ERP/ecommerce.
• Propiedades muertas archivadas.
• Proceso escrito para pedir campos nuevos, con un aprobador nombrado.

Con proceso firmado y dato confiable, ya puedes automatizar sin miedo: lead scoring y enrutamiento que el equipo respeta. El sistema completo está en la guía RevOps.