Casi todos los centros de formación con teoría online usan Moodle, y casi ninguno lo tiene conectado con el sitio donde gestiona alumnos y cobros. El resultado es una persona de oficina que, cada día, crea usuarios a mano, los matricula en el curso que toca, les manda las credenciales por WhatsApp uno a uno y, cuando alguien deja de pagar, se acuerda —o no— de quitarle el acceso.
Esa persona no es el problema. El problema es que la regla —quién debe estar dentro del aula— vive en su cabeza en lugar de en el sistema.
Lo que se puede automatizar
Moodle expone servicios web para casi todo lo que hace un administrador a mano: crear y modificar usuarios, matricularlos en cursos, suspender o reactivar una matrícula, leer calificaciones. Eso permite que el CRM, que es quien sabe si el alumno ha pagado, mande sobre el aula:
- Al confirmarse el primer pago, el CRM crea el usuario en Moodle, lo matricula en la edición del curso que le corresponde según su grupo y le envía las credenciales por WhatsApp. Sin esperar a que oficina lo vea.
- Si cambia de grupo, de curso o de modalidad, el cambio en el CRM le mueve también en el aula.
- Si deja de pagar, tras los días de gracia que decida el centro, la matrícula se suspende y el alumno recibe el aviso; cuando paga, se reactiva sola.
- Cuando aprueba el examen, sale del curso.
- Y en el otro sentido: el CRM lee las calificaciones para saber cuánto ha avanzado cada alumno de verdad, no solo si tiene acceso.
La pieza que evita los sustos: el repaso diario
Automatizar el alta es lo fácil. Lo que evita los dos problemas clásicos —el alumno que ha pagado y no puede entrar, y el que no paga y sigue dentro— es un repaso diario que compara lo que el CRM dice que debería haber en el aula con lo que hay: quien está al corriente tiene acceso, quien no lo está no lo tiene, y cualquier cuenta que exista en Moodle sin respaldo en el CRM aparece en una lista para que alguien la mire.
Ese repaso convierte la integración en algo en lo que se puede confiar. Sin él, el primer fallo de red que se pierda una alta deja a un alumno fuera durante días sin que nadie se entere.
| Situación | Antes | Con el CRM mandando sobre el aula |
|---|---|---|
| Alumno paga la primera cuota | Oficina crea usuario, matricula y manda credenciales cuando puede | Alta, matrícula y credenciales en el momento |
| Cambio de grupo | Dos cambios a mano, en dos sistemas | Un cambio en el CRM |
| Impago | Se detecta tarde; el alumno sigue en clase | Aviso, días de gracia y suspensión automática |
| Vuelve a pagar | Alguien tiene que acordarse de reactivar | Reactivación automática |
| Aprueba | Sigue matriculado indefinidamente | Sale del curso |
| Algo fallo por el camino | Nadie lo sabe | El repaso diario lo detecta |
Las decisiones que hay que tomar antes de programar nada
- Cuál es el identificador del alumno. En la práctica, el teléfono: es lo que llega en el formulario y por donde se le escribe. Una persona es un alumno aunque entre por cinco formularios.
- Qué es una «edición» del curso. El mismo carnet se imparte muchas veces al año, en varias sedes; el CRM tiene que saber a qué curso concreto de Moodle corresponde cada grupo.
- Cuántos días de gracia hay ante un impago, y si el aviso va antes o después de suspender. Es una decisión del centro, y se configura, no se programa.
- Qué pasa con las cuentas que ya existen en Moodle antes de la integración: hay que casarlas con los alumnos del CRM una vez, con cuidado, antes de dejar que el sistema mande.
Cómo queda en un centro real
En un centro de formación técnica con sedes en varias ciudades, el CRM gobierna hoy las cuentas del aula: alta al primer pago, credenciales por WhatsApp, suspensión y reactivación según los cobros, salida al aprobar, y un repaso diario que detecta accesos de más o de menos. La regla de quién entra al aula dejó de estar en la cabeza de nadie. Los mensajes al alumno salen del mismo servicio de WhatsApp que los recordatorios de cuota, con las reglas que contamos en WhatsApp automático desde el CRM.
Preguntas frecuentes
¿Hay que tocar Moodle?
No hay que modificarlo: se activan sus servicios web, se crea un usuario técnico con los permisos justos y el CRM habla con él. Moodle sigue siendo Moodle.
¿Vale con otro aula virtual?
El planteamiento es el mismo con cualquier plataforma que tenga una API razonable. Lo que cambia es el detalle técnico de cada llamada, no las reglas de negocio.
¿Y si prefiero seguir dando las altas a mano?
Puedes: el CRM te dice qué toca hacer y tú lo haces. Pero el repaso diario merece la pena igualmente, porque es el que te avisa de quién está dentro sin deber estarlo.
Si gestionas un centro y esto te suena
Cuéntanos cómo llegan hoy tus alumnos, cómo cobras y quién da las altas en el aula. Con eso se ve qué parte del ciclo —del anuncio al carnet— se puede dejar en manos del sistema. Es el trabajo de CRM a medida, y si tu duda es si te basta uno de suscripción, la tratamos en este artículo.
Fuentes
- Web service API functions (Moodle Developer Documentation). Funciones de usuarios y matriculación, entre ellas core_user_create_users, core_user_update_users y enrol_manual_enrol_users.
- Enrolment API (Moodle Developer Resources). Estados de matrícula activa y suspendida.
Última revisión: 21 de septiembre de 2026.