El algoritmo en Python que hice para conseguir cita en el SEPE

Uno de los proyectos mas curiosos que he construido fue un algoritmo en Python para ayudar a conseguir cita previa en el SEPE. No era una app bonita, ni un SaaS, ni una automatizacion con una arquitectura enorme. Era algo mucho mas simple: un bot de escritorio pensado para resolver una friccion muy real.

El problema era claro. Muchas personas necesitaban una cita presencial o telefonica, pero el sistema mostraba constantemente que no habia disponibilidad. En ese contexto empezaron a aparecer grupos y personas que revendian citas publicas. Mi idea fue justo la contraria: crear una herramienta gratuita y sencilla que ayudara a detectar ventanas de disponibilidad sin tener que estar haciendo clics manualmente durante horas.

El proyecto termino teniendo bastante recorrido: publique el codigo en GitHub, lo comparti desde thePalms y acabo apareciendo en El Lado del Mal, el blog de Chema Alonso, dentro de un articulo sobre como conseguir cita en el SEPE sin caer en mafias.

El problema tecnico

El cuello de botella no era solo que la web fuera lenta o que hubiera que repetir clics. Al principio, para comprobar si aparecian nuevas citas, parecia necesario recargar la pagina y volver a introducir todos los datos personales desde cero.

Probando el flujo encontre un comportamiento curioso, casi un bug de estado: si alternabas entre las opciones Presencial y Telefonica, el sistema refrescaba los resultados de disponibilidad sin obligarte a recargar toda la pagina ni a volver a escribir los datos personales. Ese fue el punto clave. El nuevo metodo no consistia en reiniciar el formulario, sino en alternar entre esos dos botones hasta que apareciera una cita disponible.

Esa clase de tarea tiene tres caracteristicas muy concretas:

1. Es repetitiva.
2. Depende de conservar el estado del formulario.
3. Necesita que una persona intervenga cuando aparece una oportunidad real.

Por eso no plantee el bot como un sistema que completara todo el proceso de principio a fin. Lo plantee como una ayuda: automatizar los clics repetitivos y dejar la decision final en manos del usuario.

Por que use Python y PyAutoGUI

La solucion tenia que ser facil de ejecutar por gente no tecnica. Por eso use Python con PyAutoGUI y keyboard. No necesitaba una integracion profunda con el backend del SEPE ni un scraper complejo. Necesitaba controlar el raton, registrar posiciones y repetir una secuencia.

La logica era bastante directa:

• El usuario abre el portal, introduce sus datos y llega manualmente al punto donde aparecen las opciones Presencial y Telefonica.
• El script registra las posiciones de esos botones cuando el usuario pulsa Enter.
• Cuando el usuario pulsa Esc, termina la grabacion.
• Tras una pequena cuenta atras, el bot alterna esos clics en bucle para forzar el refresco de disponibilidad sin reiniciar el formulario.
• Si el usuario detecta disponibilidad o quiere parar, pulsa Esc.

Esta arquitectura tiene una ventaja importante: no depende de selectores HTML fragiles ni de cambios pequenos en el DOM. Al trabajar sobre coordenadas de pantalla, se comporta como una automatizacion RPA ligera.

La parte mas importante: no automatizar lo que no debes

Una decision clave fue no automatizar datos personales, captchas ni confirmaciones finales. Los datos los introducia la persona una vez, de forma manual, y el bot solo aprovechaba el comportamiento de alternar entre Presencial y Telefonica para refrescar resultados. La herramienta ayudaba con la parte repetitiva, pero no intentaba saltarse controles ni reservar citas de forma masiva.

Esto para mi era fundamental. Cuando automatizas un servicio publico, el limite etico importa mucho. El objetivo no era crear ventaja injusta ni saturar el sistema. Era reducir una friccion absurda para personas que ya estaban intentando acceder a un servicio al que tenian derecho.

Por eso el proyecto siempre lo entendi como una herramienta de asistencia, no como una herramienta de explotacion.

Que lo hizo interesante

Tecnologicamente, el proyecto no era complejo en el sentido academico. No habia modelos de IA, infraestructura cloud ni arquitectura distribuida. Pero era interesante porque resolvia bien una tarea concreta.

Lo que funciono fue:

• Simplicidad: cualquiera podia entender la idea.
• Hallazgo de producto: el valor estaba en encontrar que alternar canales refrescaba resultados sin perder el formulario.
• Bajo coste: no necesitaba servidores ni APIs.
• Control humano: el usuario seguia tomando la decision final.
• Adaptabilidad: se podia usar en otros formularios o portales lentos.
• Impacto social: atacaba un problema que afectaba a personas reales.

Ese tipo de proyecto me enseño algo que sigo aplicando en automatizacion: a veces el mejor software no es el mas sofisticado, sino el que reduce una carga repetitiva en el punto exacto.

Por que tuvo repercusion

Creo que llamo la atencion por dos motivos. Primero, porque el problema del SEPE era muy reconocible: mucha gente habia sufrido la misma frustracion. Segundo, porque la solucion era facil de explicar: un script que hace los clics repetitivos por ti y te permite reaccionar cuando aparece una cita.

El articulo de El Lado del Mal contextualizaba justo ese escenario: la dificultad para conseguir cita previa, el metodo de alternar entre canales para refrescar la disponibilidad sin rehacer todo el formulario y el uso de automatizacion para evitar depender de grupos de reventa. Tambien mencionaba que el script original se ofrecia gratis desde thePalms.

Para mi, que un proyecto asi saliera en un medio tecnico fue una confirmacion interesante: no hace falta construir algo enorme para que tenga valor. Si el problema es real, una solucion pequena puede tener mucho alcance.

Lo que aprendi

Este proyecto fue una buena leccion de ingenieria practica:

• Antes de automatizar, hay que entender el flujo humano.
• A veces el descubrimiento importante no esta en el codigo, sino en el comportamiento del producto.
• Una interfaz lenta tambien puede ser una API, si sabes interactuar con ella con cuidado.
• La automatizacion debe tener limites claros.
• La documentacion y el aviso legal importan, especialmente si el codigo es publico.
• Un proyecto pequeño puede comunicar muy bien tu forma de pensar como desarrollador.

Tambien reforzo una idea que despues he usado en proyectos de NexaVision AI: automatizar no significa quitar a la persona del proceso. Muchas veces significa quitarle la parte mas tediosa para que pueda actuar mejor cuando realmente importa.

Si lo hiciera hoy

Si reconstruyera este proyecto hoy, mantendria la misma filosofia, pero mejoraria varias cosas:

• Una interfaz mas clara para usuarios no tecnicos.
• Deteccion visual mas robusta para saber cuando cambia el estado de la pagina.
• Control mas explicito del estado del formulario para saber si los datos siguen cargados.
• Logs locales para entender que ha pasado durante la ejecucion.
• Pausas y limites configurables para evitar patrones agresivos.
• Documentacion mas explicita sobre uso responsable.

Aun asi, no perderia lo esencial: una herramienta pequeña, comprensible y enfocada en ayudar, no en explotar.

Puedes ver el repositorio en GitHub, leer la cobertura en El Lado del Mal o revisar la ficha del SEPE Availability Bot en mi portfolio.