SLA de atendimento: como definir metas que a operação consegue cumprir

SLA de atendimento é o prazo acordado para responder e resolver um chamado, definido por prioridade e por impacto no negócio. Um SLA que a equipe não consegue cumprir é pior do que não ter SLA: cria relatório bonito, expectativa quebrada e discussão mensal sobre número em vez de sobre serviço.

Quase toda área de TI já passou por isso. Alguém define que «todo chamado deve ser resolvido em 4 horas», a meta vai para a apresentação da diretoria e, três meses depois, o indicador está em 60% e ninguém confia nele. O problema raramente é a equipe. Quase sempre é a forma como o SLA foi desenhado.

Neste artigo mostramos como definir prioridade a partir do impacto, trazemos uma matriz de SLA pronta para adaptar, explicamos os três erros mais comuns e como medir o cumprimento sem transformar o indicador em ferramenta de punição.

Antes de começar, uma distinção que muda tudo: tempo de resposta e tempo de solução são metas diferentes. O tempo de resposta mede quanto demora o primeiro contato humano com o usuário, e não a confirmação automática do sistema. O tempo de solução mede quanto demora até o chamado ser encerrado com o serviço restabelecido. Um chamado pode ter resposta em 10 minutos e levar dois dias para ser resolvido, e as duas coisas precisam ser acompanhadas separadamente.

Prioridade não é urgência: a matriz de impacto

O erro mais frequente na hora de priorizar é deixar o usuário escolher. Quando o formulário tem um campo «prioridade», quase todo mundo marca «alta», porque para quem abre o chamado o problema sempre é urgente. Resultado: a fila fica cheia de prioridades altas e a prioridade deixa de significar alguma coisa.

A alternativa é calcular a prioridade cruzando dois critérios objetivos:

• Impacto: quantas pessoas, processos ou clientes param. Um notebook com defeito afeta uma pessoa; o ERP fora do ar afeta a empresa inteira.
• Urgência: quanto tempo até o problema virar crítico. Uma impressora parada no fechamento da folha é mais urgente do que a mesma impressora parada numa sexta à tarde sem demanda.

O usuário pode informar a urgência, porque ele conhece o próprio prazo. O impacto quem define é o service desk, com critérios publicados. A prioridade sai da combinação dos dois:

A vantagem dessa matriz é que ela tira a discussão do campo da opinião. Se o chamado foi classificado como P3, qualquer pessoa consegue ver por quê: impacto médio, urgência média. Se alguém discorda, discute o critério, não o humor do técnico.

Vale definir por escrito o que é «processo crítico» na sua empresa. Para uma indústria pode ser a linha de produção; para um varejista, o PDV; para um escritório contábil, o sistema fiscal no fim do mês. Sem essa lista, o impacto volta a ser subjetivo.

Matriz de SLA pronta para adaptar

Com a prioridade definida, o próximo passo é associar a cada nível um prazo de resposta e um prazo de solução. A tabela abaixo é um ponto de partida usado por muitas equipes de TI de porte médio. Os prazos são sugestões: ajuste à capacidade real da sua operação antes de publicá-los.

Como montar a sua versão:

1. Levante o histórico. Pegue os chamados dos últimos três a seis meses e veja quanto tempo cada faixa de prioridade levou de fato. Esse é o seu ponto de partida real.
2. Defina a meta um pouco acima do histórico. Se hoje 80% dos P3 são resolvidos em três dias, comece com três dias e aperte depois. Meta que nasce inalcançável não melhora a operação, só desmoraliza o indicador.
3. Separe solicitações de incidentes. Pedidos de acesso, instalação ou equipamento novo têm prazos próprios, normalmente definidos no catálogo de serviços, e não devem disputar a mesma matriz.
4. Defina o calendário. Deixe claro se o relógio conta 24×7 ou só em horário comercial, e quais feriados entram.
5. Publique e combine. O SLA é um acordo. Apresente a matriz às áreas de negócio, ouça as exceções e registre o que foi combinado.
6. Revise a cada trimestre. Volume, equipe e sistemas mudam. A matriz precisa acompanhar.

Os três erros que fazem o SLA virar ficção

1. O prazo nasce do desejo, não da capacidade. A diretoria quer «tudo em 4 horas», mas a equipe tem três técnicos para 600 chamados por mês. A conta não fecha, e todo mundo sabe disso desde o primeiro dia. Um SLA sério começa pelos dados de volume e capacidade e, se a meta desejada for diferente, a conversa passa a ser sobre recursos, não sobre esforço.

2. O relógio não pausa. Um chamado que depende de resposta do usuário, de peça do fornecedor ou de visita técnica de terceiros não está nas mãos da equipe. Se o relógio continua correndo, o indicador mede a paciência do fornecedor, não o desempenho da TI. A regra precisa ser explícita: estados como «aguardando usuário» e «aguardando fornecedor» pausam o SLA, e o SLA só vale para terceiros quando o contrato do fornecedor tem prazo compatível.

3. A prioridade é escolhida por quem abre o chamado. Como vimos, se o usuário decide a prioridade, tudo vira P1. A equipe passa a ignorar a classificação, os chamados realmente críticos se perdem na fila e o SLA de P1 vira o mais violado do relatório.

Há um quarto erro, mais silencioso: medir o SLA e não fazer nada com o resultado. Um relatório que ninguém lê não melhora o serviço.

Como medir sem virar caça às bruxas

O SLA é um instrumento de gestão do serviço, não de avaliação individual. Quando vira ranking de técnicos, a equipe aprende rapidamente a proteger o número: encerra chamados antes da hora, reclassifica prioridades para baixo, divide um problema em vários tickets. O indicador melhora e o serviço piora.

Algumas práticas ajudam a manter o foco certo:

• Meça por fila e por tipo de serviço, não por pessoa. A pergunta é «onde o processo trava?», não «quem errou?».
• Olhe a tendência, não o mês isolado. Um mês ruim pode ter explicação pontual. Três meses caindo indicam um problema de capacidade ou de processo.
• Analise cada violação pela causa. Falta de pessoal, dependência de fornecedor, falta de conhecimento, classificação errada. Cada causa pede uma ação diferente.
• Acompanhe a reabertura. Um SLA de solução alto com muitos chamados reabertos significa que o problema está sendo fechado, não resolvido.
• Publique os critérios. Quando todos sabem como a prioridade é definida e quando o relógio pausa, o número deixa de ser motivo de desconfiança.

O SLA também não deve ser o único número do relatório. Sozinho, ele mostra se os prazos foram cumpridos, mas não explica por quê. Três indicadores complementares ajudam a ler o resultado com mais contexto:

• Volume por categoria e por canal. Se os chamados de acesso dobraram depois de uma migração de sistema, a queda no SLA tem causa conhecida e temporária.
• Resolução no primeiro contato. Quanto mais chamados são resolvidos sem escalonamento, menos a fila depende dos especialistas, e mais folga sobra para os casos P1 e P2.
• Satisfação do usuário. Uma pesquisa curta no encerramento mostra se o prazo cumprido também foi percebido como bom atendimento. SLA verde com satisfação baixa costuma indicar chamados fechados sem conversa.

Por fim, combine com a equipe um ritual simples: uma reunião mensal de 30 minutos para olhar as violações do período, agrupar por causa e decidir uma ou duas ações concretas. Pode ser um artigo novo na base de conhecimento, uma conversa com um fornecedor, um ajuste na matriz ou um pedido de reforço para a diretoria. É esse ciclo, e não o percentual em si, que transforma o SLA em melhoria contínua.

E qual é um bom percentual de cumprimento? Mais importante que o número é ele ser estável e auditável. Um indicador de 90% que se sustenta mês a mês e pode ser verificado chamado por chamado vale mais do que 99% que ninguém consegue explicar. Para quem segue boas práticas, a gestão de níveis de serviço está descrita no ITIL 4, e a ISO/IEC 20000-1 exige que os acordos sejam documentados, monitorados e revisados.

Nada disso funciona em planilha por muito tempo. Para o SLA ser confiável, a ferramenta precisa calcular prazos por prioridade e por calendário, pausar o relógio nos estados certos, avisar antes do vencimento e gerar relatórios que qualquer pessoa consegue auditar. O OTRS faz isso de forma nativa, com escalonamentos e calendários por fila, e a Aufiero apoia equipes de TI no Brasil na licença e na implantação. Conheça o SLA que dá para ver.

Perguntas frequentes