La situación
En un negocio por suscripción, la baja casi nunca avisa. Cuando el cliente pulsa «cancelar», probablemente lo decidió semanas antes, así que la lista que le sirve al equipo no es la de bajas del mes pasado, sino la del mes que viene. Pero hay una dificultad que se ve poco: solo se da de baja un 5 % de los clientes. Con un problema tan raro, un modelo que respondiera «nadie se va» acertaría casi siempre. Y no serviría para nada.
Qué se construyó
Preparamos los datos y construimos variables de uso: accesos, funciones usadas, incidencias abiertas y días desde la última interacción. Comparamos tres modelos con validación temporal, para que ninguno aprendiera del futuro. Cada predicción se explica cliente a cliente, porque quien llama necesita saber por qué llama. Encima va una aplicación web: buscas un cliente y te da su probabilidad de baja, su nivel de riesgo y una acción sugerida.
Qué salió
Elegimos el modelo por F2 y no por precisión, porque perder a un cliente que se va cuesta más que llamar a uno que se iba a quedar. Pasa lo mismo con una alarma de humo: que suene de más molesta un minuto; que no suene cuesta la casa. Con ese criterio, el modelo detecta 84 de cada 100 bajas. Pero el análisis de sensibilidad mostró algo menos obvio: a partir de cierto volumen, el coste de contactar se come el beneficio. Así que la mejora no está en llamar a más gente, sino en elegir mejor a quién.
Elegir la métrica es probablemente la decisión más importante de un proyecto, y por eso en cada implantación la acordamos por escrito antes de tocar nada. Y si las cuentas dicen que no compensa, te lo decimos.
Proyecto propio, con un conjunto de datos público de telecomunicaciones adaptado al escenario. Las variables de uso son sintéticas y el impacto económico es un modelo, no una factura. El código está en GitHub (se abre en una pestaña nueva).