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 tienes el modelo que vale: el reequilibrado, que caza a 7 de cada 10 de los 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

Hasta ahora has trabajado con socios de los que ya sabías si renovaron: te servían para entrenar y para medir. Pero la lista que quiere Marisol es sobre los socios activos de HOY, de los que todavía no sabemos si renovarán. Entrenas el modelo reequilibrado con toda la tabla de modelado, lo aplicas a los 13.500 socios de hoy para obtener su probabilidad de no renovar, y los ordenas de mayor a menor. Los primeros son los que fidelización debe llamar primero. Esa es la lista. Y como el umbral es una palanca, le das a Marisol no un número cerrado, sino la lista ordenada: ella decide cuántos de los primeros N llama según las manos que tenga.

## 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: una barra con la accuracy al lado del recall del modelo normal, para que se vea de un golpe que acertaba mucho en global y casi nada sobre los que se iban. El segundo compara los dos modelos —normal y reequilibrado— sobre la cifra que importa: cuántos de los que no renuevan coge cada uno. Y el tercero es la curva precision-recall con el punto del umbral elegido, para enseñar la palanca. 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 y que el modelo bueno es el que caza a los pocos que importan. 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 ahora me hablas de reequilibrar no sé qué.» Y tú ya sabes contestar: «El 90% era un espejismo. Como solo el 10% no renueva, el modelo acertaba diciendo "renuevan todos" y se dejaba fuera justo a los que se iban. Reequilibrado, coge a 7 de cada 10 de los que no renuevan. Y podéis decidir cuánto apretar: si no queréis dejaros a nadie, bajamos el corte y la lista crece, pero haréis más llamadas a socios que igual renovaban. Eso lo decidís vosotros.» 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 con qué umbral.