Como usar este artigo
Cada prompt funciona com qualquer modelo moderno (ChatGPT 4o, Claude 4.5+, Gemini 2.5+). Copia o prompt para a janela de chat e substitui o conteúdo entre [colchetes] pelo teu contexto. Se usares o ChatGPT da empresa com dados sensíveis, confirma a política de privacidade. Para incidentes com dados pessoais, usa modelos com data residency na UE.
Não substituem julgamento humano. Substituem trabalho repetitivo de comunicação, classificação e estruturação. Quem decide és tu.
Dica de método. Cria uma pasta no teu computador chamada "Incident playbook". Cola estes 10 prompts e adapta a tua versão por cliente ou produto. Em 2 semanas tens uma colecção privada que vale ouro à equipa.
1
Triagem rápida
És um service desk agent ITIL com 10 anos de experiência.
Vou-te dar a descrição que um utilizador acabou de registar um incidente. Quero que classifiques este incidente em três dimensões:
1. CATEGORIA (escolhe uma): hardware | software | rede | acesso | segurança | base de dados | aplicacional | outro
2. SEVERIDADE (escolhe uma):
- Crítica (serviço indisponível para muitos utilizadores)
- Alta (impacto significativo num grupo)
- Média (impacto num utilizador, sem alternativas)
- Baixa (inconveniente, com alternativas)
3. URGÊNCIA (escolhe uma): imediata | hoje | esta semana | quando puder
Devolve APENAS no formato:
Categoria: ...
Severidade: ...
Urgência: ...
Justificação (2 linhas): ...
Descrição do utilizador:
[COLAR DESCRIÇÃO AQUI]
Caso real: num cliente com 200+ tickets diários, este prompt eliminou disputas entre agentes sobre "P2 ou P3?". A consistência subiu e o tempo médio de classificação caiu de 90 para 25 segundos.
2
Comunicação para utilizadores
Vou-te dar a descrição técnica de um incidente em curso. Escreve uma mensagem clara para os utilizadores afectados, em português europeu.
Regras:
- Sem jargão técnico (substitui termos como "DNS", "load balancer", "API" por explicações simples)
- Tom calmo, factual, sem desculpabilização excessiva
- 4 a 6 linhas no máximo
- Inclui: o que está a acontecer (em palavras de utilizador), desde quando, o que estamos a fazer, hora da próxima actualização, alternativa enquanto resolvem (se houver)
Não inclui:
- Promessas de tempo de resolução que não são certas
- Atribuição de culpa a fornecedores
- Pedidos de desculpa repetidos
Descrição técnica:
[COLAR DESCRIÇÃO AQUI]
Hora de início: [XX:XX]
Caso real: numa empresa de retalho, o tempo médio entre detecção e primeira comunicação aos utilizadores caiu de 25 para 4 minutos. As reclamações ao service desk durante o próprio incidente reduziram-se em 60%.
3
Comunicação para administração
És analista de service management. Vou-te dar dados de um incidente. Escreve um status report executivo para a administração (CEO, CTO, COO).
Estrutura obrigatória:
1. ESTADO ACTUAL (1 linha, máximo 15 palavras)
2. IMPACTO NEGÓCIO (3 bullets: utilizadores afectados, serviços críticos parados, perda estimada se aplicável)
3. CAUSA SUSPEITA (1 frase, com nível de confiança: alto/médio/baixo)
4. ACÇÕES EM CURSO (3 bullets máximo)
5. PRÓXIMA ACTUALIZAÇÃO (hora exacta)
Tom: profissional, sem alarme, sem minimização. 200 palavras no total. Sem perguntas, sem opções, sem "queremos a vossa orientação". Apenas factos e plano.
Dados do incidente:
[COLAR TIMELINE E FACTOS]
Caso real: num banco, este prompt substituiu uma chamada de 30 minutos com o COO durante um incidente significativo. Mensagem foi por email às 14:22, ele respondeu "claro, sigam" às 14:24, equipa voltou ao foco.
4
Plano de acção em 5 minutos
És um incident commander experiente. Tens 5 minutos para criar um plano de acção priorizado para este incidente antes de chamar a equipa.
Vou-te dar a descrição. Devolve:
CONTAINMENT (acções para parar o sangramento, primeiros 15 min):
- ...
- ...
INVESTIGAÇÃO (paralelo ao containment):
- Quem investiga: [função]
- Logs a verificar: ...
- Sistemas a inspecionar: ...
COMUNICAÇÃO:
- Quem informar: [stakeholders]
- Cadência: ...
ESCALAÇÃO:
- Em que condições escalo: ...
- A quem escalo: ...
CRITÉRIO DE RESOLUÇÃO:
- ...
Sê específico. Sem "investigar a fundo" ou "comunicar adequadamente". Acções concretas, com responsável e prazo onde fizer sentido.
Descrição do incidente:
[DESCRIÇÃO]
Caso real: numa SaaS portuguesa, este prompt deu estrutura ao primeiro grande incidente de uma analista promovida a incident commander dois dias antes. Em vez de improvisar, leu o output em 90 segundos e abriu a war room com plano.
5
Análise de impacto cross-sistema
Vou-te dar a descrição de um sistema com incidente. Tens conhecimento profundo de arquitecturas IT modernas.
Lista TODOS os sistemas e serviços que provavelmente estão a ser afectados, mesmo indirectamente.
Para cada um:
- Nome do sistema
- Tipo de impacto (total, parcial, lentidão, intermitente)
- Nível de confiança (alto, médio, baixo)
- Como confirmar (que verificar)
Pensa em:
- Sistemas downstream que consomem dados deste
- Integrações via API
- Jobs batch que dependem
- Relatórios que vão falhar
- Processos de negócio interrompidos
- Sistemas que precisem de re-sync depois de resolver
Sistema com incidente:
[NOME E DESCRIÇÃO]
Caso real: num cliente de logística, este prompt revelou impacto em 7 sistemas além do óbvio. Evitou que um incidente parecesse resolvido enquanto 3 jobs nocturnos continuavam a falhar silenciosamente.
6
Lessons learned automáticas
Vou-te dar a timeline completa de um incidente já resolvido. Faz uma análise de lessons learned em 5 dimensões:
1. DETECÇÃO - quanto tempo levou a detectar? Era inevitável esse atraso? Como melhorar?
2. RESPOSTA - a equipa actuou como deveria? Onde houve fricção?
3. COMUNICAÇÃO - stakeholders ficaram informados? Faltou alguém?
4. RESOLUÇÃO - causa raiz foi atacada ou só sintomas?
5. PREVENÇÃO - este incidente pode repetir-se? O que evita?
Para cada dimensão, devolve:
- O que correu bem (1 linha)
- O que pode melhorar (1 linha)
- Acção recomendada com responsável e prazo
Sem culpas a pessoas. Foca em sistema e processos.
Timeline do incidente:
[COLAR TIMELINE]
Caso real: numa equipa pequena sem incident manager dedicado, este prompt criou rigor analítico onde antes havia "blame storming". Rotação semanal de quem aplica acabou por treinar todos em pensamento sistémico.
7
Geração de KB article
Vou-te dar a descrição da resolução de um incidente. Cria um artigo de Knowledge Base.
Estrutura obrigatória:
- TÍTULO: pergunta que um utilizador faria, sem tecniquês
- SINTOMAS: como o utilizador detecta o problema (3 a 5 bullets)
- CAUSA: explicação curta, accessível
- SOLUÇÃO RÁPIDA: passos numerados que utilizador pode tentar (3 a 5 passos)
- QUANDO ESCALAR: critérios para abrir ticket ao service desk
- PALAVRAS-CHAVE: 5 a 8 termos para indexação (incluindo erros típicos do utilizador, ex: "não consigo entrar", "página em branco")
Tom: prestável, sem condescendência. PT-PT.
Resolução técnica:
[DESCRIÇÃO]
Caso real: num service desk universitário, em 2 meses 30 KB articles gerados por este prompt desviaram 18% dos tickets repetitivos para self-service. Equipa ganhou tempo para os casos complexos.
8
Detecção de padrão (candidatos a problemas)
Vou-te dar a lista dos últimos 30 incidentes resolvidos. Faz análise de padrões para identificar candidatos a problemas no sentido ITIL (causa raiz subjacente).
Devolve:
- AGRUPAMENTOS (se vês incidentes que podem ter causa comum)
- CANDIDATOS A PROBLEMAS (3 a 5, prioritizados por impacto + frequência)
- Para cada candidato a problema:
- Hipótese de causa raiz
- Incidentes que suportam esta hipótese (referência por id)
- Que dados extra precisarias para confirmar
- Custo estimado de não resolver (em incidentes/mês)
Não inventes ligações. Se não vês padrão claro, diz-me.
Lista dos 30 incidentes (cada linha: id | data | título | sistema | resolução):
[COLAR LISTA]
Caso real: num retalhista, este prompt detectou que 11 incidentes aparentemente "diferentes" eram todos sintoma de patch em falha numa cron task. Resolução de 1 problema fechou a porta a 11 incidentes/mês.
9
Notificação NIS2 (24h)
És responsável de cibersegurança a redigir notificação obrigatória sob NIS2 para a autoridade competente (CNCS em Portugal).
Vou-te dar dados do incidente. Compõe a notificação inicial obrigatória nas primeiras 24h após detecção.
Estrutura obrigatória (alinhada com guidelines NIS2):
1. IDENTIFICAÇÃO DA ENTIDADE: [DEIXAR PLACEHOLDER]
2. RESUMO EXECUTIVO DO INCIDENTE (3 linhas, factual)
3. INDICADORES CONHECIDOS:
- Hora de detecção
- Hora estimada de início (se diferente)
- Sistemas afectados
- Tipo de incidente (acesso não autorizado, ransomware, DoS, exfiltração, outro)
4. IMPACTO INICIAL ESTIMADO:
- Utilizadores afectados (intervalo)
- Serviços essenciais interrompidos
- Existe potencial impacto cross-fronteiriço? (sim, não, desconhecido)
5. ACÇÕES EM CURSO
6. PRÓXIMA ACTUALIZAÇÃO (compromisso 72h obrigatório)
Tom: factual, não-alarmista, sem especulação. Se algo é desconhecido, escreve "Em apuramento".
Dados do incidente:
[DESCRIÇÃO]
Contexto importante: nem todos os incidentes requerem notificação NIS2. O artigo NIS2 e ITIL explica em detalhe quando a notificação é obrigatória, o mapeamento por prática e o roadmap de 90 dias para chegar a conformidade.
10
Pós-mortem blameless
Vou-te dar a timeline completa de um incidente significativo. Cria um pós-mortem blameless completo.
Estrutura:
1. RESUMO (3 a 4 linhas, factual)
2. IMPACTO (utilizadores afectados, duração, serviços, custo se conhecido)
3. TIMELINE (formato Hora | Quem | O que aconteceu | O que sabíamos)
4. CAUSA RAIZ (técnica + contributing factors organizacionais)
5. O QUE CORREU BEM (3 a 5 itens, sim, mesmo num incidente mau há coisas boas)
6. O QUE CORREU MENOS BEM (3 a 5 itens, sem nomes de pessoas)
7. ACÇÕES (cada uma com responsável e prazo, distribuídas em: prevenção, detecção, resposta, comunicação)
8. SE ACONTECESSE OUTRA VEZ: o que faríamos diferente?
Princípios obrigatórios:
- Zero nomes de pessoas em contexto negativo. Refere funções (ex: "o operador on-call") não pessoas.
- Linguagem que assume boa intenção
- Foca em sistemas e processos, não em decisões individuais
Timeline:
[COLAR]
Caso real: numa empresa de e-commerce, este prompt deu estrutura blameless onde antes havia procura de culpados. Em três meses, equipa começou a reportar incidentes mais cedo (sem medo de represálias) e o tempo médio de resolução baixou 35%.
Um caso real onde estes prompts mudaram um turno
Numa empresa de logística com 400 colaboradores, o service desk tinha um turno especialmente difícil: domingo à tarde, com apenas dois operadores. Era comum entrar segunda-feira de manhã com 30+ tickets pendentes, vários major escondidos no meio dos triviais, comunicação atrasada e duas pessoas exaustas.
A equipa adoptou estes prompts num domingo de Maio. Ao final desse turno, com os mesmos dois operadores, a fila estava em 8 tickets, todos os Major Incidents tinham comunicação aos utilizadores em <5 minutos, e o relatório para a administração saiu às 18h em vez das 23h. Não foi a IA a resolver os incidentes. Foi a IA a tirar do ombro dos operadores o trabalho repetitivo de classificação, comunicação e estruturação para libertar foco para o que requer julgamento humano.
Esse é o ponto. Estes prompts não substituem analistas de service desk. Substituem o pior do trabalho deles, o que esgota e que produz erros. O que sobra é mais interessante.
Recursos para complementar
Para tirar partido total destes prompts, podes querer:
Gestão de incidentes ITIL
Página completa com framework, fluxos e boas práticas para a prática de gestão de incidentes.
NIS2 e ITIL: como cumprir
Mapa completo entre exigências NIS2 e práticas ITIL, com roadmap de 90 dias para conformidade.
252 templates ITSM
Word e Excel, em PT e EN. Inclui templates de RACI, runbook de incidente, plano de continuidade e mais.
Análise de causa raiz
Métodos de RCA (5 Whys, Ishikawa, Kepner-Tregoe) explicados com exemplos práticos.
Precisa de estruturar a gestão de incidentes na sua organização?
Posso ajudar a desenhar o processo, treinar a equipa e implementar o playbook adaptado ao seu contexto.
Falar com João Rodrigues