Zammad en colegios: tickets, roles y respaldo probado
Un colegio profesional puede ordenar reclamos, matrículas y soporte interno con Zammad. Flujo, permisos, costo y prueba mínima antes de mover la atención diaria.
Antes, cada reclamo entraba por teléfono, WhatsApp o una casilla compartida; después, cada consulta tuvo número, estado y responsable. Zammad sirve para un colegio profesional de Cuyo que atiende matrículas, pagos, certificados y soporte interno sin perder el rastro de una respuesta. La guía muestra qué se instala, quién toca cada ticket y cómo se prueba el respaldo antes de mover la atención diaria.
Dónde aparece el reclamo que vuelve cada lunes
El grupo de WhatsApp de soporte es el antagonista. Acelera el primer mensaje y deja débil la segunda respuesta: nadie sabe si el adjunto llegó, quién prometió llamar o qué trámite quedó pendiente. La documentación de Zammad para Docker pide al menos 4 GB de RAM para correr los contenedores y ajustar Elasticsearch, según su guía de instalación. Ese número pone piso al proyecto antes de hablar de pantallas. El repositorio zammad/zammad registraba 5.741 estrellas y 1.011 forks al momento de la verificación local. Stack Overflow informó en 2025 que GitHub fue la herramienta de documentación y colaboración más usada con 81 %, seguida por Jira con 46 % y GitLab con 36 %. El puente es operativo: los equipos ya aceptan trabajar con registros compartidos cuando el flujo devuelve estado y responsabilidad. En la mesa de entrada queda una carpeta con separadores azules y recibos abrochados. La diferencia es que el ticket guarda la misma historia sin depender de esa carpeta.
Cómo funciona por dentro
El flujo puede arrancar con cinco pasos. Primero, una persona crea un ticket desde correo, formulario o carga manual y el sistema guarda asunto, solicitante, grupo, prioridad y estado. Segundo, Zammad asigna el ticket a un grupo como matrícula, cobranza, soporte o dirección. Tercero, los roles definen permisos; la API de roles requiere permiso admin.role para listar, crear o cambiar roles. Cuarto, cada respuesta queda como artículo del ticket. La documentación de artículos indica permisos ticket.agent o ticket.customer para crear registros, y permite adjuntos cuando corresponde. Quinto, la base guarda tickets, usuarios, estados y tiempos; Elasticsearch acelera búsqueda y reportes; el backup copia archivos y PostgreSQL. La prueba debe restaurar un ticket con adjunto y confirmar que conserve estado, responsable y conversación. El dato vive en dos lugares. La base conserva la estructura del caso y el almacenamiento guarda archivos. Si falla Elasticsearch, la búsqueda cae o se vuelve lenta; si falla PostgreSQL, el sistema pierde el registro transaccional; si falla el backup, el colegio descubre tarde que el ticket era solo una pantalla.
Qué se instala o configura primero
La pila mínima incluye Zammad, PostgreSQL, Elasticsearch, Nginx o proxy HTTPS, copias de seguridad, monitoreo de contenedores y una política de retención. Un servidor con 8 GB de RAM, disco SSD y copia externa puede costar entre USD 50 y USD 100 mensuales, unos $ 75.500 a $ 151.000 al dólar oficial vendedor de $ 1.510. El costo incluye infraestructura; falta contar carga inicial, capacitación y diseño de grupos. El primer entregable verificable es una mesa de ayuda piloto con cuatro colas: matrícula, pagos, certificados y soporte interno. UMSA podría aplicarlo en una cámara o colegio profesional sin nombrar personas reales: se cargan diez casos de prueba, se responden con dos perfiles distintos y se mide si dirección puede ver pendientes sin editar conversaciones. La configuración empieza por lenguaje y acuerdos de atención. Hay que definir estados permitidos, nombres de grupos, responsables, horarios de atención, plantilla de respuesta y criterio de cierre. Zammad recibe esos datos y entrega una cola ordenada; si se cargan categorías vagas, el tablero devuelve pendientes vagos. El reporte semanal completa el circuito. Dirección necesita ver tickets abiertos, vencidos y cerrados por grupo; administración necesita exportar casos ligados a matrícula o cuota; soporte necesita saber qué cola crece. Esas vistas se diseñan antes de abrir el formulario público.
Dónde se rompe y cómo probarlo
El primer riesgo es abrir permisos de más. La señal aparece cuando un agente de cobranza puede ver tickets de dirección o cambiar roles. La prueba es crear usuarios de cada área, entrar con cada perfil y documentar qué puede leer, editar o borrar. El segundo riesgo es migrar conversaciones sin criterio. La señal aparece cuando un trámite viejo queda duplicado o sin solicitante. La prueba es importar veinte casos representativos, buscar por matrícula, correo y fecha, y revisar si el número de ticket permite reconstruir la historia. El tercer riesgo es respaldar archivos y olvidar la base. La señal aparece en restauraciones con adjuntos presentes y tickets vacíos. La prueba es ejecutar el backup recomendado, restaurar en un entorno aislado y abrir un ticket con adjunto, estado y artículo interno. El cierre llega cuando el lunes deja de preguntar quién contestó. Pregunta qué ticket sigue abierto y qué prueba falta para cerrarlo.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.