Lo que la gente realmente quiere decir con "ejemplos de sistemas de tickets"
Dos búsquedas distintas llegan a la misma frase, y ambas son legítimas.
Algunas personas quieren ejemplos de sistemas: dime las herramientas, muéstrame las pantallas, dime cuál encaja con un equipo de soporte de 12 personas. Otras quieren ejemplos de tickets: cómo se ve un registro real una vez que llega, y qué pasa después con él. Yo trabajo en la cola de soporte de eesel, así que me importa sobre todo lo segundo, y tengo opiniones al respecto. La comparación de herramientas viene después de saber cómo es un buen ticket, por eso el resumen de software de sistema de tickets tiene más sentido después de este artículo que antes.
Esto es lo que tres años de colas en vivo me han enseñado: el registro del ticket es donde los equipos de soporte pierden dinero silenciosamente. No en la respuesta. En el ticket que quedó en Pending durante nueve días porque nadie definió quién lo cierra, en el campo de prioridad que cada solicitante marca como Urgent, en los dos tickets que eran el mismo problema abierto por dos personas distintas.
Esa diferencia no es cosmética. Zendesk incluye seis estados (New, Open, Pending, On-hold, Solved, Closed). Freshdesk incluye cuatro que no se pueden eliminar, y en HubSpot no hay ningún campo de estado, porque allí un ticket es un registro de CRM que avanza por un pipeline de soporte.
Jira Service Management apila tres objetos: un tipo de solicitud sobre un tipo de trabajo sobre un flujo de trabajo. Si te saltas la capa de tipo de solicitud, el elemento de trabajo pierde por completo el acceso a las funciones de mesa de servicio.
Elige el ejemplo que coincide con tu cola
Seis de los ocho ejemplos que siguen, tal como llegan. Recórrelos antes de leer las versiones largas.
Ocho ejemplos de sistemas de tickets, trabajados de principio a fin
Cada uno de los siguientes sigue la misma forma: la solicitud tal como llega, el registro que crea, el camino de estados y la trampa que muerde a los equipos en el tercer mes.
1. "¿Dónde está mi pedido?" en una cola de ecommerce
El ejemplo de mayor volumen en cualquier cola de retail, y el menos interesante de responder. Un cliente pega un número de pedido, el agente abre la pestaña del transportista, copia una fecha de vuelta. En Gorgias el pedido se sitúa en un panel lateral junto a la conversación, que es todo el argumento a favor de un helpdesk nativo de ecommerce frente a uno genérico.
El registro es escueto: solicitante, número de pedido, una etiqueta, una respuesta pública. El estado va de New a Open a Solved y casi nunca se reabre. Esta es la forma que hace que la gente compre seguimiento de pedidos con IA, porque la respuesta es una búsqueda, no un juicio. Si un tipo de ticket nunca necesita una opinión, no debería necesitar un agente.
La trampa está en la medición. Zendesk cuenta la resolución de un solo contacto como "tickets resueltos o cerrados con una única respuesta del agente o sin respuestas", según su documentación de resolución de un solo contacto, así que una cola llena de estos hace que tu equipo parezca más rápido de lo que es.
2. Un reembolso fuera del plazo de devolución
Este llega educado y se convierte en una decisión de política. El cliente está 11 días fuera del plazo de devolución y tiene una razón razonable.
El registro adquiere un estado de aprobación, que toma cuatro valores en los campos de tickets de Zendesk: Pending, Approved, Denied, Withdrawn. Muchos equipos añaden un estado personalizado como "Reembolso procesado" para que finanzas pueda filtrarlo después. Vale la pena saberlo antes de crearlo: Zendesk permite hasta 100 estados de ticket, pero "el selector de estados mostrará los primeros 10" según su documentación de gestión de estados, y un ticket resuelto con un estado personalizado conserva esa etiqueta después de cerrarse.
El camino de estados se desvía por Pending mientras esperas fotos o una confirmación de pedido, y Pending es donde los tickets de reembolso van a morir. Freshdesk restablece un ticket a Open "cada vez que un cliente responde", lo cual es útil, pero nada rescata el ticket cuyo cliente nunca vuelve a responder. Automatizar la redacción está bien aquí, según nuestro recorrido de automatización de reembolsos. Automatizar la decisión de la excepción, no.
3. Restablecimiento de contraseña y bloqueo por MFA
El ticket más comentado en TI, y el que tiene el mayor rango de costes. La misma pregunta, seis puertas de entrada:
Las cifras de HDI de 2021 sitúan la autoayuda en 2,37 $ y el mostrador presencial en 37,52 $, una diferencia que los autores del análisis de costes de HDI describen como "más de dos órdenes de magnitud (100X)". Nada de la respuesta cambió. Solo la puerta por la que entró el usuario.
El problema es que la desviación no abarata la cola en promedio. HDI es directo al respecto en su referencia de autoservicio: a medida que los incidentes de bajo tiempo de gestión pasan a autoservicio, "la complejidad media y el tiempo medio de gestión de los incidentes que siguen atendiendo los agentes en vivo aumentará". El coste por ticket puede subir mientras baja el coste total. Planifica la conversación sobre informes antes de que se publique tu portal de autoservicio, o la primera revisión mensual parecerá un fracaso.
También vale la pena poner la ambición en su sitio: la base de datos de referencia de MetricNet sitúa la tasa media de finalización en autoservicio en 10,4 %, frente a presentaciones de proveedores que prometen 60 u 80. Nuestra guía de desviación de tickets usa ese mismo número como base.
4. Solicitud de acceso y equipo para un nuevo empleado
Un mánager escribe una línea ("nuevo empleado el lunes, el kit habitual") y crea una semana de trabajo. Esto es una solicitud de servicio, no un incidente, y la distinción sale cara: los datos de campo de MetricNet sitúan el tiempo de trabajo de un incidente entre 12,3 y 21,5 minutos frente a 35,4 a 95,9 minutos para una solicitud de servicio en el estudio de volumen de MetricNet.
Jira Service Management modela esto correctamente. Un espacio nuevo incluye cinco tipos de trabajo (IT Help, Purchase, Change, Fault, Access) y dos tipos de solicitud listos para usar, y los campos del tipo de solicitud provienen de su tipo de trabajo. También renombra los estados para el solicitante: internamente el ticket dice Waiting for Customer, y el portal muestra "Requester Action Needed" en la configuración predeterminada de JSM. Un detalle pequeño, una gran diferencia en cuántas respuestas de "¿alguna novedad?" recibes.
Si esta forma domina tu cola, lee a continuación los desgloses de solicitud de acceso y solicitud de hardware, y trata la incorporación de RR. HH. como el mismo patrón con distintos aprobadores.
5. Un informe de error que se convierte en escalación de ingeniería
Un cliente encuentra un defecto genuino. Soporte lo reproduce, vincula una incidencia de ingeniería, y ahora posee un ticket que no puede cerrar.
El campo Type de Zendesk lleva cuatro valores (Question, Incident, Problem, Task) en el conjunto de campos estándar, y es de un solo sentido: una vez fijado, no puedes dejarlo en blanco de nuevo. Desactivar el campo por completo hace que todos los tickets pasen a Incident por defecto. Jira Service Management separa los dos ejes en su lugar, manteniendo el estado para dónde está el trabajo y la resolución para cómo terminó, con un valor de resolución Known error para el caso de causa documentada más solución alternativa.
La trampa aquí es On-hold. Es un estado interno opcional que "el solicitante del ticket nunca ve", según la documentación del ciclo de vida de Zendesk; su vista sigue diciendo Open. Así que el ticket está aparcado y el cliente cree que se está trabajando en él. Establece un ritmo de actualizaciones proactivas, y consulta gestión de escalaciones y triaje de informes de errores para el lado del enrutamiento.
6. Una disputa de facturación en un helpdesk centrado en CRM
"Me cobraron dos veces en junio" es un ticket de soporte que en realidad es un ticket de finanzas, que es exactamente por qué los equipos lo gestionan en un sistema con forma de CRM.
En HubSpot Service Hub el ticket es un objeto en un pipeline, y el Support Pipeline por defecto tiene cuatro estados: New, Waiting on contact, Waiting on us, Closed. Hay varios comportamientos que importan para una disputa que rebota entre equipos. La fecha de cierre es bidireccional, así que devolver un ticket a una etapa abierta borra el valor. Category la fija la IA a partir del primer mensaje y solo existe en Enterprise. Y hs_ticket_owner_type registra si un Human rep, Customer Agent o Rule-based bot tocó el registro, que es el primer rastro de auditoría honesto que he visto para tickets gestionados por IA en un helpdesk convencional.
Los objetivos de desviación deberían ser modestos con esta forma. Nuestro artículo de desviación de tickets de HubSpot tiene el detalle de las restricciones por plan, y CRM de servicio al cliente cubre cuándo el modelo centrado en CRM realmente gana.
7. Una caída de servicio que llega como cuarenta tickets
Un fallo, cuarenta registros, y un campo de prioridad a punto de ser puesto a prueba.
Las cinco prioridades de Jira vienen con la redacción propia de Atlassian, en el esquema de prioridades de JSM, desde Highest ("Este problema bloqueará el progreso") hasta Lowest. Las cuatro prioridades de Freshdesk están "codificadas de forma fija en nuestros sistemas" porque las políticas de SLA dependen de ellas, según su guía de campos de tickets. Zendesk esconde una dependencia más desagradable: desactiva el campo Priority y los objetivos de SLA dejan de aplicarse por completo.
Deja que los solicitantes fijen la prioridad ellos mismos y el campo deja de significar nada:
"Dealt with this decades ago. It was scrapped quickly because as you might imagine it was abused to death. It really didn't bother me though. I still got the same number of tickets and just slogged through them. When people got mad because we were missing SLAs we just replied there was nothing we could do now that all tickets were priority."
371 votos a favor en ese comentario, lo que indica lo común que es el patrón. La prioridad debería derivarse de reglas de impacto y urgencia que tú controlas, no escribirse a mano por quien grite más fuerte. La guía de gestión de SLA tiene el lado de la política, y priorización de tickets con IA cubre cómo derivarla automáticamente.
8. Una solicitud de función que nunca se construirá
El ticket más educado de la cola y el más propenso a pudrirse. Alguien pide un modo oscuro, producto dice que no, y el registro no tiene adónde ir.
Jira Service Management tiene una respuesta clara: resolución Won't do, separada del estado, y la clave del elemento de trabajo se muestra tachada una vez resuelto. Zendesk y Freshdesk en cambio te empujan hacia Solved o Resolved, lo que codifica silenciosamente "hicimos lo pedido" cuando no lo hiciste. Freshdesk al menos es explícito sobre la división: en sus propias palabras, Resolved significa hecho "según el agente" y Closed significa hecho según el cliente, con cierre automático a las 72 horas.
El cierre a menudo no le corresponde al agente de todos modos. Zendesk afirma claramente en su documentación del ciclo de vida del ticket que "los tickets no se pueden fijar manualmente en Closed": una automatización predeterminada los cierra cuatro días después de Solved, y con las automatizaciones de cierre desactivadas, entra en juego un límite duro de 28 días que no se puede cambiar.
El mismo ticket en seis sistemas reales
Ahora la otra lectura de la palabra clave: sistemas de ejemplo. Esto es lo que cuesta y cómo se ve una solicitud idéntica en seis de las herramientas que más veo en llamadas con clientes.
| Sistema | Un ticket es | Estados listos para usar | Precio de entrada | Unidad de facturación de IA | Mejor ajuste de ejemplo |
|---|---|---|---|---|---|
| Zendesk | Objeto de ticket con 15 campos estándar | 6 (más hasta 100 personalizados) | 19 $/agente/mes Support Team, 55 $ Suite Team | Resolución automatizada verificada, tarifa no publicada | Colas grandes multimarca |
| Freshdesk | Ticket con 11 predeterminados que no se pueden eliminar | 4 | 19 $/agente/mes Growth | Sesión, 49 $ por 100 extra | Equipos medianos que quieren simplicidad |
| Zoho Desk | Ticket dentro de un departamento | 3 principales más personalizados | 0 $ Free (3 usuarios), 14 $ Standard | Zia, incluido según la edición | Equipos sensibles al coste |
| Help Scout | Conversación en una bandeja compartida | Active, Pending, Closed | 0 $ Free (5 usuarios), 25 $/usuario/mes | Resolución, 0,75 $ | Equipos pequeños, trabajo con forma de email |
| Gorgias | Ticket vinculado a un pedido de Shopify | Open, Closed | 40 $/mes (50 tickets), nunca por agente | Interacción automatizada, 1,50 $ | Ejemplos de pedidos de ecommerce |
| Jira Service Management | Tipo de solicitud sobre tipo de trabajo sobre flujo de trabajo | Doble nombre, definido por el flujo de trabajo | 25 $/agente/mes Standard (1 a 15 agentes) | 1 $ por resolución, más 0,30 $ conversación asistida | TI interno y aprobaciones |
Los precios son tarifas de lista anuales de la página de precios de cada proveedor, verificadas esta semana. Dos de ellos merecen una advertencia. Jira Service Management anuncia un promedio combinado de 20 $ por agente, que es la tarifa para su control deslizante predeterminado de 75 agentes bajo precios por volumen progresivo, no lo que paga un equipo de 10 agentes. Y la unidad principal de Zendesk, la resolución automatizada, no tiene ninguna cifra en dólares publicada en ninguna parte de la página de precios, lo que convierte en una llamada de ventas presupuestar la capa de IA.
Las valoraciones y las tablas de funciones no te dirán cuál de estos encaja. Las formas de ticket anteriores sí lo harán. Una cola de ecommerce que es 60 % seguimiento de pedidos quiere el modelo de Gorgias; una mesa de TI interna llena de aprobaciones quiere Jira Service Management.
Para el panorama más amplio, mejor software de helpdesk va herramienta por herramienta, y ejemplos de software cubre el extremo orientado al cliente.
Tres ejemplos de tickets saliendo mal
Los casos de fallo son más instructivos que el camino ideal, y cada uno de estos se puede arreglar con configuración en lugar de más personal.
El ticket que nadie está esperando. Un líder de soporte contó su cola y descubrió que el backlog era en gran parte ficticio:
"I was going through our queue today and found 90 tickets where we responded, asked for more information from the customer but then never heard back from them. They just sit there inflating our numbers and that honestly doesn't look good for management. We have been called before for unresolved open tickets so this is a big deal."
90 de 200 tickets abiertos estaban esperando a un cliente silencioso, así que el número de abiertos nunca fue el backlog real. Otro gestor de TI reportó reducir el backlog de un grupo en un 54 % solo con cerrar automáticamente los tickets de más de cinco días. Nuestro artículo de limpieza de backlog es la versión larga de ese arreglo.
La base de conocimiento que nadie actualiza. Todos los ejemplos de autoservicio anteriores asumen que existe un artículo y está actualizado:
"I run a small team, and we have an internal wiki for processes, FAQs, and troubleshooting. The problem? No one updates it. People keep asking the same questions in Slack instead of checking the wiki."
Las dos mitades fallan juntas: la base de conocimiento interna se pudre, y la gente la rodea. Entrenar la IA con tickets pasados en lugar de solo con artículos es la respuesta práctica, que cubre nuestra guía de entrenamiento de la base de conocimiento.
Los informes que no puedes sacar de la herramienta. Un líder de soporte que ha construido paneles en una herramienta de BI real aún así no pudo sacar cifras básicas:
"I have never found anything as complex as Zendesk explore. I've worked with ThoughtSpot building dashboards, reports and exports but omg Zendesk, you are taking so much of my time!!!!!!!!"
Revisa la capa de informes contra estos ejemplos exactos antes de comprar, no después. Informes de Zendesk y KPI de servicio al cliente son las dos cosas que probar el primer día de una prueba.
Lo que cambia una capa de IA en estos ocho ejemplos
No los ocho, y ahí está la clave. Los ejemplos 1, 3 y la mayor parte del 6 se repiten para siempre con una respuesta conocida. Los ejemplos 2, 5, 7 y 8 necesitan a una persona sosteniendo la política.
He visto de cerca el modo de fallo. Uno de nuestros propios clientes, un proveedor danés de energía solar, tuvo un bot que fabricó afirmaciones de suscripción y se las envió a personas reales cuando su base de conocimiento no tenía un artículo coincidente. Ese incidente es por lo que ahora cada implementación de eesel ejecuta una simulación contra tickets históricos antes de responder en vivo a nadie. Un responsable de CX de una marca de suplementos en Gorgias planteó el requisito mejor que nuestra propia documentación:
"The AI will never be able to answer 100% of the questions, but if it tries and just answers 'sorry I don't know this,' I cannot go and check all my 7,000 tickets to see if the AI actually made a good answer. I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."
Eso es una petición justa, y encaja exactamente con la lista de ejemplos: dale a la IA la forma de estado de pedidos, mantenla alejada de la caída de servicio. Cuando el alcance es correcto, los números salen bien. Gridwise resolvió el 73 % de las solicitudes de nivel 1 en su primer mes tras una prueba de siete días. Cuando el alcance es incorrecto, terminas con la historia del panel solar.
Lee alucinaciones de IA en soporte y traspaso de IA a humano antes de elegir qué formas automatizar.
Clasificación de tickets y etiquetado de tickets son los primeros pasos seguros en casi cualquier cola, porque una etiqueta equivocada no cuesta nada y una respuesta equivocada cuesta un cliente.
Prueba eesel con tus propios ejemplos de tickets
Si tu cola se parece a la lista de arriba, el movimiento útil no es cambiar de helpdesk. Es poner una capa de IA sobre el que ya tienes y apuntarla a las dos o tres formas que se repiten.
eesel se conecta a Zendesk, Freshdesk o Gorgias en unos minutos, se entrena con tus tickets pasados y tu centro de ayuda, y luego simula contra el volumen histórico para que veas las respuestas que habría enviado antes de que las vea un cliente.
Tú eliges a qué formas de ticket toca, así que el ejemplo 7 nunca le llega. La facturación es de 0,40 $ por ticket gestionado, sin cuota por puesto, así que enrutar 200 de tus 1.000 tickets mensuales cuesta 80 $, no un nuevo nivel de plan. Gratis para probar.
Empieza por el ejemplo 1 o el ejemplo 3. Son los de mayor volumen, el menor riesgo y los más fáciles de demostrar en una semana.
Preguntas frecuentes
¿Qué es un ejemplo de sistema de tickets?
¿Cuáles son ejemplos de sistemas de tickets?
¿Cómo se ve un ticket de soporte dentro del sistema?
¿Cuáles son ejemplos de tickets de un sistema de tickets de TI?
¿Cuánto cuesta un solo ticket de soporte?
¿Cuál es la diferencia entre un incidente y una solicitud de servicio?
¿Puede la IA gestionar estos ejemplos de sistemas de tickets de principio a fin?
Article by
Riellvriany Indriawan
Riell is a designer and writer at eesel AI with about two years of experience researching CX platforms, AI chatbots, and helpdesk software. She combines her design background with a sharp eye for how these tools actually look and feel in practice — making her comparisons unusually visual and user-focused.
