Sistema de tickets automático para pymes
Cómo montar un sistema de tickets automático: canales, campos, estados, prioridades, SLA internos, automatizaciones y errores comunes.
Actualizado el
Un sistema de tickets automático convierte solicitudes dispersas en trabajo visible. Cada incidencia deja de vivir en una bandeja de entrada, un WhatsApp o la memoria de una persona y pasa a tener identificador, responsable, prioridad, estado y fecha de seguimiento.
Para una pyme, esto no es solo atención al cliente. También sirve para incidencias internas, soporte técnico, solicitudes de administración, cambios de proyecto, peticiones de clientes o tareas recurrentes que hoy se pierden entre mensajes.
La herramienta importa, pero el proceso importa más. Si no defines campos, estados y reglas, un help desk solo será otra bandeja de entrada.
Resumen
Un sistema de tickets automático sirve para que ninguna solicitud dependa de memoria, chats sueltos o bandejas personales. La clave es definir canales, estados, prioridades y responsables antes de añadir automatizaciones.
Qué es un ticket
Un ticket es una solicitud convertida en registro. Zendesk documenta campos estándar como requester, assignee, subject, description, status, type, priority y tags (Zendesk, ticket fields). No necesitas copiar exactamente su modelo, pero sí entender la lógica: cada solicitud debe poder clasificarse, asignarse y resolverse.
Campos mínimos para empezar:
| Campo | Función |
|---|---|
| ID | Identificar la solicitud |
| Solicitante | Saber quién pide |
| Canal | Email, formulario, WhatsApp, interno |
| Asunto | Resumen corto |
| Descripción | Contexto suficiente |
| Prioridad | Orden de atención |
| Responsable | Quién actúa |
| Estado | En qué fase está |
| Fecha de creación | Medir antigüedad |
| Fecha objetivo | Evitar olvidos |
Sin estos campos, no hay sistema. Hay mensajes.
Cuándo necesitas ticketing
No todas las empresas necesitan una herramienta completa. Pero si reconoces varias de estas señales, conviene actuar:
- clientes escriben a cuentas personales
- no sabes cuántas incidencias hay abiertas
- dos personas responden lo mismo
- nadie sabe si un problema se resolvió
- las urgencias se mezclan con preguntas menores
- soporte depende de una persona
- no puedes medir tiempos de respuesta
- se pierden solicitudes por WhatsApp
Un sistema de tickets reduce ambigüedad. No garantiza buen servicio por sí solo, pero permite ver qué está pasando.
Paso 1: define canales de entrada
Empieza por pocos canales. Por ejemplo:
| Canal | Recomendación |
|---|---|
| Email soporte | Bueno para incidencias generales |
| Formulario web | Bueno para capturar campos obligatorios |
| Útil pero difícil de controlar sin integración | |
| Teléfono | Debe convertirse en ticket manual |
| Interno | Para solicitudes de equipo |
Si aceptas incidencias por cualquier canal y nadie las registra, el sistema nace incompleto. La regla debe ser: todo lo que requiera seguimiento acaba como ticket.
También conviene distinguir canal de conversación y sistema de registro. Un cliente puede escribir por email o WhatsApp, pero la solicitud importante debe acabar registrada en el sistema. Si el equipo responde por el canal original pero actualiza el ticket, mantienes cercanía sin perder trazabilidad.
Paso 2: crea estados simples
Zendesk describe un ciclo de vida con estados como New, Open, Pending, On-hold, Solved y Closed (Zendesk, ticket lifecycle). Zoho Desk agrupa estados en abiertos, en espera y cerrados (Zoho Desk).
Para una pyme, puedes empezar con:
| Estado | Uso |
|---|---|
| Nuevo | Recibido, sin revisar |
| En curso | Asignado y trabajando |
| Esperando cliente | Falta información del cliente |
| Esperando tercero | Depende de proveedor u otra área |
| Resuelto | Solución propuesta |
| Cerrado | Confirmado o sin acción pendiente |
Evita estados ambiguos como “mirar”, “pendiente varios” o “luego”. Si el estado no ayuda a decidir, sobra.
Paso 3: define prioridades
Prioridad no es quien grita más. Debe mezclar impacto y urgencia.
| Prioridad | Ejemplo | Tiempo objetivo |
|---|---|---|
| Alta | Servicio parado, cliente clave afectado | Respuesta rápida |
| Media | Incidencia que afecta trabajo pero tiene alternativa | Mismo día o siguiente |
| Baja | Duda, mejora o solicitud no urgente | Según capacidad |
Freshdesk muestra en su vista de ticket propiedades como estado, prioridad, agente/grupo y fechas objetivo calculadas por reglas SLA (Freshdesk). No hace falta prometer SLA complejos desde el primer día, pero sí conviene tener tiempos internos.
Paso 4: asigna responsables
Cada ticket debe tener dueño. Puede ser una persona o grupo, pero no “equipo” en abstracto.
Reglas útiles:
- nuevo ticket se asigna a bandeja de triage
- prioridad alta avisa al responsable
- tickets sin asignar se revisan dos veces al día
- tickets esperando cliente se revisan antes de cerrar
- tickets reabiertos vuelven a prioridad visible
La automatización puede asignar por categoría, cliente, canal o horario. Pero siempre debe haber forma de corregir manualmente.
Para equipos pequeños, una bandeja de triage suele funcionar mejor que asignar todo automáticamente desde el primer día. Una persona revisa tickets nuevos en horarios concretos, completa campos y asigna. Cuando el patrón sea claro, entonces puedes automatizar categorías recurrentes.
Si ves claro que se pierden solicitudes pero no sabes qué canales aceptar ni quién debería clasificarlas, podemos revisar cómo entran hoy tus incidencias y dónde se pierden antes de que elijas herramienta.
Paso 5: automatiza acciones básicas
Automatizaciones útiles:
| Evento | Acción |
|---|---|
| Nuevo formulario | Crear ticket con campos obligatorios |
| Email a soporte | Crear ticket y responder acuse |
| Prioridad alta | Avisar en Slack/Teams |
| Sin respuesta cliente | Recordatorio |
| Ticket resuelto | Enviar confirmación |
| Ticket cerrado | Pedir feedback opcional |
| Repetición de tema | Crear artículo de ayuda |
HubSpot documenta que los tickets pueden crearse desde el índice, un registro, help desk, workflows o un formulario de soporte (HubSpot, create tickets). Ese tipo de entrada múltiple es útil, pero solo si todas las solicitudes terminan en una vista común.
Paso 6: valida el sistema
Antes de lanzarlo a todo el equipo, prueba con diez tickets reales.
Comprueba:
- todos tienen solicitante
- todos tienen responsable
- la prioridad se entiende
- los estados no se atascan
- las notificaciones llegan
- el cliente recibe confirmación
- el equipo sabe qué hacer
- se puede encontrar el historial
Si algo falla en diez tickets, fallará mucho más con cien.
Prueba de extremo a extremo
Haz una prueba como si fueras cliente:
- Envía una solicitud por el canal principal.
- Comprueba que se crea ticket.
- Revisa el mensaje de confirmación.
- Asigna responsable.
- Cambia prioridad.
- Pide información al cliente.
- Resuelve el ticket.
- Cierra y localiza el historial.
Esta prueba revela detalles que no aparecen en la configuración: asuntos poco claros, notificaciones excesivas, estados confusos o respuestas automáticas frías.
Documenta reglas internas
Un sistema de tickets necesita una guía breve para el equipo.
| Regla | Ejemplo |
|---|---|
| Qué se registra | Toda solicitud que requiere seguimiento |
| Quién clasifica | Responsable de triage |
| Cómo se prioriza | Impacto + urgencia |
| Cuándo se cierra | Resuelto y sin acción pendiente |
| Cómo se reabre | Nueva respuesta del cliente o fallo confirmado |
Sin reglas, cada persona interpreta el sistema a su manera.
Herramientas posibles
| Herramienta | Encaje habitual | Cuidado con |
|---|---|---|
| HubSpot Tickets | Empresas que ya usan HubSpot CRM | Planes y configuración |
| Zendesk | Soporte con volumen y procesos maduros | Complejidad inicial |
| Freshdesk | Help desk generalista para pymes | Definir bien SLA y campos |
| Zoho Desk | Ecosistema Zoho | Personalización y adopción |
| Notion/Trello/ClickUp | Equipos pequeños internos | Menos estructura de soporte |
No elijas por lista de funcionalidades. Elige por canal, volumen, trazabilidad, integraciones y capacidad del equipo para mantenerlo.
Automatizaciones avanzadas con cuidado
Cuando el sistema básico funciona, puedes añadir automatizaciones más finas:
- etiquetar por cliente o producto
- detectar palabras clave de urgencia
- avisar si un ticket supera tiempo interno
- crear tareas técnicas desde ciertos tickets
- sugerir artículos de ayuda
- agrupar incidencias repetidas
- generar resumen interno antes de escalar
La IA puede ayudar a resumir conversaciones o sugerir categoría, pero no debería cerrar tickets sensibles sin supervisión. En soporte, una respuesta rápida pero incorrecta puede costar más que una respuesta algo más lenta y bien revisada.
KPIs de soporte
| KPI | Por qué importa |
|---|---|
| Tickets abiertos | Carga actual |
| Tickets sin asignar | Riesgo de pérdida |
| Tiempo de primera respuesta | Experiencia inicial |
| Tiempo hasta resolución | Eficiencia |
| Tickets reabiertos | Calidad de resolución |
| Temas repetidos | Oportunidad de documentación |
| Tickets por cliente | Riesgo o mala implantación |
Mide para mejorar, no para castigar. Si el equipo teme los KPIs, tenderá a manipular estados.
Errores frecuentes
El primer error es crear demasiadas categorías. Si el agente tarda más en clasificar que en responder, el sistema estorba.
El segundo es usar prioridad como etiqueta emocional. Todo no puede ser urgente.
El tercero es no cerrar tickets. Un ticket resuelto pero abierto distorsiona métricas y genera ruido.
El cuarto es dejar WhatsApp fuera. Si clientes siguen escribiendo por WhatsApp y nadie registra esas solicitudes, el help desk no representa la realidad.
El quinto es no crear base de conocimiento. Si la misma pregunta aparece cada semana, no basta con responderla cada vez: hay que documentarla.
Cuándo no automatizar todavía
Es mejor esperar si no sabes qué canales quieres aceptar, no hay responsable de soporte, nadie revisará la bandeja o el equipo no acepta registrar solicitudes. Primero acuerda reglas mínimas.
También conviene empezar pequeño. Un formulario, una bandeja de soporte y tres estados bien usados pueden aportar más que una herramienta compleja mal implantada.
Si quieres que las incidencias dejen de perderse entre correos y mensajes, podemos ordenar tu soporte e incidencias con Intención y diseñar un flujo de tickets sostenible.
Preguntas frecuentes
¿Cómo consigo que los clientes dejen de escribir al móvil de una persona?
Prohibirlo no funciona; redirigir, sí. Cuando llegue un mensaje al privado, contesta desde la cuenta de soporte con una frase corta (“te sigo por aquí, así queda registrado y te responde quien esté disponible”) y pon esa dirección en firmas, facturas y web. En dos o tres semanas el cliente aprende el camino, sobre todo si por ahí le contestan antes.
¿Cuántas categorías conviene crear al arrancar?
Tres o cinco, sacadas de leer las solicitudes de los dos últimos meses y no imaginadas en una reunión. Añade una categoría “otros” y revísala al mes: si acumula muchos tickets, ahí está la categoría que falta. Abrir una categoría nueva cuesta menos que retirar quince que nadie usa.
¿Qué hago con las incidencias que ya están abiertas cuando arranco?
Pon una fecha de corte y da de alta a mano solo las que sigan vivas, cada una con una línea de contexto y su responsable. El histórico cerrado se queda donde está: buscar un hilo antiguo en el correo las pocas veces que haga falta cuesta menos que volcar años de conversaciones y estrenar el sistema con ruido.