Viernes: que se entienda y se fíen de la lista

## Viernes, 10:00. De un modelo a una lista en la que fiarse

Ya sabes cómo usar el modelo: el normal, el del miércoles, con la lista ordenada por riesgo y cortada donde se acaban las llamadas. En la prueba, con 450 llamadas, caza a 157 de los 329 que se van. Pero un modelo no es un entregable. Lo que fidelización necesita es una lista de nombres ordenada por riesgo, y lo que Teresa necesita es entender en cinco segundos por qué debe fiarse de ella. Hoy haces las dos cosas: puntúas a los socios activos de hoy, montas la lista, preparas las figuras que explican el hallazgo sin jerga, y cierras el repositorio con su README y su requirements. Al acabar, lo que empezó el lunes como seis CSV sucios es un proyecto que podrías subir a tu GitHub.

## Puntuar a los socios de hoy, preparados igual

Hasta ahora has trabajado con socios de los que ya sabías si renovaron: te servían para entrenar y para medir. La lista que quiere Marisol es sobre los socios activos de HOY, de los que todavía no sabemos si renovarán. Antes de puntuarlos, una comprobación que te ahorra un disgusto: ¿los datos de hoy están preparados igual que los de entrenamiento? Aquí no. Los extractos de donaciones, emails y eventos son del ciclo pasado: ninguno de los 13.500 socios de hoy tiene una sola fila, y en socios_hoy_modelo esas columnas salen a 0 para todos. Para el modelo, «0 aperturas» quiere decir «socio desenganchado», no «no tengo el dato».

Si puntúas así, el riesgo medio previsto de hoy sale 0,242, más del doble de la tasa real del ciclo pasado (0,11). Con el modelo reequilibrado el efecto es aún más visible: el 88 % de los socios de hoy pasaría del 0,5, frente al 38 % en la prueba. No es que hoy haya más riesgo: es que has preparado distinto los datos. La regla es la misma preparación para entrenar y para puntuar: el mismo código y las mismas columnas, construidas igual. Hoy eso significa usar solo el perfil del socio (canal, domiciliación, antigüedad, cuota y edad), que sí existe en los dos lados. El riesgo medio previsto vuelve a 0,109, como debe. El precio es que, sin la actividad, el modelo ordena peor: en la prueba, su PR-AUC baja de 0,351 a 0,249, y con 450 llamadas caza 122 en vez de 157. Para recuperarla hay que pedir a Mailchimp, a la pasarela y a eventos la actividad de los socios de hoy y pasarla por el mismo `02_limpiar.py`. Hasta entonces, la lista de hoy se hace con el perfil, y se dice.

Con los datos bien preparados, la lista es sencilla: los 13.500 socios ordenados de mayor a menor riesgo, y cortados en los 2.000 que caben en las llamadas de fidelización. Si el equipo tiene más manos, la lista se alarga; si tiene menos, se acorta. No hace falta reentrenar nada: el corte se mueve solo.

## Las figuras honestas para Teresa

Teresa no quiere ver tu código ni tus matrices. Quiere entender, en cinco segundos, por qué la lista sirve. Así que preparas tres apoyos visuales limpios con matplotlib. El primero enseña por qué el 90% engañaba: la accuracy al lado de lo que cazaba el modelo cortado en 0,5. El segundo es el que cuenta la semana: de los 329 socios de la prueba que no renuevan, a cuántos llega cada forma de elegir a quién llamar con las mismas 450 llamadas: cortar en 0,5 (3), llamar al azar (unos 49) o llamar a los primeros de la lista (157). Y el tercero es la curva precision-recall con el punto de las llamadas que caben. Nada de jerga: cada figura cuenta una frase que Teresa pueda repetir en el patronato.

## Cerrar el repositorio: README y requirements

Lo último es dejar el proyecto listo para que otra persona —o tú mismo dentro de seis meses— pueda abrirlo y entenderlo. Eso son dos ficheros. El `requirements.txt` lista las librerías que usa el proyecto, para que cualquiera pueda instalarlas de un golpe y reproducir tu trabajo. Y el `README.md` es la portada: qué hace el proyecto, cómo se ejecuta (en qué orden van los scripts de `src/`), y —lo más importante— el hallazgo honesto del caso. No es un trámite: es el entregable intelectual, el sitio donde cuentas que el 90% era un espejismo, que el problema era el corte y no el modelo, y que la lista se corta por las llamadas que caben. Un repo sin README es una caja de piezas sin instrucciones.

## 12:00. La demo

En la demo, Teresa va al grano: «¿La lista sirve para que mi equipo llame a quien de verdad se va a caer? Porque me dijeron 90% y luego que no cazaba a nadie.» Y tú ya sabes contestar: «El 90% era un espejismo, y el "no caza a nadie" también. El modelo sabe quién tiene más riesgo; lo que fallaba era pedirle un sí o un no con un corte que no pensaba en vuestras llamadas. Si llamáis al 15 % de más riesgo, que son las 2.000 llamadas que tenéis, en la prueba eso llegó a casi la mitad de los que se iban, tres veces más que llamando al azar. Si tenéis más manos, la lista se alarga. Una advertencia: la lista de hoy va sin la actividad de los socios, porque no la tenemos de este ciclo, y sin ella llega a algo más de un tercio de los que se van, todavía dos veces y media el azar. En cuanto llegue la actividad, mejora. Y para saber cuántos se quedan gracias a la llamada, propongo llamar a una mitad de la lista elegida al azar y comparar con la otra.» Teresa asiente: «Prefiero una lista honesta que un número bonito. Buen trabajo.» El caso cierra cuando tu hallazgo cambia una decisión real: a quién llama fidelización, y hasta dónde.