Zammad 7 en cooperativas: reclamos, grupos y respaldo
Caso anonimizado de mesa de ayuda en cooperativa eléctrica: tickets, grupos, roles, costos y prueba de cierre con Zammad 7.
Un reclamo por baja tensión entró por WhatsApp, volvió por teléfono y terminó sin responsable. En una cooperativa eléctrica de Cuyo, la guardia mezclaba mensajes, planillas y notas del mostrador con un número de reclamo escrito a mano. Zammad 7 ordena tickets, grupos, roles y respaldo; este caso muestra qué dato entra, quién lo lee y cómo se prueba el cierre.
Dónde un reclamo deja de ser una conversación suelta
El problema operativo aparece cuando atención, técnica y administración miran canales distintos. Una persona llama por baja tensión, otra manda una foto del medidor y un tercero consulta por deuda. Si todo queda en chats, cada reclamo depende de memoria, turno y voluntad de buscar. Zammad convierte esas entradas en tickets con estado, grupo, prioridad y responsable.
La cifra que corrige el costo inicial está en la página de precios de Zammad: el plan alojado Starter parte de 7 euros por agente al mes con facturación anual, mientras que la versión self-hosted deja actualizaciones, backups y disponibilidad a cargo de la organización. En una cooperativa con 18 personas entre guardia, administración y técnica, la cuenta deja de ser una suscripción chica y pasa a ser una decisión de gobierno del reclamo.
El ticket sin grupo se enfría en el cambio de turno.
GitHub informó en Octoverse 2025 que 81,5% de las contribuciones ocurrió en repositorios privados. La lectura local es directa: muchas herramientas abiertas se adoptan puertas adentro, porque el dato sensible exige roles y respaldo. La cooperativa necesitaba mostrar solo lo necesario para cada área y medir demoras desde dirección.
Cómo funciona por dentro
El flujo empieza en un canal: correo, formulario web, llamada registrada o mensaje copiado por atención. Zammad crea un ticket con asunto, cliente, grupo, prioridad, estado y artículo inicial. El agente agrega notas, adjuntos y cambios de estado. PostgreSQL guarda registros de usuarios, tickets, grupos, permisos y auditoría. Elasticsearch o OpenSearch acelera búsquedas, si la instalación lo usa.
Los roles de Zammad definen qué puede hacer cada usuario. Atención crea y responde tickets. Técnica cambia estados de intervención y adjunta fotos. Administración ve reclamos ligados a facturación. Dirección consulta reportes. El sistema entrega vistas por grupo, vencimientos y responsable; si falla, el síntoma aparece como ticket sin asignar, búsqueda lenta o correo entrante sin conversión.
El backup copia base, archivos, configuración y secretos. La documentación de respaldo separa copia y restauración para instalaciones de paquete. La prueba útil recupera un ticket cerrado con adjunto, comentario interno y responsable; una pantalla vacía deja incompleta la auditoría de atención.
Qué se instala o configura primero
La pila mínima usa Zammad 7, PostgreSQL, almacenamiento local o S3 para adjuntos, servidor SMTP/IMAP, proxy HTTPS con Caddy o Nginx, y Restic para copias. En infraestructura propia, el costo mensual ronda USD 25 a USD 60, entre ARS 35.800 y ARS 85.920 al dólar vendedor de ARS 1432. Ese valor cubre servidor, disco y monitoreo. La migración de conversaciones viejas y la limpieza de contactos se estiman aparte.
El primer entregable verificable es un flujo de reclamo de punta a punta: alta, asignación, respuesta, adjunto, cierre y encuesta interna. El segundo es una matriz de grupos con permisos: atención, técnica, administración, gerencia y proveedor externo. UMSA lo usa como prueba de salida antes de automatizar canales, porque un correo conectado sin roles puede multiplicar tickets repetidos. Cada grupo recibe una cola, un horario de guardia y una regla de escalamiento escrita.
La implementación toma entre tres y seis semanas. La primera define grupos y estados. La segunda conecta correo y formularios. La tercera migra contactos activos. Las siguientes prueban reportes, backup y restauración. En la cooperativa, el objeto que cambió la reunión fue una hoja A4 plastificada en la guardia: grupo, responsable y horario de escalamiento. El cierre mensual incorporó un corte de tickets abiertos, vencidos y reabiertos, firmado por atención y técnica. El tablero muestra ese corte por grupo y por guardia.
Dónde se rompe y cómo probarlo
El primer riesgo es crear demasiados grupos. La señal aparece cuando un reclamo rebota entre áreas sin respuesta visible. La prueba carga diez tickets reales anonimizados y mide cuántos cambios de grupo necesitó cada uno.
El segundo riesgo es abrir datos de clientes a proveedores. La señal aparece cuando un usuario externo ve deuda, teléfono o domicilio fuera de su tarea. La prueba entra con un rol de proveedor y revisa búsqueda, adjuntos y tickets relacionados.
El tercer riesgo es confiar en un backup sin restauración. La señal aparece cuando el archivo existe, aunque nadie recuperó un ticket completo. La prueba restaura en otro servidor, busca un caso cerrado y compara adjunto, comentario, fecha y responsable.
La cooperativa gana cuando el reclamo tiene dueño antes de que el turno cambie.