Comunicação de crises em TI: 12 prompts para sobreviver 🙌

Comunicação de crises em TI: 12 prompts para sobreviver entre a teoria dos manuais e a diretoria no seu cangote

Você está no meio de um incidente crítico às 23h47 da Black Friday. O sistema de pagamentos caiu. O Slack está explodindo. O diretor comercial acabou de entrar na sala de guerra com aquele olhar que você conhece — o mesmo que precede demissões. E a primeira coisa que ele pergunta não é “qual é a causa raiz?”. É: “Quando volta?”

Nesse momento, todo o treinamento de comunicação de crises que você fez — o diagrama de Ishikawa, o framework de RCA, o template de post-mortem de cinco páginas — vale exatamente zero. O custo invisível desse gap entre teoria e realidade não é apenas o estresse do momento: é a credibilidade acumulada em anos de trabalho que pode evaporar em 90 segundos de silêncio ou, pior, numa resposta técnica incompreensível para quem não sabe a diferença entre um timeout e um deadlock.

Neste guia você vai encontrar 12 prompts prontos para usar com qualquer IA generativa que transformam o caos de um incidente em comunicação estratégica — desde o primeiro aviso para a diretoria até o relatório de causa raiz. Você vai copiar os scripts, os frameworks e os atalhos que separam quem sobrevive a uma crise de quem aprende com ela depois da demissão.

Neste guia: 12 prompts prontos para comunicação de crises em TI. Copie os scripts, frameworks e os atalhos de recuperação emocional e técnica.

Índice

• O método dos dois mundos — por que a teoria falha na prática
• O que você vai conseguir gerar
• Tabela 01: Os tipos de público numa crise de TI
• Tabela 02: Teoria vs realidade — comparativo brutal
• Tabela 03: Anatomia de uma comunicação de crise eficaz
• 12 prompts prontos para comunicação de crises em TI
• Brendon aconselha
• Comandos de atalho
• O que a IA não consegue fazer numa crise
• SOS: a diretoria quer uma resposta agora
• Erros fatais
• Prompt fraco vs prompt forte
• Glossário rápido
• FAQ

Por que o método dos dois mundos funciona (3 pilares)

Pilar 1: O escudo técnico — jargão como ferramenta de gestão de tempo

Há uma verdade que nenhum manual de ITIL vai admitir: numa crise aguda, termos técnicos complexos não são arrogância — são gestão de expectativas. Quando você diz “estamos investigando uma possível inconsistência de estado no cluster de banco de dados primário causada por uma condição de corrida no mecanismo de replicação”, a diretoria não entende a frase — mas entende que existe um problema real sendo tratado por alguém que sabe o que está fazendo. Isso compra os 5 a 10 minutos que você precisa para realmente executar o CTRL+Z salvador ou reiniciar o maldito servidor.

Pilar 2: A tradução progressiva — diferentes públicos pedem idiomas diferentes

O erro clássico é usar a mesma comunicação para a equipe técnica e para o board. O dev precisa saber o stack trace; o CFO precisa saber se o faturamento está sendo afetado e quando para. Comunicação de crise eficaz não é uma mensagem — é uma cascata de mensagens adaptadas: altamente técnica para o time de resolução, operacionalmente focada para gerentes, e financeiramente enquadrada para executivos. A IA é perfeita para gerar as três versões em paralelo nos primeiros 2 minutos de incidente.

Pilar 3: O controle de narrativa — quem conta primeiro conta melhor

Em toda crise, existe uma janela de 3 a 7 minutos antes que alguém de outro departamento envie um print no WhatsApp do CEO dizendo “o sistema caiu e ninguém avisou nada”. Quem preenche essa janela com uma comunicação proativa — mesmo que só diga “estamos cientes do problema e investigando” — controla a narrativa. Quem fica quieto esperando ter a resposta perfeita perde o controle da percepção, e percepção numa crise vale mais do que solução tardia.

O que você vai conseguir gerar com estes prompts

Tabela 01: Os tipos de público numa crise de TI e o que cada um precisa ouvir

✔️ Até aqui você já sabe: que comunicação de crise não é uma mensagem — é um portfólio de mensagens; que cada público tem uma linguagem e uma urgência diferentes; e que a IA pode gerar todas as versões em paralelo em menos de 3 minutos.

Tabela 02: Teoria vs realidade — comparativo brutal

Tabela 03: Anatomia — o que cada elemento de um bom comunicado de crise faz por dentro

12 prompts prontos para comunicação de crises em TI — copie e cole 📌

Cada prompt abaixo foi desenhado para um momento específico de crise. Identifique em qual fase você está, copie o prompt correspondente, substitua os campos entre colchetes e envie para a IA. O resultado estará pronto em menos de 30 segundos.

Mantenha o contexto técnico real nos campos de substituição — quanto mais específico você for, mais preciso e convincente será o output. Você pode adaptar o tom pedindo “reescreva mais formal” ou “versão para não técnicos” após o primeiro resultado.

🚨 Série A — Alerta Inicial (prompts A-01 a A-03)

📢 Prompt A-01 — Alerta imediato para canal interno (90 segundos de trabalho)

Você é um especialista em comunicação de incidentes de TI. Escreva um alerta inicial de incidente para o canal interno do Slack no seguinte formato:

🚨 [INCIDENTE ATIVO] [sistema afetado em maiúsculas]
Status: Investigando
Impacto: [descreva o impacto operacional em termos de negócio, não técnicos]
Desde: [horário de início]
Responsável: [nome ou papel]
Próximo update: em [X] minutos

Detalhes técnicos (canal dev): [sintoma técnico — ex: timeouts no endpoint /checkout, erro 500 no serviço de autenticação]

Use linguagem direta. Máximo 8 linhas. Não use jargões para a parte de impacto operacional.

Dados para preencher:
- Sistema afetado: [preencha]
- Impacto no negócio: [preencha]
- Horário de início: [preencha]
- Responsável pela investigação: [preencha]
- Sintoma técnico observado: [preencha]

📢 Prompt A-02 — Versão executiva do alerta inicial (para diretoria e C-Level)

Você é um gerente de TI comunicando um incidente crítico ao board executivo. Escreva uma mensagem de alerta com estas características:
- Sem jargão técnico
- Impacto em linguagem de negócio (revenue, clientes, operação)
- Tom confiante: "estamos gerenciando" — não "não sabemos o que é"
- Máximo 5 linhas
- Inclua: o que está acontecendo, impacto, o que está sendo feito, próximo update

Situação:
- Incidente: [descreva o problema em linguagem técnica — a IA vai traduzir]
- Impacto no negócio: [ex: checkout fora do ar, atendimento impossibilitado]
- Ação em curso: [ex: equipe de infraestrutura investigando, failover sendo preparado]
- Próximo update em: [X minutos]

📢 Prompt A-03 — Alerta com jargão técnico estratégico (para comprar tempo)

Crie uma mensagem técnica de status de incidente que soe impressionantemente específica e competente para uma audiência mista (devs + gestores com algum conhecimento técnico). O objetivo é transmitir que a equipe sabe exatamente o que está investigando, mesmo que ainda não tenha causa raiz confirmada.

Use a seguinte estrutura:
1. Identificação do componente com linguagem técnica específica
2. Sintoma observado com métricas se disponíveis
3. Hipótese técnica em investigação (use termos como "possível", "indicando", "consistente com")
4. Ação imediata em curso
5. ETA de próximo update

Contexto do incidente:
- Componente/sistema: [preencha]
- Sintoma: [preencha — ex: latência acima de 8s, taxa de erro 23%]
- Hipótese atual: [preencha ou escreva "desconhecida" e peça para a IA sugerir baseado no sintoma]
- Ação tomada: [preencha]

🔄 Série B — Updates Intermediários (prompts B-01 a B-04)

🔄 Prompt B-01 — Update de progresso quando ainda não há solução

Escreva um update de status de incidente para ser enviado ao canal geral após [X] minutos desde o alerta inicial. O incidente ainda não foi resolvido. O objetivo do update é:
1. Mostrar progresso real ou descartamento de hipóteses
2. Revisar o ETA sem parecer que estamos perdidos
3. Manter confiança sem prometer o que não podemos entregar

Formato esperado:
📊 UPDATE [HORÁRIO] — [NOME DO SISTEMA]
Status: Investigando / Mitigando / Contornado parcialmente
O que descobrimos: [progresso técnico simplificado]
O que descartamos: [hipóteses eliminadas — aumenta credibilidade técnica]
Próximo passo: [ação específica em andamento]
ETA revisado: [novo tempo ou "em reavaliação — próximo update em X min"]

Dados:
- Tempo desde o incidente: [X min]
- O que foi investigado: [preencha]
- Hipóteses descartadas: [preencha ou "nenhuma ainda"]
- Ação atual: [preencha]
- Novo ETA: [preencha]

🔄 Prompt B-02 — Resposta ao diretor que quer saber “quando volta” em tempo real

Estou em um incidente crítico e um diretor está me pressionando diretamente por respostas. Preciso de uma resposta verbal ou por mensagem que:
- Seja honesta mas não revele que ainda não sabemos a causa raiz
- Transmita controle da situação
- Defina claramente o próximo check-in para tirar a pressão agora
- Seja curta — máximo 3 frases
- Não use "não sei" sem complementar com o que está sendo feito

Contexto:
- Pergunta do diretor: "[cole aqui o que ele perguntou]"
- Status real do incidente: [preencha honestamente]
- O que está sendo feito agora: [preencha]
- Quando você vai ter mais informações: [preencha — seja realista]

🔄 Prompt B-03 — Update quando a solução é “reiniciar o servidor” (comunicar sem parecer amador)

Preciso comunicar que a solução aplicada foi tecnicamente simples (reinício de serviço, rollback de deploy, limpeza de cache) de forma que transmita competência e processos, não descuido ou improviso.

Reescreva a resolução abaixo em linguagem que soe como processo deliberado e rastreado:

Solução real aplicada: [ex: reiniciamos o servidor de aplicação principal]
Por que isso funcionou (se souber): [ex: processo acumulou memória por 6 horas de operação contínua]
Garantias de que não vai repetir agora: [ex: monitoramento ajustado, alerta configurado]

Formato esperado: comunicado de resolução de máximo 5 linhas, tom técnico mas acessível, adequado para stakeholders de negócio e operações.

🔄 Prompt B-04 — Script para call de crise com múltiplos líderes (abertura e condução)

Crie um script de abertura para uma war room call de incidente com as seguintes características:
- Duração máxima do opening: 90 segundos
- Participantes: [liste os papéis presentes — ex: CTO, Gerente de Produto, DBA, DevOps Lead, Comercial]
- Objetivo da call: alinhar status, dividir frentes de trabalho e definir cadência de updates
- Tom: urgente mas organizado — não caótico

O script deve ter:
1. Abertura com status atual em 2 frases
2. Definição de papéis nesta call
3. Estrutura de updates: a cada X minutos, quem fala
4. Regra de escalada: quem decide se precisar de mudança de estratégia
5. Frase de fechamento que libera a equipe técnica para trabalhar

Contexto do incidente:
- Sistema afetado: [preencha]
- Tempo de incidente: [preencha]
- Impacto atual: [preencha]
- Principal hipótese em investigação: [preencha]

✅ Série C — Resolução e Encerramento (prompts C-01 a C-03)

✅ Prompt C-01 — Comunicado de resolução do incidente

Escreva um comunicado de encerramento de incidente que:
- Confirme a resolução e o horário de retorno à normalidade
- Agradeça brevemente a equipe sem ser bajulatório
- Mencione a causa raiz de forma técnica mas acessível (se já souber)
- Compromexa com RCA detalhado em 48h (sem especificar o que vai ter lá)
- Transmita aprendizado positivo, não culpa

Formato: máximo 6 linhas, adequado para Slack/Teams em canal geral.

Dados:
- Sistema afetado: [preencha]
- Horário de início: [preencha]
- Horário de resolução: [preencha]
- Causa raiz (se conhecida): [preencha ou "em análise"]
- Impacto total: [preencha]
- Equipe envolvida: [opcionalmente cite papéis, não nomes]

✅ Prompt C-02 — E-mail formal de encerramento para stakeholders externos e internos sênior

Escreva um e-mail formal de encerramento de incidente para ser enviado a stakeholders executivos internos e, se necessário, parceiros externos. O e-mail deve:
- Ter assunto: [RESOLVIDO] Incidente de [sistema] — [data]
- Estrutura: Resumo executivo (3 linhas) → Linha do tempo (bullets) → Impacto quantificado → Ação tomada → Próximos passos (RCA + preventivas)
- Tom: profissional, sem drama, sem autocomiseração
- Idioma: português formal brasileiro

Dados para preencher:
- Sistema: [preencha]
- Data/hora início: [preencha]
- Data/hora resolução: [preencha]
- Impacto (usuários afetados, transações perdidas, downtime em minutos): [preencha]
- Causa identificada: [preencha]
- Solução aplicada: [preencha]
- Ações preventivas comprometidas: [preencha]

✅ Prompt C-03 — Post-mortem completo com RCA estruturado (15 minutos de trabalho)

Você é um engenheiro de confiabilidade de site (SRE) sênior. Crie um documento de post-mortem completo e blameless baseado nos dados abaixo. O documento deve seguir o formato SRE do Google adaptado:

1. Sumário executivo (5 linhas)
2. Impacto (downtime, usuários afetados, impacto financeiro estimado)
3. Linha do tempo cronológica (bullets com horários)
4. Causa raiz (análise de 5 Whys — conduza você mesmo baseado nas informações fornecidas)
5. Fatores contribuintes
6. O que funcionou bem na resposta
7. O que pode melhorar
8. Action items com: descrição, responsável (papel), prazo e prioridade (P1/P2/P3)

Tom: blameless — o objetivo é aprender, não punir. Use linguagem como "o sistema falhou em" em vez de "o desenvolvedor X falhou em".

Dados do incidente:
- Sistema: [preencha]
- Data: [preencha]
- Duração: [preencha]
- Impacto: [preencha]
- Sequência de eventos observados: [cole os logs ou descreva em ordem cronológica]
- Solução aplicada: [preencha]
- Hipótese de causa raiz: [preencha]

🧠 Série D — Comunicação emocional e controle de narrativa (prompts D-01 a D-02)

🧠 Prompt D-01 — Resposta para quando te culpam antes do diagnóstico estar completo

Durante o incidente, [papel do acusador — ex: diretor comercial] disse diretamente que o problema foi causado por [acusação — ex: "aquela atualização que vocês fizeram ontem"]. Preciso de uma resposta que:
- Não confirme nem negue a acusação (ainda não há dados suficientes)
- Não seja defensiva nem submissa
- Redirecione o foco para a resolução em vez de apuração de culpa
- Seja curta — máximo 2 frases
- Preserve a relação e a posição profissional

Situação atual: [descreva brevemente o que você sabe e o que não sabe sobre a causa]

Gere 3 versões: (a) mais direta, (b) mais diplomática, (c) mais técnica/neutra.

🧠 Prompt D-02 — Retrospectiva de narrativa: como proteger a imagem da equipe depois do incidente

O incidente acabou, mas a percepção da diretoria sobre a equipe de TI ficou negativa. Preciso de uma estratégia de comunicação pós-crise para as próximas 2 semanas que:

1. Reconheça o incidente sem ampliar o drama
2. Demonstre maturidade operacional com dados de resposta (ex: MTTR, ações preventivas já tomadas)
3. Reposicione a equipe como proativa, não reativa
4. Proponha 1 iniciativa de melhoria que seja visível para o board mas executável internamente

Dados para contextualizar:
- Duração do incidente: [preencha]
- MTTR real: [preencha]
- Percepção negativa específica que circulou: [preencha]
- Capacidade real da equipe para melhorias: [preencha]

Entregue: (a) mensagem para reunião de alinhamento pós-incidente, (b) slide de 1 página com métricas positivas da resposta, (c) proposta de iniciativa preventiva para apresentar ao board.

👉 Brendon aconselha:

Comandos de atalho: o que digitar quando a resposta não saiu certa

✔️ Até aqui você já sabe: como usar os 12 prompts em cada fase do incidente; como calibrar o tom por público usando comandos de atalho; e que a solução pode ser simples — a comunicação é que não pode ser descuidada.

O que a IA não consegue fazer numa crise de TI (e o que usar no lugar)

A IA é um acelerador de comunicação, não um substituto de julgamento humano. Numa crise, ela entrega o texto — mas você entrega a decisão de o que, quando e para quem comunicar. Esses dois elementos juntos é que fazem a diferença entre uma crise gerenciada e uma narrativa fora de controle.

👀 Erros fatais (80% cometem o erro #1 nos primeiros 5 minutos)

• Erro 1 — “O silêncio que grita”: Não comunicar nada enquanto tenta encontrar a causa raiz completa. A ausência de comunicação é percebida como falta de controle — e alguém de outro departamento vai preencher esse silêncio com especulação. Correção: Envie o Prompt A-01 em até 3 minutos do detectamento, mesmo que só diga “estamos investigando”.
• Erro 2 — “A promessa suicida”: Dar um ETA definitivo e não revisá-lo. “Vai estar em 10 minutos” seguido de 2 horas de silêncio é mais danoso do que nunca ter dado um ETA. Correção: Use sempre ETAs revisáveis com comprometimento de update (“estimamos X, mas vamos atualizar em Y minutos”).
• Erro 3 — “O técnico que fala para o espelho”: Usar a mesma linguagem técnica para todos os públicos. O CFO não precisa saber do stack trace — ele precisa saber se o faturamento está sendo impactado. Correção: Use os prompts da Série A e B sempre com o campo [público] preenchido corretamente.
• Erro 4 — “A culpa antes da causa”: Aceitar ou sugerir culpados antes do RCA estar completo. Seja pressão externa ou impulso interno de justificar, atribuir culpa prematura compromete o diagnóstico e cria conflito desnecessário. Correção: Use o Prompt D-01 para redirecionar acusações sem confirmar nem negar.
• Erro 5 — “O post-mortem fantasma”: Prometer um post-mortem no comunicado de resolução e não entregá-lo. Isso é pior do que não prometer — demonstra falta de follow-through. Correção: Use o Prompt C-03 nas 24h seguintes ao incidente enquanto a memória está fresca. 15 minutos de trabalho.

Prompt fraco vs prompt forte — veja a diferença na prática

Este é o erro mais comum com qualquer IA: o prompt vago que todo mundo usa — e o prompt específico que entrega resultado real. A diferença não está na ferramenta. Está no que você digita.

Exemplo 01 — Alerta inicial de incidente

Me ajuda a comunicar que o sistema caiu.

Alerta de incidente para canal Slack. Sistema: checkout. Impacto: pedidos não estão sendo finalizados. Desde: 23h47. Responsável: time de infra. Próximo update: 20 min. Tom: urgente mas controlado. Máximo 6 linhas.

Exemplo 02 — Resposta para a diretoria em pressão direta

Como respondo meu chefe que quer saber quando o sistema vai voltar?

Meu diretor comercial perguntou: "você sabe o que causou isso?" Incidente ativo há 25 min. Ainda não tenho causa raiz. Estou testando se o problema é no banco ou na aplicação. Preciso de resposta de máximo 2 frases que compre 15 minutos sem mentir. Tom: confiante, não defensivo.

Exemplo 03 — Comunicar solução simples sem parecer amador

Comunica que resolvemos o problema reiniciando o servidor.

Resolução: reinício do processo de aplicação após identificar acúmulo de memória em processo rodando há 18h. Preciso comunicar isso soando como ação deliberada e rastreada, não como improviso. Inclua: o que foi aplicado, por que funcionou, e o que foi ajustado para monitoramento. Máximo 5 linhas, para gerentes de produto e operações.

Exemplo 04 — Post-mortem que ninguém vai ler

Escreva um post-mortem do incidente de ontem.

Post-mortem blameless formato SRE. Sistema: API de pagamentos. 14/04 22h-00h37. 400 transações afetadas. Logs: [cole os logs]. Causa: timeout no pool de conexões com o banco após pico de tráfego. Solução: aumento do pool + restart. Quero: sumário executivo, linha do tempo, 5 Whys, 3 action items com prazo e owner (papel, não nome). Tom blameless.

Exemplo 05 — Defesa quando te culpam prematuramente

Como me defendo quando o diretor diz que foi culpa do meu deploy?

O diretor disse: "foi esse deploy de hoje à tarde que causou". Meu deploy foi às 14h, o incidente ocorreu às 22h — correlação não confirmada. Não tenho RCA ainda. Preciso de resposta de 2 frases que: não confirme a acusação, não seja defensiva, redirecione para o diagnóstico, preserve relação. Gere versão direta e versão diplomática.

Ferramentas além do ChatGPT: quando usar cada uma para comunicação de crises

Glossário rápido: termos técnicos deste guia

Se algum termo do guia pareceu novo, este glossário resolve em 30 segundos — sem precisar sair da página.

Conclusão: o problema nunca foi a tecnologia 🙌

Incidentes em TI são inevitáveis. O que não é inevitável é perder credibilidade, queimar relacionamentos com a diretoria e passar horas reescrevendo comunicados toda vez que algo cai. Os 12 prompts deste guia existem para separar os dois problemas que sempre chegaram juntos: resolver o incidente e comunicar o incidente — porque tentar fazer os dois ao mesmo tempo, sob pressão máxima, é o que faz equipes brilhantes parecerem incompetentes.

O ROI aqui é duplo: você economiza em média 3 a 4 horas de trabalho por incidente em reescrita de comunicações, e você protege algo que vale mais do que qualquer hora — a percepção de competência e controle que define como a organização vai tratar a equipe de TI nos próximos projetos, nos próximos orçamentos, nas próximas negociações de headcount.

Comece com o Prompt A-01 no próximo incidente. Salve os prompts da Série B no seu telefone agora, antes que você precise deles. E use o Prompt C-03 nas 24h após qualquer incidente relevante — o post-mortem que você nunca fez é a oportunidade de aprendizado que a organização perdeu.

No mundo real, o herói de TI não é quem resolve mais rápido — é quem faz parecer que estava no controle o tempo todo. Jargão, ETA revisável e narrativa consistente são as ferramentas desse jogo. Agora você tem os prompts.

ps: obgda por chegar até aqui, é importante pra mim.