Respuesta directa
En pocas palabras
Para preparar los datos del CRM para un AI Sales Copilot, empieza por un caso de uso concreto y define qué campos necesita, de qué sistema proceden, quién los mantiene y qué nivel de acceso está autorizado. Después corrige definiciones ambiguas, duplicados y fechas, conserva los datos faltantes como faltantes, separa precios y monedas, crea casos de prueba y mide calidad durante la operación. No es necesario limpiar toda la base antes de comenzar; sí es necesario conocer y controlar los datos que sostienen cada salida.
Empieza por la decisión que el copiloto debe apoyar
Preparar datos no significa corregir cada registro histórico antes de probar una función. Primero describe la tarea: resumir una oportunidad, sugerir un siguiente paso, preparar una propuesta o localizar negocios que necesitan atención. Cada tarea exige fuentes, campos, actualidad y permisos diferentes. Sin ese límite, el proyecto se convierte en una limpieza indefinida y resulta difícil saber cuándo el conjunto está listo.
Escribe la entrada, la salida y la decisión humana asociada. Si el copiloto prepara un resumen para una reunión, necesita hechos recientes, participantes, acuerdos y pendientes. Si prepara una propuesta, además necesita el catálogo autorizado y las condiciones aprobadas. El mismo dato puede ser suficiente para una nota interna y demasiado débil para una comunicación externa.
NIST recomienda documentar el contexto de uso, las tareas, los datos disponibles y sus limitaciones antes de medir el sistema. La regla práctica es sencilla: cada campo debe justificar qué decisión mejora o qué riesgo controla. Si nadie puede explicarlo, no lo incorpores por costumbre.
Construye un inventario pequeño de fuentes y responsables
Enumera los sistemas que pueden aportar contexto: CRM, catálogo de productos, documentos aprobados, calendario, notas y otras fuentes autorizadas. Para cada uno registra dueño, finalidad, campos utilizados, frecuencia de actualización, método de acceso, retención y restricciones. Disponible técnicamente no significa autorizado para el copiloto.
Distingue sistema de origen, copia e integración. Un campo visible en el CRM puede proceder de una importación antigua, una hoja de cálculo o una sincronización que dejó de funcionar. Documenta el recorrido suficiente para investigar un resultado: origen, transformación relevante, fecha de actualización y dependencia que lo entrega.
Microsoft plantea los datos confiables como productos con responsabilidad, acceso y ciclo de vida definidos. No necesitas adoptar una plataforma concreta para aplicar el principio: cada fuente utilizada por el caso debe tener una persona capaz de explicar su significado, corregirla y decidir cuándo deja de ser válida.
Define el modelo comercial mínimo antes de añadir contexto
Para una oportunidad B2B suele ser necesario relacionar cuenta, contactos, negocio, responsable, etapa, actividad, siguiente paso y productos. El conjunto exacto depende del proceso. Evita acumular campos porque podrían servir; empieza con los que permiten reconstruir el estado actual sin abrir cinco sistemas.
Documenta las relaciones. Un contacto puede participar en varias oportunidades y una cuenta puede tener filiales, compradores, usuarios y asesores distintos. Si el sistema confunde estas identidades, un resumen correcto por campo puede contar una historia equivocada. Define claves, reglas de asociación y qué hacer cuando la relación no está confirmada.
Separa hechos, interpretaciones y decisiones. Una fecha de reunión registrada es un hecho. La etiqueta oportunidad interesada es una interpretación. La decisión de cambiar de etapa pertenece al proceso comercial. Conservar esa diferencia ayuda a que el copiloto cite evidencia y a que la persona revise lo que sigue siendo una inferencia.
| Criterio | Pregunta que resuelve | Ejemplos de datos |
|---|---|---|
| Identidad | ¿De qué cuenta y personas hablamos? | Cuenta, contacto, función y relación confirmada |
| Estado | ¿Dónde está el proceso y por qué? | Etapa, evidencia, responsable y fecha de actualización |
| Movimiento | ¿Qué ocurrió y qué está acordado? | Actividad, compromiso, siguiente paso y fecha |
| Condiciones | ¿Qué puede ofrecerse sin inventar? | Producto, precio, moneda, vigencia y fuente autorizada |
Alinea el significado de campos, etapas y estados
Un nombre de campo no garantiza una definición compartida. Fecha de cierre puede significar una meta del vendedor, una estimación revisada o una fecha confirmada por el comprador. Monto puede ser lista, propuesta, total antes de impuestos o una cifra preliminar. Crea un diccionario con definición, formato, responsable, fuente y condición de actualización.
Define criterios de entrada y salida para cada etapa. Si propuesta enviada puede seleccionarse antes de que exista un documento compartido, el copiloto no debe tratar la etapa como evidencia de envío. Relaciona cada estado con hechos observables y conserva una forma explícita de marcar una excepción.
Mantén valores controlados cuando la comparación lo exige: monedas, países, industria, fuente, resultado, motivo de pérdida y estado de actividad. Los campos de texto libre siguen siendo útiles para contexto, pero no sustituyen una clasificación consistente cuando el equipo necesita filtrar, medir o aplicar una regla.
Conserva la diferencia entre faltante, desconocido y no aplicable
No rellenes un vacío con la opción más probable. Un monto ausente no equivale a cero; una persona sin función registrada no es necesariamente quien decide; una fecha vacía no significa que la compra no tenga calendario. Utiliza estados que permitan distinguir no capturado, pendiente de confirmar, no aplicable y dato rechazado.
Define qué faltantes bloquean una salida y cuáles solo exigen una advertencia. Preparar una agenda interna puede tolerar que falte el teléfono. Una propuesta no debe completar un precio, impuesto, vigencia o condición que no existe en la fuente aprobada. El umbral depende del efecto, no de la comodidad del formulario.
Haz visible la ausencia en las pruebas y en la interfaz. Un sistema que responde con seguridad ante datos incompletos oculta el problema. El comportamiento esperado puede ser abstenerse, solicitar confirmación, mostrar la fuente disponible o entregar un borrador con campos pendientes.
Resuelve duplicados sin borrar relaciones válidas
Busca duplicados por señales combinadas, no únicamente por nombre. Razón social, dominio, identificador fiscal cuando corresponda, correo, teléfono y relación corporativa pueden ayudar, pero ninguno demuestra por sí solo que dos registros sean la misma entidad. Conserva una cola de revisión para coincidencias ambiguas.
Antes de fusionar, revisa oportunidades, actividades, permisos, propietarios, archivos y consentimientos asociados. Define qué registro prevalece por campo y conserva la referencia necesaria para rastrear el cambio. Una fusión irreversible puede eliminar contexto que después explique una decisión comercial.
Previene la recurrencia con reglas de captura, búsqueda antes de crear, identificadores estables y responsables. La deduplicación puntual mejora una fotografía; el control de entrada mantiene el proceso.
Protege precios, monedas y condiciones comerciales
El catálogo autorizado debe identificar producto, variante, unidad, precio, moneda, vigencia y fuente. Si existen listas por cliente, canal o región, documenta la regla que selecciona cada una. Un archivo más reciente por nombre no siempre es la versión aprobada.
Mantén MXN, USD y otras monedas como dimensiones explícitas. No sumes ni compares importes de monedas distintas sin un método de conversión aprobado, fecha de referencia y trazabilidad. Tampoco deduzcas impuestos, descuentos, flete o vigencia cuando la fuente no los define.
Prueba conflictos: dos listas vigentes, producto sin precio, precio vencido, moneda ausente, unidad incompatible y descuento fuera de autoridad. El resultado correcto puede ser detener la preparación y pedir confirmación. Evitar una propuesta incorrecta es más importante que completar todos los campos automáticamente.
Minimiza datos y aplica el acceso efectivo de cada persona
El copiloto no debe ampliar la visibilidad del usuario. Si una persona no puede consultar una cuenta, un adjunto o un campo sensible en el proceso normal, una respuesta generada tampoco debe revelarlo. Revisa permisos directos, grupos, cuentas de servicio, enlaces compartidos e integraciones que puedan crear rutas alternativas.
Clasifica datos personales, confidenciales, credenciales, secretos comerciales y material de terceros. Excluye campos que el caso de uso no necesita y limita qué contenido puede entrar en registros, exportaciones o herramientas conectadas. NIST recomienda documentar colección, uso, acceso y divulgación, además de aplicar controles y minimización según el contexto.
Prueba revocación y cambios de función. Cuando una persona sale del equipo, cambia de territorio o vence una excepción, deben cerrarse sesiones, tokens, enlaces y accesos heredados. Una interfaz sin el botón correcto no demuestra que el dato dejó de estar disponible.
Define actualidad, corrección y retiro de datos
Cada fuente necesita una expectativa de actualidad. Una etapa puede revisarse después de cada interacción; un catálogo puede cambiar por versión; una nota histórica debe conservar su fecha original. Mostrar cuándo se actualizó un dato permite decidir si todavía sostiene la respuesta.
Diseña una ruta de corrección. El usuario debe saber dónde reportar un contacto incorrecto, una asociación equivocada, un precio obsoleto o una actividad duplicada. Asigna responsable y plazo según impacto, y comprueba que la corrección llegue a las copias e índices que consumen el sistema.
Retira datos y fuentes cuando termina su finalidad, vence el permiso o el contenido deja de ser confiable. Conserva únicamente la evidencia requerida por el proceso y las reglas aplicables. Acumular versiones sin estado aumenta la probabilidad de utilizar una fuente equivocada.
Mide calidad por campo, escenario y consecuencia
No reduzcas la calidad a un porcentaje global. Mide completitud, validez, consistencia, unicidad, actualidad y trazabilidad donde cada dimensión importe. Un noventa por ciento de completitud puede ser suficiente si faltan campos opcionales y peligroso si el diez por ciento ausente corresponde a moneda o siguiente paso.
Define población, periodo, fuente, umbral, responsable y acción para cada métrica. Separa errores encontrados antes de la salida, abstenciones correctas, correcciones humanas y problemas que llegaron a una comunicación externa. NIST recomienda seleccionar medidas según el contexto y documentar también lo que no puede medirse.
Revisa muestras, no solo agregados. Incluye oportunidades nuevas, antiguas, multinacionales, sin actividad, con varias monedas y con permisos restringidos. Los casos raros suelen revelar relaciones y límites que un promedio oculta.
Crea un conjunto de prueba antes de conectar producción
Reúne casos representativos y casos difíciles sin copiar información innecesaria. Incluye un registro completo, datos faltantes, fuentes en conflicto, duplicados, permisos insuficientes, precios vencidos, varias monedas, texto ambiguo y una solicitud fuera del alcance. Define de antemano qué salida, advertencia o abstención sería aceptable.
Separa datos de desarrollo, evaluación y producción cuando corresponda. Protege las muestras y controla quién puede consultarlas. Si utilizas registros sintéticos, documenta qué condiciones representan y qué aspectos reales no pueden validar.
Ejecuta la misma prueba cuando cambien campos, integraciones, instrucciones, permisos o fuentes. Compara la versión candidata con la activa y conserva ejemplos aceptados, corregidos y rechazados. La prueba no demuestra que nunca habrá un error; sí permite detectar regresiones conocidas antes de ampliar el uso.
Mejora los datos mientras el copiloto está en operación
Empieza con el escenario y el grupo mínimos que permiten observar la condición real. Explica qué datos se utilizan, qué limitaciones siguen abiertas y dónde reportar. No ocultes problemas conocidos detrás de una etiqueta piloto.
Clasifica el feedback por captura, definición, relación, actualidad, permiso, integración o comportamiento del sistema. Una corrección de salida no siempre exige cambiar el modelo; con frecuencia revela un campo ambiguo, una fuente obsoleta o una regla del proceso que nadie había documentado.
Opera una cadencia con negocio, datos, tecnología, seguridad y usuarios. Cada revisión debe terminar en una decisión: corregir, aclarar, capacitar, limitar, volver a probar, aceptar temporalmente con control o detener el escenario. La preparación de datos continúa mientras cambian clientes, productos, equipo y proceso.
Aplica estas reglas a los datos que utiliza Cerravi
Cerravi organiza señales registradas en el CRM y propone siguientes pasos para revisión humana. La utilidad depende de que cuenta, contacto, etapa, actividad, responsable y fecha reflejen el proceso. Una actividad de Buyer Room aporta contexto, pero no confirma identidad, aceptación, contrato, pago ni intención de compra.
Las propuestas utilizan productos y precios disponibles en el catálogo cargado. Si falta un importe o la fuente es contradictoria, la persona debe confirmar el dato; Cerravi no inventa la cifra. MXN, USD y otras monedas permanecen separadas mientras no exista una conversión aprobada.
Forecast es una estimación operativa basada en reglas transparentes y datos registrados en el CRM. No es un modelo predictivo entrenado o calibrado y no garantiza cierres ni ingresos. Cerravi ayuda a localizar contexto y faltantes; la empresa conserva responsabilidad sobre origen, acceso, corrección, decisión y requisitos aplicables.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Hay que limpiar todo el CRM antes de usar un AI Sales Copilot?
No. Conviene definir primero un caso de uso y preparar los campos, relaciones, fuentes y permisos que necesita. La organización debe conocer las limitaciones restantes y bloquear o advertir cuando un dato crítico no cumple el umbral acordado.
¿Qué campos del CRM son indispensables para empezar?
Depende del escenario. Para resumir una oportunidad suelen ser útiles cuenta, contactos, responsable, etapa, actividad reciente, acuerdos y siguiente paso. Para una propuesta también hacen falta productos, precios, moneda, vigencia y condiciones procedentes de una fuente autorizada.
¿Cómo debe tratar el copiloto un dato faltante?
Debe conservarlo como faltante y aplicar la regla definida: mostrar una advertencia, pedir confirmación, entregar un borrador incompleto o abstenerse. No debe sustituirlo por cero, una opción probable o una cifra inventada.
¿Qué métricas sirven para evaluar la calidad de datos?
Completitud, validez, consistencia, unicidad, actualidad y trazabilidad son dimensiones frecuentes. Deben medirse por campo y escenario, con población, periodo, umbral, responsable y acción; un promedio general puede ocultar un dato crítico incorrecto.
¿Los datos del CRM pueden utilizarse sin revisar permisos?
No. El acceso efectivo del copiloto debe respetar el alcance de cada usuario y la finalidad autorizada. También deben revisarse grupos, cuentas de servicio, integraciones, enlaces, registros, exportaciones y revocación.