Políticas de tiempo de espera
La política de tiempo de espera es un conjunto de reglas que definen qué debe suceder cuando un elemento de la aplicación permanece en un estado determinado durante más horas de las especificadas.
En los capítulos anteriores, creamos el flujo de trabajo y definimos nuestros campos personalizados. Ahora, añadiremos algunas reglas de tiempo de espera.
Continuando con nuestra aplicación Bug, supongamos que nuestra empresa es muy estricta con el control de calidad y exige lo siguiente:
- Regla n.° 1: Un nuevo error debe verificarse en un plazo de 48 horas. Si se trata de un error de alta prioridad, debe verificarse en un plazo de 24 horas.
- Regla n.° 2: Un error marcado como solucionado debe probarse dentro de las 72 horas posteriores a su corrección. Si se trata de un error de alta prioridad, debe probarse dentro de las 48 horas.
Agregar una política de tiempo de espera
Abra la pantalla de la lista de aplicaciones yendo a Menú principalAdministraciónAplicaciones personalizadasAplicaciones and clicking on the icon for our Bug app. Then click on the Agregar botón.
| When In State | El estado del error en el que se aplica la regla. En nuestro caso, hemos definido las reglas para los estados Nuevo y Verificado porque el equipo de control de calidad es responsable en estos estados. |
| Sla Ttl | Puedes establecer las horas por prioridad. En nuestro caso, hemos establecido las horas según nuestras reglas n.° 1 y n.° 2. La Anular , si está marcada, significa que el usuario final que realiza la transición puede especificar cuándo ocurrirá el tiempo de espera. Tomemos como ejemplo un sistema CRM. El ejecutivo de ventas realiza un seguimiento con el cliente potencial cada 5 días. Sin embargo, en algunos casos, el cliente potencial puede estar de vacaciones y pedirle que realice el seguimiento después de, digamos, 2 semanas. En ese caso, el ejecutivo de ventas, al momento de marcar la consulta como "Seguimiento realizado", puede especificar la próxima fecha de seguimiento. |
| Acción | La transición de estado se realiza después de que expire el tiempo. No necesitamos esto en nuestro ejemplo de seguimiento de errores, pero tomemos el ejemplo de este flujo de trabajo de mesa de ayuda. En este ejemplo, puede que se desee que todos los tickets en Resuelto pasen al Cerrado si no recibimos respuesta del cliente en 5 días. En ese caso, estableceríamos 5x24, es decir, 120 para todas las prioridades y elegiríamos la acción Cerrar. |
| Sla Mark Delayed | Esta opción marcará el error como "Retrasado" y notificará al responsable asignado y al administrador del estado. |
¿Qué sigue?
En este capítulo hemos visto cómo definir políticas de tiempo de espera y para qué se utilizan. En el próximo capítulo, veremos cómo iniciar flujos de trabajo a partir de correos electrónicos.