CRM educativo: de candidato a estudiante sin duplicar datos

Un CRM puede ordenar las consultas, asignar tareas y conservar cada conversación con una persona interesada. El conflicto aparece después de la resolución de admisión. Cambiar la oportunidad a «matriculada» no abre por sí solo un expediente académico, no acredita un pago, no resuelve si esa persona ya existía y tampoco garantiza que reciba la cuenta y las asignaturas correctas.

Para automatizar ese paso con garantías hay que tratarlo como un traspaso entre responsabilidades. Admisiones confirma qué solicitud puede avanzar; el sistema académico crea o actualiza la relación formal; el sistema económico acredita el estado del pago; identidad aprovisiona la cuenta; el aula virtual recibe la matrícula que le corresponde. Cada parte conserva su propio estado y todas comparten una referencia estable de la misma operación.

El resultado exigible es concreto: una sola persona reconocida, un expediente académico enlazado con la solicitud, ninguna matrícula concedida por deducción y una explicación comprensible cuando el recorrido se detiene. Esta guía desarrolla ese cruce. El mapa completo está en Automatizar procesos educativos: del primer contacto al certificado.

El cambio de etapa en el CRM inicia el traspaso; la matrícula solo existe cuando el sistema académico confirma sus condiciones y devuelve un resultado comprobable.

El CRM llega hasta una frontera

Antes de esa frontera, el CRM necesita responder preguntas sobre la relación: quién ha pedido información, por qué programa, qué permiso existe para contactar, quién lleva el caso y qué conversaciones se han mantenido. Puede alojar formularios de solicitud y ayudar a reunir documentos si el procedimiento se ha diseñado así. También puede mostrar una resolución recibida desde admisiones.

Después aparecen datos con otra autoridad. El expediente académico, la matrícula, las asignaturas, las condiciones económicas y los permisos institucionales producen efectos que una etiqueta comercial no debería conceder. Que el CRM marque a alguien como «ganado» sirve para cerrar una oportunidad; no autoriza a crear una matrícula si falta una condición académica o económica.

Conviene escribir ese reparto antes de elegir conectores. La tabla siguiente no asigna productos universales. Obliga a que cada institución nombre su fuente autorizada y el equipo que puede corregirla.

Este reparto también limita los datos que viajan. El artículo 5 del Reglamento General de Protección de Datos exige, entre otros principios, finalidad determinada, minimización y exactitud. No hay motivo para copiar al aula virtual todas las notas comerciales del CRM ni para devolver al CRM el expediente completo. Cada destino recibe lo necesario para su función y sabe dónde se corrige el original.

Los estados deben pertenecer al proceso que los produce

Un embudo único resulta atractivo porque ofrece una línea continua: contacto, solicitud, admisión, matrícula y estudiante. Esa línea mezcla decisiones que pueden estar en situaciones distintas durante días. Una persona puede estar admitida, haber aceptado la plaza, tener el pago sin conciliar y conservar una identidad institucional de un curso anterior. Reducirlo todo a una etapa obliga a esconder información o a multiplicar etiquetas ambiguas.

Mantendría, como mínimo, cuatro grupos de estados:

• Admisión: solicitud abierta, documentación pendiente, evaluable, admitida, admitida con condiciones, no admitida, renuncia.
• Matrícula: no iniciada, preparada, pendiente de condición, confirmada, modificada, anulada.
• Situación económica: no aplicable, pendiente, justificante recibido, conciliada, incidencia, devolución.
• Identidad y acceso: sin resolver, coincidencia encontrada, revisión necesaria, cuenta preparada, acceso parcial, acceso activo, bloqueado.

La vista general se calcula a partir de esos estados; no los sustituye. «Preparando acceso» puede significar que la matrícula está confirmada y falta crear una cuenta. «Pendiente de formalización» puede reunir una admisión favorable con un pago aún no conciliado. La etiqueta ayuda a trabajar, pero no tiene permiso para modificar las fuentes que resume.

Esta separación evita una inferencia peligrosa: la ausencia de una persona en el aula virtual no demuestra que carezca de matrícula. Puede haber una cola retrasada, una cuenta duplicada o un alta fallida. Tampoco conviene interpretar un pago recibido como autorización académica. Cada decisión avanza cuando su fuente correspondiente lo confirma.

La ficha de traspaso que debe existir antes de integrar

El paso de admitida a estudiante necesita una ficha que pueda leer admisiones, secretaría, tecnología y quien mantenga los sistemas. Si la conversación empieza por campos de API, faltan decisiones anteriores. Una ficha útil responde a estas preguntas:

La condición inicial debe ser verificable. «Candidato listo» no basta. Puede significar que ha entregado documentos, que ha aceptado la plaza o que alguien ha pulsado un botón. El contrato nombra el estado exacto, la versión de la solicitud y las condiciones que siguen pendientes. Si una admisión condicionada puede iniciar parte del recorrido, también declara qué efectos quedan bloqueados.

El destino devuelve algo más útil que «200 OK». Informa de si ha creado una persona, ha enlazado una ya existente o ha detenido el alta por una coincidencia dudosa. Devuelve asimismo el identificador académico y la versión aplicada. Esa respuesta permite continuar con identidad y acceso sin buscar a la persona por nombre o correo.

El correo no identifica de forma permanente a una persona

Las direcciones cambian, se escriben mal, se comparten y a veces llegan desde canales distintos. Un antiguo alumno puede usar hoy un correo personal diferente del que figura en su expediente. Dos solicitudes del mismo año pueden entrar con variantes del nombre. La integración necesita resolver esas situaciones sin crear automáticamente otro estudiante ni unir expedientes por aproximación.

La resolución puede organizarse en tres salidas:

1. Coincidencia suficientemente acreditada. Las reglas institucionales permiten enlazar la solicitud con una persona existente y se registra qué evidencias se usaron.
2. Persona nueva. No existe una coincidencia relevante y el sistema académico crea el registro, conservando la relación con la solicitud de origen.
3. Posible duplicado. Hay señales contradictorias o más de una coincidencia; el proceso abre un caso para revisión y no crea ni fusiona nada todavía.

El tercer resultado es una salida prevista del proceso. Una fusión equivocada puede mezclar expedientes, comunicaciones y permisos de dos personas. Por eso las coincidencias aproximadas sirven para priorizar una revisión, pero no para resolverla automáticamente.

Tampoco usaría el número de documento como clave técnica que circula por cada sistema. Puede formar parte de la comprobación cuando existe base jurídica y el procedimiento lo requiere, pero la integración puede enlazar sus mensajes mediante identificadores internos y una clave de correlación. Así se reduce la exposición y se separa la prueba de identidad del mecanismo que reintenta una operación.

Repetir un mensaje no debe crear otro expediente

Las integraciones repiten mensajes. Puede caducar una respuesta, reiniciarse un proceso o llegar dos veces la misma confirmación. El receptor tiene que distinguir una petición nueva de la repetición de la anterior.

Para ello, cada traspaso lleva una referencia única y la versión del estado que lo originó. Al recibirlo, el sistema académico comprueba si ya produjo un resultado:

• si no lo ha visto, aplica la operación y guarda la relación entre referencia y resultado;
• si ya la completó con los mismos datos, devuelve los identificadores existentes;
• si la referencia coincide pero los datos han cambiado, rechaza la repetición y pide una nueva versión;
• si el expediente avanzó por otra vía, devuelve un conflicto que debe resolverse antes de continuar.

Este comportamiento se conoce como idempotencia, pero la prueba puede redactarse sin jerga: «enviar dos veces la misma admisión crea una sola matrícula y devuelve el mismo identificador». Otra prueba necesaria es la contraria: «reutilizar la misma referencia con otro programa no modifica la matrícula ya creada».

La protección cubre también los efectos posteriores. Si la matrícula existe y falla la creación del acceso al aula, se repite solo el alta que falta. No se vuelve a crear la persona, no se rehace el pago y no se envía otra matrícula al sistema académico.

El siguiente diagrama sigue un caso concreto. Enseña dos desvíos que una línea feliz suele ocultar: la coincidencia con un expediente anterior y el pago recibido pero todavía no conciliado.

Abrir la imagen a tamaño completo

Un pago pendiente no tiene por qué detenerlo todo

La situación económica suele producir atajos. Un justificante adjunto se interpreta como pago; una conciliación tardía bloquea todos los servicios; una devolución se queda en el sistema económico y no alcanza a la matrícula. El contrato debe declarar qué estado económico habilita cada efecto.

Puede ocurrir que una plaza quede reservada al aceptar la oferta, que la matrícula solo se confirme tras la conciliación y que una cuenta limitada se prepare antes para completar documentación. Son decisiones de la institución. La integración las aplica, no las inventa.

Cuando una condición no se cumple, la respuesta debe ser precisa: «pago localizado y pendiente de conciliación», «importe inferior al esperado», «referencia asociada a otra solicitud» o «exención pendiente de aprobar». «Error de pago» deja al equipo sin criterio para actuar y suele provocar que el estudiante traslade mensajes entre departamentos.

El proceso conserva el plazo, el responsable y lo que ya existe. Una admisión favorable no desaparece porque la matrícula esté pendiente; una cuenta preparada no concede acceso a asignaturas si falta autorización; un reembolso no borra automáticamente el expediente. Las compensaciones que afecten a derechos o registros académicos requieren una decisión expresa.

La conciliación encuentra lo que la cadena no contó

Una sucesión de respuestas correctas no demuestra que el estado final siga siendo correcto. Después puede modificarse una matrícula, corregirse una identidad o recuperarse manualmente una incidencia. Por ese motivo hace falta una comprobación periódica que compare lo esperado con lo observado.

Para cada admisión que debía formalizarse, revisaría al menos:

• solicitud y resolución enlazadas con una persona académica;
• una sola matrícula activa para el programa, edición y modalidad esperados;
• condición económica compatible con ese estado;
• identidad institucional vinculada con la misma persona;
• asignaturas y grupos de acceso coherentes con la matrícula;
• ausencia de casos vencidos sin responsable.

La comprobación no corrige automáticamente todo lo que encuentra. Clasifica la diferencia y la envía a quien puede decidir. Si falta un alta por una interrupción técnica, puede reintentarse. Si aparecen dos expedientes posibles o una modificación académica incompatible, se abre un caso y se detiene la propagación.

Los estándares evitan acordar cada formato desde cero, pero no sustituyen este reparto. Edu-API, de 1EdTech, se encuentra todavía en fase pública previa a su primera versión final. Aborda el intercambio de datos académicos entre los sistemas de administración y aprendizaje de la educación superior. SCIM define un protocolo para administrar identidades entre dominios. Ninguno decide qué solicitud debe admitirse, cuándo una condición se considera cumplida ni quién resuelve dos expedientes posibles. Esas reglas siguen perteneciendo a la institución.

La separación también se aprecia en el último tramo. La matrícula con base de datos externa de Moodle 5.2 presupone que la cuenta ya exista antes de incorporar a la persona a un curso. Crear la identidad y asignar la matrícula son dos efectos relacionados, pero siguen teniendo condiciones y recuperaciones distintas.

Qué medir en el primer programa

Empezaría con un programa, una convocatoria y un conjunto de condiciones conocido. El piloto debe incluir un caso ordinario y las excepciones que más daño pueden causar, no solo diez altas perfectas.

Antes de activarlo se fijan las medidas y su fuente. Estas seis permiten saber si el cruce ha mejorado:

1. tiempo desde que la admisión puede avanzar hasta que el expediente queda disponible;
2. solicitudes cuyos datos se vuelven a escribir manualmente;
3. posibles duplicados detectados antes y después de crear el expediente;
4. traspasos repetidos que producen más de una matrícula;
5. casos pendientes más allá del plazo acordado;
6. discrepancias entre matrícula, identidad y acceso encontradas por conciliación.

No hace falta prometer un porcentaje de ahorro antes de medir. El primer avance puede demostrarse de otra forma: ninguna matrícula duplicada en los reintentos, todas las excepciones con responsable, trazabilidad entre solicitud y expediente, y concordancia final entre la matrícula y los accesos del piloto.

La revisión del piloto debe poder reconstruir tres historias completas: una persona nueva, una antigua alumna reconocida sin duplicarla y una admisión que se detuvo por una condición pendiente. Si el equipo puede explicar quién decidió, qué se creó, qué quedó bloqueado y cómo volvió al recorrido, el proceso está preparado para ampliar volumen.

El criterio para dar el traspaso por terminado

Un CRM educativo aporta mucho antes de la matrícula: ordena la relación, conserva las conversaciones y permite que admisiones trabaje con continuidad. Su límite aparece cuando una decisión produce expediente, derechos, obligaciones y permisos institucionales. En ese punto necesita entregar el caso a las fuentes autorizadas y recibir un resultado que pueda comprobarse.

El traspaso está terminado cuando la solicitud y el expediente quedan enlazados, la identidad ha sido resuelta, la matrícula refleja sus condiciones reales y los servicios posteriores coinciden con ella. Si algo no puede avanzar, existe un caso con motivo, responsable, plazo y punto de reentrada.

Esa disciplina evita que el estudiante se convierta en mensajero entre admisiones, secretaría y soporte. También permite automatizar más adelante sin consolidar duplicados ni decisiones implícitas. En veintidós años construyendo plataformas educativas explico por qué las restricciones que aparecen en operación pesan tanto como la arquitectura inicial. Aquí la consecuencia es inmediata: el proceso debe diseñarse también para la coincidencia dudosa, el pago tardío y el alta parcial, porque ahí se decide si la integración puede sostenerse.