Cómo implementar un sistema de gestión de tickets y soporte técnico con Drupal

Zendesk cobra entre 19 y 115 euros por agente al mes. Freshdesk, Jira Service Management, Zoho Desk... todos repiten el mismo modelo de suscripción que escala con cada agente y cada bandeja de entrada. Para una empresa con 10 agentes de soporte, la factura anual puede superar los 13.000 euros sin contar complementos. Y los datos del cliente --conversaciones, tiempos de respuesta, históricos-- quedan en servidores de un tercero, sujetos a términos de servicio que cambian cuando les apetece.

Drupal plantea una alternativa más sensata: un sistema de tickets propio, alojado en infraestructura que controlas tú, adaptable a tus flujos de trabajo y sin coste por agente. No es lo más rápido de desplegar --requiere configuración-- pero a medio plazo compensa en flexibilidad, propiedad de datos y ahorro acumulado.

Qué necesita un sistema de tickets funcional

Antes de hablar de módulos, definamos los requisitos mínimos de un helpdesk operativo:

1. Formulario de apertura de ticket. El cliente describe el problema, adjunta capturas y selecciona categoría y prioridad.
2. Asignación automática o manual. El ticket llega al agente correcto según la categoría, la carga de trabajo o las reglas de turno.
3. Estados y transiciones. Abierto, en progreso, esperando respuesta del cliente, resuelto, cerrado. Cada transición puede disparar notificaciones.
4. Comunicación bidireccional. El agente responde desde el backoffice; el cliente recibe la respuesta por email y puede contestar sin entrar en el portal.
5. SLA (Service Level Agreement). Tiempos máximos de primera respuesta y de resolución según prioridad. Alertas cuando un ticket está a punto de incumplir el SLA.
6. Base de conocimiento. Artículos de ayuda que reducen el volumen de tickets que necesitan intervención humana.
7. Métricas. Tiempo medio de respuesta, tiempo de resolución, volumen por categoría, satisfacción del cliente (CSAT).

Arquitectura en Drupal: tipos de contenido y campos

Tipo de contenido: Ticket

Campo	Tipo	Notas
Asunto	Text (plain)	Título del ticket
Descripción	Text (formatted, long)	Detalle del problema con editor WYSIWYG
Categoría	Entity Reference (Taxonomy)	Facturación, Incidencia técnica, Consulta general, Solicitud de cambio
Prioridad	List (text)	Baja, Media, Alta, Crítica
Estado	List (text)	Controlado por el módulo Workflows
Agente asignado	Entity Reference (User)	Filtrado por rol "Agente de soporte"
Adjuntos	File	Múltiple, con restricción de extensiones (png, jpg, pdf, zip)
Cliente	Entity Reference (User)	Autocompletado, rellenado automáticamente si el usuario está autenticado
Canal de origen	List (text)	Web, Email, Teléfono, API
SLA - Primera respuesta	Datetime	Calculado automáticamente al crear el ticket
SLA - Resolución	Datetime	Calculado según prioridad
Referencia externa	Text (plain)	Para vincular con IDs de otros sistemas

Tipo de contenido: Respuesta de ticket

En lugar de usar los comentarios nativos de Drupal --que tienen limitaciones serias de formato y permisos--, es mejor crear un tipo de contenido "Respuesta" vinculado al ticket mediante Entity Reference. Cada respuesta tiene:

• Cuerpo del mensaje (texto formateado).
• Autor (agente o cliente).
• Visibilidad: pública (el cliente la ve) o interna (solo agentes).
• Adjuntos.
• Timestamp.

El módulo Inline Entity Form permite a los agentes añadir respuestas directamente desde la página de edición del ticket, sin cambiar de pantalla.

Flujo de estados con Workflows

Drupal 10 incluye en el core los módulos Workflows y Content Moderation. Aunque fueron diseñados para flujos editoriales, se adaptan bien a un sistema de tickets:

• Nuevo. Estado inicial al crear el ticket.
• Asignado. Un agente toma el ticket o el sistema lo asigna automáticamente.
• En progreso. El agente está trabajando en la resolución.
• Esperando cliente. Se ha solicitado información adicional. El SLA de resolución se pausa.
• Resuelto. El agente marca el ticket como solucionado.
• Cerrado. El cliente confirma la resolución o pasan 72 horas sin respuesta.
• Reabierto. El cliente responde tras el cierre. Vuelve a "En progreso".

Las transiciones se definen en Configuration > Workflow > Transitions. Cada transición puede restringirse por rol: un cliente solo puede mover de "Resuelto" a "Reabierto"; un agente no puede cerrar directamente sin pasar por "Resuelto".

Automatización con ECA y Rules

El módulo ECA (Event-Condition-Action), sucesor espiritual de Rules para Drupal 10, permite automatizar sin escribir código. Las automatizaciones no cuestan extra ni vienen bloqueadas en un plan premium.

Asignación automática por round-robin

• Evento: Creación de nodo tipo Ticket.
• Condición: El campo "Agente asignado" está vacío.
• Acción: Ejecutar una vista que devuelve el agente con menos tickets abiertos y asignarlo al campo. Enviar notificación al agente.

Escalado por SLA

• Evento: Cron (cada 5 minutos).
• Condición: Tickets donde el campo "SLA - Primera respuesta" es anterior a la hora actual Y el estado sigue en "Nuevo" o "Asignado".
• Acción: Cambiar prioridad a "Crítica". Enviar email al supervisor del equipo. Crear entrada en el log de escalados.

Cierre automático

• Evento: Cron (diario).
• Condición: Tickets en estado "Resuelto" con última actividad hace más de 72 horas.
• Acción: Cambiar estado a "Cerrado". Enviar encuesta de satisfacción al cliente.

Notificación al cliente

• Evento: Creación de nodo tipo "Respuesta de ticket" con visibilidad "Pública".
• Condición: Ninguna adicional.
• Acción: Enviar email al cliente con el contenido de la respuesta y un enlace al ticket.

Recepción de tickets por email

Muchos clientes prefieren enviar un email a soporte@empresa.es antes que rellenar un formulario web. El módulo Mailhandler cubre ese canal:

1. Configurar una conexión IMAP al buzón de soporte.
2. Parsear los emails entrantes y crear tickets automáticamente.
3. Detectar respuestas a hilos existentes (por el campo In-Reply-To del header) y añadirlas como nuevas respuestas al ticket correspondiente.
4. Extraer adjuntos y vincularlos al ticket.

Con Mailhandler y ECA combinados, el cliente gestiona todo su soporte por email sin acceder al portal, mientras que el agente trabaja desde una interfaz estructurada con estados, prioridades y métricas.

Panel del agente con Views

El módulo Views del core permite construir cuadros de mando operativos. Estos son los tres que monto siempre:

Vista: "Mis tickets abiertos"

• Filtro: Agente asignado = usuario actual, Estado != Cerrado.
• Ordenación: SLA - Primera respuesta (ascendente), para que los más urgentes aparezcan arriba.
• Columnas: ID, Asunto, Cliente, Prioridad, Estado, Tiempo restante SLA.
• Formato: tabla con filtros expuestos por prioridad y categoría.

Vista: "Tickets sin asignar"

• Filtro: Agente asignado = vacío, Estado = Nuevo.
• Acción masiva (módulo Views Bulk Operations): seleccionar varios tickets y asignarlos a un agente con un clic.

Vista: "Dashboard del supervisor"

• Sin filtro de agente. Agrupación por agente asignado.
• Campos calculados: número de tickets abiertos por agente, tiempo medio de respuesta (requiere un campo computado o una vista con agregación).
• Gráfico de volumen diario con el módulo Charts (soporta Chart.js y Google Charts).

Base de conocimiento integrada

Reducir el volumen de tickets es tan importante como resolverlos rápido. Una base de conocimiento bien mantenida puede desviar entre un 20 y un 40 % de las consultas, según datos de HDI (Help Desk Institute).

En Drupal:

• Crear un tipo de contenido "Artículo de ayuda" con campos: título, cuerpo, categoría (misma taxonomía que los tickets), módulo/producto afectado, etiquetas.
• Usar Search API con Solr o Database Search para un buscador con relevancia, autocompletado y facetas.
• Configurar un bloque "Artículos relacionados" en la página de creación de tickets: antes de enviar, el cliente ve sugerencias basadas en las palabras clave del asunto. El módulo Search API Autocomplete facilita esta funcionalidad.
• Registrar qué artículos resuelven la consulta sin necesidad de abrir ticket (campo "¿Te ha resultado útil?" con Voting API o Fivestar).

Métricas y reporting

Un sistema de tickets sin métricas es una bandeja de entrada glorificada. Las métricas esenciales:

Métrica	Cómo obtenerla
MTTR (Mean Time to Resolve)	Vista con agregación: promedio de diferencia entre fecha de creación y fecha de cambio a "Resuelto".
MTFR (Mean Time to First Response)	Promedio de diferencia entre fecha de creación del ticket y fecha de la primera respuesta pública.
Volumen por categoría	Vista con agrupación por taxonomía de categoría y conteo.
Cumplimiento de SLA	Porcentaje de tickets resueltos antes del deadline de SLA. Campo calculado o vista con filtro condicional.
CSAT	Encuesta post-cierre con Webform. Escala 1-5. Promedio mensual.
Tickets reabiertos	Porcentaje de tickets que pasan de "Resuelto" a "Reabierto". Indicador de calidad de resolución.

Para reportes avanzados, Views Data Export permite exportar cualquier vista a CSV para analizar en Metabase o Google Looker Studio.

Seguridad y control de acceso

Un sistema de tickets contiene información sensible. Medidas imprescindibles:

• Permisos por rol. Los clientes solo ven sus propios tickets; los agentes, los de su equipo; los supervisores, todos. Configurable con Content Access o Group.
• Notas internas. Las respuestas marcadas como "internas" no se muestran al cliente ni se envían por email.
• Registro de actividad. El módulo Audit Log registra cambios de estado, reasignaciones y ediciones.
• Autenticación reforzada. TFA con TOTP para los agentes.

Integración con herramientas externas

Un sistema de tickets rara vez funciona aislado. Drupal conecta con:

• Slack / Microsoft Teams vía webhooks para notificar tickets nuevos o escalados al canal del equipo.
• CRM (HubSpot, Salesforce, SuiteCRM) mediante API REST, vinculando cada ticket al contacto comercial.
• Monitorización (Nagios, Zabbix, Uptime Robot) que puede abrir tickets automáticamente al detectar caídas, usando JSON:API de Drupal.

Para el rendimiento, activar Varnish como reverse proxy, usar Search API con Solr en lugar de búsquedas SQL directas y archivar tickets cerrados con más de 12 meses mantiene el sistema ágil con 100.000 registros.

Coste de implementación vs. SaaS

Una comparativa realista para una empresa con 15 agentes:

Concepto	SaaS (Zendesk Professional)	Drupal propio
Licencia / suscripción anual	~20.700 EUR	0 EUR (open source)
Hosting (VPS/cloud)	Incluido	~1.800 EUR/año
Desarrollo inicial	0 (configuración guiada)	8.000-15.000 EUR
Mantenimiento anual	Incluido	2.000-4.000 EUR
Coste a 3 años	~62.100 EUR	~19.400-28.600 EUR

El ahorro acumulado a tres años puede superar los 30.000 euros, y la empresa retiene la propiedad total del sistema y los datos.

Si tu empresa necesita un sistema de soporte que se adapte a vuestros flujos y no al revés, consultadnos para diseñar la arquitectura sobre Drupal.