SLA

Como configurar SLA no Contact Desk

Passo a passo para configurar SLA por fila, categoria, prioridade e acompanhar tickets em risco de atraso.

Exemplo visual do Contact Desk para SLA

Resposta rápida

Para configurar SLA no Contact Desk, crie uma política com nome, prazo, fila, categoria, prioridade e regras de contagem. Depois teste com tickets reais ou de demonstração para validar se o prazo calculado corresponde ao processo da equipe.

Passo a passo

  1. Acesse Políticas de SLA.
  2. Clique em Nova política.
  3. Informe nome e descrição operacional.
  4. Defina filas, categorias, prioridades e condições aplicáveis.
  5. Configure prazo e regra de contagem.
  6. Salve e crie um ticket de teste.
  7. Verifique se o SLA aparece corretamente na lista e no ticket.

O que definir antes de criar a política

Antes de configurar o sistema, defina o acordo operacional. O prazo deve refletir o que a equipe consegue cumprir. Separar SLA por fila, categoria e prioridade evita que uma demanda simples tenha o mesmo prazo de uma demanda crítica.

  • Quais filas terão SLA.
  • Quais categorias precisam de prazo específico.
  • Quais prioridades mudam o tempo de resposta.
  • Se o prazo considera horário útil.
  • Quem acompanha tickets em risco.

SLA por fila, categoria e prioridade

A combinação de fila, categoria e prioridade permite criar regras mais justas. Por exemplo, uma solicitação urgente de TI pode ter prazo menor que uma dúvida administrativa normal. O objetivo não é criar muitas regras, mas criar regras suficientes para refletir o processo real.

  • Fila define área responsável.
  • Categoria define tipo de demanda.
  • Prioridade define urgência.
  • Impacto pode refinar criticidade.
  • Status define se o prazo continua contando.

Como acompanhar risco de atraso

Depois de aplicar SLA, use lista de tickets, dashboard e relatórios para acompanhar vencimentos. Tickets em risco precisam aparecer antes de vencer, para que a equipe consiga agir. Automação pode notificar responsável, mover para uma fila de escalonamento ou adicionar comentário interno.

  • Filtrar tickets com SLA próximo do vencimento.
  • Acompanhar painel de SLA no dashboard.
  • Criar automação de escalonamento.
  • Revisar filas com maior atraso.
  • Analisar causas recorrentes.

Erros comuns na configuração

O erro mais comum é criar um SLA genérico demais. Outro problema é definir prazos muito agressivos sem considerar volume e capacidade. Também é importante revisar políticas após mudanças em filas, categorias ou horários de atendimento.

  • Aplicar o mesmo prazo para tudo.
  • Não considerar horário de atendimento.
  • Criar regras duplicadas.
  • Esquecer tickets de e-mail.
  • Não revisar após mudança de processo.

Como validar se o SLA está correto

Crie tickets de teste com combinações diferentes de fila, categoria e prioridade. Compare o prazo calculado com a regra esperada. Depois verifique se o SLA aparece na lista, no ticket e nos relatórios. Uma validação curta evita cobranças incorretas em produção.

  • Testar ticket normal.
  • Testar ticket urgente.
  • Testar categoria sem SLA específico.
  • Testar mudança de fila.
  • Testar conclusão e reabertura.

Boas práticas

  • Revise permissões antes de liberar recursos para novos usuários.
  • Teste mudanças em um fluxo controlado antes de aplicar em toda a operação.
  • Use nomes claros para filas, categorias, automações e respostas prontas.
  • Consulte logs e auditoria quando uma ação precisar de rastreabilidade.

Perguntas frequentes

Todo ticket precisa ter SLA?

Não obrigatoriamente, mas tickets sem SLA não entram no mesmo controle de prazo. Em operações maduras, o ideal é ter pelo menos uma política geral por fila crítica.

Posso alterar SLA de tickets já criados?

Depende da regra e do fluxo. Em geral, mudanças futuras devem ser testadas para não gerar interpretações erradas em tickets antigos.

SLA deve considerar prioridade?

Na maioria dos casos, sim. Prioridade ajuda a diferenciar prazos entre demandas normais, altas e urgentes.

Quando acionar o administrador?

Acione um administrador quando a configuração envolver credenciais, permissões, integrações, filas compartilhadas, políticas de SLA, automações globais ou dados sensíveis.