Como este tema funciona na sua empresa
Comunicação é pessoal e direta. Usuários esperam que TI avise rapidamente via WhatsApp, Slack ou telefone. Documentação é mínima. O desafio é evitar pânico desnecessário e manter credibilidade quando a solução demora.
Comunicação segue canais formais (email, status page, SMS) com audiências distintas (usuários finais, gerentes, liderança). Esperado: atualizações a cada 30 minutos em incidentes críticos. Documentação e post-mortem são parte da rotina.
Comunicação é altamente estruturada: war room com representantes de áreas impactadas, cadeia de comando clara, status page em tempo real, relatórios regulatórios para auditoria. Cada incidente crítico gera documentação formal e revisão de políticas.
Comunicação de incidentes de TI é a transmissão estruturada de informações sobre falhas, seus impactos e progresso da resolução para diferentes públicos (usuários, lideranças, clientes) através de canais apropriados, mantendo credibilidade, reduzindo pânico e facilitando decisões durante a crise.
Por que comunicação de incidentes importa
Quando sistema está fora, primeiro instinto da maioria é ligar para TI perguntando "quando volta?". Se não há resposta clara, usuários imaginam cenários catastróficos: "Fomos hackeados?", "Perdemos dados?", "Quanto tempo sem acessar cliente?". Esse vácuo de informação gera pânico, desconfiança em TI e decisões apressadas da liderança.
Comunicação proativa muda a narrativa. Em vez de "TI desapareceu, ninguém sabe nada", a empresa diz "Sistema X está instável desde 14h30, somos é causa (HD cheio). Prazo esperado: 16h. Vamos atualizar a cada 30 minutos." Ao manter usuários informados, TI preserva confiança mesmo em falha.
Dados de satisfação de usuários mostram que a percepção de qualidade de TI é mais influenciada pela comunicação durante incidentes do que pela frequência de incidentes. Equipe que comunica bem é percebida como competente; equipe que é silenciosa é percebida como incompetente, mesmo que tecnicamente igualmente capaz.
Estágios de incidente e o que comunicar em cada um
Estágio 1 — Detecção (primeiros 5-15 minutos)
Assim que incidente é detectado (por alerta, por chamado de usuário ou por descoberta acidental), comunicação começa imediatamente.
O que comunicar:
- Qual sistema/serviço foi impactado
- Que operações são afetadas (não conseguem logar, email não envia, relatório não carrega)
- Severidade (crítico = sem contingência, grave = com workaround, menor = incômodo)
- Horário de início estimado (ex: "começou às 14h30")
- Status: "TI está investigando" ou "causa identificada, trabalhando na solução"
Para quem: Afetados diretos (usuários impactados), gestores desses usuários, liderança se severidade é crítica.
Via qual canal: Email para aviso formal + status page se existir + SMS/Slack para avisos urgentes.
Estágio 2 — Investigação (15 minutos até 2 horas)
Equipe técnica está investigando, causa pode ainda não ser clara. Atualizações devem ser frequentes (a cada 15-30 minutos) para incidentes críticos, mesmo que a atualização seja apenas "ainda investigando, mais informações em 30 minutos".
O que comunicar:
- Progresso: "Estágio 1 — verificação de servidores" ou "Estágio 2 — teste de conectividade"
- Causa preliminar, se identificada ("HD no servidor primário está 99% cheio")
- Próxima atualização em X minutos
- Se há workaround temporário, descrever
Para quem: Continuar com afetados + liderança.
Estágio 3 — Resolução (30 minutos até N horas)
Equipe implementa solução. Atualizações ainda devem ser frequentes para incidentes críticos.
O que comunicar:
- Ação em andamento: "Limpando disco", "Reiniciando serviço", "Executando failover"
- Prazo esperado de volta: "Esperado às 16h30" ou "Esperado em 30 minutos"
- Risco: "Possível breve oscilação de performance quando reiniciarmos"
- Se solução for paterna/temporária: "Solução é temporária, faremos ajuste definitivo amanhã"
Estágio 4 — Recuperação (últimas horas até recuperação total)
Sistema volta, mas pode estar degradado (performance mais lenta, funcionalidade reduzida). Comunicação agora foca em validação.
O que comunicar:
- "Sistema voltou às 16h45. Estamos validando integridade de dados."
- Se degradação é esperada: "Performance pode estar 20% mais lenta enquanto validamos."
- Quando estará 100% normal: "Retorno à normalidade em ~30 minutos."
Estágio 5 — Encerramento e aprendizado (horas a dias após resolução)
Incidente foi resolvido. Comunicação agora é com foco em lições aprendidas e prevenção.
O que comunicar:
- Causa raiz (não apenas sintoma: "HD cheio" é sintoma; "processo manuttenção agendada não foi executada em 4 meses" é causa raiz)
- Impacto: "Sistema ficou indisponível por 2 horas, afetou ~120 usuários, prejuízo estimado R$ X"
- Ações preventivas: "Agora há alerta automático quando disco atinge 80% de uso"
- Quando isso entra em produção
Esse estágio é onde TI demonstra profissionalismo. Empresas que divulgam aprendizados ganham credibilidade; empresas que varrem incidentes para baixo do tapete perdem confiança.
Públicos-alvo e o que cada um precisa ouvir
Usuários finais afetados
Linguagem: clara, não-técnica, empática. Devem saber: o que está fora, quando volta, se existe workaround, se perderão dados.
Exemplo: "Sistema de folha de ponto está fora desde 14h. Causa: servidor em manutenção emergencial. Volta às 16h. Enquanto isso, registrem ponto no formulário de backup." NÃO fale: "RAID-1 em modo degradado no storage, falha em HBA."
Gestores de usuários/liderança operacional
Linguagem: impacto no negócio, não técnica. Devem saber: quantas pessoas impactadas, quanto tempo sem poder trabalhar, prejuízo operacional, causa, prevenção.
Exemplo: "Financeiro ficou sem acesso ao sistema de folha por 2 horas, afetando 8 pessoas. Causa: manutenção emergencial no servidor. Ação: escalamos alertas de disco cheio." NÃO envie logs técnicos.
Liderança executiva (CEO, COO, etc.)
Apenas para incidentes críticos (sistema fora > 1 hora, dados comprometidos, clientes impactados). Mensagem: contexto do incidente, impacto financeiro/reputacional, se há comunicação com clientes/auditoria, próximos passos.
Exemplo: "Sistema de vendas ficou indisponível 90 minutos desta manhã, afetando 3 clientes que não conseguiram acessar pedidos. Impacto: ~R$ 50k em vendas adiadas. Causa: falha no banco de dados. Ação: backup da solução implementada." Tome cuidado com tom de crise; informar, não alarmista.
Clientes externos (se aplicável)
Apenas para indisponibilidade que afeta clientes (SaaS, portal, API). Mensagem: o que está fora, impacto estimado, quando volta, desculpas e compensação se aplicável.
Status pages públicas (ex: status.empresa.com) são padrão para SaaS e empresas com serviços públicos. Usuários checam isso antes de ligar para suporte.
Canais de comunicação e quando usar cada um
| Canal | Melhor para | Frequência de atualizações |
|---|---|---|
| Aviso formal, comunicação a larga escala, registro para auditoria | Inicial + a cada 30-60 min em crítico | |
| Status page | Transparência, histórico, usuários podem self-service | A cada 15-30 min; atualização em tempo real ideal |
| SMS/Alerta push | Avisos urgentes, críticos, garante que será visto | Apenas para início + fim de incidente crítico |
| Slack/Teams | Comunicação rápida, time interno, gestores | Contínuo enquanto resolvendo |
| Telefone direto | Liderança, cliente crítico, situações de crise | Uma chamada inicial, depois email |
Cuidado: WhatsApp é informal e rápido, mas deixa rasto desnecessário. Evite para avisos oficiais de incidente; use para "ei, galera, email sobre incidente indo agora".
Template de comunicação de incidente
Assunto do email: [INCIDENTE] Nome do Sistema — Indisponível desde HH:MM
Corpo do email — Formato padronizado:
INCIDENTE: [Nome do Sistema]
SEVERIDADE: [Crítico | Grave | Menor]
INÍCIO: [Hora de detecção]
STATUS: [Investigando | Resolvendo | Validando | Resolvido]
O QUE ESTÁ AFETADO:
[Descrição clara do impacto: quem, o quê, quanto tempo]
CAUSA:
[Se conhecida: "HD no servidor primário cheio". Se não: "Sob investigação."]
AÇÕES EM ANDAMENTO:
[Passo a passo técnico, em linguagem clara]
PRAZO DE VOLTA:
[Melhor estimativa: "Esperado às 16h00"]
WORKAROUND TEMPORÁRIO:
[Se existe: "Registrem ponto no formulário de backup disponível em..."]
PRÓXIMA ATUALIZAÇÃO: [Hora exata, ex: "16h30"]
Qualquer dúvida: [email protected] ou ramal XXXX
Usar esse template garante que nenhuma informação essencial é deixada de lado.
Template acima pode ser simplificado. Essencial: foco em impacto (quem é afetado, quando volta), linguagem clara, atualizações via Slack ou WhatsApp. Documentação formal pós-incidente pode ser mínima ou verbal.
Usar template completo acima. Manter status page ou pelo menos Google Sheet compartilhado. Documentação pós-incidente deve ser registrada. Reunião de retrospectiva com stakeholders é prática.
Status page em tempo real obrigatória. War room com representantes de áreas. Comunicação estruturada em níveis (técnico, operacional, executivo). Documentação formal, análise de causa raiz, plano de prevenção. Auditoria e compliance devem revisar incidentes críticos.
Sinais de que sua empresa precisa melhorar comunicação de incidentes
Se você se reconhece em três ou mais cenários abaixo, estrutura de comunicação de incidentes precisa ser revisada.
- Durante incidentes, usuários não sabem o que está fora ou quando volta.
- Liderança descobre incidente via reclamação de usuário, não via TI.
- Atualizações de progresso são inconsistentes ou demoradas.
- Após incidentes, não há documentação de causa ou ações preventivas.
- Confiança em TI é baixa; usuários descrevem equipe como "desaparecida durante problemas".
- Não existe processo formal de comunicação, tudo é ad-hoc.
- Clientes reclamam que não recebem avisos de indisponibilidade de sistemas públicos.
Caminhos para implementar comunicação estruturada
Dois caminhos principais: estruturar internamente ou apoiar-se em ferramenta especializada.
Viável para empresas médias que têm processo ITIL básico.
- Perfil necessário: Gestor de incidentes ITIL ou coordenador de TI com experiência em comunicação
- Tempo estimado: 4-8 semanas para estruturar processo, treinar equipe e testar
- Faz sentido quando: Infraestrutura é interna, equipe tem maturidade ITIL
- Risco principal: Falta de ferramentas (status page, integração com monitoring), dependência de pessoas
Consultoria ou ferramenta dedicada de status page/incident management.
- Tipo de fornecedor: Consultoria ITIL, ou plataforma de gerenciamento de incidentes (StatusPage, Opsgenie, PagerDuty)
- Vantagem: Ferramenta reduz esforço manual, integra com monitoring, automação de avisos
- Faz sentido quando: Há incidentes frequentes, equipe é pequena, SaaS/serviço público (precisa de status page)
- Resultado típico: Processo operacional em 2-4 semanas, ferramentas implementadas e testadas
Precisa estruturar comunicação de incidentes na sua empresa?
O oHub conecta você gratuitamente a especialistas em gerenciamento de incidentes e ferramentas de status page. Descreva seu atual processo e receba recomendações personalizadas, sem compromisso.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
Com que frequência devo atualizar durante incidente?
Incidentes críticos (sistema fora completamente): a cada 15-30 minutos. Graves (funcionalidade reduzida): a cada 30-60 minutos. Menores (incômodo): atualizações espaçadas, mas pelo menos duas (inicial + fim). Se mais de 2 horas sem atualização, usuários começam a descontar em confiança.
O que fazer se não souber a causa ou prazo?
Comunique isso honestamente. "Causa ainda sob investigação. Próxima atualização em 30 minutos." é muito melhor que silêncio. Usuários entendem imprevistos; não entendem falta de comunicação.
Quanto detalhe técnico devo incluir na comunicação?
Nenhum para usuários finais. Para gestores: impacto e causa em linguagem simples (não jargão técnico). Para executivos: contexto e consequência. Para técnicos: detalhes completos, logs, stack traces. Use linguagem apropriada para cada público.
Devo avisar se é minha culpa ou culpa de terceiros?
Sim, mas com tato. Se é culpa interna: "Erro em procedimento de manutenção identificado e corrigido." Se é de terceiros: "Fornecedor Y teve indisponibilidade que afetou nosso serviço." Transparência aumenta confiança, não a reduz.
Como documentar incidentes para auditoria?
Template: (1) Hora de início e fim. (2) Causa raiz. (3) Sistemas afetados. (4) Número de usuários impactados. (5) Ações tomadas. (6) Ações preventivas implementadas. (7) Qui fez, e quando. Guardar em repositório central (wiki, Jira, Confluence) por mínimo 2 anos.