Cómo funcionan las etapas

Las etapas están diseñadas para modelar el flujo de trabajo que desarrolla una empresa para procesar los temas de soporte. Las etapas se definen por la definición del Departamento de servicios. Una etapa se define como la etapa de Inicio y una etapa se define como la etapa de Finalización. Generalmente hay varias etapas medias.

Las etapas se secuencian seleccionando una o más etapas "a". La secuencia de las etapas se define por el usuario. Depende de las directivas definidas por la organización del servicio y los criterios de los usuarios individuales que usen el sistema. Una secuencia de etapas está representada gráficamente por la pestaña Vista dentro de una definición del Departamento de servicios.

Un procedimiento de evento se ejecuta en el momento en que un ticket pasa de una etapa a la siguiente. Un procedimiento programado, como los procedimientos de escalamiento, se desencadena para la ejecución según el tiempo que un ticket permanece en una etapa. Por ejemplo, un procedimiento de escalamiento se ejecuta normalmente cuando un ticket permanece demasiado tiempo en una etapa, en lugar de ser resuelto y movido a otra etapa.

Cuando se crea una definición del Departamento de servicios, las secuencias de etapas se completan con la plantilla que se usa para crear la definición. Una vez que se creó una definición del Departamento de servicios basada en una plantilla, estas etapas predeterminadas se pueden modificar para adaptarse a sus requisitos comerciales.

Ejemplo: las etapas de Customer_SD_Automation

La descripción de cada etapa a continuación supone que los usuarios del VSA en cuestión no son administradores de Service Desk y, por lo tanto, sus vistas de tickets están limitadas por su rol de usuario y su ámbito.

Nota: Consulte el tema Plantillas del Departamento de servicios para obtener instrucciones sobre cómo crear este y otros Departamentos de servicios predefinidos en forma automática.

Nuevo ticket: un nuevo ticket creado en Customer_SD_Automation se inicia en la etapa New Ticket.

• En el procedimiento de entrada de etapa CS Incident enters New Ticket, se asigna el ticket a un grupo de técnicos del servicio de tickets de Tier1Support. Los usuarios del VSA ven todos los tickets asignados a ellos además de cualquier ticket asignado al grupo al cual pertenecen.
• Para estos mismos usuarios, se crea un mensaje del VSA y un mensaje de correo electrónico. El remitente del ticket también recibe un correo electrónico de confirmación de que se creó un ticket.
• Un procedimiento de escalación se vincula a esta etapa. Si el ticket no se movió de la etapa CS Incident enters New Ticket en el transcurso de 1 hora, se ejecuta el procedimiento de escalamiento. En el procedimiento de escalamiento, se notifica al asignatario del ticket y al grupo de usuarios de Tier1Support. La intención del procedimiento de escalación es asegurar que todos los tickets recientemente creados sean revisados inmediatamente.

Existen otros dos factores que pueden automatizar el comportamiento de los tickets en cualquier etapa:

• Asignación automática de ticket de un grupo: el ticket se asigna al miembro del Tier1Pool que abre el ticket por primera vez. Los otros miembros del Tier1Pool ya no ven el ticket en su vista de tickets.
• Ticket modificado: esta no es una etapa, sino un procedimiento de Cambio de ticket. El mismo procedimiento CS Incident is Changed se ejecuta cada vez que se guarda el ticket, aun si un cambio menor en el ticket no incluye cambiar de etapa. En este procedimiento de cambio de ticket, se comprueba lo siguiente:
  • Si el ticket es nuevo, se mueve de inmediato a la etapa Tier1.
  • Si el ticket tiene un asignatario, este se convierte en el “propietario” del ticket. En general, el propietario de un ticket sigue siendo responsable del ticket, aun si se asigna a una serie de usuarios diferentes durante 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.
  • Si el ticket está resuelto, se cierra.
  • Si un ticket ya está cerrado, pero un cliente envía un correo electrónico que hace referencia al ticket, este se vuelve a abrir.

Tier1: el asignatario del ticket ahora tiene la tarea de trabajar con el ticket en la etapa Tier1.

• Se envía un correo electrónico al asignatario.
• También se vincula un procedimiento de escalamiento a esta etapa.
• Un ticket se puede asignar manualmente tanto a la etapa Tier2 como a la etapa Solved, como lo indican las dos flechas rojas que salen de la burbuja de Tier1 en el gráfico anterior.

Tier2: en general, mover un ticket a la etapa Tier2 implica que el ticket requiere una persona con más experiencia para resolverlo, que cubra un área de especialización en particular.

• En el procedimiento de entrada de la etapa CS Incident Enters Tier2, se asigna el ticket de forma automática a un Tier2Pool de usuarios, de manera que el personal del Tier1 no tenga que adivinar a quién asignarlo.
• Para estos mismos usuarios, se crea un mensaje del VSA y un mensaje de correo electrónico. El remitente del ticket también recibe un correo electrónico de confirmación de que el ticket se asignó al Tier2Pool para continuar la investigación.
• También se vincula un procedimiento de escalamiento a esta etapa.

Resuelto: los tickets resueltos se envían a esta etapa a la espera de que el remitente confirme que recibió la notificación.

• En la etapa CS Incident Enters Solved, se envía un correo electrónico al remitente con la notificación de que se resolvió el ticket.
• Los tickets resueltos se vuelven a abrir cuando el cliente envía un correo electrónico de respuesta o cuando el cliente no vuelve a comunicarse. Finalmente el ticket se cierra en forma manual.

Cerrado: los tickets resueltos se establecen en la etapa Closed.

• En el procedimiento de entrada de la etapa CS Incident Enters Closed, se notifica al remitente del ticket que el ticket se cerró.