Envie o primeiro aviso assim que a queda for confirmada, sem esperar o diagnóstico. Ele precisa dizer três coisas: o que está indisponível, que a equipe já está trabalhando e a que horas sai a próxima atualização. Prometa o horário da próxima notícia, nunca o horário da solução, porque você ainda não sabe qual é o problema. Depois cumpra esse horário mesmo que não tenha novidade nenhuma para dar.
Abaixo você encontra os modelos prontos para copiar em cada momento da queda, o que nunca deve entrar no comunicado, quem precisa escrever durante a crise e quando a queda deixa de ser só um problema técnico.
Sumário
O que todo comunicado de queda precisa ter
O erro mais comum é esperar entender o problema para só então avisar. Enquanto a empresa investiga em silêncio, o cliente já percebeu, ligou duas vezes e começou a achar que ninguém sabe o que está acontecendo. O silêncio custa mais caro que a queda.
O segundo erro é prometer horário de solução. Dizer “voltamos em 30 minutos” quando ninguém ainda sabe a causa cria uma promessa que provavelmente será quebrada, e aí a empresa perde duas vezes.
A regra que resolve os dois: prometa a próxima atualização, não a solução. E cumpra o horário prometido.
|
Momento |
Quando enviar |
O que precisa constar |
|---|---|---|
|
Primeiro aviso |
Assim que a queda é confirmada, antes do diagnóstico |
O que está fora, que a equipe já atua, horário da próxima atualização |
|
Atualização |
No horário prometido, mesmo sem novidade |
Situação atual, o que já se sabe, novo horário de atualização |
|
Resolução |
Depois de confirmar que voltou, não no primeiro sinal |
O que voltou, desde que horas, e o que fazer se ainda houver problema |
|
Manutenção programada |
Com antecedência, e um lembrete no dia |
Data, janela, o que fica indisponível e o que fazer antes |
Modelos prontos para copiar
Adapte o nome do serviço e os horários. Deixe esses textos salvos em algum lugar de acesso rápido, porque no meio da crise ninguém escreve bem.
-
Primeiro aviso para cliente, curto (WhatsApp ou e-mail): “Estamos com instabilidade no acesso ao [sistema] desde as [hora]. Nossa equipe já está trabalhando na normalização. Enviamos uma nova atualização às [hora + 30 min], mesmo que ainda não haja solução. Pedimos desculpas pelo transtorno.”
-
Primeiro aviso interno, para a equipe: “[Sistema] fora do ar desde [hora]. A TI já está atuando. Por favor, não abram chamados individuais sobre este assunto, para não atrasar o atendimento. Quem falar com cliente pode usar o texto padrão de instabilidade. Próxima atualização às [hora].”
-
Atualização quando ainda não resolveu: “Atualização sobre a instabilidade no [sistema]: seguimos trabalhando na normalização. Já identificamos que a origem está em [descrição sem detalhe técnico] e a equipe atua na correção. Nova atualização às [hora].”
-
Atualização quando ainda não se sabe a causa: “Atualização sobre a instabilidade no [sistema]: ainda estamos trabalhando na identificação da causa. Assim que tivermos previsão de retorno, comunicaremos. Próxima atualização às [hora].”
-
Aviso de resolução: “O acesso ao [sistema] foi normalizado às [hora] e já validamos o funcionamento. Se você ainda encontrar dificuldade, feche e abra o sistema novamente e, persistindo, entre em contato pelo [canal]. Obrigado pela compreensão.”
-
Manutenção programada, aviso prévio: “Informamos que o [sistema] ficará indisponível para manutenção no dia [data], das [hora] às [hora]. Durante a janela não será possível [ação afetada]. Recomendamos concluir [tarefa] antes do início. Enviaremos uma confirmação quando o serviço voltar.”
Uma observação sobre o canal. Se o sistema que caiu é o próprio e-mail, o aviso por e-mail não chega. Vale ter combinado antes qual é o canal alternativo, seja um grupo de WhatsApp, um aviso no site ou uma ligação para os clientes principais. Definir isso no meio da crise custa tempo que não existe.
O que nunca escrever em um aviso de queda
Tão importante quanto o texto certo é o que fica de fora. Cinco coisas costumam piorar a situação.
-
Horário de solução que você não pode cumprir. “Voltamos em 20 minutos” sem saber a causa é a frase que mais gera desgaste. Prometa a próxima atualização.
-
Culpar o fornecedor pelo nome. Dizer que “a operadora tal derrubou tudo” transfere a responsabilidade mas não devolve o serviço, e cria problema contratual com quem você vai precisar amanhã.
-
Detalhe técnico demais. Nome de servidor, versão de sistema, mensagem de erro e endereço interno não ajudam o cliente e podem entregar informação útil para quem quer atacar a empresa.
-
Confirmar ataque antes de saber. Se existe suspeita de invasão, o comunicado inicial fala de indisponibilidade, e a confirmação pública só vem quando o escopo estiver claro. Voltar atrás depois é pior que demorar.
-
Silêncio até resolver. Ficar sem comunicar porque “logo volta” transforma um problema de 40 minutos em uma crise de confiança.
Quem comunica enquanto a equipe técnica resolve
Aqui está um dos erros mais caros: a mesma pessoa que está resolvendo o problema é a que responde o cliente, o diretor e o grupo do WhatsApp. Cada interrupção atrasa o reparo, e o cliente recebe respostas desencontradas.
O capítulo sobre gestão de incidentes do SRE Book, do Google, disponível gratuitamente, trata isso separando papéis. Além de quem comanda o incidente e de quem mexe no sistema, existe a figura do responsável pela comunicação, descrito como a face pública da resposta ao incidente, encarregado de emitir atualizações periódicas para a equipe e para as partes interessadas.
Em uma empresa de 20 a 200 pessoas isso não exige estrutura grande. Exige apenas combinar antes duas coisas: quem comunica e quem resolve não são a mesma pessoa, e quem comunica busca a informação em um horário combinado, em vez de interromper a cada cinco minutos.
Um exemplo prático de como isso muda o dia: em uma transportadora, com o sistema de emissão de documentos fora do ar, cada motorista parado gera uma ligação para o escritório. Se quem está tentando restabelecer o sistema é quem atende essas ligações, o reparo simplesmente não avança.
Quando a queda deixa de ser só um problema técnico
Nem toda indisponibilidade é um incidente de segurança, mas algumas são. Quando a origem é ransomware ou invasão, a queda passa a ter uma segunda camada de obrigações, e o relógio começa a correr.
Segundo a ANPD, com base na Resolução CD/ANPD nº 15, de abril de 2024, a comunicação à autoridade e aos titulares deve ser feita pelo controlador em até três dias úteis, contados do conhecimento de um incidente que possa causar risco ou dano relevante aos titulares. A avaliação depende do caso e envolve quem responde pela proteção de dados na empresa.
Na prática, isso significa que a apuração técnica precisa correr em paralelo à restauração do serviço, e não depois dela. Tratar o caso como incidente de segurança desde o início preserva os registros que vão sustentar essa avaliação. Restaurar tudo às pressas e apagar o rastro no caminho é o que costuma inviabilizar a análise depois.
Como precisar menos vezes dessa mensagem
Nenhuma estrutura zera a indisponibilidade, e vale a honestidade com o número. Um ambiente com 99,8% de disponibilidade ainda soma cerca de 1 hora e 26 minutos de parada por mês. A meta razoável não é eliminar a queda, é reduzir a frequência, encurtar a duração e não ser pego de surpresa.
-
Saber antes do usuário. Com monitoramento de TI ativo, disco enchendo, link oscilando e serviço parando são identificados enquanto ainda dá para agir. Boa parte das quedas dá sinal antes.
-
Redundância onde a parada dói. Dois links de internet com troca automática resolvem a causa mais banal de indisponibilidade em PME, que é a operadora cair. Nem todo sistema precisa de redundância, mas o que para a operação precisa.
-
Plano de retorno escrito. Saber a ordem em que os sistemas voltam, quem executa e quanto tempo cada etapa leva é o que separa o disaster recovery de uma improvisação sob pressão.
-
Revisão depois que passou. Uma conversa curta sobre o que causou a queda e o que evita a repetição vale mais que qualquer relatório longo que ninguém lê.
Como a HLTI atua antes e durante a queda
Antes, o trabalho é reduzir a chance de a mensagem ser necessária: acompanhamento contínuo do ambiente, redundância nos pontos que param a operação, rotina de atualização e backup testado. É a lógica do modelo de TI gerenciada, em que o problema é tratado antes de virar chamado. Hoje, 98% dos incidentes são resolvidos assim, antes de o usuário perceber.
Durante, o que muda o resultado é ter alguém acompanhando o ambiente fora do horário comercial, com o NOC 24×7, e prazos definidos em contrato. Em casos críticos, a resposta acontece em até 1 hora e a resolução em até 4 horas. O suporte técnico não tem multa de fidelidade: para encerrar, bastam 30 dias de aviso prévio.
Conclusão
A mensagem de sistema fora do ar tem uma regra que resolve quase tudo: avise cedo, prometa a próxima atualização em vez da solução, e cumpra o horário que prometeu mesmo sem novidade. O silêncio é o que transforma uma queda administrável em desgaste com o cliente.
Vale deixar os modelos salvos antes de precisar deles, definir qual é o canal alternativo caso o e-mail seja justamente o que caiu, e combinar que quem comunica não é quem resolve. São três decisões que custam uma reunião e mudam o dia da próxima parada.
A HLTI atua há mais de 34 anos em TI, com mais de 175 empresas atendidas e 700 projetos entregues, com monitoramento 24×7, SLA em contrato e sem multa de fidelidade. Se a sua operação para junto com o sistema e você não sabe onde estão os pontos frágeis, faça o diagnóstico gratuito da sua infraestrutura.
Perguntas Frequentes
O que escrever no primeiro aviso de sistema fora do ar?
Diga o que está indisponível, desde que horas, que a equipe já está atuando e a que horas sai a próxima atualização. Não prometa horário de solução antes de conhecer a causa, porque uma promessa quebrada gera mais desgaste que a própria queda. Envie o aviso assim que a indisponibilidade for confirmada, sem esperar o diagnóstico ficar pronto.
Devo enviar atualização mesmo sem ter novidade?
Sim. Se você prometeu uma atualização para determinado horário, cumpra o horário mesmo que a mensagem seja apenas “seguimos trabalhando, próxima atualização às [hora]”. O silêncio no horário prometido faz o cliente concluir que ninguém está cuidando do problema, e é exatamente isso que gera a enxurrada de ligações.
Quem deve comunicar durante uma queda de sistema?
Alguém que não esteja resolvendo o problema. O material do SRE Book, do Google, descreve o papel do responsável pela comunicação como a face pública da resposta ao incidente, encarregado de emitir atualizações periódicas para a equipe e para as partes interessadas. Em empresas menores basta combinar antes quem assume esse papel e em que horários ele busca informação com o time técnico.
Como a HLTI ajuda a reduzir as paradas de sistema?
A HLTI acompanha o ambiente de forma contínua com NOC 24×7, identificando disco enchendo, link oscilando e serviços parando antes que virem indisponibilidade. Também estrutura redundância nos pontos que param a operação e o plano de retorno com a ordem em que cada sistema volta. Hoje, 98% dos incidentes são tratados antes de o usuário perceber, com SLA definido em contrato para os casos críticos.
Com mais de 30 anos de experiência acumulada, me especializei em tecnologia da informação, com foco em arquiteturas seguras para infraestruturas locais, em nuvem e híbridas. Acredito que o sucesso é construído em conjunto; o compartilhamento de ideias, visões e conhecimentos entre as pessoas é fundamental para impulsionar o crescimento, promover o aprendizado contínuo e desenvolver soluções mais eficazes e equilibradas.
