En Support, las vistas permiten organizar los tickets en listas usando los datos de tickets y usuarios. Si desea más información sobre las vistas, consulte Uso de vistas para administrar el flujo de trabajo de tickets.
Si alguna vez ha creado una vista compleja con muchas condiciones o una vista que devuelve muchos tickets, es posible que no haya estado muy contento con el tiempo que toma cargar y mostrar la vista. Si un vista es muy compleja o muy grande, eso puede afectar el rendimiento.
En este artículo se describen algunas de las mejores prácticas que se pueden usar para optimizar las vistas en Zendesk Support. Lo que sigue no es una lista estricta de lo que se puede y lo que no se puede hacer, sino más bien sugerencias para crear vistas optimizadas para el rendimiento y evitar la complejidad innecesaria.
En este artículo, se tratan los siguientes temas:
- Consejos generales
- Manipulación de conjuntos de datos grandes
- Paginación
- El "tope de consultas"
- Vistas complejas
Consejos generales
Para comenzar, al crear declaraciones de condición de vistas, se debe evitar lo siguiente:
- Marcar varios campos de texto
- Comprobar si hay un valor nulo, p. ej., "Agente asignado es ( - )"
- Usar condiciones ampliamente excluyentes, p. ej., declaraciones "NOT"
En su lugar, se deben usar condiciones incluyentes y lo más específicas que se pueda - Comprobar si hay etiquetas
- Usar la condición "no contiene la siguiente cadena/palabra" para buscar una descripción del ticket
Al comprobar si hay una cadena/palabra se introduce una mayor complejidad que al comprobar si hay una etiqueta
Se prefieren las condiciones que comprueban si hay etiquetas ya que se consideran "el menor de dos males" comparado con las comprobaciones para ver si hay una palabra/cadena.
Recuerde que mostrar una vista implica hacer búsquedas en todos los tickets no almacenados para encontrar coincidencias para las condiciones definidas en las vistas. Siempre es mejor definir vistas que busquen algo que sí existe en lugar de comprobar que algo no existe.
Manipulación de conjuntos de datos grandes
Si tiene que ver una gran cantidad de tickets (por ejemplo, cientos de miles de tickets para un informe de fin de año), podría ser mejor exportar primero los tickets a un almacén de datos externos fuera de Zendesk Support y luego extraer los datos desde ahí.
Almacenamiento de tickets
Zendesk Support almacena automáticamente los tickets 120 días después de que se han cerrado. Todavía es posible acceder a los tickets, pero no se incluyen en las vistas. Consulte Acerca del almacenamiento de tickets.
Paginación
Una vista podría contener tantos tickets que los resultados podrían tener una gran cantidad de páginas. En esos casos, los resultados se dividen en varias páginas de 30 tickets cada una. En el sector a esto se le conoce como una "consulta de compensación grande" y puede tener un impacto considerable en el rendimiento.
Se podría preguntar, "¿Pero cuál es el límite de paginación?", y la respuesta sería que no se trata de un límite estricto de paginación (aunque tener varias decenas de páginas hará que la vista sea más compleja) sino de los siguientes factores:
- El volumen de tickets
- El número de agentes que acceden a la vista a la vez
- Las condiciones
El "tope de consultas"
¿Qué es el "tope de consultas"? Es algo que los expertos de nuestro equipo de operaciones implementó para evitar la carga de una vista de enormes proporciones debido a la cantidad de procesamiento que requeriría.
Estos son los dos motivos principales por lo que eso puede suceder:
- Una vista requiere un cálculo muy complejo de los tickets y/o se devuelve un volumen enorme de tickets.
Nota: Una vista personal solo necesitaría un tope de consultas si genera un volumen enorme de tickets. - Una vista tiene mucho tráfico en un momento dado (por ejemplo, cientos de agentes miran la vista al mismo tiempo).
Vistas complejas
Una vista compleja que se abre una sola vez al día probablemente está bien. La primera vez que se abre una vista en un día en particular, es cuando más tiempo toma en todo el día, salvo que en algún momento se borre la memoria caché. El mayor impacto en el rendimiento se producirá si hay una vista muy compleja que tiene miles de tickets y a la que acceden cientos de agentes varias veces en un minuto.