Como os estágios funcionam

Estágios foram criados para modelar o fluxo de trabalho executado por uma empresa para processar problemas de suporte. Eles são especificados por definição de desk. Um estágio é definido como um estágio Inicial e outro, como um estágio Final. Há, normalmente, vários estágios do Meio.

Os estágios são sequenciados selecionando um ou mais estágios "para". A seqüência dos estágios é definida pelo usuário. Ela depende das políticas definidas pela empresa de serviços e dos julgamentos de usuários individuais que usam o sistema. Uma sequência de estágios é representada graficamente pela guia Visualizar dentro de uma definição de desk.

Um procedimento de evento é executado assim que um ticket passa de um estágio para o seguinte. Um procedimento agendado, como um procedimento de passagem para outro nível, é acionado para execução com base no tempo em que um ticket permanece em um estágio. Por exemplo, procedimentos de passagem para outro nível são normalmente executados quando um ticket permaneceu por muito tempo em um estágio, em vez de ser resolvido e transferido para outro estágio.

Quando uma definição de desk é criada, sequências de estágios são preenchidas pelo modelo usado para criar essa definição. Depois que uma definição de desk é criada com base em um modelo, esses estágios padrão podem ser modificados para se adequarem às suas necessidades comerciais.

Exemplo - Os estágios de Customer_SD_Automation

A descrição de cada estágio a seguir supõe que os usuários do VSA discutidos não sejam administradores do Service Desk e, portanto, tenham suas exibições de tickets limitadas por suas funções de usuário e escopos.

Nota: Consulte o tópico Modelos de service desk para obter instruções sobre como criar esse e outros service desks predefinidos automaticamente.

Novo ticket: um ticket recém-criado em Customer_SD_Automation é iniciado no estágio New Ticket.

• Um procedimento de entrada no estágio CS Incident enters New Ticket atribui o ticket a um conjunto Tier1Support de técnicos de tickets de serviços. Os usuários do VSA visualizam todos os tickets que lhes foram atribuídos, além de tickets atribuídos aos conjuntos aos quais eles pertencem.
• Uma mensagem do VSA e uma mensagem de e-mail são criadas para esses mesmos usuários. O remetente do ticket também recebe um e-mail de confirmação informando que um ticket foi criado.
• Um procedimento para passar para outro nível está vinculado a esse estágio. Se o ticket não tiver saído do estágio CS Incident enters New Ticket no prazo de 1 hora, o procedimento de passagem para outro nível será executado. O procedimento de passagem para outro nível notifica o responsável pelo ticket e o conjunto de usuários Tier1Support. A intenção do procedimento para passar para outro nível é garantir que todos os tickets recém-criados sejam revisados imediatamente.

Dois outros fatores podem automatizar o comportamento dos tickets em qualquer estágio:

• Atribuição automática de ticket de um conjunto: a primeira vez em que o ticket é aberto por um membro do Tier1Pool, esse membro receberá a atribuição do ticket. Outros membros do Tier1Pool deixam de ver o ticket em suas exibições de tickets.
• O ticket foi alterado: isso não é um estágio, e sim um procedimento de Alteração de ticket. O mesmo procedimento CS Incident is Changed é executado sempre que o ticket é salvo, mesmo que uma pequena alteração no ticket não inclua mudança de estágio. Este procedimento de alteração de ticket testa o seguinte:
  • Se for verdadeiro, o ticket será imediatamente movido para o estágio Tier1.
  • Se o ticket tiver um responsável, este também se tornará o "proprietário" do ticket. Um proprietário de ticket normalmente continua a ser responsável pelo ticket, mesmo que esse ticket seja atribuído a uma série de responsáveis diferentes durante seu ciclo de vida. As visualizações de tickets podem ser filtradas por proprietário, permitindo que os proprietários gerenciem tickets que possam ter sido esquecidos por seus cessionários atuais.
  • Se o ticket tiver sido resolvido, ele será fechado.
  • Se um ticket já tiver sido fechado, mas um cliente enviar um e-mail com referência a ele, o ticket será reaberto.

Nível1: o responsável pelo ticket recebe agora a tarefa de trabalhar com o ticket no estágio Tier1.

• O responsável recebe uma mensagem de e-mail.
• Um procedimento de passagem para outro nível também está vinculado a esse estágio.
• Um ticket pode ser atribuído manualmente ao estágio Tier2 ou Solved, conforme indicado pelas duas setas vermelhas que saem da bolha Tier1 no gráfico acima.

Nível 2: mover um ticket para o estágio Tier2 normalmente significa que esse ticket requer uma pessoa com mais experiência para resolvê-lo, talvez fornecendo uma área especial de especialidade.

• Um procedimento de entrada no estágio CS Incident Enters Tier2 atribui o ticket automaticamente a um Tier2Pool de usuários, de modo que o pessoal de Tier1 não precise adivinhar para quem atribui-lo.
• Uma mensagem do VSA e uma mensagem de e-mail são criadas para esses mesmos usuários. O remetente do ticket também recebe um e-mail de confirmação informando que o ticket foi atribuído ao Tier2Pool para uma investigação mais detalhada.
• Um procedimento de passagem para outro nível também está vinculado a esse estágio.

Resolvido: tickets resolvidos são enviados a esse estágio para aguardarem a confirmação do remetente depois que este recebe uma notificação.

• O estágio CS Incident Enters Solved envia ao remetente uma notificação por e-mail informando que o ticket foi resolvido.
• Tickets resolvidos ou são reabertos quando o cliente retorna uma resposta por e-mail ou quando deixa de estabelecer contato. No final das contas, o ticket é fechado manualmente.

Fechado: tickets resolvidos são definidos para o estágio Closed.

• O procedimento de entrada no estágio CS Incident Enters Closed notifica o remetente do ticket de que o ticket está fechado.