Zammad en cooperativas: reclamos, grupos y respaldo
Una cooperativa con reclamos por internet rural necesita tickets con grupo, responsable, SLA, disparadores y backup. Caso con Zammad y PostgreSQL.
El reclamo vuelve a abrirse cuando ventas y soporte cambian el grupo sin dejar responsable. En una cooperativa electrica con internet rural, un corte puede entrar por telefono, WhatsApp, correo o mostrador, y cada canal llega con datos distintos. Zammad permite ordenar tickets, grupos, permisos, disparadores y respaldo. Este caso muestra qué se carga primero, quien edita y cómo se prueba una restauración.
Dónde se pierde el reclamo rural
La cifra que corrige la rutina aparece en el backup: la documentación de Zammad para Docker Compose indica que el stack crea una copia al iniciar y otra a las 3 de la mañana. Un respaldo diario suena suficiente hasta que el reclamo entra a las 8, cambia de grupo a las 10 y se cierra a las 16 sin archivo recuperable. Un ticket sin grupo es una promesa sin dueño. El dato global muestra que la mesa de ayuda ya no atiende un solo sistema. Octoverse 2025 informo más de 180 millones de desarrolladores y 630 millones de repositorios. En una cooperativa chica, la escala baja a enlaces, routers, facturacion, cuadrillas y socios. El orden sigue siendo el mismo: cada caso necesita estado, responsable y prueba.
El chat de guardia mezcla deuda y poste caido
El antagonista es el chat de guardia donde conviven reclamos técnicos, deuda, alta de servicio y fotos de postes. En una cooperativa del este mendocino, el gerente revisa cuadrillas, cobranzas y reclamos antes de salir a ruta. Un patch cord amarillo cuelga del rack junto al router de borde; el ticket debe decir si el problema esta en domicilio, radioenlace, fibra o facturacion. Zammad separa grupos, roles y permisos. La documentación de permisos marca que ticket.agent habilita acceso a vistas y tickets, y que los permisos por grupo definen alcance. Los disparadores envian respuestas o cambian campos cuando se crea o modifica un ticket. Las etiquetas ayudan a leer cortes repetidos sin abrir veinte conversaciones.
Cómo funciona por dentro
El flujo mínimo tiene siete pasos. Primero, mesa de entrada crea el ticket con canal, socio, domicilio, servicio y sintoma. Segundo, Zammad asigna grupo segun tema: soporte, cobranza, instalaciones o redes. Tercero, un agente toma el ticket y registra responsable. Cuarto, PostgreSQL 17 guarda tickets, usuarios, grupos, roles, estados y auditoría. Quinto, Elasticsearch o el buscador configurado indexa texto para encontrar casos parecidos. Sexto, el disparador avisa al socio o escala por demora. Septimo, el backup copia base y archivos, y se prueba restaurando un ticket cerrado. PostgreSQL guarda registros estructurados, usuarios, grupos, estados y auditoría. Zammad recibe mensajes de canales, entrega tickets con responsable y deja historial por caso. El buscador recibe texto del ticket y devuelve resultados para soporte. El almacenamiento guarda adjuntos, fotos y comprobantes. Si falla Zammad, la mesa cae. Si falla la base, se pierden estados. Si falla el indice, buscar antecedentes se vuelve lento. Si falla el backup, el cierre queda sin prueba. Los permisos se dividen por tarea. Mesa de entrada crea casos y ve datos básicos. Soporte edita tickets técnicos. Cobranza ve deuda y pagos. Redes ve enlaces y equipos. Gerencia lee reportes. Borrar tickets cerrados queda bloqueado; corregir un cierre exige nota.
Qué se instala o configura primero
La pila inicial usa Zammad, PostgreSQL 17, buscador, HTTPS, correo entrante y saliente, grupos, roles, etiquetas, disparadores y backup diario. El piloto cuesta entre USD 1.000 y USD 3.200, entre ARS 1,42 y 4,53 millones al dólar vendedor oficial de $1.417 informado por Bluelytics. Incluye instalación, canales, permisos, cuatro grupos, reportes y restauración. El plazo va de tres a seis semanas. UMSA suele pedir un entregable verificable: cien tickets migrados o simulados, cuatro grupos, diez agentes, dos disparadores, un reporte de demoras, cinco adjuntos y una restauración completa. El costo incluye capacitacion corta para mesa de entrada y soporte; no incluye telefonia ni reemplazo de CRM. La primera semana se dedica a nombres de grupos y estados. Cada ticket debe mostrar socio, domicilio, tecnologia, responsable, vencimiento y proxima acción. Si el estado queda libre, vuelve el chat. La segunda semana mide tiempos. El reporte separa primera respuesta, cierre, reabiertos y tickets por zona. Esa lectura permite ver si el cuello esta en cuadrilla, provision de equipos o cobranza. El tablero diario también muestra casos sin domicilio completo, fotos sin etiqueta y tickets con socio mal escrito.
Dónde se rompe y cómo probarlo Primer riesgo: grupos que nadie mira.
La señal aparece cuando un ticket queda más de un día sin agente. La prueba crea casos por canal y confirma grupo, responsable y aviso. Segundo riesgo: disparadores que responden de mas. La señal es un socio que recibe dos mensajes por el mismo evento. La prueba crea un ticket, cambia estado y revisa salidas. Tercer riesgo: permisos cruzados. La señal aparece cuando cobranza ve adjuntos técnicos o soporte edita deuda. La prueba usa cuatro usuarios y fuerza lectura, edición y cierre. Cuarto riesgo: backup sin archivos. La guía de restauración separa base y archivos; la prueba recupera ticket, historial y foto. La cooperativa sabe que ordeno la mesa cuando un reclamo viejo vuelve completo.