Zammad en mesa de ayuda: tickets, roles y respaldo
Guía técnica para ordenar soporte con Zammad: canales, grupos, permisos, SLA, API, costos y restauración antes de depender del buzón compartido.
El ticket falla cuando una respuesta queda en el buzón de una sola persona y el resto de soporte no ve el estado. Zammad 7.0 permite convertir correos, formularios, teléfono o chat en tickets con grupos, roles, SLA y API. Esta guía explica dónde vive el dato, quién puede cambiarlo, qué respaldo se prueba y cuánto cuesta una mesa de ayuda abierta.
Dónde aparece el buzón compartido
La cifra que corrige la costumbre viene de GitHub: el repositorio zammad/zammad supera las 5.000 estrellas y publica su código con licencia AGPL-3.0. La versión 7.0 fue anunciada el 4 de marzo de 2026 y la documentación mantiene API, roles, grupos, backup y requisitos de hardware. Para una pyme, esa combinación alcanza para probar sin atarse al correo personal. Un ticket necesita estado visible. La documentación de Zammad define una API REST qué permite las mismas operaciones disponibles en la interfaz. Los roles controlan permisos, los grupos ordenan colas y el backup guarda base y archivos. El dato global da escala al criterio: GitHub informó en Octoverse 2025 más de 1.120 millones de contribuciones a proyectos públicos y abiertos durante el período medido. La mesa de ayuda también se beneficia de proyectos mantenidos en público.
Cómo funciona por dentro
El flujo empieza en el canal de entrada. Un correo, formulario o llamada crea un ticket con asunto, solicitante, organización, prioridad y adjuntos. Zammad recibe ese dato, lo asigna a un grupo y muestra estado, agente y conversación. Si el canal falla, la señal aparece como correo recibido sin ticket o ticket sin solicitante. El segundo paso clasifica. Los grupos separan soporte interno, sistemas, facturación o mantenimiento. Los roles deciden quién lee, responde, reasigna, cierra o administra objetos. Un agente puede responder tickets de su grupo; supervisión mira reportes; administración técnica cambia plantillas y usuarios. Si falla el permiso, aparece un agente cerrando tickets de otra cola. El tercer paso guarda datos. Zammad usa base de datos, índice de búsqueda y almacenamiento de adjuntos. PostgreSQL guarda registros estructurados si se configura como base; Elasticsearch u OpenSearch ayudan a buscar conversaciones; el sistema de archivos o volumen guarda adjuntos. La API entrega tickets, usuarios, organizaciones, estados y eventos para integraciones. El cuarto paso controla tiempo. SLA y estados muestran cuándo un ticket está abierto, pendiente o cerrado. El quinto paso audita: cada respuesta y cambio de estado queda en el historial. El sexto paso respalda: base, archivos, configuración y secretos se copian; la restauración reinicia el servicio y permite abrir un ticket cerrado con adjuntos.
Qué se instala o configura primero
La pila mínima usa Zammad, PostgreSQL 17, índice de búsqueda compatible, proxy HTTPS, correo entrante y saliente, grupos, roles, backup y monitoreo. Con dólar oficial vendedor de $ 1.495, un servidor de USD 25 a USD 70 por mes equivale a $ 37.375 a $ 104.650 mensuales. Una implementación de USD 850 a USD 1.800 queda entre $ 1,27 y $ 2,69 millones. Incluye tres colas, diez usuarios, plantillas de respuesta, dos SLA, importación de contactos, tablero inicial y restauración. No incluye call center ni migración histórica completa. UMSA puede empezar con soporte interno de sistemas o mesa de mantenimiento: correo, grupo, responsable, estado y cierre. El primer entregable verificable es abrir el mismo caso desde correo y ver ticket, agente, permiso y recuperación. El objeto concreto es una etiqueta adhesiva en un monitor de recepción con el número viejo de soporte. Ese número debe terminar en un canal registrado, no en un chat suelto. La capacitación termina con una prueba de turno. Un usuario crea un ticket, un agente lo reasigna, supervisión mira el vencimiento y sistemas restaura el caso. La salida esperada es historial completo, adjunto intacto y permisos separados. La mesa también necesita nombres de estado simples. Abierto indica trabajo pendiente, pendiente indica espera externa y cerrado indica respuesta aceptada o tarea terminada. Si cada área inventa estados, el reporte mensual suma tickets que no significan lo mismo.
Dónde se rompe y cómo probarlo
El primer riesgo es correo sin ruta. La señal aparece cuando llegan mensajes a una casilla que Zammad no importa. La prueba envía cinco correos con adjuntos y exige cinco tickets con solicitante. El segundo riesgo es grupo mal definido. La señal aparece cuando todo cae en una cola general. La prueba crea casos de sistemas y facturación, revisa asignación y mide tiempo de primera respuesta. El tercer riesgo es permiso de cierre abierto. La señal aparece cuando un agente nuevo cierra tickets críticos. La prueba entra con rol limitado, intenta cerrar un caso de otra cola y registra rechazo. El cuarto riesgo es respaldo sin adjuntos. La prueba restaura base, índice, archivos y configuración en otro servidor. Una mesa de ayuda funciona cuando una persona nueva puede leer el historial y seguir el caso sin pedir capturas.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.