Cómo crear un sistema de tickets de soporte: tickets, estados, asignación y correo

Un sistema de tickets de soporte convierte las peticiones dispersas (correos, mensajes, «una pregunta rápida» en el pasillo) en tickets: un registro por problema, con un responsable, un estado, una prioridad y la conversación completa. Para crearlo necesitas una forma de abrir tickets, una cola compartida con filtros, asignación, un hilo que separe las respuestas públicas de las notas internas y avisos para que nadie se quede esperando. Un creador de apps con IA puede construir una primera versión sólida para una mesa interna de TI, RRHH o mantenimiento en una tarde. El soporte a clientes, con hilos de correo, tiempos de respuesta e informes, exige más cuidado y es donde los productos de helpdesk consolidados se ganan su precio.

Lo que necesita el sistema

Datos

Guarda desde el principio las marcas de tiempo de la primera respuesta y de la resolución. Son la base de todos los informes, y no se pueden reconstruir después.

Páginas

• Solicitante: un formulario para «enviar una solicitud» con categoría y adjuntos, una lista de «mis solicitudes» y el hilo de cada ticket.
• Agente: la cola (mis tickets, sin asignar, todos los abiertos), filtros y búsqueda, y la vista del ticket con controles para responder, anotar, cambiar el estado, la prioridad y el responsable.
• Administración: categorías, equipos, agentes, respuestas predefinidas y un informe sencillo.

Permisos

Los solicitantes solo ven sus propios tickets y solo las respuestas públicas. Los agentes ven los tickets de su equipo y las notas internas. Los responsables y administradores lo ven todo y gestionan la configuración. Que una nota interna llegue a un cliente es el desastre clásico de un helpdesk, así que aplícalo en el servidor, no solo ocultando una pestaña. Consulta control de acceso por roles.

Decisiones y compensaciones

Formulario, correo o ambos

Un formulario web es lo más sencillo y te da datos limpios: categoría, prioridad y campos obligatorios. La entrada por correo, en la que la gente escribe a soporte@ y aparece un ticket, es lo que esperan los clientes, pero necesita un proveedor de correo que pueda recibir mensajes y enviarlos a tu app, además de hilos que unan las respuestas al ticket correcto (normalmente un número de ticket en el asunto o una dirección de respuesta única). Empieza con el formulario y añade el correo cuando el flujo de trabajo esté probado. Enviar correo desde tu app cubre la parte de salida.

Asignación

Opciones: los agentes eligen de la cola sin asignar; reparto por turnos dentro de un equipo; o asignación por categoría. Elegir de la cola funciona para equipos pequeños. La asignación automática ayuda cuando los tickets se quedan sin dueño.

Prioridades y tiempos de respuesta

Define dos o tres prioridades con un objetivo de primera respuesta («urgente: 1 hora; normal: 1 día laborable»). Mostrar el tiempo restante en cada ticket es más útil que un informe mensual que nadie lee. El horario laboral complica las cuentas: decide pronto si los objetivos cuentan las noches y los fines de semana.

Fusionar y duplicados

Es habitual que el mismo problema se reporte tres veces. Una acción «fusionar con el ticket n.º» evita que los agentes respondan lo mismo una y otra vez; merece la pena construirla pronto.

Un primer prompt que funciona

Crea un helpdesk interno de TI para una empresa de 60 personas. Los empleados envían solicitudes con un formulario: asunto, categoría (hardware, software, accesos, red, otra), prioridad (baja, normal, urgente), descripción y adjuntos. Cada ticket recibe un número y los estados nuevo, abierto, esperando al solicitante, resuelto y cerrado. Los agentes de TI ven una cola con pestañas de sin asignar, míos y todos los abiertos, filtros por categoría, prioridad y estado, y búsqueda. La página del ticket muestra el hilo con las respuestas públicas y las notas internas claramente separadas; los empleados nunca ven las notas internas. Los agentes pueden asignar, cambiar el estado y la prioridad, usar respuestas predefinidas y fusionar duplicados. Registra los tiempos de primera respuesta y de resolución y muestra en cada ticket el tiempo desde la última actualización. Los empleados tienen una página de «mis solicitudes». Roles: empleado, agente, administrador. Guárdalo todo en una base de datos. Interfaz sobria, densa y rápida: la velocidad por encima de la decoración.

Pasos de construcción

1. Modelo del ticket y formulario. Enviar, listar, abrir un ticket, responder.
2. Cola y filtros. Sin asignar, míos, todos los abiertos; filtrar y buscar; ordenar por prioridad y antigüedad.
3. Roles e inicio de sesión. Solicitante, agente, administrador, con las notas ocultas a los solicitantes en el servidor.
4. Controles de asignación, estado y prioridad, con un registro de actividad de cada cambio.
5. Avisos. Enviar un correo al solicitante en las respuestas públicas y al agente en las nuevas asignaciones, a través de tu propio proveedor de correo.
6. Respuestas predefinidas y fusión.
7. Tiempos objetivo e informe básico: tickets abiertos por antigüedad, tiempo de primera respuesta, tickets por categoría.
8. Entrada por correo, cuando lo demás funcione, con los hilos probados a fondo.
9. Piloto con un equipo durante dos semanas antes de pasar a todos.

Errores habituales

• Notas internas visibles para los solicitantes porque solo se ocultaban en la interfaz.
• Demasiados estados y categorías. Los agentes eligen el primero que se parece. Empieza con cinco de cada como máximo.
• Sin marcas de tiempo de la primera respuesta y de la resolución. Querrás esos números el día que alguien pregunte «¿vamos más rápido?».
• Que las respuestas por correo creen tickets nuevos en lugar de unirse al hilo. Prueba a responder desde la app de correo del móvil, que a menudo cambia el asunto.
• Todos asignados y nadie responsable. Un solo responsable por ticket; usa observadores para el resto.
• Adjuntos con URL públicas. Las capturas de mensajes de error suelen contener datos privados. Mantén los archivos privados y sírvelos solo a quien pueda ver el ticket.

Cuándo es mejor un producto ya hecho

Para el soporte a clientes en correo, chat y redes sociales, con seguimiento de tiempos de respuesta, encuestas de satisfacción, macros, informes e integraciones, un producto de helpdesk especializado es casi siempre la mejor inversión. Esos productos llevan años trabajando en la unión de hilos de correo, el spam, el enrutamiento y los informes, y no es la parte de tu negocio que te diferencia. Nuestra guía de alternativas a Zendesk compara opciones.

Una solución a medida encaja con las mesas internas (TI, RRHH, mantenimiento, solicitudes de finanzas), con flujos de trabajo de nicho en los que un ticket es realmente un encargo con pasos concretos, y con equipos que quieren que las solicitudes se conecten con otros datos que ya guardan. También evita pagar por agente cuando mucha gente atiende tickets de forma ocasional. La guía de herramientas internas cubre esa categoría con más amplitud.

Crearlo con Mythex

En Mythex describes el helpdesk en el chat, lo revisas en la vista previa en directo y lo publicas para tu equipo. Los tickets se guardan en una base de datos Postgres que el agente añade cuando hay que guardar datos, y los adjuntos van al almacenamiento de archivos del proyecto. Los inicios de sesión de solicitantes y agentes, y todo el correo de entrada y salida, usan tus propios proveedores: Mythex no tiene un producto integrado de inicio de sesión de usuarios finales ni de correo. La receta de envío de correo muestra el enfoque. Los miembros del equipo pueden ayudar a crearlo a través de un espacio de trabajo compartido, sin cuotas por puesto en Mythex.

Para un prompt inicial, prueba las plantillas de cola de solicitudes internas o de gestor de errores, y combina el helpdesk con una base de conocimiento para que las preguntas frecuentes se respondan solas.

Preguntas