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

Un sistema de tickets de soporte convierte peticiones dispersas —correos, mensajes, «preguntas rápidas» por el pasillo— en tickets: un registro por problema, con un responsable, un estado, una prioridad y la conversación completa. Para crear uno necesitas una forma de crear tickets, una cola compartida con filtros, asignación, un hilo que separe las respuestas públicas de las notas internas, y notificaciones para que nadie se quede esperando. Un creador de apps con IA puede construir una primera versión sólida para un servicio interno de TI, RR. HH. o mantenimiento en una tarde. El soporte al cliente con agrupación de correos, tiempos de respuesta objetivo e informes requiere más cuidado, y es donde los productos de soporte consolidados se ganan su precio.

Lo que necesita el sistema

Datos

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

Páginas

• Solicitante: un formulario de «enviar 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, la vista del ticket con controles para responder, anotar, cambiar el estado, la prioridad y el responsable.
• Administrador: 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 los sistemas de soporte, así que aplícalo en el servidor, no solo ocultando una pestaña. Consulta control de acceso basado en roles.

Decisiones y compromisos

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 —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 agrupación para que las respuestas se asocien al ticket correcto (normalmente un número de ticket en el asunto o una dirección de respuesta única). Empieza con el formulario; 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; turno rotatorio 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 objetivo

Define dos o tres prioridades con un objetivo para la 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. Los horarios laborables complican las cuentas: decide pronto si los objetivos cuentan las noches y los fines de semana.

Fusiones y duplicados

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

Un primer prompt que funciona

Crea un servicio interno de soporte de TI para una empresa de 60 personas. Los empleados envían solicitudes con un formulario: asunto, categoría (hardware, software, accesos, red, otros), 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 para sin asignar, mis tickets y todos los abiertos, filtros por categoría, prioridad y estado, y búsqueda. La página del ticket muestra el hilo con respuestas públicas y 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 el tiempo desde la última actualización en cada ticket. Los empleados tienen una página de «mis solicitudes». Roles: empleado, agente, administrador. Guárdalo todo en una base de datos. Una interfaz sobria, densa y rápida: velocidad por encima de decoración.

Pasos de construcción

1. Modelo de 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. Notificaciones. Enviar un correo al solicitante con las respuestas públicas y al agente con las nuevas asignaciones, a través de tu propio proveedor de correo.
6. Respuestas predefinidas y fusión.
7. Tiempos objetivo y un informe básico: tickets abiertos por antigüedad, tiempo de primera respuesta, tickets por categoría.
8. Entrada por correo, una vez que lo demás funcione, con la agrupación probada a fondo.
9. Piloto con un equipo durante dos semanas antes de pasar a todos.

Errores comunes

• Notas internas visibles para los solicitantes porque solo estaban ocultas en la interfaz.
• Demasiados estados y categorías. Los agentes eligen el primero que parece encajar. Empieza con cinco de cada como máximo.
• Sin marcas de tiempo para la primera respuesta y la resolución. Querrás esos números el día que alguien pregunte «¿estamos respondiendo más rápido?».
• Las respuestas por correo crean tickets nuevos en lugar de agruparse. Prueba responder desde la app de correo del teléfono, que a menudo cambia el asunto.
• Todos asignados, 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 quienes pueden ver el ticket.

Cuándo es mejor un producto ya hecho

Para el soporte a clientes a través de correo, chat y redes sociales —con seguimiento de tiempos objetivo, encuestas de satisfacción, macros, informes e integraciones—, un producto de soporte especializado casi siempre es la mejor inversión. Esos productos llevan años trabajando en la agrupación de correos, 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 las opciones.

Una solución a medida encaja con las mesas internas (TI, RR. HH., mantenimiento, peticiones de finanzas), con flujos de trabajo específicos en los que un ticket es realmente un trabajo 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 vez en cuando. La guía de herramientas internas cubre esa categoría con más amplitud.

Crearlo con Mythex

En Mythex describes el sistema de soporte en el chat, lo revisas en una vista previa en directo y lo publicas para tu equipo. Los tickets viven en una base de datos Postgres que el agente añade cuando los datos necesitan guardarse, 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 mediante un espacio de trabajo compartido, sin tarifas por puesto en Mythex.

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

Preguntas