Cómo automatizar altas, bajas y cambios de alumnos

Cuando solo se actualiza una herramienta, aparecen los errores

En muchos centros, la matrícula está en una aplicación y el acceso al campus en otra. La facturación puede llevarse en un tercer sistema. Mientras tanto, las solicitudes llegan por varios canales: correo o formulario, pero también teléfono o WhatsApp. Cuando un alumno pide un cambio, alguien tiene que saber qué herramientas toca actualizar.

Los errores aparecen cuando solo se actualiza una parte. Un cambio de grupo puede dejar asociada la cuota del grupo anterior. Una baja puede quedar registrada mientras el campus sigue abierto. También puede ocurrir lo contrario: retirar el acceso antes de la fecha acordada o generar un recibo que ya no correspondía. Son fallos pequeños en apariencia, pero obligan al equipo a revisar después varias herramientas para corregirlos.

Por eso, cambiar una ficha no basta. Hay que saber qué ha pedido el alumno y desde cuándo debe aplicarse. Después se actualizan únicamente las herramientas afectadas.

La guía sobre automatización para academias y centros de formación cubre todo el recorrido del alumno. Aquí nos centramos en las altas, bajas y cambios administrativos una vez iniciada la relación con el centro.

Matrícula, cobro, grupo y acceso no siempre cambian a la vez

Un único estado no sirve para describir todo lo que ocurre con un alumno. La matrícula puede seguir activa mientras cambia el grupo. El cobro puede tener otra fecha y el acceso depender de condiciones diferentes. Por eso es mejor guardar cada situación por separado y evitar etiquetas genéricas como «activo» o «baja» cuando no explican qué ha pasado realmente.

Estas situaciones no siempre cambian a la vez. Un alumno puede seguir matriculado y pasar a otro grupo. También puede terminar las clases presenciales y conservar temporalmente el acceso al campus. Incluso después de la baja puede quedar una cuota pendiente. Si todo se resume en un único estado, el equipo pierde precisamente el detalle que necesita para saber qué hacer después.

Moodle distingue, por ejemplo, entre una inscripción activa y una suspendida. Suspenderla puede bloquear el acceso sin borrar la inscripción. Es un buen ejemplo de por qué matrícula y acceso deben tratarse como datos diferentes. Cada centro puede resolverlo de otra manera.

Con las suscripciones ocurre algo parecido. En Stripe, el estado de la suscripción y el del pago pueden cambiar por separado. La aplicación que da acceso al servicio tiene que consultar esos cambios y actuar según las reglas definidas por el centro. Un pago fallido, por ejemplo, no implica necesariamente que el acceso deba retirarse en ese mismo instante: depende de cómo esté configurado el servicio.

La fecha de la solicitud y la fecha del cambio pueden ser distintas

Una baja solicitada hoy puede tener efecto a final de mes. Un cambio de grupo puede empezar el lunes siguiente. También puede haber altas con una fecha futura. Si se usa la fecha del mensaje como si fuera siempre la fecha efectiva, es fácil cobrar una cuota incorrecta o modificar el acceso antes de tiempo.

Cuando las fechas importan, merece la pena distinguir estos cuatro momentos:

• Solicitud: cuándo llega la petición.
• Validación: cuándo se comprueba que el cambio puede hacerse y en qué condiciones.
• Fecha efectiva: desde cuándo debe aplicarse realmente.
• Confirmación: cuándo se comprueba que las aplicaciones afectadas reflejan la nueva situación.

No hace falta crear cuatro campos para todos los casos. Basta con guardar las fechas que sean necesarias. Una baja prevista para final de mes puede registrarse hoy y seguir activa hasta el día acordado.

Con esa fecha guardada, las acciones pueden programarse para el momento correcto. El cobro siguiente se detiene cuando corresponda y el acceso se modifica en la fecha prevista. Después se comprueba que el cambio se haya aplicado. Así una solicitud recibida hoy puede quedar preparada sin adelantar cambios que el alumno ha pedido para dentro de varios días.

Ejemplo: un alumno pide la baja el 20 de mayo para terminar a final de mes

«Quiero darme de baja al acabar mayo» parece una petición sencilla. Antes de hacer cambios, alguien debe comprobar qué condiciones se aplican a ese alumno y qué fecha debe utilizarse.

La automatización puede localizar la matrícula a partir de la solicitud y extraer la fecha indicada. Con esos datos se prepara la baja para que se aplique en las herramientas que correspondan. Si las condiciones de baja ya están definidas, se pueden comprobar antes de programar nada. Si falta información, la solicitud queda pendiente hasta que una persona la revise.

1. Registrar que la solicitud llegó el 20 de mayo.
2. Comprobar las condiciones de baja aplicables a ese alumno y servicio.
3. Fijar el 31 de mayo como fecha prevista si la solicitud cumple esas condiciones.
4. Evitar que se genere un cobro posterior si ya no corresponde.
5. Mantener matrícula, grupo y acceso hasta la fecha que corresponda.
6. Actualizar los sistemas afectados cuando llegue el momento.
7. Comprobar que no queda una cuota futura, un grupo activo o un acceso abierto por error.
8. Confirmar al alumno qué se ha realizado.

Dar de baja a un alumno no significa cortar todo en el mismo momento. El acceso puede mantenerse hasta final del periodo pagado. También puede existir un preaviso o una condición específica del servicio. Esas reglas deben estar definidas antes de automatizar nada.

Cambiar de presencial a online puede afectar a más cosas que el grupo

También hay cambios que no implican una baja. Un alumno puede seguir en el mismo curso y pedir que, a partir del mes siguiente, su modalidad pase de presencial a online.

Antes de aplicarlo hay que comprobar qué cambia realmente. Puede variar el grupo o el precio. Quizá también haya que activar otro acceso al campus. Si la modalidad online requiere una plaza o unas condiciones distintas, eso se revisa antes de modificar la ficha. También puede ocurrir que el método de pago y la fecha de renovación sigan exactamente igual, por lo que no tendría sentido tocar esos datos.

Una actualización de grupo no basta si el cambio afecta a otras herramientas. Si cambia la tarifa, el cobro tendrá que reflejarla desde la fecha acordada. Si hace falta otro acceso, se activa cuando corresponda. Y si el cambio de grupo requiere aprobación académica, se espera esa decisión antes de seguir.

La guía sobre horarios, cambios de grupo y recuperaciones explica cómo gestionar plazas y compatibilidades. Aquí nos interesa qué ocurre después, cuando el cambio ya está aprobado y hay que actualizar el resto de la gestión.

Qué conviene registrar cuando cambia la situación de un alumno

Cuando un cambio afecta a varias herramientas, conviene dejar un registro que permita saber después qué se hizo. No hace falta copiar el mismo correo en todas partes. Sí debe quedar claro quién pidió el cambio, desde qué fecha se aplicaba y qué se terminó modificando. También interesa saber si alguna parte quedó pendiente, porque esa información evita volver a revisar toda la conversación cuando aparece una duda semanas después.

Ese registro cobra importancia cuando el alumno pregunta semanas después por un cobro o por un acceso que ya no tiene. Si solo se conserva la situación actual, una persona del equipo tiene que volver al correo y comparar fechas para saber qué ocurrió.

• Alumno: identificador suficiente para saber a qué matrícula pertenece la solicitud.
• Solicitud: qué pidió realmente y por qué canal llegó.
• Situación anterior: grupo, modalidad, producto o acceso que tenía antes cuando sea relevante.
• Cambio aprobado: qué debe modificarse y qué debe mantenerse.
• Fecha: desde cuándo debe aplicarse el cambio.
• Acciones realizadas: qué sistemas se actualizaron y con qué resultado.
• Revisión: qué persona intervino cuando el caso necesitó una decisión o excepción.

No todos los cambios necesitan el mismo nivel de detalle. Para corregir un email bastarán pocos datos. Una baja que afecta a cobros o accesos necesita dejar más información registrada.

Los documentos que justifican el cambio tampoco tienen que duplicarse en cada aplicación. Si existe un formulario o un correo relevante, puede guardarse una referencia para que el equipo pueda consultarlo cuando haga falta.

Cada cambio afecta a unas herramientas concretas

No todas las aplicaciones necesitan recibir cada cambio. Antes de conectar nada, hay que decidir dónde se guarda cada dato y qué otras herramientas necesitan actualizarse.

Un cambio de email puede quedarse en el CRM y en la herramienta de comunicaciones. Un cambio de grupo quizá afecte también al campus, pero no a facturación si el precio es el mismo. Una baja suele tener más efectos, y algunos pueden aplicarse en fechas distintas. Definir estas dependencias de antemano evita que cada solicitud obligue a decidir de nuevo qué aplicaciones hay que tocar.

Conectar todas las herramientas entre sí suele añadir más problemas de los que resuelve. Es preferible decidir qué sistema mantiene cada dato y actualizar únicamente las aplicaciones que lo necesitan.

Comprobar el cambio antes de darlo por cerrado

Un cambio puede quedar bien en una herramienta y mal en otra. Por ejemplo, el siguiente cobro puede haberse cancelado mientras el acceso sigue activo. También puede haberse cambiado el grupo y seguir apareciendo el contenido del anterior.

Después de aplicar el cambio hay que leer de nuevo los datos relevantes. El caso se cierra solo cuando las herramientas implicadas reflejan la situación prevista.

Estas comprobaciones también sirven para medir si la automatización está funcionando. Los indicadores de automatización de procesos pueden adaptarse para revisar cuánto tarda cada cambio y cuántos casos necesitan corrección manual.

También hay que prever los cambios que quedan a medias. Si la matrícula se actualiza pero la herramienta de cobro falla, no debería enviarse un mensaje diciendo que todo está resuelto. La solicitud puede quedar abierta hasta completar la parte pendiente. Esto evita una situación bastante habitual: el alumno recibe una confirmación y días después descubre que todavía aparece un cobro o un acceso antiguo.

El mensaje final debe contar únicamente lo que afecta al alumno. Puede indicar desde qué fecha se aplica el cambio y cuál será su nueva modalidad. Cuando sea relevante, también puede aclarar la última cuota o hasta cuándo conservará el acceso.

Casos que necesitan revisión antes de continuar

No todas las solicitudes deberían ejecutarse automáticamente. Cuando faltan datos o hay una decisión que no está definida por una regla, el caso debe quedar pendiente de revisión.

La persona que revise el caso debería recibir ya al alumno identificado y la solicitud localizada. Así puede centrarse en resolver la duda concreta en lugar de reconstruir todo el caso.

Cada herramienta debe recibir solo los datos que necesita

Los centros educativos trabajan con datos personales de alumnos y, en algunos casos, también de familias o responsables de pago. La guía de la AEPD para centros educativos insiste en limitar el tratamiento a la información necesaria y controlar quién puede acceder a ella.

Un dato no tiene por qué copiarse a todas las aplicaciones. El email usado para facturación puede no hacer falta en el campus virtual. Y un dato académico puede requerir permisos distintos a los de un dato de contacto.

Si se utiliza IA para leer una solicitud, debería enviarse solo la información necesaria para esa tarea. También hay que revisar qué proveedor se usa y bajo qué condiciones trata los datos. Enviar el expediente completo por defecto no tiene sentido si basta con el mensaje del alumno y unos pocos datos de su matrícula.

Un primer piloto puede empezar por pocos tipos de cambio

Para un primer piloto basta con elegir unos pocos cambios frecuentes y trabajar con las aplicaciones imprescindibles. Una baja a final de mes o un cambio de modalidad son buenos ejemplos si el centro tiene reglas claras para gestionarlos.

1. Elegir los tipos de solicitud que se repiten con frecuencia.
2. Documentar qué condiciones debe comprobar administración en cada uno.
3. Definir desde cuándo debe aplicarse cada cambio.
4. Identificar qué aplicaciones se ven afectadas.
5. Automatizar primero lectura, clasificación, extracción de datos y preparación.
6. Mantener aprobación humana en casos económicos, académicos o ambiguos.
7. Añadir actualizaciones automáticas solo en casos suficientemente claros.
8. Comprobar siempre el resultado después de escribir en los sistemas.
9. Medir errores, tiempo de gestión y casos que vuelven a abrirse.

Al principio puede mantenerse una revisión antes de ejecutar el cambio. La solicitud llega ya clasificada y con el alumno identificado. La persona responsable comprueba los datos y aprueba la actualización. De esta forma se puede comprobar durante unas semanas si las fechas se interpretan bien y si las herramientas reciben los cambios correctos. Cuando esos casos son repetitivos y las reglas están claras, algunos pueden ejecutarse automáticamente.

El piloto debe demostrar algo muy concreto: que una solicitud termina aplicada correctamente en todas las herramientas implicadas. Si una baja deja la matrícula, el cobro y el acceso como estaban previstos, ya existe una base razonable para ampliar el proyecto. Si cada semana aparecen excepciones nuevas o hay que corregir los mismos fallos manualmente, todavía no es momento de ampliar.

Durante las primeras semanas merece la pena anotar qué solicitudes generan más dudas. A veces el problema está en mensajes demasiado ambiguos. Otras veces faltan reglas internas claras. Detectarlo ayuda a mejorar los formularios y las respuestas que recibe el alumno.

Cuando el piloto funcione bien, es mejor ampliar por tipo de solicitud. Automatizar todas las bajas que siguen una misma regla es más controlable que mezclar en un solo flujo bajas, devoluciones especiales y cambios académicos.

Preguntas frecuentes sobre automatizar altas, bajas y cambios de alumnos