Detectar churn con datos dispersos en CRM

La frase "no sabemos qué clientes estamos perdiendo" es mucho más común de lo que parece. No porque la empresa no tenga datos, sino porque los tiene en tres sistemas que nunca se han juntado: CRM (contratos, contactos, histórico comercial), soporte (tickets, tiempos de resolución, sentimiento) y producto (actividad, features usadas, integraciones). Este post es sobre cómo pasar de "datos dispersos" a un scoring de riesgo semanal sin montar una catedral.

El problema real: no es el modelo, es la identidad del cliente

El primer obstáculo cuando se empieza a explorar churn con datos dispersos no es el machine learning, es la ausencia de una clave común. El CRM tiene el cliente por ID contrato, soporte lo identifica por email del remitente del ticket y producto lo conoce por user_id asignado al crear cuenta. Cruzar los tres sistemas requiere resolver tres cosas antes de pensar en un modelo:

• Resolución de identidad (customer resolution): qué email del ticket corresponde a qué user_id del producto y a qué cuenta del CRM.
• Ventana temporal unificada: las métricas de cada sistema vienen con granularidades diferentes (CRM mensual, soporte por evento, producto diario) y hay que agregarlas a la misma frecuencia.
• Definición operativa de churn: para SaaS suele ser "no renovó en los últimos 30 días tras fin de contrato", para pyme transaccional "no ha comprado en N semanas comparado con su histórico".

Arquitectura mínima viable

Para la primera iteración no necesitas un lakehouse completo. La arquitectura más barata que funciona en pyme tiene estos componentes:

1. 1Capa de ingesta: Fivetran (fiable, 120 USD/mes arranque), Airbyte (auto-alojado, gratis) o scripts Python con Cloud Scheduler para cargas simples.
2. 2Capa de almacenamiento: BigQuery, Snowflake o incluso Postgres para volúmenes bajos. Tres fact tables: fact_account, fact_usage, fact_interactions.
3. 3Tabla de resolución de identidad: dim_customer con mappings crm_id ↔ support_email ↔ product_user_id. Se alimenta con reglas (matching por email normalizado, dominio corporativo, etc.).
4. 4Capa de features: vistas dbt que agregan las tres fact tables por cliente/semana, calculando métricas como días desde último login, tickets abiertos en últimas 4 semanas, etc.
5. 5Capa de modelo: notebook o script Python con scikit-learn entrenando regresión logística. Output es un score 0-1 por cliente.
6. 6Capa de acción: ese score se devuelve al CRM (Salesforce, HubSpot, Pipedrive) vía API para que el account manager lo vea junto al cliente.

Coste total de infraestructura para una pyme con 500-5.000 cuentas activas: 200-600 €/mes. Tiempo de montaje: 6-8 semanas si se parte de cero.

Features que pesan más en B2B

La experiencia acumulada en proyectos reales indica que estas 10-15 variables cubren el 80% del valor predictivo en modelos de churn B2B:

Las features demográficas son las menos predictivas. Si tienes que elegir 5 variables para un primer modelo, empieza por uso de producto y soporte.

Un modelo simple que funciona: regresión logística

Para la primera iteración, una regresión logística con 10-15 features da típicamente AUC de 0,75-0,85 en B2B SaaS. Ventajas frente a XGBoost o deep learning en esta fase:

• Interpretable: puedes explicar al equipo comercial por qué un cliente tiene score alto.
• Robusto con pocos datos: funciona bien a partir de 500-1.000 ejemplos de cada clase.
• Barato de entrenar y desplegar: corre en cualquier servidor sin GPU.
• El incremento de precisión de XGBoost (típicamente 3-5 puntos AUC) no compensa la pérdida de interpretabilidad en la primera fase.

Cuando el modelo de regresión está estable y el equipo comercial ya lo usa a diario, tiene sentido evaluar el paso a XGBoost o LightGBM para ganar precisión. Antes no.

Cómo convertir el scoring en acción operativa

El modelo no entrega valor solo por existir. Necesita un playbook de retención que defina qué hacer según el nivel de riesgo:

Sin este playbook, el equipo comercial ve un score en el CRM y no sabe qué hacer con él. La tasa de uso del modelo se hunde en 4-6 semanas. Las empresas que consiguen retornos reales con churn prediction son siempre las que invierten tiempo en diseñar el playbook antes que en refinar el modelo.

Qué NO hacer en la primera iteración

• Montar un data lake completo con Databricks o Snowflake Horizon si no tienes equipo data de al menos 2 personas.
• Empezar con deep learning o modelos de caja negra antes de haber validado que los datos están limpios.
• Construir dashboards antes del modelo: sin clasificación no hay acción priorizada.
• Querer predicción individual exacta: el valor está en la priorización relativa, no en "este cliente churn al 82,3%".
• Pretender integrar los tres sistemas en un MDM formal (Informatica, Stibo) como prerrequisito: es sobredimensionado para una primera iteración.

Cuándo invertir en arquitectura más sólida

Las señales de que has superado la arquitectura mínima y necesitas profesionalizarla:

• El modelo está en producción y lo consumen dos o más equipos (comercial, producto, marketing).
• La frecuencia de actualización pasa de semanal a diaria.
• Hay SLA comprometido con negocio (ej. "el score está actualizado antes de las 9:00 cada día").
• Empiezan a sumarse casos de uso vecinos (upsell propensity, lead scoring) que pueden reutilizar la misma infraestructura.

En ese punto tiene sentido evaluar una plataforma de datos real con dbt + orchestrator (Airflow, Dagster) + MLOps mínimo (MLflow, Weights & Biases). Ese salto típicamente duplica la infraestructura mensual pero habilita que el modelo de churn se convierta en un activo transversal.

Preguntas frecuentes

¿Cuánto tarda en empezar a dar resultados?

Desde arranque del proyecto hasta primer scoring operativo: 6-8 semanas con un consultor senior dedicado. Resultados medibles en retención (variación del churn rate): 3-6 meses, porque requiere ciclo completo de playbooks ejecutados y clientes salvados.

¿Qué pasa si tengo pocos datos históricos de churn?

Con menos de 100 casos de churn confirmados en los últimos 12 meses, un modelo supervisado no será fiable. En esa situación se puede empezar con un scoring por reglas (basado en umbrales sobre las features más obvias: sin login 30 días + ticket crítico abierto + renovación próxima) y acumular datos durante 6-12 meses antes de pasar a un modelo estadístico.