Quizás programe informes del panel desde Explore para enviar archivos PDF a su equipo. O puede que extraiga números manualmente todos los meses y los coloque en una hoja de cálculo. También es posible que cree informes en Explore con los mismos números. Si estos métodos muestran resultados diferentes y le confunden, cabe preguntarse por qué no coinciden los números.
Al analizar estas discrepancias, lo más importante que debe recordar es que los archivos PDF y las hojas de cálculo son estáticas, mientras que Explore es dinámico.
En este artículo se tratan los siguientes temas:
Por qué cambian los resultados
Supongamos que el 1 de agosto exportó datos de todo el mes de julio y los puso en una hoja de cálculo. Pero después, en septiembre, generó otro informe en Explore con los mismos datos, y este tiene números diferentes para julio.
| Columna de julio basada en una exportación realizada en agosto: | Columna de julio en un informe generado en Explore en septiembre: |
 |
 |
Siga leyendo para obtener más información:
¿Por qué hay diferencia en los tickets creados?
El número total de tickets creados puede reducirse si se borran tickets.
Los tickets borrados se eliminan del conjunto de datos Tickets. De modo que, si marca tickets como spam o los borra, esos tickets se eliminan del número total de tickets. Y, por extensión, también se cambia el número de tickets creados.
En el ejemplo de arriba, el número de tickets creados bajó de 705 a 693. Eso sugiere que se borraron 12 tickets entre cuando se exportaron los datos en agosto y cuando se generó el informe en Explore en septiembre.
Por otro lado, el número total de tickets creados puede aumentar si se han recuperado tickets borrados.
Si desea analizar el número de tickets borrados y recuperados, puede usar las métricas Eliminaciones y Recuperaciones en el conjunto de datos Updates history.
Para las Eliminaciones, no se pueden ver los detalles como la ID del ticket u otros atributos (porque los tickets se han borrado), pero sí se puede ver:
- Cuándo se borraron los tickets, usando el atributo Actualizar - Marca de tiempo.
- Quién borró los tickets, usando el atributo Nombre del actualizador.
Para las Recuperaciones, se puede ver información similar sobre cuándo ocurrieron y quién las hizo, además de otros atributos del ticket, como la ID del ticket (porque el ticket vuelve a existir).
¿Por qué hay diferencia en los tickets resueltos?
Normalmente, los tickets creados se visualizan en función del atributo Ticket creado - Fecha, y los tickets resueltos en función del atributo Ticket resuelto - Fecha. Sin embargo, hay casos en que estos números varían en función de eventos determinados.
Si se analizan los tickets resueltos por fecha de resolución, estos números se verán afectados por la métrica Reaperturas (disponible en los conjuntos de datos Tickets y Updates history). Las cifras cambian si los tickets se vuelven a abrir entre el momento en que se exportaron los datos y el momento en que se generó el informe en Explore. Una reapertura puede eliminar un ticket de la métrica por completo (porque ya no está resuelto) o moverlo de un periodo a otro (si la última resolución tuvo lugar en un periodo diferente al de la primera resolución).
Si se analizan los tickets resueltos por fecha de creación, estos números se verán afectados por las resoluciones a lo largo del tiempo. Si se crean 10 ticket el lunes y 2 se resuelven el mismo día, la exportación muestra 2 tickets resueltos el lunes. Si se resuelven 3 más el martes, el informe —y la siguiente exportación— muestra que el lunes se crearon 5 tickets resueltos.
La métrica Tickets resueltos en el conjunto de datos Updates history solo tiene en cuenta la última resolución de los tickets resueltos en ese momento. Esto se puede ver en la fórmula de la métrica (en concreto, en las dos condiciones que aparecen en negrita):
IF ([Changes - Field name]="status"
AND [Changes - Previous value]!="solved"
AND ([Changes - New value]="solved" OR [Changes - New value]="closed")
AND ([Ticket status - Unsorted] = "Solved" OR [Ticket status - Unsorted] = "Closed")
AND [Update - Timestamp]=[Ticket solved - Timestamp])
THEN [Update ID]
ENDIF
Si desea hacer seguimiento de todas las resoluciones, puede crear una métrica calculada estándar que elimine esas dos condiciones aplicables al estado y la fecha actuales, lo que creará la siguiente fórmula:
IF ([Changes - Field name]="status"
AND [Changes - Previous value]!="solved"
AND ([Changes - New value]="solved" OR [Changes - New value]="closed"))
THEN [Update ID]
ENDIF
¿Por qué hay diferencia en los tickets de una categoría determinada
El conjunto de datos Tickets analiza el estado actual de los tickets: estado, grupo, agente asignado, prioridad, campos personalizados y otros aspectos. Eso quiere decir que si un campo cambia entre el momento en que se exportan los datos y el momento en que se genera un informe en Explore, lo más probable es que los resultados cambien.
En las capturas de pantalla del ejemplo de arriba, se puede ver que la exportación de agosto muestra 10 blips y 61 bugs. Pero en la exportación de septiembre, Explore muestra 2 blips y 69 bugs. Eso sugiere que, entre el momento en que se hizo la exportación y el momento en que se creó el informe, se reclasificaron 8 tickets de blip a bug.
Este tipo de cambio también puede afectar los filtros de los informes. Por ejemplo, digamos que tiene un informe filtrado para mostrar los tickets del grupo A únicamente. Si un ticket se cambia del grupo A a otro grupo entre el momento en que se hizo la exportación y el momento en que se creó el informe, ese ticket ya no aparecerá en el informe.
Lo contrario es cierto para los tickets que estaban asignados originalmente al grupo B y luego fueron reasignados al grupo A. En este caso, habrá más tickets que antes en el informe, debido al filtro.
La importancia de entender los números en su contexto
Al examinar las discrepancias entre las exportaciones y los informes de Explore, conviene no perder la perspectiva de los números en sí. Tome en cuenta lo siguiente:
- Si un resultado cambia de 20 tickets a 21, el aumento es 1. En principio no parece mucho. Pero es un cambio del 5 %.
- Si otro resultado cambia de 1998 a 2100, la diferencia es 102. Eso podría parecer bastante. Pero también es un cambio del 5 %.
Cuando se trata de varianzas, hay que mirar el porcentaje además del número sin procesar. Eso puede ayudarle a comprender qué es importante y qué no lo es.
Considere cuántos agentes tiene. Si tiene 200 agentes y un resultado cambia por 102, eso sugiere que aproximadamente la mitad de los agentes, en promedio, cambió ese campo en un ticket entre el momento en que se exportaron los datos y el momento en que se generó el informe en Explore.
Una vez más, puede analizar estos resultados en el conjunto de datos Updates history. Utilice el atributo Nombre del actualizador para filtrar un informe que muestre el atributo [Cambios: nombre de campo] correspondiente y el resultado anterior o el nuevo que le esté causando confusión.
Con frecuencia, se verá una amplia distribución de cambios; por ejemplo, 100 agentes que hacen aproximadamente un cambio de campo en un periodo.
No obstante, es posible que vea que uno o dos agentes están cambiando los campos con más frecuencia. Quizás se trate de un gerente que está poniendo la cosas en orden. O quizás son agentes nuevos que no han comprendido bien cómo se aplica el campo, en cuyo caso podrían necesitar un poco más de capacitación.
Uso de los agregadores correctos
Por último, al analizar las duraciones, es una buena idea recordar la diferencia entre “cantidad” y “calidad”.
De manera predeterminada, Explore usa el agregador de la mediana (MED) para las métricas como el tiempo de primera respuesta y el tiempo de resolución. Pero podría tener algunos agentes asignados o grupos que atienden muy pocos tickets, y que además lo hacen de una manera muy diferente a los demás agentes. Tal vez pertenezcan a los equipos de finanzas o de seguridad que no trabajan con tickets con mucha frecuencia y que no tienen las mismas expectativas en cuanto a tiempos de respuesta.
Si usa el agregador MED en las métricas de duración podrá protegerse contra esos valores atípicos. Si utiliza el agregador de promedio (AVG), esa protección se reduce. Por ejemplo, digamos que el equipo de finanzas ha tenido un ticket de un cliente en particular por seis meses, mientras que el resto del equipo normalmente resuelve los tickets en menos de una semana. El valor atípico del equipo de finanzas afecta seriamente la antigüedad de los tickets sin resolver, sobre todo si se está usando el agregador AVG.
Cuando el equipo de finanzas finalmente solucione el ticket, el tiempo de resolución para el periodo en que lo resolvió también podría verse afectado considerablemente, sobre todo si se está usando AVG.
Conclusión
Que los números cambien a lo largo del tiempo puede ser confuso. Lo comprendemos perfectamente. Sobre todo si su jefe le hace preguntas al respecto. Pero puede haber muchas razones lógicas para los cambios.
Si le preocupa la situación, considere los temas descritos anteriormente y cuál podría estar siendo su efecto. Si todavía tiene preguntas, échele un vistazo a la documentación de Explore o la comunidad para obtener ayuda, o contacte a Atención al cliente de Zendesk.