Este artículo de perfeccionamiento trata sobre lo que hay que tener en cuenta al crear un flujo de trabajo, lo que incluye:
Además, no olvide darle una mirada a la 1ra parte de esta discusión de perfeccionamiento.
Si desea ver más artículos de perfeccionamiento, consulte Recursos de perfeccionamiento.
1ra parte: Disparadores y automatizaciones
Mi último artículo de Perfeccionamiento paso a paso, trató sobre los elementos básicos que se necesitan para crear la instancia ideal de Zendesk y cómo se pueden configurar para satisfacer necesidades específicas. Esta vez, voy a analizar los demás elementos que permiten crear un flujo de trabajo ideal.
Disparadores
Los disparadores son algo maravilloso. Son acciones del sistema basadas en eventos que se ejecutan al crear los tickets o al actualizarlos. Hay varias maneras de usar los disparadores en Zendesk, pero en general se pueden categorizar así:
- Asignar tickets a un agente específico o a un grupo de agentes.
- Cambiar los valores de campo de ticket o agregar/eliminar etiquetas.
- Notificar a los usuarios (o destinos) que se han creado o actualizado tickets.
- Cambiar los valores de campo de usuario u organización (solo en las actualizaciones de ticket).
Problemas potenciales:
Zendesk tiene algunos disparadores estándar que quizás convenga desactivar o modificar. Si no verifica la lista de disparadores antes de ponerlos en funcionamiento, es posible que termine con una bandeja de entrada llena de notificaciones no deseadas.
El disparador predeterminado Notificar al solicitante sobre actualización de comentarios es el disparador más importante de la cuenta. Ese es el disparador que envía los comentarios del ticket a los usuarios finales. Si lo modifica o lo borra, tenga en cuenta que se puede ver afectada su capacidad de comunicación con los clientes.
Intente que un disparador no haga muchas cosas. Cuanto más complicado sea un disparador, más difícil será resolver los problemas y mantenerlo.
Si tiene una instancia abierta de Zendesk Support en la que cualquier persona puede enviar tickets y no se requiere ningún tipo de registro, los disparadores de primera respuesta (que se gatillan cuando se crea un ticket) que usen cualquiera de los siguientes marcadores de posición pueden ser objetivo de spam de retransmisión.
- {{ticket.title}}
- {{ticket.requester.first_name}}
- {{ticket.requester.last_name}}
- {{ticket.requester.name}}
El spam de retransmisión ocurre cuando se envía correo a un destino a través de un tercero (en este caso, Zendesk) para ocultar el origen de la dirección de correo electrónico y hacerse pasar por el tercero. Estos marcadores de posición son objetivos del spam de retransmisión porque utilizan un extremo anónimo que permite que cualquier persona ingrese el texto o los vínculos que desee.
Para evitar el riesgo de que su cuenta se convierta en un objetivo para el spam de retransmisión, considere configurar su instancia para que sea cerrada o restringida, como se explica en Configuración del acceso de los usuarios finales. Si no, en una instancia abierta de Zendesk Support, no utilice los marcadores de posición de arriba en el asunto o el cuerpo de los disparadores de primera respuesta, use texto estático en su lugar. Así se podrá asegurar de que la notificación por correo electrónico que se envía cuando se crea un ticket, por ejemplo, no reemplace el saludo que debería decir “Estimada Amanda Suárez” con “Estimada www.spam.com”. El uso de marcadores de posición en otros disparadores (después de la primera respuesta) es aceptable porque, para ese entonces, ya se ha establecido que la interacción es genuina.
Mejores prácticas:
Use una convención de nomenclatura, y no se aparte de ella. Lo ideal es poder conocer la función del disparador con solo ver su nombre. Ahorrará mucho tiempo si no tiene que hacer clic en cada disparador para ver qué hace. A continuación se muestran algunos ejemplos:
Establecer prioridad - Normal
Establecer horario - Norteamérica
Asignar a grupo - Nivel 1
Notificar al solicitante sobre actualización de comentarios
Si la lista de disparadores tiene más de una página, la convención de nomenclatura será muy importante. Se pueden hacer búsquedas de disparadores en función del título.
El orden de los disparadores es importante. El sistema verificará cada disparador cada vez que se crea o actualiza un ticket. Yo sugiero ordenar los disparadores de la siguiente manera:
- Cambiar/actualizar los valores del ticket: los disparadores que cambian los valores del ticket como las prioridades, los estados y cualquier otro valor de campo, o que agregan tickets, deben ir primero. Esto es porque estos disparadores pueden afectar las asignaciones del ticket y las notificaciones.
- Asignaciones de tickets: los disparadores que asignan tickets a grupos o a agentes individuales deben ir después de los disparadores que actualizan cualquier otro valor del ticket.
- Notificaciones: los disparadores que envían notificaciones a los usuarios o destinos deben ir al final, porque conviene que el sistema haga los cambios necesarios antes de enviar las notificaciones por correo electrónico.
Dentro de cada una de las categorías mencionadas arriba, se recomienda ordenar los disparadores de los más específicos a los más generales. Así se evita que los disparadores más generales se disparen sobre los disparadores más específicos.
Dentro de lo posible, intente que los disparadores sean más bien sencillos y bien pensados. Cuanto más sencillos sean, más fácil será mantenerlos al ir creciendo o al cambiar de administrador.
Preguntas que se debe hacer:
- ¿Usan los agentes Zendesk todo el día, o usan más bien el correo electrónico?
- ¿Cuáles de los agentes necesitan recibir notificaciones por correo electrónico?
- ¿Cuándo necesitan recibir las notificaciones?
- ¿Cuándo necesitan recibir las notificaciones los usuarios finales?
- ¿Qué elementos del flujo de trabajo pueden automatizarse?
- ¿Qué elementos del flujo de trabajo necesitan automatizarse?
- ¿Cómo se deben redactar los disparadores de una notificación?
Hay más información sobre cómo crear y administrar disparadores aquí.
Automatizaciones
Las automatizaciones son acciones del sistema basadas en el tiempo. Se ejecutan cada hora y por lo general tienen condiciones que dependen del tiempo, y se pueden usar para hacer lo siguiente:
- Asignar tickets a un agente específico o a un grupo de agentes.
- Cambiar los valores de campo de ticket o agregar/eliminar etiquetas.
- Notificar a los usuarios (o destinos) que se han creado o actualizado tickets.
- Cambiar los valores de campo de usuario y organización.
Es posible que haya observado que las acciones que se pueden realizar con las automatizaciones son iguales a las acciones que se pueden realizar con los disparadores. La diferencia no es qué acciones pueden realizar, sino más bien qué condiciones las gatillan. Las automatizaciones permiten realizar acciones del sistema cuando han transcurrido x horas desde o quedan x horas hasta un evento.
Problemas potenciales:
Las automatizaciones solo se ejecutan como máximo una vez por hora. Por eso es difícil depender de ellas para las actualizaciones de alta prioridad. Si un ticket llega incluso un minuto después de la ejecución de las automatizaciones, es posible que el ticket se siga viendo como 0 horas desde que se creó una hora después, cuando se vuelven a ejecutar las automatizaciones.
Si establece una condición basada en el tiempo estricta (como Horas desde que se creó es X) en lugar de una condición basada en el tiempo menos estricta (como Horas desde que se creó es mayor que X), es posible que las automatizaciones no se ejecuten durante la hora en que el ticket cumple la condición. En ese caso se corre el riesgo de que se pierdan notificaciones importantes o actualizaciones del ticket.
Mejores prácticas:
Antes de crear una automatización, pregúntese si conviene usar un disparador o una automatización para obtener los resultados que desea. En muchas situaciones, los disparadores son más eficaces porque se pueden gatillar de inmediato.
De ser posible, use las condiciones mayor que/menor que en lugar de la condición es al crear automatizaciones basadas en el tiempo. Así se elimina la posibilidad de que el ticket pase desapercibido y la automatización no se dispare. Tenga en cuenta que si hace esto, tendrá que agregar una condición y acción de anulación para evitar un bucle (el sistema le advertirá si es necesario).
Para que eso funcione, lo más sencillo es hacer que las condiciones busquen algo (como una etiqueta o un valor de campo) que el ticket no debía tener antes de ejecutarse la automatización, y luego asegurarse de que la automatización haga un cambio que haga que el ticket quede descalificado la próxima vez que se ejecute la automatización. Así se podrá asegurar de que la automatización no se ejecute varias veces.
Las automatizaciones se pueden usar para crear un flujo de trabajo recordar, recordar, resolver automatizado. Así se asegura de que los tickets no se estanquen si el solicitante no responde, y también evita que dichos tickets obstruyan innecesariamente las vistas.
Preguntas que se debe hacer:
- ¿Conviene más un disparador o una automatización?
- ¿Necesita que el sistema le notifique o haga algo cuando un ticket se vuelve obsoleto?
- ¿Cuánto tiempo debe permanecer un ticket en estado resuelto antes de cerrarse?
- ¿Qué desea que digan las notificaciones por correo electrónico?
Hay más información sobre cómo crear y administrar automatizaciones aquí.
2da parte: Horarios comerciales y SLA
Horarios comerciales
Si bien los horarios comerciales no son tan llamativos como los disparadores y las automatizaciones, sí pueden desempeñar un papel esencial en los flujos de trabajo. Si se establecen horarios comerciales, es posible:
- Realizar acciones del sistema con disparadores y automatizaciones durante el horario comercial o fuera de él.
- Especificar el tiempo en función del horario comercial (en lugar de horas calendario) dentro de las automatizaciones y los SLA.
- Proporcionar objetivos de servicio precisos a través de SLA.
Problemas potenciales:
El primer horario de la lista es el horario predeterminado, y se aplicará a todos los tickets nuevos. Los horarios no se pueden reorganizar, lo que quiere decir que no puede usar un horario nuevo o uno existente como su horario predeterminado. Para establecer un horario nuevo como predeterminado, tendrá que borrar todos los horarios de más arriba (o cambiarles el nombre y las propiedades).
Puede agregar feriados a sus horarios, pero no se transfieren de un año a otro, lo que quiere decir que tendrá que agregarlos manualmente todos los años.
Los feriados son fechas que se eliminarán del horario comercial, de modo que si solo trabaja medio día, se hará una pausa de todo el día en los SLA basados en el horario comercial. (Eso podría ser conveniente, según como se interprete).
Los horarios no se pueden clonar, por lo que tendrá que ingresar manualmente los feriados todos los años en cada horario.
No olvide especificar la zona horaria. El horario será útil solo si tiene la zona horaria correcta. En algunos tipos de planes, se puede especificar la zona horaria para cada horario individual. En otros tipos de planes, se puede establecer el horario aquí.
Mejores prácticas:
Haga un plan antes de comenzar a configurar horarios. Ingrese el horario predeterminado (si tiene uno) primero. Este horario se aplicará a todos los tickets nuevos de manera predeterminada, lo que significa que todos los SLA que se hayan aplicado al ticket usando el horario comercial usarán ese horario.
Si usa varios horarios, puede utilizar disparadores para asignar horarios a los tickets. Por ejemplo, podría crear un disparador que se asigne al horario X cuando se asigne un ticket al grupo X. Si lo hace para todos los horarios, no importará cuál de los horarios esté establecido como el predeterminado.
Los horarios no se pueden clonar, pero SÍ se pueden clonar los feriados. Aunque tendrá que ingresarlos manualmente, por lo menos podrá clonarlos y cambiar las fechas. Esa es la mejor manera de ingresar los feriados que se repiten de un año a otro.
Al crear los feriados, no es posible establecer una cantidad parcial de horas. Todo el día queda excluido del horario. Utilice esos días como días de recuperación, ya que probablemente el volumen de trabajo será menor de todos modos.
Preguntas que se debe hacer:
- ¿Ofrece soporte a los usuarios finales las 24 horas del día todos los días del año?
- ¿Tiene equipos que solo están disponibles durante horas o días específicos?
- ¿Tiene días feriados con menos horas de trabajo?
- ¿Cuántos horarios diferentes necesita crear?
Los horarios comerciales no están disponibles en los planes Team. Hay más información sobre cómo crear y administrar horarios aquí.
Políticas de SLA
Muchas compañías tienen compromisos con sus clientes que determinan la duración esperada de ciertos eventos.
Los Contratos de nivel de servicio (SLA) de Zendesk permiten priorizar tickets agregándoles objetivos de servicio. Los objetivos disponible son, entre otros:
- Tiempo de primera respuesta (el tiempo transcurrido entre la creación del ticket y el primer comentario público de un agente).
- Tiempo de espera del solicitante (el tiempo total que un ticket pasa en los estados Nuevo, Abierto y En espera).
- Tiempo de trabajo del agente (el tiempo total que un ticket pasa en los estados Nuevo y Abierto).
- Tiempo de siguiente respuesta (el tiempo transcurrido entre un comentario de un usuario final y el siguiente comentario público de un agente).
- Actualización periódica (el tiempo transcurrido entre un comentario público de un agente y el siguiente comentario público de un agente).
- Actualización con pausa (el tiempo transcurrido entre cada comentario público de los agentes cuando el estado del ticket es Nuevo, Abierto y En espera; se pone en pausa cada vez que el ticket está en estado Pendiente).
Problemas potenciales:
Los SLA de Zendesk exigen el uso del campo de prioridad del sistema. Si un ticket no tiene asignada una prioridad, no se aplican las políticas de SLA.
Si los SLA usan el horario comercial y hay varios horarios, será necesario verificar que cada ticket tenga aplicado el horario correcto. Salvo que se especifique lo contrario, cada ticket usará el horario comercial predeterminado.
El objetivo de tiempo de primera respuesta se cumplirá instantáneamente cuando un agente cree un ticket (aunque establezca a un usuario final como el solicitante). Esto se debe a que la descripción del ticket cuenta como el primer comentario público de un agente. Puesto que este objetivo se cumple de inmediato, aparecerá como si el ticket ya ha sido atendido.
El objetivo de tiempo de siguiente respuesta no funcionará para los tickets internos. El objetivo mide el tiempo transcurrido entre el comentario de un usuario final y el siguiente comentario público de un agente, de modo que ignorará todos los tickets solicitados por los agentes.
Evite usar todos los objetivos en una misma política. Decida entre Tiempo de espera del solicitante, Tiempo de trabajo del agente, o ninguno de los dos. No es necesario usar estos dos objetivos en la misma política, y si lo hace se complicarán demasiado las cosas.
Los incumplimientos de SLA no están disponibles como eventos que se pueden usar con los disparadores. Eso quiere decir que no hay manera de crear un disparador de notificación de incumplimiento inmediato.
Mejores prácticas:
Tiene seis objetivos diferentes a su disposición, pero no es necesario (ni aconsejable) usarlos todos en una sola política.
Los objetivos de tiempo de primera respuesta son una manera excelente de asegurarse de que todos los tickets nuevos se atiendan en un tiempo razonable. Los objetivos de tiempo de siguiente respuesta son igualmente importantes por la misma razón. Por lo general, recomendamos crear los objetivos de tiempo de siguiente respuesta para que sean muy parecidos o exactamente iguales a los objetivos de tiempo de primera respuesta dentro de la misma política.
Elija entre Tiempo de trabajo del agente o Tiempo de espera del solicitante, o ninguno de los dos, ya que ambos miden el tiempo que toma resolver un ticket. El Tiempo de trabajo del agente se mide desde la perspectiva del agente, de modo que se hace pausa cuando los tickets están en espera o pendientes. El Tiempo de espera del solicitante se mide desde la perspectiva del solicitante, de modo que se hace pausa cuando un ticket está pendiente.
Elija entre Actualización periódica o Actualización con pausa, o ninguna de las dos, ya que ambas miden el tiempo transcurrido entre los comentarios públicos realizados por los agentes.
Preguntas que se debe hacer:
- ¿Tiene obligaciones contractuales que dicten el cumplimiento de metas específicas?
- ¿Tiene metas internas para los objetivos de servicio?
- ¿Necesita varias políticas o una sola política que incluya todo?
- ¿Cómo prioriza los tickets?
- ¿Tiene una meta de servicio para el tiempo que tarda la solución de un ticket?
De ser así, ¿debe medirse desde la perspectiva del solicitante o del agente? - ¿Ofrece soporte a todos sus clientes las 24 horas del día todos los días del año?
¿Desea verificar sus objetivos usando horas calendario o su horario comercial?
Las políticas de SLA no están disponibles en los planes Team. Hay más información sobre cómo crear y administrar SLA aquí.
3ra parte: Macros y vistas
Macros
Las macros son scripts activados por los agentes que pueden realizar varias acciones en un ticket a la vez. Es importante saber que una macro solo puede hacer lo que hace un agente y que los cambios en el ticket se guardarán solo después de que el agente actualice el ticket.
Si los agentes usan macros aumentará su productividad, ya que se reduce la cantidad de veces que tienen que hacer clic.
Las macros pueden:
- Agregar el texto del comentario
- Actualizar los campos de los tickets (solo campos desplegables o casillas de verificación)
- Agregar o eliminar etiquetas de los tickets
- Agregar CC
- Cambiar el agente asignado
- Definir el asunto del ticket (título)
- Adjuntar archivos a los comentarios de los tickets
Problemas potenciales:
Las macros son básicamente métodos abreviados para los agentes. La macro solo puede hacer lo que el usuario actual puede hacer. Por ejemplo, si un agente no tiene permiso para editar las etiquetas de un ticket, la macro no agregará ni eliminará etiquetas cuando el agente ejecute la macro.
Las macros no actualizan texto, texto de varias líneas, fechas ni expresiones numéricas o regulares.
Mejores prácticas:
Al igual que con los campos desplegables, las macros se pueden anidar, lo cual es una excelente manera de organizarlas y mantenerlas limpias.
Se pueden ejecutar varias macros en una sola actualización del ticket, por lo que no es necesario crear una macro para cada situación que se pueda presentar. La sencillez es fundamental.
Utilice marcadores de posición. Si usa {{requester.first_name}} al comienzo de los comentarios, incluso sus respuestas más genéricas tendrán un toque personal. Los marcadores de posición también se pueden usar para definir el asunto del ticket.
Las macros se pueden asignar a todos los agentes o a grupos específicos. Si desea que solo algunos agentes puedan ver una macro, asegúrese de restringirla a esos agentes únicamente para reducir el exceso.
Puede hacer búsquedas de macros. Comience a escribir el título de la macro en el menú de macros dentro de un ticket para filtrar las macros en el menú.
Para que sea más fácil filtrar las macros, cree una convención de nomenclatura y no se aparte de ella.
Use las macros para actualizar varios tickets a la vez. Para ello, en la pantalla de vistas marque las casillas junto a varios tickets y haga clic en el botón negro que dice Editar tickets en la esquina superior derecha. Desde ahí, aplique una macro y envíela.
Los disparadores y las automatizaciones se pueden usar paralelamente con las macros. Por ejemplo, podría tener una macro que agregue una etiqueta que active de inmediato un disparador. Imagínese todas las posibilidades.
Preguntas que se debe hacer:
- ¿Cuáles son los problemas más comunes que hacen que sus usuarios finales envíen tickets?
- ¿Qué debe decir el texto de su comentario?
- ¿Debe la macro dejar un comentario público o privado?
- ¿Qué agentes deben tener acceso a qué macros?
Las macros están disponibles en todos los planes. Hay más información sobre cómo crear y administrar macros aquí.
Vistas
Y he guardado lo mejor para el final. Las vistas son posiblemente la parte más importante de los flujos de trabajo, ya que determinan qué tickets pueden ver los agentes y el orden en que deben ser atendidos.
Las vistas NO son carpetas. Son búsquedas guardadas o bases de datos filtradas. Son como las listas de reproducción inteligentes de iTunes.
Problemas potenciales:
No cree vistas demasiado complicadas. Cuantas más condiciones tenga una vista, más filtrados estarán los resultados. Eso puede ser conveniente, pero también puede ser desastroso. Si hay demasiadas condiciones, es posible que se pierdan algunos tickets.
Si hay demasiadas vistas, es posible que los agentes no prioricen los tickets como deberían. Para evitar esto, se puede reducir la cantidad de vistas a solo lo que se necesita.
Si el navegador queda abierto en una vista, no se actualizará automáticamente. Se actualizará cada vez que se haga clic en la vista (o se vuelva a cargar la página).
Las vistas pueden mostrar hasta 30 tickets por página. Si las vistas no están ordenadas correctamente, podrían perderse tickets importantes.
Mejores prácticas:
Al igual que con las macros, es posible asignar las vistas a todos los agentes o a grupos específicos. En muchos casos, tiene sentido crear vistas personalizadas para cada grupo. Así se puede garantizar que cada agente vea solo la información que le corresponde.
Si usa SLA, es una buena idea ordenar las vistas según el Próximo incumplimiento de objetivo de SLA. Así se puede asegurar de que todos los tickets llegarán a la parte de arriba en algún momento.
Utilice el botón Play, que se encuentra en la esquina superior derecha de la página de vistas y se encarga de abrir el siguiente ticket disponible en la vista.
Preguntas que se debe hacer:
- ¿Cómo deben priorizarse sus tickets?
- ¿Qué tickets debe ver cada grupo?
- ¿Cómo clasifica sus tickets?
Hay más información sobre cómo crear y administrar vistas aquí.