Acordo de nível de serviço TI: como definir metas, prazos e responsabilidades na prática

Um acordo de nível de serviço TI define, por escrito, quais resultados de atendimento ou entrega são esperados, como serão medidos e quais responsabilidades cabem a cada parte. Na prática, isso transforma a negociação de “qualidade” em critérios verificáveis, com medição de desempenho e, quando previsto, consequência por descumprimento (Acordo de Nível de Serviço (ANS)).

A dificuldade costuma aparecer porque o documento vira ambíguo: metas não deixam claro o que conta como sucesso, prazos não consideram janelas de operação e “responsabilidade” fica genérica demais para sustentar auditoria ou cobrança. Em serviços de TI, essa falta de precisão é onde surgem disputas sobre causalidade e contagem de tempo (IN02_30042008).

Com um modelo executável, o leitor consegue descrever o serviço, mapear tipos de demanda (como incidente e requisição), escolher indicadores e definir critérios de aceitação com evidências auditáveis. O resultado esperado é um acordo que orienta rotinas de acompanhamento, e não apenas um texto para arquivo, com metas alinhadas ao processo de gestão (Processo Cumprimento de Requisição — Portal IFFluminense).

O que é acordo de nível de serviço TI e o que esse documento precisa conter para ser executável

O acordo de nível de serviço TI deve trazer uma descrição objetiva do escopo, com horário de atendimento e regras de cobertura, além de indicadores operacionais, metas por tipo de demanda e critérios de aceitação do que será considerado “entregue”. Também precisa definir responsabilidades por papel (provedor e área solicitante) e explicitar como a medição será registrada e validada, inclusive com consequências formalizadas para descumprimento, como glosas, renegociação ou ajuste de pagamento, quando previsto em contrato.

Como o contrato se transforma em critérios mensuráveis para o serviço prestado

• Critérios operacionais por demanda — ex.: incidente crítico tem prioridade definida, triagem registrada e tempo de atendimento medido a partir do registro na ferramenta, não do recebimento por e-mail.

• Métricas com fórmula e janela — percentil de disponibilidade, taxa de solução na janela e SLA pausas explícitas (ex.: tempo de espera de fornecedor) para evitar disputa na medição.

• Responsabilidades com “dono” e interface — cada indicador aponta quem mede, quem executa e quem valida aceite; anexar canais e horário de comunicação para reduzir retrabalho.

• Registro de evidência e gatilho de descumprimento — especificar quais relatórios/prints/logs comprovam o indicador e a partir de qual evento o descumprimento é considerado para tratativa.

Como definir metas e prazos: do tempo de resposta às regras de medição e aceitação

Metas numéricas no acordo de nível de serviço TI precisam amarrar três pontos: janela de atendimento (horários e dias), tempo de resposta/tempo de recuperação e critérios objetivos de aceitação do “feito”. Para evitar interpretações, a medição deve indicar fonte (ferramenta de monitoramento ou ticket), ponto de início e fim do cronômetro e tolerâncias permitidas (por exemplo, exclusão de tempo fora da janela). A aceitação deve prever evidências mínimas, como log, evidência de restauração e validação em ambiente previsto.

Que métricas usar por tipo de demanda (incidente, requisição e mudança) sem criar metas impossíveis

• Incidente crítico (ex.: indisponibilidade total): meta de tempo de resposta menor que 15 min e início de ação registrado no ticket; aceitar somente evidência de atendimento (log/escalação), não “tentativa” sem retorno.

• Requisição padrão (ex.: acesso, e-mail, software): use janela de atendimento por categoria com SLA por fila (ex.: backlog separado) e critério de aceitação “entregue e validado” pelo requisitante.

• Mudança emergencial (ex.: contorno de falha em produção): defina tempo de avaliação + “gate” de risco (rollback testado/Plano B) e aceite com evidência pós-implementação (status monitorado e sem regressão).

• Regra de medição: registre eventos no sistema (abertura, triagem, diagnóstico, resolução) e não pause o relógio por falta de informação; em vez disso, crie etapa formal de “dependência do cliente” com responsável.

Como descrever validade, comunicação e rotinas de acompanhamento para o acordo não virar “documento de gaveta”

Para o acordo de nível de serviço TI não virar “documento de gaveta”, a validade precisa ser explícita (início e término), com gatilhos de revisão e um período de transição quando houver mudança de escopo. Na prática, o documento deve prever, por exemplo, que uma revisão ocorra em até 30 dias após implantação de uma nova ferramenta de monitoramento, mantendo a versão anterior até a data de troca.

A comunicação deve ligar cada métrica ao canal e ao horário de reporte: defina quem recebe, em que periodicidade (semanal ou mensal) e qual formato de evidência será aceito na medição (relatório, log exportado ou registro de ticket).

Segundo o TCU (IN02_30042008), o ANS típico inclui comunicação e validade para tornar objetivo o acompanhamento; por isso, registre também janela de atendimento e critérios de aceitação do que “conta” como resposta, como status final do chamado e horário do evento no sistema.

As rotinas de acompanhamento precisam ter cadência e regra de correção, com tratamento de exceções para reduzir disputa de interpretação. O acordo pode prever, por exemplo, que atrasos por indisponibilidade de fornecedor sejam segregados em relatórios separados, e que a contagem do tempo de resposta use o timestamp do primeiro registro no sistema. Uma orientação desse tipo aparece também em guias do setor público sobre responsabilidades e medição no acordo (Acordo de Nível de Serviço (ANS)).

Quando o descumprimento gera consequência: evidências, papéis e trilha de auditoria

A apuração do descumprimento do acordo de nível de serviço TI deve ser feita com um conjunto único de evidências e papéis definidos, para que a negociação seja baseada em fatos e não em interpretações.

Para isso, o serviço precisa vincular cada métrica a um “evento rastreável” (chamado, requisição ou mudança), com registros de monitoramento e comunicações que indiquem data, horário e responsável; e o processo deve separar claramente quem mede, quem valida e quem decide a consequência, seguindo o fluxo de notificação, contestação e aceite do relatório.

Que registros sustentam a medição (relatórios, relatórios de monitoramento e comunicações) e como evitar disputas

A apuração do descumprimento fica rastreável quando cada meta do acordo de nível de serviço é vinculada a uma evidência observável, com responsável, origem da medição e janela de consolidação do dado. Na prática, a trilha deve apontar, para cada demanda, qual ferramenta/ticket registrou o evento, qual indicador foi calculado e qual critério definiu “aceito” ou “não aceito”, evitando depender de memória operacional.

Os registros precisam existir em três camadas: relatórios de monitoramento (mostram comportamento ao longo do tempo), comunicados (registram solicitações, escalonamentos e alinhamentos) e relatórios de desempenho consolidados (servem para auditoria e reconciliação). Segundo o TCU, o conteúdo típico do ANS contempla indicadores, métricas, metas, responsabilidades e relatórios de monitoramento, justamente para sustentar essa medição com lastro documental. Um erro comum é consolidar só o número final; a disputa começa quando não há como reconstruir o cálculo.

Para evitar disputas, a responsabilidade pela evidência deve ser segmentada: quem executa fornece os dados brutos; quem valida aplica o critério de aceitação; quem aprova fecha a consolidação do período. Quando houver contestação, o procedimento precisa prever reprocessamento com a mesma fonte e regra de cálculo, incluindo o tratamento de falhas de monitoramento (por exemplo, registrar “sem dado” e definir qual evidência substitui o gap). Assim, a negociação ocorre sobre critérios e registros, não sobre versões divergentes da rotina.

SLA de nível do cliente, SLA multinível e vínculos contratuais: como escolher o modelo certo

O desenho que melhor atende ao serviço sem perder controle costuma combinar um SLA de nível do cliente (o que o negócio recebe) com um SLA multinível (como TI opera internamente: filas, bases e suporte técnico) e, no contrato, vínculos explícitos de obrigações mínimas e condições de aceite. Isso alinha governança do pedido, previsibilidade de desempenho e tratativa de exceções, como contingência em manutenção programada.

O desenho mais consistente para manter controle operacional costuma combinar metas de nível do cliente (visão e responsabilidade) com estrutura multinível (diagnóstico e execução), amarrando ambos ao contrato com evidências, contingência e regras mínimas de medição.

Aprovação do acordo de nível de serviço TI: critérios para decisão e limites onde o texto precisa ser revisto

A aprovação final do acordo de nível de serviço TI deve validar consistência entre escopo, critérios de medição e governança de mudanças, garantindo que a planilha de indicadores feche com o que será auditado. A redação precisa ser revisada antes de “contrato firmado” quando houver dependências de terceiros, exceções por indisponibilidade planejada e ausência de critérios de aceitação para cada entrega (por exemplo, relatório mensal, evidência de monitoramento e aprovações de comunicação).

Também merece ajuste a matriz de responsabilidades para run e change, incluindo contingência e tratativa de incidentes fora do controle do provedor.

Quais sinais indicam que as metas precisam de ajuste (cobertura de indicadores, lacunas de responsabilidade e regras de contingência)

• Cobertura de indicadores — metas precisam mapear todo o ciclo (detecção, triagem, execução, validação, comunicação); lacuna em qualquer etapa costuma impedir medir cumprimento e causa disputa na aprovação.

• Responsabilidades por papel — cada entregável deve ter responsável e substituto (ex.: atendimento NOC, gestão de mudanças, segurança); ausência de back-up torna a meta “cumprível no papel” e inexecutável na contingência.

• Regras de contingência — incluir gatilhos e efeitos (incidente massivo, indisponibilidade de ferramenta, janela de manutenção) com revisão de prazos e comunicação; sem isso, o mesmo evento gera interpretações diferentes pelas partes.

• Condições de medição — travar o que conta como início/fim da contagem, fontes de registro e critério de aceite; quando medições dependem de “relato manual”, a revisão deve exigir evidência automática ou formulário padrão.

Com o acordo de nível de serviço TI bem definido, a equipe pode tratar o desempenho como um ciclo: medir com a mesma fonte indicada no documento, confrontar com as metas por tipo de demanda e registrar as divergências com evidências replicáveis. Quando os indicadores falham, o critério de decisão deve ser se a causa é de capacidade, de escopo ou de medição; a próxima ação imediata é revisar janela, critérios de aceitação e responsabilidades, mantendo o vínculo contratual.

Perguntas Frequentes

Como contar o prazo do atendimento no acordo de nível de serviço TI quando há reabertura, indisponibilidade do fornecedor ou mudanças de prioridade?

O prazo precisa ser definido com regras de contagem: por exemplo, quando o relógio inicia e se pausa em janelas de operação, e como fica a contagem após reabertura e reclassificação do chamado. Também é necessário prever exceções documentadas para eventos fora do controle do provedor (como indisponibilidade programada) e descrever o efeito dessas ocorrências no indicador. Sem essa governança, a medição tende a gerar disputa sobre causalidade e sobre qual versão do SLA vale no momento do fato.

Quando não vale a pena usar acordo de nível de serviço TI para serviços de TI?

Em geral, não vale quando o serviço não tem entregáveis claros ou quando a demanda é predominantemente exploratória, sem critérios de aceite verificáveis. Também tende a ser inadequado quando o processo de registro e evidência (chamados, filas, logs e critérios de aceitação) não existe ou não é confiável, porque o SLA vira apenas uma promessa não auditável. Antes de firmar, a organização deve garantir que consegue medir o que promete e que há um mecanismo real de acompanhamento e correção.

O que costuma causar conflito entre provedor e contratante na medição do desempenho do SLA de TI?

Os conflitos mais comuns surgem de definição vaga de sucesso, ausência de critérios objetivos de aceitação e falta de clareza sobre quais evidências sustentam a medição. Outro ponto recorrente é misturar métricas de gestão com metas de resultado sem especificar o que conta como serviço prestado e o que é retrabalho por falha. Para reduzir atrito, o acordo deve indicar, de forma operacional, quais indicadores serão usados e quais registros provam cada medição.

Como lidar com custos e esforço operacional para cumprir o acordo de nível de serviço TI, especialmente quando o provedor precisa investir em monitoramento e melhoria de processo?

O custo “escondido” costuma aparecer quando o SLA exige coleta de dados, monitoramento e rotinas de reporte que não estavam no escopo original. A solução prática é tratar capacidade e esforço como parte da negociação: especificar o nível de instrumentação necessário para medir indicadores e estabelecer rotinas de acompanhamento que caibam no processo existente. Se a medição depende de novos controles, o acordo deve refletir isso para evitar metas inviáveis e cobranças baseadas em dados incompletos.