Simples Solução TI | Suporte Técnico e Serviços de TI no RJ e SP
Voltar ao blog
Fabiano Lucio, autor do blog da Simples Solução TI

Fabiano Lucio

8 minutos de leitura

Contrato de suporte TI com SLA: o que definir agora

Um contrato de suporte TI com SLA reduz risco operacional quando define escopo, tempos mensuráveis e critérios de aceite verificáveis. A Simples Solução TI, com atendimento no Rio de Janeiro e São Paulo, estrutura esses contratos para empresas de 10 a 50 funcionários, transformando promessas de atendimento em obrigações auditáveis.

Contrato de suporte TI com SLA: caneta sobre documento com checklist de métricas e prazos
  • SLA sem critério de aceite e evidência vira disputa: exija ticket, anexos e validação.
  • Separe tempo de resposta de tempo de resolução e defina prioridade por impacto.
  • Exclua do cálculo dependências do cliente, com pausa registrada e prazo de retorno.
  • A Simples Solução TI aplica esse modelo para B2B no Rio de Janeiro e São Paulo.

O que um contrato de suporte TI com SLA precisa definir para reduzir riscos operacionais?

Um contrato de suporte TI com SLA reduz risco operacional quando define quatro blocos verificáveis: escopo, tempos, evidências e aceite. Sem esses blocos, o SLA vira promessa sem lastro, e qualquer incidente vira disputa. A Simples Solução TI aplica esse modelo em contratos de suporte com SLA no Rio de Janeiro e São Paulo, com gestão via service desk.

  • Escopo: listar serviços inclusos (suporte a estações, servidores, rede, backup) e exclusos (desenvolvimento, hardware não coberto, atendimento a uso pessoal). Sem delimitar, o fornecedor pode ser acionado por demandas fora do contrato, e a empresa fica sem base para recusar.
  • Tempos: definir prazos de resposta e resolução por prioridade, contados a partir do registro do chamado. Exemplo: P1 (parada total) resposta em 30 minutos e resolução em 4 horas; P2 resposta em 2 horas e resolução em 8 horas. Se o tempo começar a contar só quando o técnico "olhar" o chamado, o SLA perde valor.
  • Evidências: exigir registros de abertura, logs de atendimento, anexos de diagnóstico e relatórios de encerramento. Sem evidência, não há como auditar cumprimento nem calcular multa por descumprimento.
  • Aceite: definir critério objetivo de encerramento, com validação do usuário e prazo para contestação (ex.: 24 horas úteis). Se o chamado for encerrado unilateralmente pelo suporte, o SLA não protege a operação.

Como escrever SLAs que aguentam auditoria: quais métricas e critérios de aceite incluir?

Um SLA auditável especifica, para cada métrica, a meta numérica, o período de medição e a evidência aceita. Sem esses três componentes, o auditor não consegue verificar se o acordo foi cumprido. A tabela abaixo resume as métricas que devem constar no contrato.

MétricaMeta sugerida (exemplo)Evidência exigível
Tempo de respostaP1 em 30 min; P2 em 2h; P3 em 4h; P4 em 8h (medido a partir da abertura do chamado)Timestamp de abertura e registro da primeira resposta do técnico no service desk
Tempo de resoluçãoP1 em 4h; P2 em 8h; P3 em 2 dias úteis; P4 em 5 dias úteisRegistro de encerramento com solução aplicada e aceite do usuário
Disponibilidade de infraestrutura crítica99,5% mensal para servidores, firewall e links principaisRelatório de monitoramento (Zabbix ou PRTG) com uptime calculado no período
Evidências gerais do chamado100% dos chamados com registro completoExportação do GLPI ou Snipe-IT com logs, anexos e histórico de interações

Quais evidências e rotinas diminuem o risco de 'SLA no papel'?

Evidência é o que transforma SLA em obrigação mensurável. As rotinas que mais reduzem o risco de 'SLA no papel' são registro de chamado com timestamp, anexos de diagnóstico, histórico completo e validação pós-correção. Sem isso, o SLA vira disputa de versão entre empresa e fornecedor.

  • Registros de service desk: cada chamado deve ter data/hora de abertura, prioridade, responsável e status. Ferramentas como GLPI permitem exportar esses dados para auditoria.
  • Anexos de diagnóstico: prints de tela, logs de sistema e relatórios de erro anexados ao chamado. Sem anexo, a causa raiz fica sem prova.
  • Histórico completo: todas as interações, tentativas de correção e escalações registradas em ordem cronológica. Isso evita alegação de "não fui avisado".
  • Validação pós-correção: aceite formal do usuário com prazo para contestação (ex.: 24 horas úteis). Se o usuário não validar, o chamado deve ficar aberto ou ser escalado.

Quando vale a pena separar SLA por prioridade, por cliente e por tipo de serviço?

Separe o SLA por prioridade, por cliente ou por tipo de serviço quando a diferença de impacto e o custo de indisponibilidade justificarem metas distintas. Caso contrário, um SLA único reduz complexidade e evita disputa. A regra prática é: se dois grupos de chamados exigem tempos de resposta diferentes, separe.

A consequência de manter um SLA único para realidades distintas é a perda de rastreabilidade: um chamado de impressora pode competir com um servidor fora do ar pela mesma meta. O fornecedor tende a priorizar o que é mais visível, não o que foi contratado. A separação por prioridade resolve isso porque vincula explicitamente urgência à meta, como em um service desk com fila única e níveis P1, P2 e P3.

Separe por cliente quando houver contratos com níveis de serviço distintos, como uma clínica de saúde com retenção regulatória e um varejo com pico sazonal. Separe por tipo de serviço quando as ferramentas e os tempos técnicos forem diferentes, como suporte a servidores versus manutenção de desktops. Não separe quando a operação for homogênea; nesse caso, um SLA único com prioridades internas é suficiente.

Regra de decisão e cenários

CritérioSepare quandoNão separe quando
Por prioridadeExiste fila com níveis P1, P2 e P3 e metas distintas para resposta e resolução.Todos os chamados têm o mesmo prazo e o mesmo impacto operacional.
Por clienteContratos diferentes exigem níveis de serviço diferentes, como saúde com retenção regulatória e varejo com pico sazonal.A base de clientes é homogênea em porte, criticidade e expectativa de atendimento.
Por tipo de serviçoServiços com tempos técnicos distintos, como suporte a servidores versus manutenção de desktops.O fornecedor já usa prioridades internas para distinguir os tempos sem separar no contrato.

Quais cláusulas são inegociáveis antes de assinar o contrato de suporte TI com SLA?

São inegociáveis as cláusulas que definem escopo do atendimento, tempos de resposta e resolução, evidência aceita, cálculo dos indicadores, penalidades e saída do contrato. Sem elas, o documento não garante serviço mensurável, apenas intenção. Toda cláusula que use termos vagos precisa ser reescrita antes da assinatura.

  • Escopo e exclusões: define o que está coberto e o que gera cobrança à parte. Sem essa cláusula, a disputa sobre atendimento fora do escopo é inevitável.
  • Tempos de resposta e resolução por prioridade: metas numéricas por nível de prioridade. Sem número, não há descumprimento a ser cobrado.
  • Evidência aceita: logs de chamados, registros de abertura, capturas de tela e relatórios de sistema. Sem evidência definida, o fornecedor pode alegar atendimento sem prova.
  • Cálculo dos indicadores e período de medição: fórmula do SLA e janela de apuração (mensal, trimestral). Sem isso, as metas podem ser calculadas de forma favorável ao fornecedor.
  • Penalidades e glosas: percentual de desconto ou crédito por descumprimento, atrelado a cada meta. Sem penalidade, o SLA vira meta aspiracional.
  • Direito de rescisão e transição: o cliente pode encerrar por descumprimento recorrente e receber apoio para migrar. Sem essa cláusula, a empresa fica presa a serviço ruim.
  • Tratamento de dados (LGPD): define responsabilidades de cada parte no tratamento de dados, com base na Lei 13.709/2018. Sem essa cláusula, fica indefinido quem responde por incidentes.
  • Força maior e exclusões de responsabilidade: define eventos fora do controle e como são reportados. Sem isso, qualquer interrupção pode virar disputa.

Sinais que exigem revisão jurídica incluem expressões como 'melhor esforço', 'tempo hábil', 'conforme necessidade', metas sem número, penalidade apenas por indisponibilidade total e cláusula de alteração unilateral sem aviso. Se qualquer um aparecer, peça redação objetiva antes de assinar.

Como a Simples Solução TI aplica contrato de suporte com SLA no Rio de Janeiro e São Paulo?

A Simples Solução TI aplica contrato de suporte com SLA definindo escopo por contrato, metas numéricas por prioridade e evidência via sistema de chamados e relatórios mensais. O modelo cobre atendimento presencial no Rio de Janeiro e em São Paulo, com suporte remoto para todo o Brasil. Para empresas de 10 a 50 funcionários, o contrato separa SLA de service desk, field service e servidores, porque cada serviço tem tempo técnico distinto.

  • Diagnóstico inicial: mapeia usuários, equipamentos, volume de chamados e criticidade dos sistemas.
  • Prioridades numéricas: P1, P2 e P3 com prazos de resposta e resolução definidos por contrato.
  • Evidência auditável: registros de chamados, logs de atendimento e relatório mensal de indicadores.
  • Atendimento híbrido: field service presencial no Rio e em São Paulo, e service desk remoto nacional.

Fundada em 2008, a Simples Solução TI atende exclusivamente empresas com CNPJ e operação profissional, tipicamente de 10 a 50 funcionários. O valor do contrato depende de escopo: número de usuários, volume de chamados, quantidade de equipamentos e nível de SLA exigido. Por isso, a proposta só sai após diagnóstico; não existe preço de prateleira.

Perguntas frequentes

Meu SLA de suporte está no papel, mas o fornecedor não cumpre. Como cobro?

Solicite o relatório mensal com tempos medidos e compare com as metas por prioridade. Se a evidência não existir ou for inconsistente, recuse o aceite daquele período até regularizar. Aplique as penalidades previstas em contrato, senão vira precedente para descumprimento contínuo.

Como escrever um SLA de suporte que aguente auditoria?

Defina para cada métrica uma meta numérica, período de medição e evidência aceita (ex.: registro do chamado no GLPI). Inclua fórmula de cálculo e critério de aceite, não apenas 'melhor esforço'. Sem isso, o SLA vira promessa sem consequência.

Quando separar SLA por prioridade, por cliente ou por tipo de serviço?

Separe quando houver fila com níveis P1, P2 e P3 e metas distintas, ou quando clientes com contrato diferente exigirem tempos específicos. Exceção: não separe se a operação é homogênea e a gestão extra não compensa. Avalie impacto de indisponibilidade e custo antes de criar variações.

Quais cláusulas de contrato de suporte TI são inegociáveis?

Exija cláusulas que definam escopo, tempos de resposta e resolução, evidência aceita, cálculo dos indicadores, penalidades e saída do contrato. Sem penalidade clara, o descumprimento vira aceitável. Se o fornecedor não aceitar incluir, procure outro.

O que fazer se o fornecedor de TI não apresenta relatório de SLA?

Pare de aceitar faturas e exija o relatório antes de aprovar pagamento. Registre a falha por escrito e use a cláusula de penalidade. Se persistir, inicie o processo de saída previsto em contrato.

Como saber se a Simples Solução TI aplica SLA de verdade no Rio e SP?

Peça um exemplo de relatório mensal e verifique se inclui metas numéricas por prioridade e evidências por chamado. A Simples Solução TI atende empresas no Rio de Janeiro e São Paulo com contrato de suporte com SLA e relatórios mensais. Confirme no orçamento o escopo e as metas antes de assinar.

Vale a pena separar SLA por cliente ou ter um único SLA padrão?

Use SLA padrão se todos os clientes têm mesma criticidade e tamanho, porque reduz custo de gestão. Exceção: separe por cliente quando o impacto de indisponibilidade ou o nível de serviço contratado for diferente, como empresa com equipe remota vs. local. Avalie o volume de chamados e a receita de cada contrato.

Precisa de uma solução de TI corporativa?

Nossos especialistas avaliam sua infraestrutura, firewall e rede e propõem o caminho mais seguro para a sua empresa. Agende uma consultoria sem compromisso.

Posts sugeridos