Se você estiver tendo problemas de Service Level Agreement (SLA) (Contrato de nível de serviço), use este guia para encontrar soluções para os comportamentos mais comuns.

Este artigo contém os tópicos abaixo:

  • A medalha mostra Agora após a meta ser violada
  • As metas violadas não levam em consideração o horário de operação
  • A nova política não é exibida
  • SLA aplicado apenas a alguns tickets
  • A métrica do tempo da primeira resposta não está funcionando
  • SLA não pausado quando o status do ticket é pendente
  • Horas alvo exibidas incorretamente
  • O SLA recém-aplicado executa evento de violação adicional
  • Por que não vejo um selo de SLA quando há uma política de SLA no ticket?
  • As atualizações nas programações não são refletidas nas metas de SLA

Para obter informações gerais sobre como os SLAs funcionam, consulte Visualizar e entender metas de SLA.

A medalha mostra Agora após a meta ser violada

A medalha exibirá Agora quando a meta for alterada após uma violação. Essas alterações incluem comentários públicos, alterações de status, alterações de prioridade ou alterações de política.

As metas violadas não levam em consideração o horário de operação

Mesmo que a meta tenha sido configurada para o horário de operação, a medalha sempre mostrará o tempo em horas corridas. Não importa se a meta está em horário de operação ou horas corridas.

A nova política não é exibida

O Zendesk não aplica uma política de SLA recém criada a tickets existentes, ou o Zendesk não aplica uma política de SLA atualizada a tickets que já usam esse SLA.

Explicação

Os SLAs são baseados em eventos do ticket. Para que uma política de SLA corresponda aos tickets, um evento como a criação ou atualização de tickets deve ocorrer no ticket. Caso contrário, o ticket não mostrará informações de SLA ou continuará exibindo as informações de SLA antigas.

No exemplo abaixo, uma política de SLA não foi aplicada porque não havia uma política a ser aplicada na última atualização do ticket, ou o ticket não atendeu às condições da política.

SLA não aplicado porque a atualização foi realizada após a criação do ticket

No exemplo abaixo, uma política de SLA é aplicada após uma atualização de ticket, depois que você cria uma política ou atualiza o ticket para atender às condições de uma política existente:

SLA aplicado após a atualização do ticket

SLA aplicado apenas a alguns tickets

Um SLA não se aplica a tickets que atendem a todas as condições da política de SLA.

Explicação

Isso acontece quando os tickets não têm uma prioridade definida. Os tickets devem ter uma prioridade para que a meta de SLA seja aplicada. A prioridade do ticket precisa ser o campo padrão do sistema. Os SLAs não se aplicam usando campos de ticket personalizados.

Dependendo da prioridade do ticket, as políticas de SLA podem ter metas de tempo e horários de operação diferentes:

SLA.png

Se o ticket não tiver uma prioridade que corresponda à meta de tempo definida na política de SLA, a meta de tempo não será aplicada e nenhum cronômetro será exibido até que uma prioridade seja adicionada.

Isso também pode acontecer se você criar o ticket com um comentário privado ou observação interna de um usuário que não é um agente light. Para tickets privados, as metas de SLA do tempo da primeira resposta são adiadas. A meta de SLA é ativada quando o primeiro comentário público do usuário final for adicionado, mesmo que já tenha havido comentários públicos de agentes antes desse momento.

No exemplo abaixo, o Zendesk não aplicou uma política de SLA porque o ticket foi criado sem uma prioridade.

Ticket sem prioridade não está ativando a política de SLA

Depois que você atualiza o mesmo ticket para ter uma prioridade, o Zendesk aplica a política de SLA.

Política aplicada após a atualização do ticket

A métrica do tempo da primeira resposta não está funcionando

Um ticket recém-criado não mostra um cronômetro para a métrica Tempo da primeira resposta, mesmo se todos os critérios da política de SLA forem atendidos.

Explicação

Isso acontece quando um agente cria um ticket em nome de um usuário final e o primeiro comentário é público. A meta da primeira resposta é cumprida na criação do ticket porque o agente envia o primeiro comentário público, que é considerado a primeira resposta.

No exemplo abaixo, nenhuma métrica Tempo da primeira resposta se aplica porque o agente criou o ticket.

Ticket criado em nome do cliente

Você pode criar exceções em configurações avançadas.

SLA não pausado quando o status do ticket é pendente

O cronômetro de SLA não pausa quando o status do ticket é alterado para Pendente.

Pendente, sem pausa do cronômetro

Explicação

Isso acontece porque o ticket está aguardando os agentes cumprirem a métrica do Tempo da primeira resposta ou da próxima resposta. No momento, há quatro metas de SLA que não pausam no status pendente: Tempo da primeira resposta, Tempo da próxima resposta, Tempo da atualização periódica e Tempo total de resolução. As métricas de resposta não mudam com base no status do ticket. As métricas de resposta são atendidas se um agente responder com um comentário público ao solicitante.

O tempo da primeira resposta e o tempo da próxima resposta sempre usam um comentário do usuário final como ponto de partida, e uma resposta pública do agente como ponto de extremidade. Para obter mais informações, consulte Definição e uso de políticas de SLA.

Horas alvo exibidas incorretamente

Os tickets com SLAs que têm uma meta no horário de operação mostram um número maior de horas do que as métricas de SLA devem ter definido.

Alvo de tempo de trabalho do agente com horas corridas

Explicação

Os selos SLA são sempre exibidos em horas corridas. O tempo real restante é exibido para que os agentes possam priorizar o trabalho. Embora você possa optar por calcular a meta de tempo em horário de operação, o cronômetro ainda exibirá o tempo em horas corridas e não levará em consideração dias não úteis ou feriados definidos na sua conta.

SLAs diferentes

Para obter uma explicação detalhada, consulte Por que vejo diferenças nas metas de horas de SLA?

O SLA recém-aplicado executa evento de violação adicional

Quando o Zendesk aplica uma nova política a um ticket que já teve o SLA violado, o sistema registra outro evento de violação no momento da atualização mesmo que a nova política seja apenas uma versão modificada de uma política existente.

Explicação

O sistema não pode modificar o histórico de eventos passados do ticket. Quando uma nova aplicação de SLA acontece, o contador de SLA sempre considera o futuro a partir desse ponto.

Por que não vejo um selo de SLA quando há uma política de SLA no ticket?

Há vários motivos pelos quais um selo de SLA não é exibido em um ticket com uma política de SLA aplicada. Para obter mais informações, consulte Por que os selos de SLA não são exibidos?

As atualizações nas programações não são refletidas nas metas de SLA

Explicação

Quando uma programação é editada, incluindo a adição ou remoção de feriados, as metas de SLA não são atualizadas automaticamente. No entanto, se um ticket receber uma atualização de SLA, as metas serão reavaliadas. Se houver um comentário público ou alterações de status, de prioridade ou de política, o ticket recalculará seu quadro de SLA de acordo com a nova programação. Minimize as alterações na programação, pois as alterações frequentes geram confusão.

Observação: Os SLAs não se aplicam a tickets resolvidos na criação. O status resolvido atende aos SLAs e evita que políticas sejam ativadas, desde que o ticket continue no status resolvido. Se os tickets forem reabertos, os SLAs podem começar a ser ativados e a funcionar normalmente.

Aviso sobre a tradução: este artigo foi traduzido por um software de tradução automática para oferecer a você uma compreensão básica do conteúdo. Medidas razoáveis foram tomadas para fornecer uma tradução precisa, no entanto, a Zendesk não garante a precisão da tradução.

Em caso de dúvidas relacionadas à precisão das informações contidas no artigo traduzido, consulte a versão oficial do artigo em inglês.

Powered by Zendesk