Cómo funcionan las etapas
Las etapas están diseñadas para modelar el flujo de trabajo que desarrolla un negocio para procesar los pedidos de servicio. Las mismas se definen por la definición de mesa de servicio. Al menos una etapa se define como etapa inicial y al menos una etapa se define como etapa final. Generalmente hay varias etapas medias.
Las etapas se secuencian seleccionando una o más etapas "a". La secuencia de etapas está definida por el usuario. Depende de las políticas definidas por la organización de servicio y de los criterios de los usuarios individuales que utilicen el sistema. Una secuencia de etapas está representada gráficamente por la pestaña Ver dentro de una definición de mesa de servicio.
Los procedimientos de eventos se ejecutan en el momento en que un ticket pasa de una etapa a la siguiente. Los procedimientos programados, como los procedimientos de escalación, se activan para ser ejecutados en base al tiempo que un ticket permanece en una etapa. De cierta forma, los procedimientos de escalación se ejecutan cuando un evento de sistema no se produce dentro de un determinado período de tiempo.
Cuando se crea una definición de mesa de servicio, las secuencias de etapas se completan por medio de la plantilla utilizada para crear la definición de mesa de servicio. Una vez que se ha creado una definición de mesa de servicio en base a una plantilla, estas etapas predeterminadas pueden modificarse para adaptarse a sus requisitos comerciales.
Ejemplo: las etapas de la Mesa de servicio estándar
La descripción de cada etapa a continuación asume que los usuarios de VSA en cuestión no son administradores de la Mesa de servicio y por lo tanto tienen sus vistas de tickets limitadas por su rol de usuario y ámbito.
Nota: Ver el punto Configuración para obtener instrucciones sobre cómo crear esta y otras mesas de servicios predefinidas en forma automática.

Identificado: un ticket recientemente creado en la mesa de servicio estándar comienza en la etapa Identificado .
- El procedimiento de ingreso a etapa
Estándar ingresa a Identificado ejecuta un subprocedimiento que configura la categoría y subcategoría del ticket, en base a las palabras clave en la línea de resumen del ticket. - Un segundo subprocedimiento fija la prioridad del ticket, en base a la severidad y a la urgencia del ticket. La severidad es un campo estándar en todas las mesas de servicio. La urgencia es un campo personalizado definido para la mesa de servicio
estándar . - El ticket se asigna a un
Tier1Pool de usuarios. Los usuarios de VSA ven los tickets asignados a ellos más todos los tickets asignados al grupo al que pertenecen. Los miembros de Tier1Pool son notificados por correo electrónico y por bandeja de entrada de VSA de la creación de un nuevo ticket. - La persona que envió el ticket también es notificada de la creación de un ticket y recibe el número de ticket para su posterior referencia.
- Un procedimiento de escalación se vincula a esta etapa. Si el ticket no es movido de la etapa
Identificado dentro de los 15 minutos, se ejecuta el procedimiento de escalación. El procedimiento de escalación notifica al Tier1Pool de usuarios nuevamente, junto con un grupo de usuarios SupportManager . La intención del procedimiento de escalación es asegurar que todos los tickets recientemente creados sean revisados inmediatamente. - Un procedimiento de objetivo de una hora también se vincula a esta etapa. El procedimiento de objetivo no tiene pasos del procedimiento definidos y puede personalizarse. El tiempo del objetivo de etapa puede usarse para fijar el código de color de los tickets utilizando Preferencias por rol o Preferencias por usuario.
Existen otros dos factores que pueden automatizar el comportamiento de los tickets en cualquier etapa:
- Asignación automática de ticket desde un grupo: la primera vez que un miembro del
Tier1Pool abre el ticket, ese miembro queda asignado al ticket. Otros miembros del Tier1Pool ya no ven el ticket en sus vistas de tickets. - Estándar modificado: esta no es una etapa, sino un procedimiento de Cambio de ticket. El mismo procedimiento
Estándar modificado se ejecuta cada vez que se guarda un ticket, aún si un cambio menor al ticket no incluye el cambio de etapa. Una de las tareas que lleva a cabo Estándar modificado es la de determinar si el ticket es nuevo mirando el estado Nuevo . Si es verdadero, el ticket se mueve inmediatamente a la etapa Tier1 .
Tier1 - El asignatario del ticket ahora tiene la tarea de trabajar con el ticket en la etapa Tier1 .
- El procedimiento de ingreso a etapa
Estándar ingresa a Tier1 agrega una nota predefinida que indica que la etapa está en Tier1. - El asignatario también se convierte en el "propietario" del ticket. El propietario de un ticket generalmente sigue siendo responsable del ticket, aún si el ticket es asignado a una serie de asignatarios diferentes a lo largo de su ciclo de vida. El propietario puede filtrar las vistas de tickets, permitiendo a los propietarios administrar tickets que pueden haber sido olvidados por sus asignatarios actuales.
- Un procedimiento de escalación y procedimiento de objetivo se vinculan también a esta etapa.
- Un ticket puede asignarse manualmente tanto a la etapa
Tier2 como a la etapa Cerrado , según lo indicado por las dos flechas rojas que salen de la burbuja Tier1 en el gráfico anterior.
Tier2: el movimiento de un ticket a la etapa Tier2 implica generalmente que el ticket requiere una persona con más experiencia para resolverlo, brindando quizás un área de especialización en particular.
- Un procedimiento de ingreso a la etapa
Estándar ingresa a Tier2 automáticamente asigna el ticket a un Tier2Pool de usuarios, de manera que el personal de Tier1 no tenga que adivinar a quién asignarlo. - Un procedimiento de escalación y procedimiento de objetivo se vinculan también a esta etapa.
Cerrados: los tickets resueltos se configuran en la etapa Cerrados .
- El procedimiento de ingreso a la etapa
Estándar ingresa a Cerrados notifica al remitente del ticket que el ticket está cerrado.
|