Um SLA de apoio ao cliente é o compromisso escrito sobre o tempo máximo que a equipa demora a responder e a resolver cada pedido de um cliente, conforme a prioridade. Mede-se ticket a ticket, com duas contagens, o tempo até à primeira resposta e o tempo até à resolução, normalmente em horas úteis. O número que resume tudo é a percentagem de pedidos tratados dentro do prazo.
Em equipas de assistência técnica, de software e TI, de engenharia ou em agências, a pergunta que o cliente mais repete é «quando é que isto fica resolvido?». Sem um SLA, a resposta depende de quem abriu o email e da semana que essa pessoa está a ter. Com um SLA medido, a equipa sabe o que prometeu e o cliente sabe o que pode esperar.
O que é um SLA de apoio ao cliente?
SLA é a sigla de Service Level Agreement, em português acordo de nível de serviço. No apoio ao cliente, é a regra que diz em quanto tempo cada pedido recebe resposta e em quanto tempo fica resolvido. O SLA pode estar no contrato com o cliente, com consequências quando falha, ou ser um compromisso interno da equipa. Em qualquer dos casos, só serve se estiver escrito e se for medido.
Um ticket com SLA é um pedido registado com a hora de entrada, uma prioridade e os prazos que resultam dessas duas coisas. Um SLA completo responde a cinco perguntas.
- A quem se aplica. Que clientes, que contratos e que tipos de pedido estão cobertos.
- Quando conta o relógio. O horário de serviço, os dias úteis e os feriados.
- Que prioridades existem. Três ou quatro níveis, com critérios que não dependam de quem faz a triagem.
- Que prazos se cumprem. Um prazo de primeira resposta e outro de resolução para cada prioridade.
- O que acontece quando o prazo aperta. Quem é avisado e para quem sobe o pedido.
Que tempos se medem num ticket?
Medir um SLA não exige dezenas de indicadores. Numa equipa pequena, cinco números chegam para saber se o compromisso está a ser cumprido.
| Métrica | O que mede | Como se calcula |
|---|---|---|
| Tempo de primeira resposta | Quanto tempo o cliente espera até uma pessoa lhe responder | Da entrada do pedido à primeira resposta escrita por alguém da equipa |
| Tempo de resolução | Quanto tempo o problema fica por resolver | Da entrada do pedido ao momento em que fica resolvido, sem contar as pausas acordadas |
| Cumprimento do SLA | Se a equipa cumpre o que prometeu | Pedidos dentro do prazo a dividir pelo total de pedidos do período, por prioridade |
| Pedidos em aberto | Se o trabalho se está a acumular | Tickets por fechar e há quanto tempo espera cada um |
| Satisfação (CSAT) | Como o cliente avaliou o atendimento | Percentagem de respostas positivas num inquérito curto enviado quando o ticket fecha |
As reaberturas, os pedidos que o cliente volta a abrir depois de fechados, também merecem ser contadas. Um SLA cumprido com muitas reaberturas costuma querer dizer que os pedidos se fecham depressa demais.
Como definir prazos realistas por prioridade?
O erro mais comum é copiar os prazos de um centro de apoio com equipas por turnos para uma equipa que também tem projetos para entregar. Os prazos certos saem do ponto de partida da própria equipa.
- Medir durante quatro semanas, sem metas. Registar todos os pedidos como tickets e ver quanto tempo demoram hoje a primeira resposta e a resolução.
- Definir as prioridades pelo impacto no cliente. Por exemplo, crítica quando o serviço do cliente está parado, alta quando funciona com limitações, normal para dúvidas e pequenas alterações, baixa para sugestões.
- Fixar os prazos de cada prioridade. Um pouco melhores do que a realidade medida, para serem exigentes sem serem impossíveis.
- Escrever o horário de serviço. Por exemplo, dias úteis das 9h às 18h, sem feriados. Um pedido que entra às 17h30 de sexta-feira, com quatro horas úteis de prazo, vence na segunda-feira às 12h30.
- Decidir quando o relógio para. O mais comum é parar enquanto o pedido espera por informação do cliente.
- Combinar o aviso e o escalamento. Quem recebe o aviso quando falta pouco para o prazo e quem decide quando o prazo já passou.
A tabela seguinte é só um exemplo, numa equipa de assistência técnica. Os valores de cada empresa dependem dos contratos e da equipa disponível.
| Prioridade | Exemplo de pedido | Primeira resposta | Resolução |
|---|---|---|---|
| Crítica | Serviço do cliente parado | 1 hora útil | 8 horas úteis |
| Alta | Funciona, mas com uma falha que afeta a equipa do cliente | 4 horas úteis | 2 dias úteis |
| Normal | Dúvida ou pequena alteração | 1 dia útil | 5 dias úteis |
| Baixa | Sugestão ou melhoria | 2 dias úteis | A planear com o cliente |
Que erros tornam um SLA inútil?
- Contar a resposta automática como primeira resposta. A confirmação de receção diz ao cliente que o pedido entrou, mas não o trata.
- Fechar tickets para cumprir o prazo. Um pedido fechado sem estar resolvido volta a abrir dias depois.
- Usar o mesmo prazo para tudo. Uma sugestão e um serviço parado não podem correr no mesmo relógio.
- Contar horas seguidas quando a equipa só trabalha em dias úteis. O SLA falha em todos os fins de semana sem ninguém ter feito nada de errado.
- Olhar só para a média. Um pedido esquecido durante semanas puxa a média para cima, e a mediana mostra melhor como correm os outros.
- Medir à mão. Quando os tempos saem de uma folha de cálculo preenchida no fim do mês, já ninguém sabe a que horas cada pedido entrou.
Um exemplo prático numa empresa de assistência técnica
Imagine uma empresa de assistência técnica com seis técnicos e cerca de 40 clientes com contrato de manutenção, que recebe perto de 120 pedidos por mês numa caixa de email partilhada. Todos os pedidos parecem urgentes, e o contrato fala em «resposta rápida» sem dizer quanto tempo isso é.
Durante quatro semanas, a empresa regista cada pedido como ticket, ainda sem metas. Neste exemplo, os números mostram três coisas. A mediana da primeira resposta é de três horas úteis, o que parece bom. Mas um em cada cinco pedidos críticos esperou mais de um dia, porque chegou à caixa de um técnico em deslocação. E quase metade dos tickets em aberto está, na verdade, à espera de uma resposta do cliente.
Com estes dados, a empresa define quatro prioridades, fixa prazos como os da tabela anterior e passa a parar o relógio quando o pedido espera pelo cliente. A triagem fica com uma pessoa por semana, à vez, e os pedidos críticos passam a avisar o responsável antes de o prazo vencer. No fim de cada mês, a reunião de equipa olha para três números, o cumprimento por prioridade, a idade dos pedidos em aberto e as reaberturas.
O que muda neste exemplo não é a quantidade de trabalho. Os pedidos críticos deixam de depender de quem os recebe, e o contrato passa a dizer em horas o que antes dizia em adjetivos.
Como o Engi360 trata os pedidos com SLA
O Engi360 é a plataforma de gestão operacional da Engibots para equipas que faturam horas ou gerem projetos para clientes. Os tickets de cliente fazem parte dos módulos base, ao lado das horas, das férias e ausências e dos projetos e tarefas.
- Tickets com SLA. Cada pedido é um ticket com prazo, que o cliente acompanha e responde numa página protegida, sem criar conta.
- Do pedido ao trabalho. Os pedidos que dão origem a trabalho transformam-se em tarefas com prazo, e as horas registam-se por tarefa na mesma plataforma.
- Satisfação no fecho. Uma regra de CSAT automático envia ao cliente um inquérito de satisfação quando o ticket fecha.
- Regras e painéis. Automação baseada em regras, do tipo quando X, se Y, então Z, painéis configuráveis e um assistente de IA que analisa a operação.
O plano gratuito inclui os tickets de cliente, com até 10 tickets em aberto, a equipa toda nos primeiros 14 dias e depois até 3 utilizadores, sem cartão de crédito. As automações e o CSAT estão incluídos a partir do plano Professional. Para quem ainda recebe os pedidos por email, o artigo sobre quando passar para um sistema de tickets explica como fazer a mudança.
Perguntas frequentes
O que significa SLA no apoio ao cliente?
SLA é a sigla de Service Level Agreement, ou acordo de nível de serviço. No apoio ao cliente, define o tempo máximo para responder e para resolver cada pedido, conforme a prioridade.
Qual é a diferença entre tempo de primeira resposta e tempo de resolução?
O tempo de primeira resposta vai da entrada do pedido até à primeira resposta de uma pessoa da equipa. O tempo de resolução vai da entrada até o pedido ficar resolvido. Um SLA costuma ter um prazo para cada um.
A resposta automática conta como primeira resposta?
Não deve contar. A confirmação automática diz ao cliente que o pedido entrou, mas ninguém o tratou ainda. A primeira resposta é a de uma pessoa que já olhou para o pedido.
O prazo do SLA conta à noite e ao fim de semana?
Só se o SLA o disser. É comum os prazos contarem apenas em horas úteis, dentro do horário de serviço e sem feriados, e o relógio parar enquanto o pedido espera por uma resposta do cliente.
Como se calcula a percentagem de cumprimento do SLA?
É o número de pedidos tratados dentro do prazo a dividir pelo total de pedidos do período, vezes 100. O ideal é calculá-la por prioridade, porque uma percentagem geral esconde os pedidos críticos atrasados.
O plano gratuito do Engi360 inclui tickets de cliente?
Sim. Os tickets de cliente fazem parte dos módulos base do plano gratuito, com até 10 tickets em aberto, a equipa toda nos primeiros 14 dias e depois até 3 utilizadores. O CSAT automático e as automações estão incluídos a partir do plano Professional.