Reuniao mensal de servico com o fornecedor de TI: pauta que funciona

Por que a reunião mensal de serviço existe

Contrato de TI terceirizada sem ritmo de revisão vira caixa-preta. O fornecedor entrega chamados, envia fatura, e a empresa só descobre que algo está errado quando um servidor cai ou quando o orçamento do ano estoura. A reunião mensal de serviço — service review, na terminologia de ITIL — existe justamente para transformar operação invisível em decisão gerenciável. Não é uma reunião de status. É o momento em que o cliente valida se o dinheiro investido está comprando o resultado contratado.

A diferença entre uma service review útil e uma reunião de fachada está no que se leva para a mesa. Fornecedor que abre um PowerPoint com "97% dos chamados dentro do SLA" e passa para o próximo slide está prestando conta de atividade, não de resultado. O número isolado não diz se os 3% fora do SLA eram chamados críticos de produção ou pedidos de troca de mouse. Também não diz se o volume total de chamados subiu, o que costuma ser sinal de que algo estrutural está apodrecendo por baixo.

Uma boa reunião mensal responde a quatro perguntas objetivas: o serviço contratado foi entregue no nível acordado? O que mudou no ambiente desde o último encontro? Quais riscos estão abertos e quem é o dono de cada um? O que vem nos próximos 90 dias e quanto isso custa? Se a pauta não cobre esses quatro pontos, a reunião pode ser cancelada sem perda para ninguém.

Bloco 1 — SLA e volume: o que os números precisam mostrar

Comece pelo indicador contratual, mas exija a abertura. Percentual agregado de SLA esconde mais do que revela. O que interessa é a distribuição: quantos chamados entraram por criticidade, qual foi o tempo médio de primeira resposta e de solução em cada faixa, e quais foram os casos que estouraram o prazo — com nome, número do chamado e explicação. Um estouro de SLA em incidente P1 de servidor de arquivos é um evento a ser dissecado. Cinco estouros em solicitações P4 de instalação de software são ruído operacional.

O segundo dado obrigatório é a tendência de volume. Chamados por mês, comparados aos três meses anteriores, segmentados por categoria. Volume subindo de forma consistente numa categoria específica é o sinal mais barato que existe de problema estrutural não resolvido. Vinte chamados de "internet lenta" no mês significam que ninguém tratou a causa raiz — provavelmente link saturado, roteamento mal configurado ou Wi-Fi subdimensionado. O fornecedor que fecha os vinte chamados dentro do SLA está tecnicamente cumprindo o contrato e falhando com o cliente ao mesmo tempo.

Peça também o inverso: quais categorias caíram. Se a implantação de um novo firewall derrubou os chamados de indisponibilidade de VPN de doze para dois, isso é retorno mensurável do investimento e merece registro. Service review sem reconhecimento do que funcionou vira uma sessão de reclamação, e reunião que só cobra deteriora a relação técnica rápido.

Regra prática: se o relatório mensal cabe em um slide, ele não é um relatório. Se precisa de trinta, ninguém vai ler. A faixa útil fica entre seis e dez páginas, com um sumário executivo de meia página no topo.

Bloco 2 — Incidentes relevantes e causa raiz

Todo mês que teve interrupção de serviço merece uma análise pós-incidente formal, mesmo que curta. O formato mínimo tem cinco campos: o que aconteceu, quando começou e terminou, qual foi o impacto no negócio (quantas pessoas, quais processos, quanto tempo), qual foi a causa raiz técnica e qual ação foi tomada para impedir a repetição. Sem o último campo, a análise é apenas narrativa.

A armadilha aqui é aceitar causa raiz genérica. "Falha de hardware" não é causa raiz — é sintoma. A causa raiz é "disco em RAID degradado desde março, alerta de monitoramento não estava configurado para esse array, segundo disco falhou em agosto e derrubou o volume". A partir dessa formulação nasce uma ação concreta: revisar cobertura de monitoramento de todos os arrays de storage. A partir de "falha de hardware" não nasce nada.

Vale cobrar do fornecedor a distinção entre incidente e problema. Incidente é o evento pontual que foi restaurado. Problema é a causa subjacente que continua viva. Muitos MSPs fecham incidentes com brilhantismo e nunca abrem registro de problema, o que garante recorrência. Uma boa service review mantém uma lista de problemas abertos, com dono e prazo, revisada mês a mês até o encerramento.

Bloco 3 — Riscos abertos, segurança e conformidade

Esta é a seção que mais frequentemente falta nas reuniões e a que mais custa caro quando falta. O fornecedor deve manter um registro de riscos vivo, com itens que ele identificou no ambiente e que dependem de decisão ou orçamento do cliente para serem resolvidos. Exemplos típicos que aparecem em ambientes de médio porte:

• Servidores ou estações com sistema operacional fora de suporte do fabricante
• Backups sem teste de restauração documentado nos últimos noventa dias
• Contas administrativas sem autenticação multifator habilitada
• Ausência de cópia offsite ou imutável — exposição direta a ransomware
• Certificados, licenças ou contratos de suporte com vencimento nos próximos seis meses
• Equipamento de rede crítico sem redundância nem contrato de reposição
• Usuários desligados com acesso ainda ativo em algum sistema

Cada item precisa de três atributos: severidade, custo estimado de mitigação e dono da decisão. O papel do fornecedor é apresentar e recomendar. O papel do cliente é decidir e assumir o risco quando escolher não agir. O registro em ata dessa decisão protege os dois lados — protege o cliente de ser surpreendido e protege o fornecedor da acusação de omissão depois do incidente.

No bloco de segurança, dois números merecem espaço fixo: cobertura de proteção de endpoint (quantas máquinas do inventário estão com agente ativo e atualizado) e taxa de sucesso de backup com evidência de restauração testada. Backup que roda sem erro no relatório e nunca foi restaurado não é backup, é esperança agendada.

Bloco 4 — Roadmap, orçamento e o que ignorar na pauta

A última parte da reunião olha para frente. O horizonte útil é de noventa dias, com visão anual mais grossa. O que está previsto para os próximos três meses: renovações, migrações, upgrades, fim de garantia, projetos aprovados em andamento. Para cada item, custo estimado e janela de execução. Isso permite que o gestor de TI ou o financeiro planeje desembolso em vez de reagir a uma proposta emergencial em cima da hora.

Roadmap também é onde entra a discussão de capacidade. Crescimento de headcount previsto, expansão de filial, novo sistema que a operação vai adotar — tudo isso tem impacto em licenças, links, armazenamento e suporte. Fornecedor que participa da conversa de planejamento entrega infraestrutura pronta na data. Fornecedor que só recebe chamado entrega gambiarra no prazo apertado.

Igualmente importante é saber o que não colocar na pauta. Alguns itens consomem tempo e não geram decisão:

1. Detalhamento chamado a chamado. Se são cento e vinte chamados no mês, revisar um por um é desperdício. Só os relevantes — os que estouraram SLA, os que reabriram e os que tiveram impacto amplo.
2. Métrica de vaidade sem consequência. "Tempo médio de atendimento caiu 4 segundos" não muda nenhuma decisão. Corte.
3. Discussão técnica profunda entre dois especialistas. Se o assunto exige quarenta minutos de arquitetura, vira reunião separada com as pessoas certas. Service review tem gestores na sala.
4. Cobrança individual de técnico. Problema de pessoa se trata com o gestor do fornecedor, fora da reunião. Na service review discute-se processo.
5. Reapresentação do que já foi decidido. Se o item foi aprovado no mês passado, o status é uma linha, não um slide.

Sobre cadência e formato: mensal é o padrão para contratos de suporte contínuo, com uma revisão trimestral mais estratégica — orçamento, contrato, indicadores acumulados. Uma hora costuma ser suficiente quando o relatório é enviado com pelo menos dois dias de antecedência e todo mundo chega tendo lido. Reunião em que o fornecedor lê o relatório em voz alta desperdiça o tempo de todos os presentes. E toda reunião termina com ata curta: decisões tomadas, ações com responsável e data. Sem ata, o mês seguinte recomeça do zero.

Como a Duk conduz a service review

Na Duk Informática & Cloud, a reunião mensal de serviço faz parte do contrato de suporte, não é um extra cobrado à parte. Em 18+ anos atendendo mais de 550 empresas, ficou claro que o cliente que participa da revisão mensal tem menos incidente crítico, menos surpresa de orçamento e uma relação bem mais previsível com a área de TI do que o cliente que só aparece quando algo quebra.

O relatório que levamos para a mesa cobre os quatro blocos descritos aqui: SLA aberto por criticidade com os estouros nomeados, incidentes com análise de causa raiz, registro de riscos com severidade e custo de mitigação, e roadmap de noventa dias com valores. Como Microsoft Gold Partner, incluímos também o panorama de licenciamento Microsoft 365 — consumo real versus contratado, contas ativas de usuários desligados e postura de segurança da identidade —, que costuma ser a fonte de economia mais fácil de capturar em ambientes que cresceram sem revisão.

Se o seu contrato de TI hoje não tem esse ritmo, a pauta acima serve como ponto de partida para cobrar do fornecedor atual. E se a conversa não avançar, vale conhecer como funciona um contrato com governança de verdade — fale com a Duk e agende uma avaliação do seu ambiente.