Zammad en cooperativas: reclamos, SLA y salida
Mini-caso para cooperativas eléctricas e internet rural: reclamos, cuadrillas, SLA, roles, API, backup y prueba de restauración con Zammad propio.
Un reclamo por baja tensión quedó asignado a dos cuadrillas y ninguna vio la foto del medidor. En una cooperativa eléctrica con internet rural, ese error cuesta horas, combustible y confianza. Zammad permite ordenar tickets, grupos, SLA y canales cuando la organización define quién carga, quién deriva, quién cierra y qué evidencia queda. Esta nota muestra un piloto posible sin nombrar clientes reales.
Dónde se pierde el reclamo operativo
La documentación de Zammad separa instalación, actualización, requisitos, API y operación. Para una cooperativa, esa estructura sirve porque un reclamo puede llegar por teléfono, correo, formulario o mesa de atención. El antagonista es el cuaderno de guardia que viaja en una camioneta blanca: útil para anotar, débil para medir vencimientos y responsables. La página de requisitos de software indica que Zammad usa PostgreSQL 13 o superior y puede trabajar con Elasticsearch para búsqueda, reportes y adjuntos. También lista distribuciones soportadas como Ubuntu 22.04, 24.04 y 26.04, Debian 11, 12 y 13, y RHEL 9 y 10. Esa lista ubica el piloto en servidores conocidos y requisitos comparables contra un inventario real. Un número de reclamo escrito en birome desaparece cuando cambia el turno. El dato externo completa el cuadro. En la encuesta Stack Overflow 2025, PostgreSQL mantiene presencia fuerte entre bases usadas por desarrolladores. Para una cooperativa, esa familiaridad ayuda a que ticket, estado, usuario, fecha, adjunto y cierre queden consultables sin depender de una exportación manual.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. 1. Mesa de entrada carga reclamo con socio, suministro, zona, canal, foto, prioridad y tipo de servicio. 2. Zammad crea ticket, asigna grupo y guarda estado, fecha, agente y conversación. 3. Un supervisor deriva a cuadrilla, soporte de internet, facturación o administración según regla escrita. 4. La API de Zammad entrega o recibe datos desde un sistema de socios, un formulario o un tablero. 5. Los permisos separan agente, supervisor, administrador, auditor y consulta de consejo directivo. 6. El backup copia base, adjuntos, configuración y artículos de conocimiento; la restauración recupera tickets con historial. La introducción de API explica autenticación y endpoints para tickets, usuarios, organizaciones, roles y grupos. La sección de backup y restauración describe scripts para instalaciones por paquete y recomienda revisar su alcance. La página de releases muestra Zammad 7.2, publicado el 23 de septiembre de 2026, con registro de auditoría administrativa resistente a alteraciones. Ese dato importa cuando una cooperativa necesita explicar quién cambió una cola o una regla.
Qué se instala o configura primero
El primer entregable verificable es una mesa chica con treinta tickets de prueba. Incluye reclamo eléctrico, reclamo de internet, consulta de facturación, adjunto de foto, derivación a cuadrilla, vencimiento de SLA, cierre con causa y exportación CSV. Cada ticket debe mostrar responsable, grupo, fecha, estado y evidencia. Una pila concreta usa Zammad, PostgreSQL, almacenamiento de adjuntos, proxy HTTPS, correo entrante, roles por grupo, backup diario y tablero semanal. Tomando el dólar oficial vendedor informado por DolarAPI, un piloto de USD 540 a USD 1.100 equivale a ARS $831.600 a ARS $1.694.000. Ese costo cubre instalación, canales, permisos, plantillas, tablero y prueba de restauración; no incluye compra de hardware ni integración profunda con facturación. UMSA puede empezar con datos ficticios y recorridos reales: dos zonas rurales, tres cuadrillas, un área de facturación y una guardia de internet. El primer corte útil muestra cuántos reclamos vencen, cuáles vuelven por falta de dato, quién cerró cada caso y qué adjunto sostiene la respuesta.
Dónde se rompe y cómo probarlo
El primer riesgo es abrir tickets sin socio o suministro. La señal aparece cuando una cuadrilla recibe dirección incompleta. La prueba mínima es bloquear alta si falta identificador operativo. El segundo riesgo es cerrar sin causa. La señal aparece cuando gerencia ve cantidad de tickets cerrados, pero no distingue reparación, derivación o reclamo duplicado. La prueba mínima es exigir motivo de cierre y revisar diez casos. El tercer riesgo es mezclar áreas en un solo grupo. La señal aparece cuando facturación ve adjuntos técnicos o soporte modifica estados administrativos. La prueba mínima es crear grupos separados y probar permisos con usuarios reales. El cuarto riesgo es depender del correo sin cola de errores. La señal aparece cuando un reclamo enviado por formulario nunca aparece. La prueba mínima es apagar el buzón, reenviar mensajes y comparar conteo. El quinto riesgo es respaldar solo la base. La señal aparece cuando los tickets vuelven, pero faltan fotos y archivos. La prueba mínima es restaurar en otro host y abrir tres reclamos con adjuntos. La cooperativa mejora cuando cada reclamo tiene responsable, plazo, evidencia y recuperación comprobada antes de que el vecino vuelva a llamar.
