Qué necesitan de tus datos las funciones de IA de un CRM

La IA dentro de un CRM llega en dos familias con fallos distintos. Las funciones predictivas, como el scoring de leads y de oportunidades, necesitan volúmenes documentados de histórico etiquetado. Salesforce pide 1.000 leads y 120 conversiones, Microsoft 40 leads cualificados y 40 descartados, Zoho 200 registros que encajen. Las generativas necesitan recuperación y permisos.

Puntos clave

• Einstein Lead Scoring pide al menos 1.000 leads creados en los últimos 200 días, de los cuales 120 se hayan convertido en cuenta y contacto.
• Dynamics 365 Sales exige al menos 40 leads cualificados y 40 descartados creados y cerrados dentro de la ventana de entrenamiento, y 40 oportunidades ganadas y 40 perdidas para el scoring de oportunidades.
• Zia Field Prediction necesita al menos 200 registros que cumplan los criterios de entrenamiento y se reentrena cada quince días.
• Cuando la organización tiene poco histórico, Salesforce puntúa oportunidades con un modelo global construido con datos anónimos de muchos clientes, y cambia al propio cuando este rinde mejor.
• El scoring predictivo de HubSpot es una función Enterprise y estima la probabilidad de que un contacto abierto cierre en 90 días.

Qué son realmente las funciones de IA de un CRM

Bajo una sola etiqueta se venden dos tecnologías. La primera es predicción clásica: scoring de leads y oportunidades, predicción de campos, detección de anomalías. Aprende de resultados etiquetados en tus propios registros y devuelve un número.

La segunda es generativa: resúmenes de llamadas y correos, borradores de respuesta, siguiente mejor acción en formato narrativo, chat sobre tus registros. No aprende de ti en tiempo de ejecución: recupera contexto y escribe texto.

Las dos fallan de forma opuesta. Un modelo predictivo falla en silencio, ordenando por una señal que ya no describe tu embudo, y nadie lo nota en un trimestre. Una función generativa falla en voz alta, en una frase que alguien puede leer, y por eso se detecta antes. Esa diferencia decide cuál se activa primero y cómo se evalúa un modelo de lenguaje en producción.

Los umbrales de datos que publican las plataformas

Lo útil es que los mínimos están documentados. Salesforce indica que Einstein Lead Scoring necesita al menos 1.000 leads creados en los últimos 200 días, con al menos 120 convertidos en cuenta y contacto. El requisito se aplica a cada segmento configurado, no al conjunto de la organización.

Microsoft indica que el scoring predictivo de leads en Dynamics 365 Sales exige al menos 40 leads cualificados y 40 descartados, creados y cerrados dentro de la ventana de entrenamiento. Esa ventana se elige entre tres meses y dos años. El scoring de oportunidades pide 40 ganadas y 40 perdidas de los dos últimos años.

Zoho indica que Zia Field Prediction solo funciona con al menos 200 registros que cumplan los criterios de entrenamiento, necesita unas 24 horas antes de predecir y se reentrena cada quince días. HubSpot sitúa el scoring predictivo en sus planes Enterprise y define la salida como la probabilidad de que un contacto abierto se convierta en cliente en 90 días.

El coste de entrada publicado del scoring de leads está en un rango comparable. Salesforce Einstein pide 1.000 leads y 120 conversiones en 200 días, Microsoft Dynamics 365 Sales 40 cualificados y 40 descartados, y Zoho Zia 200 registros coincidentes (Salesforce Help, Microsoft Learn, Zoho CRM Help).

Qué hace cada plataforma si no llegas al mínimo

Esta es la pregunta que separa un despliegue real de una demo. Las tres respuestas publicadas son distintas y cada una tiene su consecuencia.

Zoho se niega. Por debajo de 200 registros coincidentes, la página de predicción muestra un estado de espera y el usuario recibe un aviso de que no se pudo predecir por falta de registros. Microsoft califica: el modelo informa de un estado de disponibilidad derivado de un área bajo la curva. Por debajo del umbral se marca como no listo para publicar, y aun así permite publicarlo a mano.

Salesforce sustituye. Su documentación indica que, sin datos suficientes de oportunidades, Einstein usa un modelo global construido con datos anónimos de muchos clientes. Pasa al modelo propio cuando este da mejores resultados. Es una decisión razonable de ingeniería y a la vez un riesgo de reporting.

Salesforce documenta que Einstein Opportunity Scoring recurre a un modelo global cuando la organización tiene poco histórico propio. Ese modelo usa datos anónimos de muchos clientes, y Einstein adopta el del cliente en cuanto rinde mejor (Salesforce Help).

Una puntuación salida de un modelo global es machine learning real que no describe tu pipeline. Puede seguir siendo útil. No se puede presentar en un consejo como evidencia sobre tu embudo, que es la misma distinción que gobierna el reporting de medición de marketing.

Los resúmenes y los borradores dependen de otra cosa

Las funciones generativas no necesitan resultados etiquetados. Necesitan recuperación, permisos y trazabilidad. Salesforce describe su Einstein Trust Layer como una capa que fundamenta los prompts en tiempo de ejecución según el acceso de cada usuario y enmascara campos sensibles antes de que el prompt salga. También declara acuerdos de retención cero con los proveedores de modelos externos.

Esa arquitectura responde a la pregunta de seguridad y deja abierta la de calidad. Un resumen de llamada vale lo que valgan las llamadas registradas. Una sugerencia de siguiente paso construida sobre el histórico de actividad se queda vacía cuando esa actividad vive en el correo de alguien. Es el patrón que apareció en la primera oleada de despliegues generativos en producción: el modelo casi nunca era la restricción.

Los fallos de datos que sobreviven a cualquier modelo

Cinco condiciones rompen la IA de un CRM con independencia de la plataforma. Cada una golpea a una función concreta:

• Cuentas y contactos duplicados. El histórico se parte entre registros, así que el scoring y el resumen ven media relación.
• El estado del lead usado como marca de flujo. Si “cualificado” significa “asignado a un comercial”, la etiqueta con la que entrena el modelo no es un resultado.
• Cerrado-perdido sin motivo codificado. La clase negativa existe pero no aporta información, que es justo lo que necesita un clasificador.
• Actividad fuera del CRM. Los correos y las llamadas que no se registran retiran del modelo las señales de interacción más fuertes.
• Texto libre donde debería haber lista. Doce formas de escribir el mismo sector se convierten en doce categorías sin volumen.

Ninguno es un problema de IA. Son problemas de proceso que la IA vuelve visibles y caros, y de ahí el argumento para tratarlo como un proyecto de operaciones y no como una compra de tecnología.

Cómo evaluar la promesa de un proveedor

Conviene hacer cuatro preguntas, y esperar que las cuatro se respondan desde la documentación y no desde una llamada.

Primera: cuál es el mínimo publicado, en registros y en ventana temporal. Todas las plataformas anteriores lo indican. Segunda: qué hace la función cuando no se alcanza ese mínimo, si se niega, si degrada o si sustituye por otra población. Tercera: qué datos lee y si aplica permisos a nivel de registro en el momento de construir el prompt. Cuarta: qué métrica de evaluación se expone al administrador y si puede seguirse en el tiempo.

Un número de precisión sin la población sobre la que se calculó no es una afirmación verificable. Un estado de disponibilidad inspeccionable, como el que expone Dynamics, vale más que un porcentaje en una diapositiva.

Qué medir después de activarlo

Conviene reservar un grupo de control. Deja una parte de los leads sin puntuar o sin enrutar durante un periodo fijo y compara la conversión entre los dos grupos. Sin control, la adopción de la función y la mejora del embudo son indistinguibles.

Después toca revisar la calibración cada mes: agrupa los registros puntuados en deciles y compara el orden previsto con lo que cerró de verdad. Un modelo que ordena bien el primer decil y mal el resto sigue sirviendo, pero solo para enrutar ese primer decil.

Y conviene tratar la puntuación de personas como actividad regulada cuando decide algo. Según el Reglamento (UE) 2016/679, una persona tiene derecho a no ser objeto de una decisión basada únicamente en el tratamiento automatizado que produzca efectos jurídicos o le afecte de modo similar. Para operaciones con la UE, eso convive con el calendario de cumplimiento del Reglamento de IA.

El Reglamento (UE) 2016/679 se publicó en el Diario Oficial el 4 de mayo de 2016. Protege a las personas frente a decisiones basadas únicamente en el tratamiento automatizado, incluida la elaboración de perfiles, que produzcan efectos jurídicos o les afecten de modo similar (EUR-Lex).

Preguntas frecuentes