# Escalation Matrix > Escalation Matrix — Skill especializada para criação, gestão e otimização de matrizes de escalada para incidentes e problemas críticos. - Skill: `kursku/escalation-matrix` (Agent Skill) - Install (CLI): `npx skillmds@latest add kursku/escalation-matrix` - Raw SKILL.md: https://api.skillmd.com/api/skills/kursku/escalation-matrix/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - License: MIT - Author: kursku (https://skillmd.com/u/kursku) - Updated: 2026-09-08 - Page: https://skillmd.com/skills/kursku/escalation-matrix --- # Escalation Matrix Esta skill capacita o Claude a projetar, implementar e otimizar matrizes de escalada robustas, garantindo a resposta eficiente a incidentes e a resolução de problemas críticos. --- ## Keywords Matriz de Escalada, Gestão de Incidentes, SLAs, MTTR, Runbooks, Severidade de Impacto, Notificação de Crise, Suporte Nível 1, Suporte Nível 2, Suporte Nível 3, On-Call, Operações de TI, Problemas Críticos. --- ## Quick Start 1. **Categorize Eventos Críticos**: Identifique cenários que exigem escalada, como "Indisponibilidade de Serviço Crítico P1" ou "Reclamação de Cliente VIP com Risco de Churn". 2. **Defina Níveis de Severidade**: Padronize as classificações de impacto (ex: P1-Crítico, P2-Alto, P3-Médio) com critérios claros para cada. 3. **Mapeie Níveis de Resposta**: Associe cada nível de severidade a camadas de equipe (ex: N1 Suporte, N2 Engenharia, N3 Gerência) e seus tempos-limite de resposta. 4. **Configure Canais de Notificação**: Estabeleça métodos de alerta para cada nível (ex: PagerDuty para L2, Slack para L3, E-mail para stakeholders executivos). 5. **Documente e Treine**: Crie SOPs detalhados e realize sessões de treinamento para todas as equipes envolvidas na matriz. --- ## Core Workflows ### Workflow 1: Criação de Matriz de Escalada para Incidentes de TI de Alta Severidade (P1/P2) Este workflow detalha a construção de uma matriz para assegurar a rápida resposta e resolução de falhas sistêmicas críticas. 1. **Identificação de Gatilhos e Classificação de Severidade**: * **Gatilho Exemplo P1**: Indisponibilidade total do sistema de processamento de pagamentos. Critério: Mais de 50% das transações falhando por mais de 5 minutos. * **Gatilho Exemplo P2**: Degradação severa da performance do CRM. Critério: Tempo de resposta do CRM > 5 segundos para 30% dos usuários por mais de 15 minutos. * **Impacto P1**: Paralisação financeira, perda de receita imediata, alto risco reputacional. * **Impacto P2**: Redução da produtividade das equipes de vendas e suporte, insatisfação do cliente, risco de perda de oportunidades. 2. **Definição das Camadas de Escalada e Responsabilidades**: * **Nível 1 (L1 - Suporte/Monitoramento)**: Equipe de Operações de TI. * **Ação**: Confirmação do incidente via ferramentas de monitoramento (Datadog, Grafana), triagem inicial, verificação de runbooks básicos. * **Tempo para Resposta (SLA)**: P1: 5 minutos; P2: 15 minutos. * **Tempo para Escalada (SLO)**: P1: 10 minutos sem progresso; P2: 30 minutos sem progresso. * **Nível 2 (L2 - Especialistas Técnicos)**: Equipe de Engenharia de Software ou Infraestrutura (on-call). * **Ação**: Análise aprofundada da causa raiz, execução de runbooks avançados, aplicação de workarounds ou correções emergenciais. * **Tempo para Resposta (SLA)**: P1: 15 minutos; P2: 45 minutos. * **Tempo para Escalada (SLO)**: P1: 30 minutos sem resolução; P2: 90 minutos sem resolução. * **Nível 3 (L3 - Gerência de TI/Líderes)**: Gerente de Operações, Diretor de TI. * **Ação**: Alocação de recursos adicionais, tomada de decisões estratégicas (ex: rollback, failover para DR), comunicação com a alta direção e stakeholders externos. * **Tempo para Resposta (SLA)**: P1: 10 minutos; P2: 30 minutos. * **Tempo para Escalada (SLO)**: P1: 60 minutos sem resolução; P2: 180 minutos sem resolução. * **Nível 4 (L4 - Alta Direção/Comitê de Crise)**: CIO, CTO, CEO. * **Ação**: Aprovação de planos de contingência de alto custo/impacto, comunicação pública, gestão de crise corporativa. 3. **Configuração de Notificações e Canais**: * **L1 -> L2**: Sistema de on-call (PagerDuty/Opsgenie) com alerta sonoro no celular e chamada automática após 10 minutos (P1) ou 30 minutos (P2) de não reconhecimento/resolução. * **L2 -> L3**: Mensagem no canal Slack #incidents-p1-critical ou #incidents-p2-high para o grupo de Gerência de TI, seguido de e-mail automático após 30 minutos (P1) ou 90 minutos (P2). * **L3 -> L4**: Chamada telefônica direta pelo Gerente de Operações para CIO/CTO, e-mail para grupo de C-level, após 60 minutos (P1) ou 180 minutos (P2) sem resolução no L3. 4. **Criação de Canais de Comunicação Dedicados**: * **Interno**: Canal de Slack temporário para cada incidente P1/P2 (ex: #inc-20240725-001-erp-down), reunindo todas as equipes envolvidas. * **Externo**: Atualização de página de status pública (ex: status.suaempresa.com) a cada 30 minutos em caso de P1, com comunicação via e-mail para clientes afetados. ### Workflow 2: Gestão Proativa de Problemas Críticos de Cliente com Risco de Churn Este workflow foca em antecipar e resolver a insatisfação de clientes de alto valor antes que resultem em perda de negócios. 1. **Identificação de Gatilhos de Insatisfação Crítica**: * **Gatilho Exemplo**: Cliente VIP (ARR > R$ 500k) com CSAT abaixo de 3/5 ou 2+ chamados de suporte abertos simultaneamente por mais de 48 horas. * **Impacto**: Perda de receita recorrente, dano à reputação, impacto em métricas de retenção. 2. **Definição de Níveis de Escalada e Responsabilidades**: * **Nível 1 (L1 - Gerente de Conta/CSM)**: Customer Success Manager (CSM) ou Gerente de Conta. * **Ação**: Contato proativo com o cliente para entender a insatisfação, coordenação interna com equipes de suporte/produto para priorização. * **Tempo para Ação (SLA)**: 4 horas após o gatilho. * **Tempo para Escalada (SLO)**: 24 horas sem plano de ação ou progresso significativo. * **Nível 2 (L2 - Liderança de CS/Vendas)**: Diretor de Customer Success, VP de Vendas. * **Ação**: Intervenção direta com o cliente, oferta de soluções estratégicas ou compensações (ex: créditos, serviços adicionais), alocação de equipe técnica dedicada. * **Tempo para Ação (SLA)**: 8 horas após a escalada. * **Tempo para Escalada (SLO)**: 48 horas sem resolução satisfatória ou reversão da insatisfação. * **Nível 3 (L3 - C-level)**: CEO, COO, CCO. * **Ação**: Contato pessoal com o cliente, decisões de negócio de alto nível (ex: renegociação de contrato, mudanças na estratégia de produto), comunicação pública em caso de grande impacto. 3. **Estabelecimento de Prazos e Modos de Ação**: * **L1 -> L2**: Notificação automática via Salesforce Service Cloud ou Zendesk para o Diretor de CS após 24 horas sem um plano de ação documentado ou após o cliente expressar desejo de cancelar. * **L2 -> L3**: E-mail detalhado do Diretor de CS para o C-level com histórico do cliente, ações tomadas e risco de churn, acionado após 48 horas sem reversão da insatisfação no L2. 4. **Documentação e Acompanhamento Contínuo**: * Todos os detalhes da escalada, interações com o cliente e planos de ação devem ser registrados no CRM (ex: Salesforce) com campos específicos para "Status de Escalada" e "Risco de Churn". * Reunião semanal de "Revisão de Clientes Críticos" com a liderança de CS e Vendas para acompanhar o progresso dos clientes escalados. --- ## Templates ### Template de Matriz de Escalada de Incidentes de TI ``` | Gatilho do Incidente | Severidade | Impacto no Negócio | Tempo p/ Resposta (SLA) | Tempo p/ Resolução (SLO) | Nível 1 - Responsável/Ação | Nível 2 - Responsável/Ação | Nível 3 - Responsável/Ação | Métodos de Notificação | |----------------------|------------|--------------------|-------------------------|--------------------------|----------------------------|----------------------------|----------------------------|------------------------| | Falha total de Autenticação | P1 (Crítico) | Indisponibilidade de acesso para TODOS os usuários. Perda de receita imediata. | 5 minutos | 30 minutos | Analista L1: Triagem inicial, coleta logs. | Engenheiro Backend Sênior: Análise causa, rollback/patch. | Gerente de Operações: Decisão de failover, comunicação executiva. | PagerDuty, Slack @oncall-ops, SMS, Telefone | | Lentidão crítica do Banco de Dados | P2 (Alto) | Degradação de performance > 70% em funcionalidades chave. Experiência do usuário severamente afetada. | 15 minutos | 120 minutos | Analista L1: Verificação de métricas DB, reinício de serviços não-críticos. | DBA Sênior: Otimização de queries, escalonamento de recursos DB. | Diretor de TI: Aprovação de infraestrutura adicional, comunicação interna. | Slack #incidents-p2, E-mail p/ ti-lideranca | | Erros intermitentes na API de Terceiros | P3 (Médio) | 15% das integrações com parceiros falham. Impacto em relatórios e automações. | 30 minutos | 240 minutos | Analista L1: Validação de credenciais, teste de conectividade. | Desenvolvedor Backend: Debugging da integração, contato com terceiro. | Coordenador de Suporte: Acompanhamento, definição de workaround. | E-mail p/ equipe-dev, Slack #integracoes | ``` ### Template de Notificação de Escalada (Email) ``` Assunto: [URGENTE] ESCALADA CRÍTICA: Incidente P1 - Indisponibilidade do Sistema de Pagamentos (ID: INC-P1-20240725-001) Prezados, Informamos que o incidente de criticidade P1 "Indisponibilidade total do Sistema de Pagamentos" (ID: INC-P1-20240725-001) atingiu o tempo limite de resolução para a equipe de Nível 2. A escalada para o Nível 3 (Gerência de Operações) foi acionada automaticamente às 14:35 BRT. O impacto atual é a paralisação completa das transações financeiras e a impossibilidade de processar vendas, resultando em perda de receita estimada em R$ 10.000/hora. Solicitamos o apoio imediato da Gerência de Operações para alocação de recursos adicionais, tomada de decisões estratégicas (ex: ativação de plano de contingência secundário) e coordenação da comunicação executiva. **Próxima atualização em 15 minutos (14:50 BRT).** Por favor, juntem-se ao canal de comunicação dedicado no Slack: #inc-20240725-001-pagamentos Atenciosamente, Equipe de Operações de TI [Nome do Contato de Plantão L2] [Telefone de Contato] ``` --- ## Checklist - [x] Gatilhos de escalada claramente definidos para cada cenário crítico. - [x] Níveis de severidade (P1, P2, P3...) padronizados e compreendidos por todas as equipes. - [x] Responsáveis por cada nível de escalada nomeados e com contatos atualizados (incluindo on-call). - [x] Tempos de resposta (SLA) e resolução (SLO) estabelecidos e realistas para cada nível de severidade. - [x] Métodos de notificação (automáticos e manuais) configurados, testados e redundantes. - [x] Canais de comunicação dedicados para cada tipo de escalada (Slack, e-mail, telefone, ferramenta de on-call). - [x] Procedimentos de comunicação com stakeholders internos e externos (clientes, imprensa) documentados. - [x] Rotinas de treinamento e simulação da matriz de escalada (tabletop exercises) realizadas periodicamente. - [x] Processo de revisão pós-incidente (post-mortem) estabelecido para melhoria contínua da matriz. - [x] Ferramentas de suporte (ticketing, monitoramento, pager) integradas à matriz de escalada. --- ## Métricas de Referência | Métrica | Benchmark | Meta | |------------------------------|----------------------|----------------------| | MTTR (Mean Time To Resolve) P1 | < 60 minutos | < 30 minutos | | Tempo Médio de Escalada (TME) | < 15 minutos | < 10 minutos | | Taxa de Re-escalada | < 5% | < 2% | | % de Incidentes Resolvidos no Nível 1 | > 60% | > 75% | | Número de Escaladas P1/mês | < 5 | < 2 | | CSAT de Clientes Escalados | > 7 (escala 1-10) | > 8 (escala 1-10) | --- ## Erros Comuns 1. **Gatilhos Ambíguos**: A ausência de critérios claros para acionar uma escalada leva a decisões inconsistentes ou tardias. * **Como evitar**: Em vez de "Escalar se o problema for grave", defina "Escalar se o serviço essencial estiver 50% indisponível por mais de 5 minutos, afetando mais de 20% dos usuários". 2. **Contatos Desatualizados**: Listas de contato e responsáveis on-call desatualizadas resultam em escaladas para pessoas erradas ou indisponíveis. * **Como evitar**: Implemente uma rotina de revisão mensal da matriz, incluindo telefones e e-mails, e utilize ferramentas de on-call que gerenciem agendas e substituições (ex: PagerDuty, Opsgenie). 3. **Falta de Ownership Claro entre Níveis**: A responsabilidade de um incidente se perde entre os níveis, com equipes esperando que outras resolvam. * **Como evitar**: Para cada nível de escalada, defina explicitamente as ações esperadas e os limites de sua responsabilidade. Exemplo: "L1 é responsável pela triagem e execução de runbooks básicos. Se o runbook não resolver em 10 minutos, o L2 assume a propriedade completa da investigação." --- ## Dicas Avançadas 1. **Escalada Preditiva com IA/ML**: Utilize algoritmos de Machine Learning para analisar dados históricos de incidentes e telemetria, prevendo a probabilidade de um problema escalar antes que atinja os gatilhos definidos. * **Exemplo Prático**: Um modelo pode identificar um padrão de uso de CPU e latência de rede que, em 80% dos casos passados, levou a um incidente P1, acionando um alerta de pré-escalada para o Nível 2 antes mesmo do impacto ser sentido pelos usuários. 2. **Matrizes Dinâmicas por Contexto**: Crie sub-matrizes de escalada para diferentes serviços, clientes ou períodos críticos (ex: Black Friday, fechamento de mês), ajustando SLAs, SLOs e equipes envolvidas. * **Exemplo Prático**: Para o serviço de e-commerce durante a Black Friday, o SLA de resposta para um incidente P1 pode ser reduzido de 5 para 2 minutos, e o Nível 3 inclui o Diretor Comercial e o CEO diretamente no ciclo de notificação inicial. 3. **Simulações de Desastre e Tabletop Exercises**: Realize simulações periódicas de cenários de falha crítica (ex: queda de datacenter, ataque DDoS) envolvendo todos os níveis da matriz, testando a comunicação, tomada de decisão e eficácia dos runbooks. * **Exemplo Prático**: Uma simulação de "falha total do provedor de nuvem" pode revelar gargalos na comunicação entre Níveis 2 e 3 e a necessidade de um canal de comunicação de emergência fora da infraestrutura principal. 4. **Feedback Loop Contínuo via Post-Mortem Automatizado**: Integre os resultados de análises post-mortem (causa raiz, ações corretivas) diretamente na revisão da matriz de escalada, ajustando gatilhos e responsabilidades automaticamente. * **Exemplo Prático**: Após um incidente P2 onde o tempo de escalada do L1 para o L2 foi 20% maior que o SLO, o sistema propõe uma revisão do critério de escalada ou um treinamento adicional para a equipe L1 na execução de um runbook específico. 5. **Integração com Ferramentas de Orquestração de Resposta**: Conecte a matriz de escalada a ferramentas de automação que disparam ações corretivas (ex: reiniciar serviço, reverter deployment, isolar componente) ao atingir um determinado nível. * **Exemplo Prático**: Quando um incidente P1 é escalado para o Nível 2, a ferramenta de orquestração (ex: Rundeck, Ansible Tower) pode automaticamente acionar um runbook para tentar um rollback do último deployment ou provisionar recursos adicionais na nuvem.