Cómo automatizar horarios, cambios de grupo y recuperaciones en una academia

Antes de mover nada, hay que saber qué está pidiendo el alumno

Muchas peticiones de horario llegan de forma informal. Un alumno escribe por WhatsApp porque no puede asistir un día. Otro llama para preguntar por un horario diferente. También es habitual que alguien diga que, a partir del mes siguiente, solo puede venir por la tarde. Ninguno de esos mensajes explica por sí solo qué cambio debe hacerse.

Antes de hacer nada hay que aclarar una cuestión sencilla: ¿quiere venir otro día solo esta semana o cambiarse de grupo? En una recuperación sigue perteneciendo a su grupo habitual. Si pide un cambio estable, habrá que fijar desde qué fecha empieza a asistir al nuevo grupo. Si la academia cambia el horario de toda la clase, el tratamiento es distinto porque afecta a todos.

Esta diferencia importa sobre todo cuando el alumno ya tiene un grupo asignado. La asignación inicial de grupo puede partir del nivel y de las opciones que la academia haya validado. Después llegan las situaciones normales del curso: una ausencia, una recuperación o un cambio de horario por motivos personales o laborales. También hay grupos que se llenan o que la academia reorganiza. Todo eso forma parte de la automatización operativa de academias y centros de formación.

Un mensaje como «jueves a las siete» no debería provocar ningún cambio por sí solo. Antes hay que saber si el alumno quiere asistir ese jueves de forma excepcional o dejar de ir a su grupo actual.

Si nadie aclara la petición, un mensaje ambiguo puede acabar cambiando listados o recordatorios que no tocaban. La IA puede servir para interpretar lo que ha escrito el alumno. La plaza y la compatibilidad del grupo se comprueban después en las herramientas que utilice la academia.

Una recuperación de un día no cambia el grupo habitual

Pensemos en una alumna de inglés B1 que va los martes a las 19:00. Una semana no puede asistir y la academia le permite recuperar la clase en otro grupo compatible. Acude el jueves y, la semana siguiente, vuelve a su horario de siempre.

Esa asistencia del jueves debe registrarse como algo puntual. Según el software, puede anotarse como una asistencia autorizada en otro grupo o reservarse una plaza para esa sesión. Lo que no tendría sentido es quitar a la alumna de su grupo del martes y dejarla inscrita de forma permanente en el del jueves.

El error no se queda en la asistencia de ese día. La alumna podría empezar a aparecer en el listado del jueves y dejar de recibir avisos de su grupo habitual. Si los contenidos dependen del grupo, también podría cambiar su acceso por equivocación.

Cada plataforma representa esta situación a su manera. OneRoster, por ejemplo, separa las clases de las inscripciones de alumnos cuando intercambia datos entre un SIS y un LMS. Google Classroom también mantiene de forma explícita qué alumnos pertenecen a cada curso. Esa separación ayuda a no convertir una asistencia de un día en un cambio permanente de grupo.

Cuando las recuperaciones se gestionan a mano, alguien puede anotarlas en WhatsApp o en un calendario y olvidarse de actualizar el lugar donde se controla la asistencia. El profesor del jueves puede no recibir el aviso. La recuperación debe quedar registrada donde haga falta, pero la inscripción habitual del alumno no cambia.

Cuando hay muchas recuperaciones, ya no basta con apuntarlas en la agenda. También hay que saber si queda plaza y asegurarse de que el profesor tenga el listado correcto.

Antes de cambiar de grupo hay varias comprobaciones que hacer

Si el alumno quiere dejar el martes y pasar definitivamente al jueves, hay que comprobar dos cosas antes de confirmarlo: que el grupo sea válido para él y que tenga plaza. Después se fija la fecha desde la que empieza el cambio. La inscripción anterior debe quedar cerrada de forma coherente con esa fecha.

Qué grupos pueden intercambiarse depende de cada academia. El nivel y la modalidad suelen influir, y también pueden hacerlo la sede, el programa o la edad. Aquí partimos de que esos criterios ya están definidos. La automatización no decide qué nivel académico corresponde al alumno.

Después hay que mirar la capacidad. Microsoft Bookings no es un software académico, pero permite fijar un máximo de asistentes en un servicio de grupo. El ejemplo sirve para ilustrar la regla. Si se ha alcanzado el límite, no se puede confirmar otra plaza.

Con esas comprobaciones hechas ya se puede registrar el cambio. Si empieza el día 1 del mes siguiente, las clases anteriores permanecen como estaban. Si empieza de inmediato debe quedar claro cuál será su próxima sesión. También hay que indicar desde cuándo deja de recibir los avisos del grupo anterior.

También debe quedar constancia del grupo anterior. Si meses después hay que revisar una asistencia o una incidencia, se tiene que poder saber en qué grupo estaba inscrito ese día. Una fecha efectiva bien registrada permite hacerlo.

Mover a un alumno no es lo mismo que cambiar el horario de todo el grupo

A veces cambia la clase completa. El grupo de los martes a las 19:00 puede pasar a las 20:00 o cambiar de aula. También puede trasladarse a otro día. En esos casos todos los alumnos del grupo se ven afectados por la misma modificación. La unidad que cambia es el propio grupo.

En este caso se modifica el horario del grupo y después se comunica a quienes están afectados. También habrá que revisar el profesor o el aula si dependen de ese horario. Si un alumno no puede adaptarse, entonces se abre su caso por separado.

Separar los tres casos evita tocar datos que no corresponden. La comunicación también cambia: una recuperación se confirma al alumno, un cambio estable requiere informar del nuevo grupo y un cambio de horario general debe llegar a toda la clase.

La última plaza hay que comprobarla de nuevo antes de confirmar

La disponibilidad puede cambiar mientras se habla con el alumno. Imaginemos que dos personas preguntan por la última plaza del jueves. En la primera consulta ambas pueden verla libre. Si una confirma antes, la otra ya no puede recibir la misma respuesta.

Por eso una plaza que estaba disponible al empezar la conversación debe comprobarse otra vez cuando se vaya a registrar el cambio. Solo después se envía la confirmación definitiva.

El motivo es sencillo: una plaza no puede confirmarse a dos personas. La solución técnica dependerá del software de la academia, pero la regla es la misma: confirmar cuando el cambio ya ha quedado registrado correctamente.

Las APIs educativas también separan la consulta de una modificación. En Google Classroom se puede consultar quién está inscrito en un curso y existen operaciones distintas para añadir o eliminar alumnos. El orden es el mismo: primero se consulta y después se cambia.

La academia debe definir cómo funcionan las recuperaciones

No todas las academias permiten recuperar de la misma manera. Algunas limitan el número de clases. Otras exigen avisar con antelación o solo permiten determinados grupos. Una academia de idiomas tampoco tiene por qué aplicar las mismas condiciones que un centro de música o de refuerzo.

La automatización debe aplicar esas condiciones tal como estén definidas. Por ejemplo, puede revisar si el alumno todavía está dentro del plazo. También puede comprobar si ya ha utilizado las recuperaciones permitidas. Los grupos posibles se buscan únicamente entre los que la academia haya marcado como compatibles. Si el caso se sale de esas reglas, una persona tiene que revisarlo.

Que la IA entienda el motivo del alumno no cambia las condiciones de la academia. Si el plazo ha terminado o esa ausencia no se puede recuperar, la respuesta debe respetar esa norma. La IA puede redactar el mensaje o dejar el caso preparado para que alguien lo revise.

A veces el alumno añade motivos personales para justificar la petición. Esa información puede ayudar a entender el mensaje, pero no debería cambiar automáticamente las condiciones que aplica la academia.

Después de un cambio puede haber que actualizar varias herramientas

Un cambio de grupo puede obligar a actualizar más de una herramienta. El profesor quizá utilice otro listado y el alumno puede necesitar un calendario distinto. Si el acceso a contenidos depende del grupo, también habrá que actualizarlo. Lo mismo ocurre con determinados recordatorios o registros de asistencia.

OneRoster permite intercambiar información de clases e inscripciones entre sistemas educativos. Google Classroom dispone de operaciones para gestionar alumnos de un curso y sincronizar listados con herramientas externas. Moodle permite sincronizar miembros de cohortes con participantes de cursos. Estas opciones sirven como referencia cuando el sistema académico y el LMS comparten información de grupos.

La academia no necesita utilizar ninguno de esos productos. Los ejemplos sirven para entender que cambiar de grupo puede obligar a actualizar varias aplicaciones.

Si la academia utiliza Google Calendar para organizar profesores o aulas, la API permite consultar los periodos ocupados y libres de los calendarios configurados. Ese dato puede servir para comprobar la disponibilidad de un recurso. Por sí solo, el calendario no permite saber si el alumno encaja académicamente en un grupo.

Una vez aprobado el cambio, se actualizan las herramientas que correspondan. El alumno recibe la confirmación cuando esas modificaciones han quedado registradas.

Cuando intervienen varias aplicaciones, hay que saber qué dato se consulta en cada una. El software académico puede guardar el grupo asignado y el LMS controlar el acceso a contenidos. El calendario puede utilizarse para una sesión concreta. La comunicación al alumno puede salir de otra herramienta.

Si el cambio aprobado también afecta a la matrícula o al cobro, la guía sobre altas, bajas y cambios administrativos de alumnos desarrolla esa coordinación entre sistemas.

Un caso completo: primero recupera una clase y después cambia de grupo

Una alumna pertenece al grupo de francés de los martes a las 19:00. El lunes escribe: «Esta semana no puedo ir el martes. ¿Puedo ir el jueves a las siete?».

El mensaje no deja claro si la alumna quiere recuperar una clase o cambiarse definitivamente. Se le pregunta y confirma que solo necesita ir el jueves esa semana. Entonces se consultan los grupos que la academia admite para recuperaciones. Si queda plaza, se registra esa asistencia y se confirma. Su grupo habitual sigue siendo el del martes.

La semana siguiente la misma alumna escribe: «El jueves me viene mucho mejor. ¿Puedo quedarme ya en ese grupo?».

La segunda petición ya habla de quedarse en el grupo del jueves. Se comprueba de nuevo que ese grupo sea compatible y que aún tenga plaza. Si no queda clara la fecha del cambio, se pregunta antes de registrarlo.

Cuando se aprueba el cambio, la inscripción se actualiza desde la fecha acordada. A partir de ese momento figura en el grupo del jueves. Los próximos recordatorios y listados deben utilizar esa nueva asignación.

Si la última plaza se ocupa antes de registrar el cambio, ya no puede mantenerse la respuesta anterior. Habrá que ofrecer otra opción o dejar la solicitud pendiente para que alguien la revise.

Las dos conversaciones se parecen, pero la primera afecta a una sola clase y la segunda modifica las semanas siguientes. La IA puede ayudar a distinguir esa intención. La compatibilidad del grupo y la plaza se comprueban aparte.

Cuándo hay que detener el cambio y revisarlo

Muchas solicitudes encajan en reglas claras. Cuando falta información o aparece una excepción, no se confirma el cambio. El caso queda pendiente para que una persona lo revise.

En esos casos la IA puede preparar un resumen para quien vaya a revisarlo. Esa persona no tendrá que releer toda la conversación y seguirá siendo quien tome la decisión pendiente.

También hay que distinguir un problema de la propia solicitud de un fallo técnico. Si el cambio sería válido pero una integración no responde, el alumno debería recibir un mensaje indicando que la petición sigue pendiente, no una confirmación.

Con qué caso conviene empezar

Para un primer piloto es preferible elegir una petición frecuente y con pocas excepciones. Las recuperaciones puntuales entre grupos que la academia ya considera compatibles suelen encajar bien. Un caso que obligue a revisar además el nivel o las condiciones económicas complica mucho más la primera prueba.

Se puede empezar, por ejemplo, con las recuperaciones de un solo programa. Hace falta que los horarios estén claros y que las plazas puedan consultarse de forma fiable. Los cambios permanentes de grupo pueden añadirse después.

Qué conviene medir durante el piloto

Durante el piloto interesa medir el tiempo que dedica el equipo a estas peticiones y cuántas terminan necesitando una corrección manual. También hay que registrar los casos que se detienen porque la plaza ha cambiado. Si una recuperación modifica por error el grupo habitual o deja una herramienta sin actualizar, ese fallo debe quedar anotado.

También merece la pena contar cuántas veces hay que preguntar al alumno qué quería decir exactamente. Si la misma duda aparece una y otra vez, se puede incorporar una pregunta sencilla al inicio de la conversación.

Estas métricas no evalúan al alumno. Sirven para saber si la academia gestiona las solicitudes con menos trabajo manual y sin introducir errores en plazas o comunicaciones.

Para gestionar el cambio solo hacen falta los datos necesarios

Una petición puede incluir el nombre del alumno, su grupo y el horario. A veces también contiene una explicación personal sobre la ausencia. Esa explicación no tiene por qué copiarse a todas las herramientas si no hace falta para resolver la solicitud.

La guía de la AEPD para centros educativos recuerda que estos centros tratan datos de alumnos, familias y profesores. Para esta automatización hay que decidir qué información necesita cada herramienta y quién debe poder consultarla.

Si el alumno incluye información especialmente sensible que no hace falta para gestionar el cambio, esa información debería quedarse fuera de las copias automáticas. No hace falta enviarla al CRM, al LMS o a otras herramientas.

Preguntas frecuentes sobre horarios, recuperaciones y cambios de grupo