Como criar um SLA para seu MSP sem prometer o que não consegue cumprir

O cliente diz: "é urgente".

O técnico pensa: "urgente para quem?".

O relógio corre… e ninguém combinou o que significa responder.

É esse problema que um SLA útil pode evitar.

Um acordo de nível de serviço não existe para prometer que tudo será resolvido em minutos. Ele define o que você atende, quando o relógio começa, quem responde, como o trabalho é escalonado e qual evidência o cliente recebe.

Este guia oferece uma base operacional para um MSP pequeno. Ele não substitui revisão jurídica nem as condições comerciais do contrato; use-o para organizar o serviço antes de transformá-lo em compromisso legal.

1) Defina o que o SLA controla

Um SLA não é uma frase como "suporte rápido".

Isso não pode ser medido.

O glossário do NIST descreve o SLA como um compromisso entre provedor e cliente que pode tratar de responsabilidades, tipo de serviço, desempenho esperado, tempos de resposta, relatórios, resolução e encerramento.

Para um MSP, isso vira seis perguntas:

• quais serviços e endpoints estão cobertos?;
• em qual horário o compromisso funciona?;
• qual canal cria uma solicitação válida?;
• como a prioridade é definida?;
• quando o cliente deve receber resposta e atualizações?;
• o que fica fora ou é cotado separadamente?

Se uma dessas respostas existe apenas na sua cabeça, você ainda não tem um SLA. Tem uma expectativa perigosa.

2) Separe resposta, atualização e resolução

Três relógios. Três coisas diferentes.

Tempo de primeira resposta: quando uma pessoa confirma o recebimento, define um responsável e comunica o próximo passo.

Frequência de atualização: a cada quanto tempo você informa o cliente enquanto o incidente continua aberto.

Meta de restauração ou resolução: quando você espera restaurar o serviço ou fechar a causa, conforme o escopo e as dependências externas.

A prática oficial de ITIL Service Level Management, da PeopleCert, explica que as metas devem ser baseadas no negócio e que os níveis acordados precisam ser monitorados, reportados e melhorados.

Por isso, não convém prometer "resolução em 30 minutos" quando você pode depender do provedor de internet, de uma peça, da Microsoft, de um fabricante ou da aprovação do cliente.

3) Defina prioridade com impacto e urgência

Tudo é urgente quando não existe uma matriz.

Uma prioridade útil combina:

• impacto: quantas pessoas, unidades ou processos foram afetados;
• urgência: quanto tempo a operação pode esperar antes de sofrer uma consequência séria.

Comece com esta tabela e ajuste à sua capacidade real:

Não copie esses prazos se não consegue sustentá-los. Meça primeiro o volume de tickets, a capacidade dos técnicos e o horário vendido.

4) Escreva quando o relógio começa, pausa e termina

O cliente manda um WhatsApp às 23h48.

O SLA já começou?

A resposta precisa estar escrita antes que isso aconteça.

Defina pelo menos:

• fuso horário e horário de atendimento;
• feriados e janelas de manutenção;
• canal que cria um ticket válido;
• dados mínimos: cliente, usuário, endpoint, sintoma e impacto;
• se o tempo de P1 corre fora do horário normal;
• quando o tempo pausa por falta de acesso, aprovação, informação ou resposta do cliente;
• o que conta como restaurado, resolvido ou encerrado;
• quantas tentativas de contato são feitas antes de fechar por falta de resposta.

A pausa não deve virar truque para esconder métricas ruins. Ela precisa ter motivo, horário e evidência visíveis.

5) Defina canais, responsáveis e escalonamento

Um bom SLA não diz apenas "em quanto tempo".

Ele também diz "quem é o próximo".

Exemplo simples:

Para cada P1, defina também para quem o MSP liga do lado do cliente. Um incidente crítico sem contato autorizado fica parado justamente quando mais importa.

6) Proteja o escopo com exclusões e responsabilidades

O SLA não deve transformar seu pacote mensal em trabalho infinito.

Esclareça o que está incluído e o que exige cotação, autorização ou agenda separada:

• endpoints, usuários e locais não registrados;
• projetos, migrações, cabeamento e mudanças grandes;
• suporte fora do horário;
• falhas de terceiros, mesmo quando você coordena o acompanhamento;
• hardware, licenças e peças;
• recuperação quando não existe backup válido;
• incidentes causados por acessos ou mudanças não autorizadas;
• trabalho presencial e despesas de deslocamento.

O cliente também precisa ter responsabilidades: manter contatos atualizados, dar acesso autorizado, responder solicitações de informação, aprovar mudanças e reportar pelo canal combinado.

7) Use este modelo como ponto de partida

Adapte este bloco à sua proposta ou anexo operacional:

```text ACORDO DE NÍVEL DE SERVIÇO — BASE OPERACIONAL

Cobertura:

• Serviços incluídos: [lista]
• Endpoints/usuários/locais: [quantidade e escopo]
• Horário: [dias, horas e fuso]
• Canal válido: [portal ou e-mail]

Prioridades:

• P1 Crítica: [definição] — resposta [tempo] — atualização [frequência]
• P2 Alta: [definição] — resposta [tempo] — atualização [frequência]
• P3 Normal: [definição] — resposta [tempo] — meta [tempo]
• P4 Solicitação: [definição] — resposta [tempo] — programação [tempo]

Regras do relógio:

• Começa quando [condição].
• Pausa quando [condições e evidência].
• Termina quando [restauração, resolução ou encerramento].

Escalonamento:

• Responsável inicial: [função]
• Escalonamento técnico: [função e condição]
• Escalonamento comercial: [função e condição]
• Contato autorizado do cliente: [função]

Exclusões:

• [projetos, terceiros, fora de horário, hardware e outras]

Relatório mensal:

• cumprimento da primeira resposta;
• tickets por prioridade;
• tempos de restauração/resolução;
• tickets reabertos ou antigos;
• decisões pendentes do cliente.

```

Antes de assinar, revise capacidade, dependências, compensações, limites de responsabilidade e legislação aplicável com orientação profissional.

8) Meça o SLA e revise todo mês

Um SLA guardado em PDF não melhora o serviço.

A revisão mensal pode melhorar.

Meça pelo menos:

• percentual de tickets com primeira resposta dentro da meta;
• tempo mediano de primeira resposta por prioridade;
• tempo de restauração ou resolução;
• tickets abertos por idade;
• tickets reabertos;
• incidentes repetidos;
• tempo esperando decisão ou resposta do cliente;
• principais causas de metas não cumpridas.

A CISA recomenda que até equipes pequenas documentem e pratiquem um plano de resposta a incidentes. Para um MSP, um ensaio simples de P1 ajuda a verificar contatos, escalonamento e comunicação antes do incidente real.

Não use o relatório para esconder falhas. Use-o para decidir: ajustar capacidade, redefinir escopo, automatizar uma tarefa ou corrigir uma promessa.

FAQ: SLA para MSPs

SLA significa tempo garantido de resolução?

Não necessariamente. Pode incluir primeira resposta, atualizações, disponibilidade e metas de restauração ou resolução. Separe cada compromisso e suas dependências.

Um MSP pequeno precisa de quatro prioridades?

Quatro são um bom ponto de partida, mas três podem funcionar em uma operação simples. O importante é que cada nível tenha critérios e exemplos claros.

Devo oferecer suporte P1 24 horas?

Somente se você tiver cobertura, escala e preço para sustentar isso. Caso contrário, defina horário e processo fora da cobertura sem vender uma disponibilidade que não existe.

Este modelo substitui um contrato?

Não. É uma base operacional. Um profissional jurídico deve adaptar obrigações, compensações, privacidade, responsabilidade e jurisdição.

Como o Lunixar RMM ajuda a cumprir um SLA?

Um RMM ajuda a centralizar contexto operacional como endpoints, alertas, patches, tickets, suporte remoto e relatórios. O cumprimento ainda depende do seu escopo, equipe, processo e capacidade.

Um SLA deve proteger o cliente e o MSP

O cliente precisa saber o que esperar.

Sua equipe precisa saber o que fazer.

E seu MSP precisa de compromissos que realmente consiga cumprir.

O Lunixar RMM pode apoiar essa operação conectando visibilidade, alertas, suporte e evidências em um único console. Conheça o Lunixar RMM para MSPs ou inicie um teste gratuito de 2 semanas sem cartão, com até 5 dispositivos e acesso completo.

Continue com estes guias:

• O que incluir no seu primeiro pacote mensal de suporte de TI
• Tickets de suporte em RMM: priorize com contexto
• Relatórios RMM para clientes e auditorias
• Como fechar o primeiro mês de suporte de TI com um cliente