Configuração de módulos
SLA
Compromissos de tempo em tickets e tarefas — meça, monitorize e escale quando os lead times ameaçam não ser cumpridos.
Atualizado em 23/01/2026
Configuração · Módulos · 4.4
Um SLA (Service Level Agreement) é um compromisso de tempo num ticket ou tarefa. O módulo de SLA capta o que promete, em que casos se aplica e acompanha se o cumpre — com um cronómetro que só corre em horário laboral.
Porque é relevante para o negócio
"Promessas que não se medem"
Time-to-first-response e time-to-resolution explícitos — reportáveis por mês.
"Esperar pelo cliente conta"
Condições pausam o cronómetro em determinados estados — medição justa.
"O relógio continua fora de horas"
Calendário associado ao SLA → o cronómetro só corre em horário laboral.
"Escalonamento tardio"
Sequência de notificações pela percentagem do SLA → lembrete, gestor, comité diretor automaticamente.
Quatro aspetos de cada SLA
| Aspeto | O que define |
|---|---|
| Classe | Time to first response ou time to resolution. Duas estratégias de medição diferentes. |
| Critérios | Quando o SLA se aplica: organização, classificação, prioridade, tipo (ticket/tarefa), template, tipo. |
| Tempo-alvo | Lead time máximo permitido em horas/minutos + o calendário que define o horário laboral. |
| Condições | Quando o cronómetro arranca, pausa ou para (p. ex. estado "À espera do cliente" pausa). |
A combinação classe + critérios é única — criar duas vezes a mesma configuração gera erro.
Duas classes de SLA
Time to first response
Em quanto tempo alguém responde ao ticket? Para assim que a primeira resposta é dada.
Time to resolution
Em quanto tempo é resolvido? Para no estado de conclusão.
Comportamento perante mudanças
Quando algo muda num ticket (organização, prioridade, classificação), o Gfacility reavalia se um SLA aplica. Um novo SLA fica ativo, ou um existente é ocultado se nenhum critério continua a aplicar-se.
Quando a configuração do SLA em si muda, os SLAs já ativos mantêm-se intactos — o antigo continua a contar até o ticket fechar. Só quando algo muda no ticket é que o Gfacility reavalia.
Que decisões irá tomar?
Que faixas de prioridade?
Crítica · alta · normal · baixa — cada uma com o seu alvo. Faixas a mais = complexidade desnecessária.
Horário laboral ou 24/7?
Que calendário associa? Um por equipa de serviço costuma bastar.
Que estados pausam?
"À espera do cliente", "Em pausa" — caso contrário, esperas externas continuam a contar e falha injustamente.
SLA no ticket ou na tarefa?
Ambos é possível, mas escolha por caso de uso — caso contrário reporta a dobrar.