¿Qué cuenta como ticket de soporte repetido?
Escribo sobre soporte para eesel y, antes, pasé dos años en SEO, así que leo consultas de búsqueda para ganarme la vida. La frase "tickets de soporte repetidos" es interesante porque quien la escribe normalmente no busca una definición. Es un responsable de soporte que mira una cola llena de nombres que reconoce y se pregunta por qué los mismos clientes siguen escribiendo. Esa es la pregunta que intenta responder este artículo.
En eesel llevamos unos años ejecutando IA en colas de helpdesk reales, y por lo que veo en las llamadas de ventas, el patrón es bastante constante: los equipos saben que los repetidos son caros, pero los miden con una métrica que se pierde la mitad.
Cuando la gente dice "ticket repetido", normalmente se refiere a una de estas cuatro cosas:
| Término | Qué es | Dónde aparece |
|---|---|---|
| Reapertura | El cliente responde a un ticket resuelto y el mismo ticket vuelve a abierto | En la métrica de reapertura de tu helpdesk |
| Ticket de seguimiento | El cliente responde después de que el ticket se cerró o archivó, así que el helpdesk crea un ticket nuevo vinculado | Un ticket aparte, a menudo pasado por alto |
| Ticket duplicado | El cliente escribe dos veces por el mismo problema, a menudo por dos canales | Dos tickets abiertos, dos agentes |
| Contacto repetido | Cualquiera de los anteriores: mismo cliente, mismo problema, dentro de una ventana de tiempo | Solo si lo construyes tú |
La última fila es la que importa de verdad aquí. Una tasa de contacto repetido cuenta las tres vías, mientras que una tasa de reapertura solo cuenta la primera.
Por qué tu tasa de reapertura subestima los contactos repetidos
Todo helpdesk tiene un punto de corte. Antes de él, la respuesta del cliente reabre el ticket anterior; después, la respuesta se convierte en un ticket nuevo y tu métrica de reapertura deja de verla. El corte es distinto en cada herramienta, y la mayoría de los equipos nunca lo consulta.
Esto es lo que hace cada helpdesk, según su propia documentación:
- Zendesk. Una automatización estándar cierra los tickets 4 días después de resolverse. Puedes ampliarlo a 28 días, pero no eliminarlo. Tras el cierre, "any response to a closed ticket from any channel automatically creates a follow-up ticket", según la documentación de seguimientos de Zendesk.
- Gorgias. Una respuesta a un ticket cerrado lo reabre, pero en correo una respuesta "more than 10 days after the last message" se divide en un ticket nuevo. En chat, SMS, voz y mensajes directos de redes sociales la división ocurre a los 3 días, según la documentación de facturación de Gorgias.
- HubSpot. Aquí la decisión es tuya. El ajuste de reapertura de tickets ofrece Always reopen, Set a time frame o Never reopen, en Service Hub Professional y Enterprise.
- Freshdesk. Su métrica "Tickets reopened" cuenta los tickets resueltos o cerrados que vuelven a Open. Cuando un ticket cerrado lleva 120 días inactivo se archiva, y una respuesta entonces "creates a new ticket instead of reopening the archived one".
- Help Scout y Front. Help Scout reabre las conversaciones cerradas salvo que configures un Conversation Lock. Front cierra las conversaciones de correo a los 30 días por defecto y divide las respuestas posteriores en una conversación nueva.
La versión de HubSpot da la imagen más clara del compromiso, ya que te entrega toda la decisión:
Así que la conclusión es que, si tu instancia de Zendesk sigue con el valor por defecto de 4 días, un cliente que vuelve el día 5 es invisible para tu tasa de reapertura. Un responsable de soporte en Reddit explicó bien el lado del comportamiento:
"Reopen rate helps too but people learn to just open a new ticket instead of reopening, so you really need the repeat contact window to catch it"
Si quieres más detalle del lado de Zendesk, escribí sobre las condiciones para reabrir tickets que puedes configurar en las automatizaciones.
Por qué la resolución en el primer contacto puede subir mientras suben los repetidos
La otra trampa que vale la pena mencionar es la resolución en el primer contacto. La mayoría de los helpdesks la calculan por ticket y no por problema, así que un cliente que abre un ticket nuevo básicamente reinicia el reloj, y eso cuenta como una victoria nueva.
Si miras las definiciones nativas, ves lo estrechas que son:
- La métrica más cercana de Zendesk son los one-touch tickets: resueltos con una respuesta del agente o ninguna. Una reapertura con una pregunta nueva sí saca un ticket de one-touch, pero un ticket de seguimiento no toca el original.
- "Tickets resolved within FCR (%)" de Freshdesk exige cero respuestas del cliente tras el primer contacto, según su glosario de métricas. Y un ticket nuevo no es una respuesta.
- Help Scout informa "Resolved on First Reply" en su informe de correo, de nuevo por conversación.
Así es como acabas con una historia como esta:
"We hit 78% FCR last quarter. Leadership celebrated. Bought donuts and everything. Then I pulled the data on customers who contacted us 3+ times in 30 days. The number went up. Turns out we were "resolving" tickets by closing them, not by actually fixing the underlying issue."
No digo que abandones el FCR (escribí una guía entera sobre IA para la resolución en el primer contacto) ni la resolución one-touch, ambas son útiles. Solo no las reportes nunca sin la cifra de repetidos al lado, igual que no reportarías la tasa de resolución sin el CSAT.
Cómo medir la tasa de contacto repetido
La fórmula que yo usaría es esta:
Tasa de contacto repetido = tickets resueltos en los que el mismo cliente volvió a contactarte por el mismo problema en 7 días ÷ todos los tickets resueltos en el periodo
Hay que tomar algunas decisiones de antemano:
- Elige una ventana y mantenla. 7 días es un valor razonable para correo y chat, mientras que los call centers suelen usar 14 o 30. Un comentarista de Reddit sugirió revisar las reaperturas dentro de 72 horas, para pillar a los agentes que cierran tickets por las estadísticas. Elijas lo que elijas, no lo cambies a mitad de trimestre.
- Cruza por cliente y problema, no solo por cliente. Un cliente que escribe por un reembolso y, dos semanas después, por un problema de inicio de sesión no es un repetido. A los agentes les molesta que los culpen por eso, y tienen razón.
- Cuenta entre canales. El mismo cliente que escribe un correo y luego abre un chat sigue siendo un solo problema, que tu helpdesk puede no vincular.
Después sacas las cifras de lo que ya te da el helpdesk:
| Helpdesk | Reaperturas | Repetidos que se convierten en tickets nuevos | Métrica tipo primer contacto |
|---|---|---|---|
| Zendesk | "Reopened tickets" y "Reopens" en Explore | Seguimientos, filtrados por el canal de actualización "Closed Ticket" | One-touch tickets |
| Freshdesk | "Tickets reopened" | Tickets nuevos tras el archivado, que se encuentran en los tickets archivados del contacto | Tickets resolved within FCR (%) |
| Gorgias | Grupo Reopened en el nuevo informe Helpdesk performance | Tickets divididos tras 10 días (correo) o 3 días (chat, SMS, voz) | No se encontró métrica FCR nativa |
| HubSpot | Propiedad "Ticket reopen date" | Tickets nuevos vinculados al original | Sin informe FCR nativo |
| Help Scout | Conversaciones devueltas a Active | Conversaciones nuevas, si Conversation Lock está activado | Resolved on First Reply |
| Front | "Reopened conversations" en el informe Workload | Conversaciones nuevas vinculadas tras el cierre | Sin métrica FCR nativa |
Ninguna te da "mismo problema" de fábrica, y la forma más barata de llegar ahí es una etiqueta. Cuando un agente recoge un ticket que claramente es un segundo contacto, añade una etiqueta repeat y también una etiqueta de motivo. Una respuesta de Reddit lo expresó mejor de lo que yo podría:
"You're right that three cheap contacts on one issue is not three wins. It is one unresolved problem with a growing cost and a customer who now expects the next reply to fail. Tag the second contact as a repeat of the first before anyone closes it again."
Si etiquetar a mano suena a algo que no se mantiene, normalmente no se mantiene, no más allá de la tercera semana. El etiquetado de tickets con IA puede aplicar las etiquetas de repetido y de motivo por ti, y así las cifras llegan a los informes propios de tu helpdesk como cualquier otro campo.
A partir de ahí es un informe normal. En Zendesk añadiría un widget de tasa de repetidos al mismo panel de analítica que tu equipo ya revisa, y en Gorgias las etiquetas aparecen en las vistas estándar de Gorgias analytics.
Lo que te cuestan los tickets repetidos
Un ticket repetido cuesta más que el primer contacto. El cliente está más molesto, el agente tiene que leer el historial antes de responder y, encima, has pagado dos veces por un problema. Tu coste por ticket no lo muestra, porque por sí solo cada ticket parece normal.
Pon tus propias cifras abajo, los valores por defecto son solo un ejemplo.
Introduce tus tickets resueltos al mes, la tasa de repetidos, el tiempo de gestión y el coste del agente para ver lo que te cuestan los tickets de soporte repetidos y lo que vale reducirlos a la mitad.
La cifra en dólares es solo la mitad de la historia. Un cliente que tiene que perseguirte tres veces es el que deja la reseña de una estrella, y ese coste nunca aparece en las cuentas del coste por resolución.
Por qué los clientes vuelven a escribir: las cuatro causas raíz
Cuando sacas 50 a 100 tickets repetidos y los lees de verdad, los motivos caen en cuatro grupos casi siempre, lo que también coincide con lo que oigo de los equipos de soporte en las llamadas de eesel.
1. El ticket se cerró, pero el problema no se arregló
Esta es la grande, y normalmente es un problema de métricas antes que un problema de personas. Si a los agentes se los puntúa por tickets cerrados, cerrar se convierte en el objetivo en sí.
"Resolution looks good because the ticket gets closed, but customers sometimes come back a few days later with basically the same problem."
Menos repetidos también significa menos tickets en total, y esa es la forma más barata de reducir el volumen de tickets.
La solución aquí es hacer que "todos los problemas del mensaje resueltos" forme parte de tu ficha de QA, en lugar de solo si el ticket se cerró. Calíbralo entre revisores para que todos lo puntúen igual, lo expliqué en calibración de QA.
2. Sin actualización mientras el cliente esperaba
Los reembolsos y los retrasos de envío generan repetidos, las escaladas de errores también, porque del lado del cliente no pasa nada durante días. Escriben "any update?" porque nadie les dijo cuándo llegaría la siguiente actualización.
Esta es la razón por la que "dónde está mi pedido" domina las colas del comercio electrónico. En una llamada de ventas de eesel, un operador de comercio electrónico multimarca con más de 500 tickets al día nos dijo que las solicitudes de reembolso, las bajas y el seguimiento de pedidos dominan su volumen, y esas son justo las categorías clásicas de repetidos.
La solución es el soporte proactivo: termina cada respuesta indicando cuándo llegará la siguiente actualización y configura una automatización que de verdad la envíe. Gorgias puede hacer seguimiento cuando no hay respuesta, Zendesk puede hacer lo mismo con automatizaciones basadas en tiempo.
Para el estado del pedido en concreto, un bot que lee el seguimiento en vivo supera a una macro; comparé ambas en esta guía sobre chatbots de estado de pedido. Mi artículo sobre servicio proactivo frente a reactivo tiene más sobre los pros y contras.
3. Media respuesta, o la equivocada
Una respuesta que contesta la pregunta literal pero no la siguiente obvia es casi una garantía de un segundo ticket. "Su reembolso se está procesando" invita a "¿cuándo lo recibiré?" Las macros lo empeoran cuando se escriben para el caso común y luego se pegan en el caso poco común.
"The responses are a push of a button by Customerservice representative and so patronizing because most the time they get it wrong."
Hay dos soluciones. Audita tus macros con tickets reales (empezaría con mi guía de macros con IA) y haz un análisis de lagunas de conocimiento para encontrar las preguntas que tu centro de ayuda no cubre, mientras que una auditoría de la base de conocimiento más amplia detecta artículos que simplemente están desactualizados. A veces los documentos están escritos para el lector equivocado: un responsable de soporte con el que hablamos tenía una base de conocimiento escrita para administradores mientras que los tickets venían de usuarios finales, lo que producía respuestas confusas.
4. El cliente tuvo que explicarlo todo de nuevo
Los traspasos entre turnos, niveles y equipos pierden contexto, y el traspaso del bot a un humano es el peor infractor. El cliente se repite y recibe una respuesta ligeramente distinta, y luego escribe una tercera vez. Los duplicados entre canales son el mismo problema visto desde el otro lado:
"Same customer would email twice about one issue, once from their phone, once from a laptop an hour later when they got worried nobody saw the first one, and we'd end up with two agents responding separately without realizing it was the same problem."
Empieza activando lo que tu helpdesk ya tiene. Las sugerencias de fusión de Zendesk muestran tickets del mismo solicitante con dos semanas de margen a cada lado, y el auto-merge de Gorgias combina tickets abiertos de un mismo cliente. Ambos tipos de fusión son permanentes, así que configúralos con cuidado.
Para los traspasos, mis artículos sobre traspasos de turno y escalada entre equipos cubren las notas que evitan el reinicio completo.
Cómo reducir los tickets de soporte repetidos: un plan de dos semanas
No necesitas una herramienta nueva para empezar, este es el plan que yo seguiría.
Semana uno: encuentra tus dos causas principales
- Extrae de 50 a 100 tickets del último mes en los que el mismo cliente volvió en 7 días. Incluye también los tickets de seguimiento y los divididos, no solo las reaperturas.
- Lee cada uno y etiquétalo con una de las cuatro causas anteriores. Añade un quinto grupo "otros" y mantenlo pequeño.
- Anota quién o qué gestionó el primer contacto, es decir, qué grupo de agentes o qué macro, o si fue el bot.
- Después cuenta. En la mayoría de los equipos, dos causas explican la mayor parte de los repetidos.
Semana dos: arregla esas dos y vuelve a medir
- Para "sin actualización mientras espera", añade la línea de la próxima actualización a tus macros principales y una automatización que la envíe.
- Para "no se arregló realmente", añade una comprobación de resolución en el QA y deja de premiar el número bruto de cierres.
- Para "media respuesta", reescribe las tres macros con más repetidos y rellena las lagunas del centro de ayuda; luego revisa la redacción con tu guía de tono.
- Para "tuvo que explicar de nuevo", activa las sugerencias de fusión o el auto-merge y exige una nota de traspaso al escalar.
- Revisa tus ventanas de cierre automático y de reapertura. Si Zendesk sigue con el valor por defecto de 4 días, decide a propósito si eso es realmente lo que quieres.
- Compara la tasa de contacto repetido con tu línea base, junto al CSAT y el customer effort score, para saber que los repetidos bajaron porque se arreglaron los problemas y no porque los clientes se rindieron.
Un análisis de tickets de soporte completo profundiza en el paso uno, por si tienes más volumen del que puedes leer a mano.
Dónde ayuda la IA y dónde empeora los repetidos
La IA puede reducir los tickets repetidos, pero también puede fabricarlos a escala. Toda la diferencia está en si se le permite adivinar.
El modo de fallo se ve más o menos así: un chatbot responde cada pregunta con algo plausible y el chat se cierra, el panel cuenta una desviación, y luego el cliente vuelve.
"How many customers finished a chat and come back 20 minutes later because the bot gave them a generic answer that didn't solve their issue? We're optimizing to close the ticket instead of solving the damn problem."
A veces también aparece una semana después en lugar de en la misma sesión. Un desarrollador en Hacker News solo lo descubrió cruzando la elección del modelo con las reaperturas:
"our dashboard only tracked immediate task completion, and had no idea a cheaper model had quietly produced a worse answer that the customer reopened a week later."
Así que, antes de confiar en cualquier IA en tu cola, pediría tres cosas:
- Responde solo cuando está segura. Una respuesta equivocada con total seguridad es peor que ninguna, porque crea un repetido y además un cliente enfadado, así que busca una puntuación de confianza real o una regla equivalente. Un responsable de CX con 7.000 tickets al mes nos dijo en una llamada: "I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone." Ese es el listón correcto, y es la razón por la que la alucinación de la IA importa más para los repetidos que para cualquier otra cosa.
- Está probada con tus tickets pasados antes de salir en vivo. No con un guion de demo, sino con tickets reales que ya resolviste, puntuados frente a lo que tu equipo realmente envió.
- Puedes dividir la tasa de repetidos por quien gestiona. Si los tickets de la IA vuelven más a menudo que los de tus agentes, tienes que poder verlo, así que etiqueta cada ticket gestionado por la IA.
Esta es la parte de eesel que señalaría. Su skill de Simulation reproduce tu agente contra tickets pasados reales y puntúa cada respuesta frente a la respuesta de tu equipo; luego sugiere cambios de instrucciones. Aquí hay una ejecución con 20 tickets de Zendesk resueltos, donde coincidió con el equipo en 17 y marcó los dos que necesitaban a una persona:
La misma lista de skills incluye "Analyze ticket trends" para temas recurrentes y "Update knowledge base", que encuentra preguntas que tu centro de ayuda no responde y redacta los artículos que faltan. Eso cubre las causas raíz dos y tres más o menos en piloto automático. Cuando se equivoca en una, la corriges en el chat y la corrección se convierte en una instrucción permanente, para que el mismo error no cree el mismo repetido la semana que viene. Mi artículo sobre el análisis de errores recorre ese ciclo.
También hay un detalle de precios que importa aquí. En la página de precios de eesel, un ticket es 1 crédito "however many replies go back and forth". Un cliente que reabre un ticket no te cuesta un segundo crédito, un ticket repetido completamente nuevo sí, así que reducir los repetidos baja tu factura de eesel además de la carga de tus agentes.
Lo que no es: una solución para un proceso de reembolsos roto o para un socio de envíos que pierde paquetes. Si la causa raíz está fuera de soporte, la IA solo responde el repetido más rápido.
Reduce los tickets repetidos con eesel
Si tu cola está llena de clientes que vuelven a escribir por el mismo problema, el compañero de helpdesk con IA de eesel se une a la configuración de Zendesk, Freshdesk, Gorgias o HubSpot que ya usas y aprende de tus tickets pasados, tus macros y tu centro de ayuda. Responde solo lo que puede resolver y pasa el resto a tu equipo, y puedes reproducirlo sobre los tickets del mes pasado para ver dónde habría causado un repetido antes de que ningún cliente vea una respuesta. La responsable de soporte de Gridwise describió el resultado así tras un mes:
"In the first month, eesel is resolving 73% of our tier 1 requests ... Responses are simple to fix and adjust."
Kim Simpson, Gridwise
Empezar es gratis con 100 créditos, y los planes de pago empiezan entonces en $299 al mes por 500 créditos.
