Contrato de suporte TI com SLA: o que definir para reduzir riscos operacionais

Um contrato de suporte TI com SLA reduz risco operacional quando transforma promessas de atendimento em obrigação verificável: escopo definido, prazos mensuráveis e critérios claros de aceite. Na prática, isso evita a disputa típica entre “tentamos resolver” e “resolver significa o quê”, principalmente quando há interrupções de serviço e impacto em negócios.

A dificuldade surge porque muitas minutas parecem completas, mas falham na parte que vira prova: como o atendimento começa, quais evidências fecham a contagem e o que acontece quando o problema não cabe no escopo. Um exemplo comum é incluir atividades como instalação/configuração, atualização/reconfiguração e troubleshooting sem amarrar o nível de serviço e as condições de medição (Serpro).

Com esse modelo bem estruturado, a operação consegue registrar tickets de service desk, classificar prioridade por impacto e aplicar um SLA multinível com cálculo transparente. Como resultado prático, o relatório mensal fecha ciclo de medição com rastreabilidade e o encerramento do chamado passa por critérios de aceite verificáveis, reduzindo “SLA no papel” (Serpro).

O que significa um contrato de suporte TI com SLA em termos práticos para o dia a dia

Para um contrato suporte TI com SLA ser aplicável e verificável, o documento precisa prometer resultados mensuráveis (ex.: tempo máximo para resposta e para restauração do serviço), definir o que entra no atendimento como “início do SLA” (por exemplo, registro do ticket no service desk) e estabelecer critérios de aceite após correções (por exemplo, testes mínimos e evidências de normalização).

Também deve fixar limites do que não será cobrado como SLA (mudanças de escopo, dependências do cliente e janelas de manutenção), com gatilhos de replanejamento quando esses limites ocorrerem.

Definição operacional: escopo, serviço e métricas que viram obrigação

O contrato precisa prometer, de forma verificável, o que será feito, em quais sistemas e com quais critérios de medição. Para isso, o escopo deve ser descrito por atividade e ambiente (por exemplo, instalação/configuração, atualização/reconfiguração e troubleshooting) e não por slogans; a Serpro, ao tratar suporte técnico operacional, organiza justamente o serviço por esse tipo de entrega. Com isso, a cobrança do SLA deixa de depender de interpretação.

As métricas que viram obrigação precisam estar ligadas a “eventos rastreáveis”: registro do chamado, classificação por prioridade e contagem de tempos a partir de um marco objetivo. Um bom critério é definir o começo do atendimento como o momento em que o ticket é aberto no service desk e recebido pela fila de triagem, e separar “tempo de resposta” do “tempo de resolução” por regras diferentes de medição. Assim, o que foi combinado pode ser conferido em auditoria.

Para evitar disputa, cada item do serviço deve ter critério de aceite após correções, incluindo o que encerra o problema e o que ainda reabre o ciclo. Na prática, essa aceitação costuma envolver verificação funcional (ex.: o serviço volta a operar) e condições mínimas (ex.: ausência de erro recorrente no mesmo cenário por um período definido no contrato, como 24 horas), além de evidências no histórico do ticket.

Quando o contrato não prevê esse padrão, “resolver” vira sinônimo de “tentar”, sem aferição real do SLA.

Partes envolvidas e papéis: quem registra, quem aprova e quem valida

O SLA só fica aplicável e verificável quando o contrato explicita quem opera o service desk, quem registra cada evidência (como anexos e logs) e quem aprova a transição do ticket entre status. Na prática, a promessa precisa amarrar responsabilidades: o provedor executa e registra; o cliente valida por critério definido e com prazo para responder, para não “parar” a contagem do atendimento por falta de retorno.

A cláusula de escopo deve listar atividades de suporte em termos auditáveis, evitando descrições amplas como “manutenção” sem detalhar o que entra. Um exemplo do tipo de detalhamento esperado aparece em “Contratar Suporte Técnico (Operações)”, que descreve suporte para ambientes cliente/servidor e inclui instalação/configuração, atualização/reconfiguração e troubleshooting; essa granularidade ajuda a definir o que conta como atendimento SLA e o que é mudança fora de cobertura.

Como validação, o contrato precisa definir um critério de aceite pós-correção com rastreabilidade mínima: ticket com identificação única, categoria, anexos (prints/logs) e histórico; além disso, deve prever uma janela objetiva para a resposta do solicitante, como 24 horas úteis para confirmar se o problema foi resolvido ou para abrir nova ação corretiva. Essa amarração reduz discussão do tipo “ficou ok no nosso entendimento” versus “não há evidência no registro”.

A diferença entre tempo de resposta e tempo de resolução no SLA

1. Defina tempo de resposta como confirmação formal em minutos/horas, incluindo canal (e-mail/portal/telefone) e início do atendimento; registre no service desk o carimbo de “primeiro contato”.

2. Trate tempo de resolução como conclusão comprovada: solução aplicada + evidência (log, mudança, retorno ao ambiente) com “status Resolvido”; vincule a baixa do ticket a critérios de aceite.

3. Compare o SLA de resposta e o SLA de resolução por prioridade: use categorias (ex.: incidente crítico vs solicitação) e exija dois campos no relatório mensal: “% dentro do TTR” e “% dentro do TTR-resolução”.

4. Registre exceções no cálculo: classifique como “dependência do cliente” quando bloqueada por ação externa; exija campo obrigatório “causa de pausa” e anexar evidência da solicitação do cliente.

Como escrever SLAs que aguentam auditoria: métricas, níveis e critérios de aceite

Para reduzir disputas, o contrato de suporte TI com SLA deve registrar, para cada categoria de atendimento, os tempos de resposta e resolução com contagem clara, a disponibilidade prometida e como ela é medida, as janelas de execução (horário de suporte e feriados) e as responsabilidades por atividade e por decisão, incluindo quem valida a correção e em que prazo. Também precisam constar campos de início do atendimento (ex.

: abertura e triagem do ticket), critérios objetivos de aceite pós-correção e regras de exclusão por dependência do cliente, como acesso, insumos ou aprovação.

SLA multinível: como separar prioridades por impacto e urgência

No SLA multinível, a separação por prioridade deve começar por um critério objetivo de impacto (ex.: quantos usuários/serviços ficam indisponíveis) e por urgência (ex.: efeito imediato no negócio). A partir daí, o contrato define faixas distintas de tempo de resposta e de restauração, além do que muda no atendimento entre prioridades (quem aciona primeiro, qual canal é aceito e qual nível técnico intervém).

Para reduzir disputa sobre “contagem do SLA”, cada faixa precisa deixar claro o que pausa e o que continua. Um exemplo prático: se a correção depende de intervenção do cliente (ex.: liberação de acesso, troca física, janela de mudança), o contrato deve registrar a responsabilidade e estabelecer um limite de aguardo — por exemplo, a medição de restauração pode ficar suspensa após um aviso formal e uma resposta dentro de 24 horas.

A composição das janelas também deve ser escrita com regras de serviço: atendimento 24x7 ou apenas horário comercial, feriados incluídos ou não, e quais tipos de solicitação entram no cálculo.

A mão de obra associada a cada prioridade deve estar vinculada a evidências de execução (ticket com anexos, atividades realizadas e caminho de validação), para que a fiscalização do relatório mensal feche o ciclo sem interpretação livre, como no modelo de definição de escopo e atividades previsto para suporte operacional (Serpro).

Exigências de suporte remoto e atendimento remoto: o que conta como começo do atendimento

Para definir o “começo do atendimento remoto” no contrato, o SLA deve tratar o início como o momento em que o service desk registra o ticket (com data/hora, categoria e descrição mínima) e não como o instante em que o técnico “começa a atuar”. Na prática de auditoria, isso reduz disputa sobre contagem do tempo. Um critério objetivo também precisa indicar quais eventos interrompem a contagem: por exemplo, quando a mensagem de retorno é enviada ao contratante.

As janelas devem ficar associadas a responsabilidades específicas (contratante e prestador), porque elas definem o que conta como pronto para avanço e o que depende do cliente. Um exemplo operacional: suporte remoto pode exigir acesso remoto habilitado e credenciais válidas; se o acesso não estiver disponível em até 2 tentativas de contato dentro da janela, o contrato deve prever pausa do SLA até a reentrega do acesso.

Esse desenho se conecta ao tipo de escopo previsto em suporte técnico operacional, que costuma incluir atividades como instalação/configuração, atualização/reconfiguração e troubleshooting.

Para evitar “SLA no papel”, o contrato precisa registrar disponibilidade e responsabilidades de forma mensurável, inclusive com exceções explícitas. O documento deve diferenciar disponibilidade (ex.: serviço acessível no período contratado) de resposta e resolução (ações de correção), e delimitar gatilhos de indisponibilidade: falhas causadas por infraestrutura do contratante, janelas de manutenção programada e mudanças não aprovadas.

Uma referência útil para estruturar esse controle é o guia de contratação do suporte técnico operacional da Serpro, por explicitar o que entra no objeto e como o suporte se relaciona ao ambiente cliente/servidor.

Relatório mensal e fiscalização: quais evidências fecham o ciclo de medição

Para fechar o ciclo de medição, o contrato precisa fixar quais evidências sustentam cada métrica e quem valida a medição. O relatório mensal deve amarrar ticket, categoria e prioridade do chamado aos prazos de resposta e resolução, com data/hora registradas no service desk como “fonte da verdade”. Com isso, o cálculo deixa de depender de relatos informais e vira conferência objetiva entre as partes.

A fiscalização também precisa prever auditoria da coleta: quais campos são obrigatórios no registro (por exemplo, anexos, descrição do incidente e resultado do troubleshooting) e quais exclusões são aceitáveis. Como referência de escopo operacional, a Serpro descreve atividades típicas como instalação/configuração, atualização/reconfiguração e troubleshooting; isso ajuda a alinhar o que conta como esforço “dentro do contrato” versus o que fica como demanda fora do SLA.

Para evitar disputa, o contrato deve definir janela de medição e tratamento de eventos que distorcem contagem. Por exemplo: contagem pode pausar quando o chamado depende de ação do cliente, mas somente se o contrato exigir registro de “bloqueio por dependência” com prazo de retorno (ex.: reconexão após recebimento de credenciais).

Em janelas de atendimento e responsabilidades, cada alteração de status do ticket deve ter critério claro de aceite, para que o relatório mensal seja auditável no mesmo padrão mês a mês.

Quais evidências e rotinas diminuem o risco de “SLA no papel”

Para comprovar cumprimento do contrato suporte TI com SLA após incidentes e solicitações, a contratante deve exigir um registro auditável no service desk e um fluxo de evidências: ticket com identificação do solicitante, categoria do problema e anexos (logs, prints, evidência do erro), histórico de ações e comunicações; classificação de prioridade e horário com fuso/local; e aceite formal após correções, com validação do cliente e confirmação de restabelecimento.

Esse conjunto sustenta auditoria e fecha divergências sobre o que foi efetivamente entregue.

Registro de atendimento (service desk): ticket, categoria, anexos e histórico

Para comprovar cumprimento do SLA depois de incidentes e solicitações, o contratante precisa exigir que cada demanda gere um ticket no service desk com trilha mínima auditável: identificador único, data e hora de abertura, categoria, prioridade, descrição do sintoma/solicitação e status com datas de avanço. Sem esses campos, a medição vira inferência, e a cobrança por atingimento de metas perde evidência.

O histórico do atendimento deve registrar também ações executadas e responsáveis por etapa, incluindo reclassificações (ex.: mudança de prioridade) e justificativa quando ocorrerem fora do padrão. Para evitar disputa sobre “começou quando? ”, o contrato deve exigir anexos que apoiem a análise, como logs, prints, versão do sistema e número da ocorrência correlata, além de confirmar quais evidências são aceitas para atendimento remoto.

Segundo o termo de referência (UFRB), a mensuração precisa estar atrelada a critérios objetivos e verificáveis dentro do fluxo de execução.

Como exceção operacional, o contrato deve prever tratamento formal para solicitações incompletas: quando faltarem informações mínimas para diagnóstico, o suporte pode suspender ou pausar a contagem, mas somente se houver registro do pedido ao solicitante no ticket (com prazo objetivo e canal definido) e retorno do solicitante com a documentação necessária. Isso reduz o “tempo morto” não medido quando o diagnóstico depende de dados do ambiente do cliente.

Em casos de indisponibilidade generalizada, a evidência do início do evento deve apontar o gatilho (monitoramento/alarme) no ticket para alinhar contagem e cobertura.

Escopo técnico que costuma entrar: instalação/configuração, atualização/reconfiguração e troubleshooting

1. Registre cada solicitação no service desk com categoria técnica (instalação/configuração, atualização/reconfiguração, troubleshooting), evidência inicial (prints/logs) e versão do ativo; exija anexos que permitam reproduzir o contexto do chamado.

2. Exija uma checklist de execução por tipo de serviço: passos realizados, comandos/ações aplicadas, mudanças de parâmetros e responsáveis; valide que cada linha tenha timestamp e referência ao ticket para fechar rastreabilidade.

3. Comprove troubleshooting com trilha técnica: hipótese levantada, testes executados, resultado de cada teste e causa provável; aceite correções apenas com evidência objetiva (antes/depois) e status “resolvido” no histórico.

4. Isole exceções contratuais no ticket: dependências externas (terceiros/fabricante), indisponibilidade do ambiente e bloqueios; anexar retorno do solicitante e registrar aprovação do escalonamento antes de contar como esforço concluído.

Critérios de aceite após correções: como garantir que o problema está resolvido

1. Registre evidências no service desk com carimbo de data/hora, ticket vinculado ao incidente, categoria, itens afetados e anexos (prints/arquivos de log) do antes e depois, mantendo trilha auditável do diagnóstico e da correção.

2. Meça o resultado da correção executando a mesma rotina de validação indicada na solicitação: reproduza o sintoma, aplique a correção e confirme o comportamento esperado; anote campos técnicos-chave no histórico.

3. Compare os logs e alertas do período do atendimento com a linha-base definida no SLA: nenhum erro recorrente deve permanecer no intervalo de observação acordado, e eventos relacionados devem cessar.

4. Ative procedimento de exceção quando a validação falhar: abra novo ticket com correlação ao anterior, descreva a discrepância (o que permaneceu igual) e bloqueie aceite até evidência adicional cumprir o critério de resolução.

SLA por prioridade, por cliente e por tipo de serviço: quando cada modelo faz sentido

O SLA deve variar conforme o impacto do tipo de incidente, o “nível de cliente” (interno vs. externo) e a natureza do serviço no contrato: falhas de segurança e indisponibilidade tendem a ter tempos menores e prioridade automática, enquanto solicitações operacionais seguem fila própria. Em prática, isso aparece como matrizes de atendimento por categoria (ex.: rede, software, infraestrutura) e regras de escalonamento, com exceções e janelas de manutenção programada.

Decisão: como escolher e fechar o contrato de suporte TI com SLA sem aumentar risco operacional

A minuta deve ser aprovada quando houver definição objetiva de objeto e escopo por atividade (instalação/configuração, atualização/reconfiguração e troubleshooting), rastreabilidade de evidências de atendimento no service desk e critérios de aceite mensuráveis, com regras de medição que aceitem exclusões por dependência do cliente (acesso, insumos e janelas de mudança). Limites para revisão jurídica aparecem quando o texto permite “melhor esforço” sem SLA, omite tratamento para indisponibilidade de terceiros e não fixa governança de comunicação e registro.

Quais cláusulas devem estar claras antes de assinar (e o que costuma gerar disputa depois)

A minuta deve ser aprovada quando a contratante consegue transformar “cumprir SLA” em critérios objetivos de medição, aceitação e penalidade operacional. Uma forma de decidir é exigir que cada cláusula traga, no mínimo, (1) evento que inicia a contagem, (2) métrica com unidade e registro, e (3) evidência auditável no mesmo padrão do service desk. Se algum item depender de “boa-fé” sem campo de verificação, a recusa tende a ser a decisão mais segura.

Gera disputa depois, principalmente, quando a medição mistura atividades diferentes: por exemplo, contabilizar tempo de diagnóstico junto com tempo de restauração sem separar categorias e prioridades. Também costuma dar conflito quando a janela de atendimento (horário e feriados) não aparece com clareza, ou quando “atendimento remoto” não define o que conta como começo efetivo (comando inicial, acesso autorizado e confirmação no ticket).

Por fim, cláusulas de “escopo em aberto” devem ser recusadas: melhor limitar por tipo de demanda (instalação/configuração, atualização/reconfiguração e troubleshooting) do que deixar o que entra como extrapolação.

"Atenção: Cláusulas jurídicas e operacionais que deslocam risco para a contratante exigem revisão antes de assinar, sobretudo quando impõem exclusões amplas para falhas do ambiente, permitem replanejamento sem aviso prévio ou condicionam SLA a resposta do cliente sem prazos definidos. A regra prática é exigir gatilhos mensuráveis para contagem pausada (por exemplo, ausência de acesso em até um prazo acordado) e registrar em contrato quem valida a correção e em quanto tempo a correção é considerada aceita."

A próxima ação imediata é montar a matriz “cláusula → evidência no ticket → critério de aceite → penalidade”, e usar esse documento na rodada final com o time jurídico e o responsável pelo service desk.

Quais sinais exigem ajuste de escopo ou revisão do modelo de medição

• A minuta deve ser recusada quando a medição não diferenciar disponibilidade, atendimento e entrega (correção/contorno). Sem fórmula de cálculo e fonte de evidência, a aferição fica discutível na execução.

• Revisão jurídica é necessária quando o contrato não definir começo do atendimento remoto, limites de acesso (VPN, credenciais) e responsabilidades do cliente por ambiente e interferências. Ambiguidade aqui tende a deslocar risco para o fornecedor.

• Ajuste de escopo é exigido quando o SLA incluir atividades técnicas fora do objeto (ex.: obras, substituição de hardware de terceiros, alterações não aprovadas). Inclua exceções e critérios de elegibilidade por tipo de solicitação.

• Ative um ciclo de medição com auditoria de campos mínimos: prioridade, horário registrado, categoria, causa inicial e status de aceite. Se faltarem, o relatório mensal vira “narrativa” e não prova de performance.

Perguntas para alinhar operação: como o suporte é solicitado, como o cliente responde e qual o aviso prévio

A minuta tende a ser aprovada quando define um fluxo objetivo de abertura, validação e resposta do atendimento, incluindo prazos distintos para aceitar o ticket e iniciar a ação. Esse alinhamento deve prever campos mínimos na solicitação (categoria, impacto, evidências e horário) e regra clara de “devolução” quando faltar informação para começar o serviço, com retorno formal em até 1 dia útil.

A resposta do cliente também precisa ser contratualizada: o contrato deve exigir confirmação de recebimento e disponibilidade para testes ou validações após correções, com critérios de aceite como “funcionalidade restaurada” ou “erro reproduzido e corrigido” descritos em linguagem verificável. Se houver suporte remoto, o aviso prévio para agendamento deve existir e ter exceção definida para incidente crítico, para evitar que a mão de obra fique aguardando permissões que não foram consideradas no SLA.

A parte jurídica costuma ser necessária quando a minuta não separa o que é responsabilidade do suporte remoto do que depende de acesso, mudanças e homologações do contratante, ou quando a medição permite recontagem do tempo por motivos pouco objetivos. A Serpro descreve suporte operacional com atividades como instalação/configuração, atualização/reconfiguração e troubleshooting, e isso serve de base para revisar se o escopo do contrato reflete exatamente o que entra e o que fica fora do ciclo de medição.

Ação imediata: aprovar apenas após ajustar o texto para que o início do atendimento e o “papel do cliente” fiquem rastreáveis por evidência e critério de aceite.

Perguntas Frequentes

Quando o suporte remoto começa e como isso impacta o SLA?

Em geral, o suporte começa quando o atendimento é efetivamente iniciado segundo o que o contrato define como “início do atendimento” (por exemplo, abertura do chamado no service desk e acionamento do suporte). Se o prestador demorar para registrar/acknowledge o ticket ou tratar como “pré-atendimento”, a contagem do SLA tende a ficar controversa. Para evitar isso, o contrato deve amarrar claramente o evento que marca o começo e quem valida esse marco.

O que fazer quando o problema não está no escopo do contrato, mas o negócio precisa de continuidade?

Nessas situações, o contrato deve prever um caminho para triagem e gestão de risco, como classificar o chamado e orientar a próxima ação sem “forçar” o SLA de um item que não foi contratado. Uma prática útil é diferenciar atendimento de diagnóstico/contorno (para manter operação) do que é correção em escopo, com critérios de aceite e evidências distintos. Sem essa separação, surgem disputas do tipo “estava no escopo” versus “não havia obrigação mensurável”.

Como tratar paradas causadas por terceiros (provedor de internet, fabricante, energia) no cálculo do SLA?

O contrato deve definir o que conta como causa externa e como isso afeta a medição do SLA, inclusive que evidência comprova a dependência (por exemplo, registros do incidente do provedor/empresa responsável). Quando não há regra, qualquer atraso pode virar disputa sobre “quem é responsável” e se houve bloqueio de contagem. Com critérios de exclusão/bloqueio bem descritos, a operação consegue medir o que realmente era controlável pelo suporte.

Vale a pena incluir atualizações e reconfigurações no SLA se isso pode gerar riscos ao ambiente?

Depende do modelo de mudança adotado e do nível de controle exigido: atualizações e reconfigurações tendem a exigir janela, aprovação e evidências de execução para não virar causa de novos incidentes. Se o contrato tratar essas atividades como obrigação sem definir pré-requisitos (como rollback, impacto esperado e condições de execução), o SLA pode ficar difícil de cumprir e de encerrar com aceite verificável. O ideal é amarrar o que será feito, quando será feito e como se prova que não houve regressão relevante no período definido.