EspoCRM 10.0.9 en colegios: consultas, roles y backup
Caso de industria para ordenar consultas de matriculados con EspoCRM 10.0.9, roles por equipo, importación, API y restauración probada en colegios.
¿Quién puede ver una consulta disciplinaria después de que entra por mesa de ayuda? En un colegio profesional de Cuyo con 1.800 matriculados, la respuesta suele quedar repartida entre correo, hojas de cálculo y llamadas internas. EspoCRM 10.0.9 permite ordenar personas, casos, equipos, roles e historial; este caso muestra qué cargar primero, quién puede tocar cada dato y cómo probar una restauración.
Dónde aparece la consulta sin dueño
La secretaria administrativa recibe matrículas, certificados, reclamos de pago y consultas sensibles. En la bandeja hay mensajes marcados con colores, una carpeta con formularios impresos y una lista de teléfonos que alguien actualizó la semana anterior. El objeto que delata el problema es un sello fechador con tinta débil: deja rastro, aunque nadie sabe si el caso siguió. EspoCRM publicó la versión 10.0.9 el 29 de septiembre de 2026. La publicación corrige, entre otras cosas, notificaciones de asignación que no mostraban nombre y borrado de datos personales en campos de array. Para un colegio, esos detalles son concretos: una consulta debe quedar asignada a alguien y un pedido de supresión de datos debe ejecutarse sin revisar tablas a mano. El correo compartido concentra el riesgo. La encuesta 2026 de Stack Overflow muestra una tendencia que ya toca organizaciones chicas: 19% de quienes construyen software interno lo hace para reemplazar proveedores pagos y 54% usa asistencia de IA para ese trabajo. El riesgo no está en elegir una herramienta abierta; aparece cuando se migra una lista de matriculados sin roles, auditoría ni prueba de salida.
Cómo funciona por dentro
El flujo de atención tiene seis pasos. Primero, mesa de entrada carga persona, matrícula, tipo de consulta, adjunto y vencimiento. Segundo, EspoCRM guarda cuentas, contactos, casos, tareas, correos y auditoría en una base relacional; si la base falla, el alta no queda completa. Tercero, los roles definen qué equipo lee, edita, asigna, exporta o borra registros. Cuarto, la importación recibe CSV con matriculados y muestra errores de formato antes de guardar. Quinto, la API permite que otro sistema consulte estado o cree casos con token controlado. Sexto, backup y restauración copian archivos, base y configuración; una prueba abre un caso real después de restaurar. Cada componente debe tener dueño. Administración define tipos de consulta y estados. Sistemas administra servidor, backup y correo saliente. La comisión revisa reportes sin editar casos. El rol de consulta puede leer métricas y expedientes cerrados, aunque no cambia responsables. La API merece una regla aparte. Un portal de matriculados puede crear una consulta, adjuntar comprobante y recibir número de caso. El CRM responde estado, responsable y fecha de actualización. Si el portal falla, el caso ya guardado sigue en la base y puede atenderse desde la interfaz interna.
Qué se instala o configura primero
La pila mínima incluye EspoCRM 10.0.9, PHP, servidor web, MariaDB, correo saliente, cron para tareas programadas y almacenamiento de adjuntos. Un servidor para 1.800 matriculados y uso administrativo puede costar entre USD 25 y USD 55 por mes; con dólar oficial vendedor a 1.540 pesos, el rango queda entre 38.500 y 84.700 pesos mensuales, sin carga inicial ni mesa de ayuda. El primer entregable verificable es una bandeja de casos con 100 matriculados importados, cuatro tipos de consulta, tres roles y un reporte semanal. La implementación lleva de dos a tres semanas si los datos de matrícula están limpios. Si hay duplicados de DNI, correos compartidos o números sin formato, la primera semana se usa para limpiar y documentar criterios. UMSA puede ayudar en esa etapa de orden técnico: definir campos, roles, importación y restauración antes de conectar portales o tableros. En un caso anonimizado de Cuyo, la mejora no fue una pantalla nueva; fue saber quién tomó cada consulta y qué prueba quedaba al cerrarla.
Dónde se rompe y cómo probarlo
El primer riesgo aparece en roles demasiado amplios. La señal es que un usuario administrativo puede exportar datos disciplinarios. La prueba crea perfiles de mesa de entrada, tesorería, comisión y consulta; cada uno intenta leer, editar, borrar y exportar. El segundo riesgo vive en importación. La señal es un matriculado duplicado con dos correos o dos estados. La prueba importa 20 filas con errores conocidos y exige reporte de rechazo antes de cargar en producción. El tercer riesgo está en adjuntos. La señal es un caso cerrado sin comprobante o con archivo inaccesible. La prueba carga un certificado, cierra el caso, restaura backup y abre archivo, historial y responsable desde otro servidor. El cuarto riesgo aparece en automatizaciones. La señal es una notificación de asignación sin nombre o sin responsable visible. La prueba crea tres casos, reasigna cada uno y verifica correo, registro de actividad y tablero del equipo. Un CRM abierto deja valor cuando la pregunta incómoda se responde sin buscar en cinco lugares: quién pidió qué, quién lo tomó y qué evidencia quedó.
