Cómo crear un informe de tickets de soporte: paso a paso

Un informe de tickets de soporte es, principalmente, un problema de definiciones. Los tickets creados, los tickets resueltos, el tiempo de primera respuesta y el tiempo de resolución parecen conceptos evidentes. Sin embargo, cada uno de ellos tiene más de un significado oficial dentro de la misma plataforma de soporte.

Establezca las reglas de conteo y el informe se redactará solo. Omita ese paso y dos personas honestas extraerán la misma exportación y discreparán por horas.

Esta guía explica qué debe incluirse en el informe, los cuatro puntos donde se bifurcan las definiciones y cómo crearlo a partir de una exportación de tickets.

Qué debe incluirse en un informe de tickets de soporte

El volumen por sí solo no dice casi nada. La organización es lo que hace que los números sean confiables de interpretar.

Elemento	Por qué está ahí
Tickets creados en el período	El lado de la demanda
Tickets resueltos en el período	El lado de la oferta, bajo una regla de estado definida
Backlog al final del período	Todo lo que no se ha resuelto ni cerrado
Tiempo de primera respuesta	Con un reloj y una definición definidos
Tiempo de resolución	Primera o total, nombrada explícitamente
Tickets reabiertos	La señal de calidad que ocultan los otros números
Tickets sin respuesta	Donde el proceso falló por completo
Una base de fechas y un alcance definidos	Qué canales, marcas y colas están incluidos

Dos filas tienen más peso de lo que sugiere su tamaño. Los tickets reabiertos y sin respuesta son los puntos donde un informe deja de ser un simple marcador y se vuelve útil.

Zendesk publica las fórmulas subyacentes, lo que hace que las definiciones sean verificables en lugar de ser una cuestión de opinión. Su referencia de métricas y atributos detalla cada una de ellas.

Comencemos con lo más sencillo. Los tickets resueltos son "el número de tickets resueltos o cerrados", por lo que la métrica abarca dos estados en lugar de uno.

El "tiempo de primera respuesta" tiene dos definiciones oficiales

Esta es la bifurcación que causa más desacuerdos, y el propio proveedor lo advierte directamente.

La documentación de SLA de Zendesk lo dice en una sola línea: "No confunda el tiempo de respuesta de SLA con la métrica nativa de tiempo de respuesta de Zendesk".

La métrica nativa es estricta respecto a quién responde. Zendesk establece que "el tiempo de primera respuesta se calcula exclusivamente en función de las respuestas de los agentes". Las acciones automatizadas y las relacionadas con bots "no se tienen en cuenta al calcular el tiempo de primera respuesta".

La métrica de SLA no lo es. En ella, el tiempo de primera respuesta es "el tiempo transcurrido entre la creación del ticket y el primer comentario público de un agente (o respuesta automática)". Zendesk añade que "las métricas de tiempo de respuesta se cumplen si se configura un disparador para responder automáticamente con un comentario público".

Al leer ambas definiciones juntas, la consecuencia es evidente. Una respuesta automática puede cumplir con su objetivo de SLA mientras el tiempo de primera respuesta nativo sigue corriendo.

Por lo tanto, un informe que muestre un 98% de cumplimiento de SLA y una mediana de tiempo de primera respuesta de cuatro horas no se está contradiciendo. Está informando sobre dos cosas diferentes, ambas de manera correcta.

Hay dos excepciones menores que vale la pena conocer. Tomemos el caso en el que un agente crea el ticket y el primer comentario es público. La referencia de métricas de duración indica que la segunda marca de tiempo "se traslada al segundo comentario público del agente".

Y los tickets compartidos no cuentan. Zendesk señala que cuando un agente comenta públicamente desde otra cuenta utilizando la función de compartir tickets, "esto no cuenta para el tiempo de primera respuesta de su cuenta".

El "tiempo de resolución" también tiene dos

La misma división se aplica a las métricas de resolución, y aquí ambas versiones se incluyen de forma predeterminada.

El tiempo de primera resolución es la "duración entre la creación del ticket y su primera resolución", que finaliza "la primera vez que el estado del ticket se establece como resuelto".

El tiempo de resolución completa es la "duración entre la creación del ticket y su resolución más reciente". Finaliza "la última vez que el estado del ticket se estableció como resuelto".

Para un ticket resuelto una sola vez, ambos son idénticos. Para un ticket resuelto, reabierto y vuelto a resolver, divergen por el tiempo que haya tomado la segunda ronda.

Es exactamente por eso que los tickets reabiertos deben estar en el informe. Zendesk los define como tickets "reabiertos después de haber sido resueltos" y señala que la métrica "no incluye los tickets resueltos y reabiertos durante la misma actualización".

Hay un efecto de segundo orden que la gente suele pasar por alto. El promedio diario de tickets resueltos los contabiliza "solo si están actualmente resueltos o cerrados". Por lo tanto, un ticket reabierto hoy desaparece silenciosamente del recuento de resueltos del mes pasado.

Por lo tanto, un informe que generó en junio no coincidirá si lo vuelve a generar en agosto. Nada falló; simplemente cambió el estado subyacente.

Dos métricas más separan el tiempo de espera del tiempo de trabajo. El tiempo de espera del solicitante es el tiempo combinado en los estados nuevo, abierto y en espera, y el tiempo de espera del agente es el tiempo combinado en pendiente.

Esta pareja responde a la pregunta que un promedio de resolución no puede contestar. Los tiempos de resolución prolongados causados por la espera del cliente representan un problema diferente al de los tiempos de resolución prolongados causados por la acumulación en la cola.

Horas naturales u horas laborables

Cada cifra de respuesta y resolución existe en dos relojes distintos, y elegir uno no es opcional.

Zendesk almacena ambos. Después de la primera respuesta pública, "el sistema calcula el tiempo de primera respuesta en horas naturales y horas laborables". Ambas métricas "se almacenan con los datos del ticket".

El valor predeterminado que ve no es neutral. Zendesk señala que los informes predefinidos de Explore "muestran información en horas naturales". Las métricas de horas laborables "están disponibles y se pueden utilizar en sus propios informes".

Así, un equipo que trabaja de nueve a cinco parecerá lento en el informe predeterminado. Un ticket que llega el viernes a las 6 p. m. acumula aproximadamente 63 horas naturales antes del lunes por la mañana, y casi cero horas laborables.

Los canales de conversación en vivo añaden una complicación más. La métrica de Tiempo de primera respuesta (seg) para mensajería y chat "ignora la configuración de sus horas laborables de mensajería y de las horas de operación del chat en vivo".

And chat reply-time SLAs are opt-in. Zendesk states that reply time SLAs for live chat "are turned off by default," so their absence is a configuration state rather than perfect performance.

Cómo hacerlo manualmente

Opción 1: Una pestaña por familia de métricas

Exporte la lista de tickets con los campos de métricas, luego divida el volumen, el tiempo de respuesta y el tiempo de resolución en pestañas separadas antes de resumir cualquier dato.

Mantenga las columnas de horas naturales y laborables una al lado de la otra en lugar de elegir una al momento de la exportación. Tarde o temprano le pedirán la otra.

Calcule las medianas en lugar de las medias para las métricas de tiempo. Un puñado de tickets que queden abiertos durante un día festivo arrastrará el promedio a un punto en el que ningún ticket real se encuentra.

El límite es que una hoja de cálculo no puede ver el historial de estados. Obtiene el estado actual de cada ticket, por lo que el comportamiento de reapertura debe provenir del recuento de reabiertos en lugar de una reconstrucción.

Opción 2: Una pestaña de definiciones, redactada primero

Registre la definición del tiempo de respuesta, el reloj, la métrica de resolución, la regla de estado para resuelto, los canales incluidos en el alcance y la base de fechas.

Luego, registre lo que el informe no pretende afirmar. Dejar por escrito que el cumplimiento de SLA y el tiempo de primera respuesta nativo miden cosas diferentes evita que un colega con buenas intenciones los cite como si fueran un solo número.

El límite es el de siempre. Documentar una regla no significa aplicarla, y el próximo trimestre alguien volverá a armar la tabla dinámica de memoria.

Opción 3: Segmente antes de promediar

Divida por canal antes de calcular cualquier métrica de tiempo. Los tickets de correo electrónico, chat y teléfono tienen dinámicas diferentes, y una mediana combinada no describirá ninguno de ellos de forma precisa.

Luego, excluya o marque los tickets que distorsionen los datos. Los tickets que llevan semanas esperando la respuesta del cliente deben ir en su propia línea en lugar de incluirse en el promedio de resolución.

Muestre qué excluyó y cuántos eran. Un lector que no pueda ver el filtro asumirá que no se aplicó ninguno.

La limitación es que la segmentación multiplica el trabajo. Tres canales por dos relojes por dos métricas de resolución equivalen a doce números que debe mantener organizados.

El límite común. Las tres opciones asumen que la exportación cubre un único rango de fechas sobre una única base de fechas para cada cola. Mezclar rangos entre pestañas es el error silencioso más común en este informe.

Dónde se ralentiza la vía manual

El primer informe de tickets de soporte toma una tarde. El cuarto toma más tiempo, porque la plataforma de soporte cambió en el proceso.

Se activa un nuevo canal, por lo que la mediana combinada varía por razones ajenas al rendimiento. Se modifican las horas laborables para una nueva región, y cada cifra histórica de horas laborables cambia con ellas.

Luego llega el efecto de la reapertura. Los números del trimestre pasado ya no coinciden, y explicar el porqué toma más tiempo que volver a generar el informe.

Hay un cuarto costo que solo aparece bajo presión. Alguien pregunta si el soporte fue más rápido este trimestre. Una respuesta honesta requiere definir primero el reloj, la definición y la combinación de canales.

Para conocer el lado de la satisfacción en este mismo panorama, consulte nuestra guía para crear un informe de NPS. Si el problema es el volumen en sí, nuestro tutorial sobre cómo crear un agente de IA para soporte al cliente de preventa cubre la parte del desvío de tickets.

Cómo crearlo con Powerdrill Bloom

Paso 1: Suba su exportación de tickets

Suba la exportación de tickets, o las exportaciones de tickets y SLA juntas. Powerdrill Bloom analiza las columnas al recibirlas, por lo que las marcas de tiempo vacías, los formatos de fecha mixtos y los tickets sin una primera respuesta salen a la luz antes de calcular cualquier mediana.

Paso 2: Describa el informe en lenguaje natural

Indique las definiciones en lugar de tener que reconstruirlas. Nombre la definición del tiempo de respuesta, el reloj, qué métrica de resolución desea, la regla de estado para resuelto y los canales incluidos en el alcance.

Luego, haga las preguntas que detectan los errores. Pregunte cuántos tickets no tienen ninguna respuesta de agente. Pregunte qué tickets se reabrieron. Solicite las medianas por canal en lugar de una sola cifra combinada.

Paso 3: Exporte el gráfico, informe o presentación

Extraiga la tabla de métricas por canal, o un gráfico de creados frente a resueltos con el backlog de fondo. Las diapositivas que muestran las definiciones junto a los números se generan en el mismo proceso.

Errores comunes

Citar el cumplimiento de SLA como tiempo de primera respuesta. Uno acepta una respuesta automática y el otro excluye por completo las acciones automatizadas.

Comparar horas naturales con horas laborables. El informe predeterminado le ofrece lo primero, mientras que su objetivo probablemente se estableció en lo segundo.

Utilizar la media para los tiempos de respuesta y resolución. Unos pocos tickets abandonados desplazan el promedio a un valor que ningún ticket real experimenta.

Mezclar canales. Las medianas de chat y correo electrónico difieren por diseño, y la mezcla oculta ambas realidades.

Informar el tiempo de resolución sin especificar cuál. El tiempo de primera resolución y el de resolución completa son métricas almacenadas independientes, no variantes de redondeo.

Tratar el recuento de resueltos como definitivo. Los recuentos de resueltos incluyen únicamente los tickets actualmente resueltos o cerrados, por lo que las reaperturas modifican el pasado.

Dejar fuera los tickets sin respuesta. Se definen como tickets con menos de una respuesta de agente, y son el fallo más evidente que el informe puede revelar.

Conclusión

Nombre la definición de respuesta, nombre el reloj, elija la primera resolución o la resolución completa, establezca la regla de estado, segmente por canal y muestre los tickets reabiertos y sin respuesta. Eso produce un informe de tickets de soporte sobre el cual se pueden tomar medidas.

Lo que el informe tal vez no logre es compararse de forma directa con los números de otra empresa. Las definiciones son configurables, por lo que un punto de referencia que haya leído en algún lugar casi con seguridad se midió de manera diferente.

En su lugar, realice un seguimiento comparándolo con su propio historial, bajo un conjunto fijo de reglas. Esa es la versión que realmente le dirá si algo ha mejorado.

Si volver a generarlo cada mes le consume un día de trabajo, pruebe Powerdrill Bloom con su exportación de tickets. Consulte también la página del generador de informes de IA y el resumidor de la voz del cliente.

Preguntas frecuentes

¿Por qué mi cumplimiento de SLA no coincide con mi tiempo de primera respuesta?

Miden eventos diferentes. El tiempo de primera respuesta de SLA de Zendesk se puede cumplir con una respuesta automática, mientras que la métrica nativa de tiempo de primera respuesta excluye por completo las acciones automatizadas y de bots.

¿Debo informar el tiempo de primera resolución o el tiempo de resolución completa?

Informe el que decida definir. El tiempo de primera resolución finaliza la primera vez que un ticket se establece como resuelto. El tiempo de resolución completa finaliza la última vez, por lo que los tickets reabiertos marcan la diferencia entre ambos.

¿Las métricas de soporte se miden en horas naturales o laborables?

Ambas se almacenan. Los informes predefinidos de Explore de Zendesk muestran horas naturales, y las métricas de horas laborables están disponibles para los informes que cree usted mismo.

¿Por qué cambió el recuento de resueltos del trimestre pasado?

Los recuentos de resueltos incluyen los tickets que están actualmente resueltos o cerrados. Un ticket reabierto después de que finaliza el período deja de pertenecer al recuento de dicho período.

¿Puedo comparar mi tiempo de resolución con un punto de referencia de la industria?

Solo de manera aproximada. Las definiciones, el reloj y la combinación de canales son configurables, por lo que una cifra publicada probablemente se midió con reglas diferentes a las suyas.