--- name: cs-customer-escalation description: Empacota uma escalação para Devs, Produto ou Davidson com contexto completo. Use quando um bug precisa de atenção além do suporte normal, vários clientes reportam o mesmo problema, um cliente está ameaçando cancelar, ou um problema ficou sem resolução além do SLA. / Package an escalation for engineering, product, or leadership with full context. Use when a bug needs engineering attention beyond normal support, multiple customers report the same issue, a customer is threatening to churn, or an issue has sat unresolved past its SLA. argument-hint: " [nome do cliente]" --- # /cs-customer-escalation > Se encontrar integrações não configuradas, verifique [CONNECTORS.md](../../CONNECTORS.md). Empacotar um problema de suporte em um briefing de escalação estruturado para Devs, Produto ou Davidson (liderança). Coleta contexto, estrutura passos de reprodução, avalia impacto de negócio e identifica o alvo de escalação correto. ## Usage ``` /cs-customer-escalation [nome do cliente ou conta] ``` Exemplos: - `/cs-customer-escalation API retornando erros 500 intermitentemente para conta Acme` - `/cs-customer-escalation Exportação de dados com linhas faltando — 3 clientes reportaram essa semana` - `/cs-customer-escalation Loop de login SSO afetando todos os clientes Enterprise` - `/cs-customer-escalation Cliente ameaçando cancelar por falta de feature de audit log` ## Workflow ### 1. Entender o Problema Analisar o input e determinar: - **O que está quebrado ou é necessário**: O problema técnico ou de produto central - **Quem está afetado**: Cliente(s) específico(s), segmento ou todos os usuários - **Por quanto tempo**: Quando começou? Há quanto tempo o cliente está esperando? - **O que foi tentado**: Qualquer troubleshooting ou workarounds tentados - **Por que escalar agora**: O que torna isso necessário além do suporte normal Usar os critérios "Quando Escalar vs. Tratar no Suporte" abaixo para confirmar que a escalação é warranted. ### 2. Coletar Contexto Reunir informações relevantes de fontes disponíveis: - **int-evo-crm** (`/int-evo-crm`): Tickets relacionados, timeline de comunicações, troubleshooting anterior - **int-evo-crm** (contexto de conta): Detalhes da conta, contatos principais, escalações anteriores - **discord-get-messages** (`/discord-get-messages`): Discussões internas sobre esse problema, relatos similares de outros clientes - **int-whatsapp** (`/int-whatsapp`): Discussões em grupos de suporte ou alertas de clientes - **int-linear-review** (`/int-linear-review`) ou **Linear MCP**: Bug reports ou feature requests relacionados, status de engineering - **Notion MCP**: Problemas conhecidos ou workarounds, documentação relevante ### 3. Avaliar Impacto de Negócio Usando as dimensões de impacto abaixo, quantificar: - **Amplitude**: Quantos clientes/usuários afetados? Crescendo? - **Profundidade**: Bloqueado vs. inconvenienciado? - **Duração**: Há quanto tempo está acontecendo? - **Receita**: ARR em risco? Negociações pendentes afetadas? - **Pressão de tempo**: Há prazo? ### 4. Determinar Alvo de Escalação Usando os níveis de escalação abaixo, identificar o alvo correto: Suporte Tier 2, Devs, Produto, Segurança ou Davidson. ### 5. Estruturar Passos de Reprodução (para bugs) Se o problema é um bug, seguir as boas práticas de passos de reprodução abaixo para documentar repro steps claros com detalhes de ambiente e evidências. ### 6. Gerar Briefing de Escalação ``` ## ESCALAÇÃO: [Resumo em uma linha] **Severidade:** [Crítico / Alto / Médio] **Time alvo:** [Devs / Produto / Segurança / Davidson] **Reportado por:** [Seu nome/time] **Data:** [Data de hoje] ### Impacto - **Clientes afetados:** [Quem e quantos] - **Impacto no workflow:** [O que eles não conseguem fazer] - **Receita em risco:** [Se aplicável] - **Tempo na fila:** [Há quanto tempo é um problema] ### Descrição do Problema [Descrição clara e concisa do problema — 3-5 frases] ### O Que Foi Tentado 1. [Passo de troubleshooting e resultado] 2. [Passo de troubleshooting e resultado] 3. [Passo de troubleshooting e resultado] ### Passos de Reprodução [Se aplicável — seguir o formato abaixo] 1. [Passo] 2. [Passo] 3. [Passo] Esperado: [X] Atual: [Y] Ambiente: [Detalhes] ### Comunicação com o Cliente - **Última atualização ao cliente:** [Data e o que foi comunicado] - **Expectativa do cliente:** [O que esperam e para quando] - **Risco de escalação:** [Vão escalar mais se não resolvido até X?] ### O Que é Necessário - [Pedido específico — "investigar causa raiz", "priorizar fix", "tomar decisão de produto sobre X", "aprovar exceção para Y"] - **Prazo:** [Quando precisam de resolução ou atualização] ### Contexto de Suporte - [Tickets relacionados ou links] - [Threads de discussão interna] - [Documentação ou logs] ``` ### 7. Oferecer Próximos Passos Após gerar a escalação: - "Quer que eu poste isso no canal Discord do time alvo?" - "Devo atualizar o cliente com uma resposta interina?" - "Quer que eu configure um lembrete de acompanhamento para verificar isso?" - "Devo redigir uma atualização para o cliente com o status atual?" --- ## Quando Escalar vs. Tratar no Suporte ### Tratar no Suporte Quando: - O problema tem uma solução documentada ou workaround conhecido - É um problema de configuração ou setup que você pode resolver - O cliente precisa de orientação ou treinamento, não de um fix - O problema é uma limitação conhecida com alternativa documentada - Tickets similares anteriores foram resolvidos no nível de suporte ### Escalar Quando: - **Técnico**: Bug confirmado que precisa de correção de código, investigação de infraestrutura necessária, corrupção ou perda de dados - **Complexidade**: Problema além da capacidade de diagnóstico do suporte, requer acesso que o suporte não tem, envolve implementação customizada - **Impacto**: Vários clientes afetados, sistema em produção fora do ar, integridade de dados em risco, preocupação de segurança - **Negócio**: Cliente de alto valor em risco, breach de SLA iminente ou ocorrido, cliente solicitando envolvimento executivo - **Tempo**: Problema aberto além do SLA, cliente esperando por tempo irrazoável, canais normais de suporte não progredindo - **Padrão**: Mesmo problema reportado por 3+ clientes, problema recorrente que supostamente foi corrigido, severidade crescente ao longo do tempo ## Níveis de Escalação (Evolution Context) ### Suporte → Suporte Sênior (Escalação Interna) **De:** Suporte frontline **Para:** Suporte sênior / especialistas técnicos de suporte **Quando:** Problema requer investigação mais profunda, conhecimento especializado de produto, ou troubleshooting avançado **O que incluir:** Resumo do ticket, passos já tentados, contexto do cliente ### Suporte Sênior → Devs (Engineering) **De:** Suporte sênior **Para:** Time de Devs (área de produto relevante) **Quando:** Bug confirmado, problema de infraestrutura, precisa de mudança de código, requer investigação em nível de sistema **O que incluir:** Passos completos de reprodução, detalhes de ambiente, logs ou mensagens de erro, impacto de negócio, timeline do cliente ### Suporte Sênior → Produto **De:** Suporte sênior **Para:** Product management **Quando:** Gap de feature causando dor ao cliente, decisão de design necessária, workflow não corresponde às expectativas do cliente, necessidades concorrentes de clientes requerem priorização **O que incluir:** Caso de uso do cliente, impacto de negócio, frequência da solicitação, pressão competitiva (se conhecida) ### Qualquer Nível → Segurança **De:** Qualquer nível de suporte **Para:** Time de segurança **Quando:** Potencial exposição de dados, acesso não autorizado, relatório de vulnerabilidade, preocupação de compliance (LGPD, etc.) **O que incluir:** O que foi observado, quem/o que está potencialmente afetado, medidas de contenção imediata tomadas, avaliação de urgência **Nota:** Escalações de segurança ignoram a progressão normal de níveis — escalar imediatamente independente do seu nível ### Qualquer Nível → Davidson (Liderança) **De:** Qualquer nível (geralmente suporte sênior ou gerente) **Para:** Davidson **Quando:** Cliente de alta receita ameaçando cancelar, breach de SLA em conta crítica, decisão cross-funcional necessária, exceção à política necessária, risco de PR ou legal **O que incluir:** Contexto completo de negócio, receita em risco, o que foi tentado, decisão ou ação específica necessária, prazo ## Avaliação de Impacto de Negócio Ao escalar, quantificar o impacto onde possível: ### Dimensões de Impacto | Dimensão | Perguntas a Responder | |-----------|-------------------| | **Amplitude** | Quantos clientes/usuários são afetados? Está crescendo? | | **Profundidade** | Qual é a gravidade do impacto? Bloqueados vs. inconvenienciados? | | **Duração** | Há quanto tempo está acontecendo? Quando se torna crítico? | | **Receita** | Qual é o ARR em risco? Há negociações pendentes afetadas? | | **Reputação** | Pode se tornar público? É um cliente de referência? | | **Contratual** | SLAs estão sendo violados? Há obrigações contratuais? | ### Resumo de Severidade - **Crítico**: Produção fora do ar, dados em risco, brecha de segurança, ou vários clientes de alto valor afetados. Precisa de atenção imediata. - **Alto**: Funcionalidade principal quebrada, cliente-chave bloqueado, SLA em risco. Precisa de atenção no mesmo dia. - **Médio**: Problema significativo com workaround, impacto importante mas não urgente. Precisa de atenção nessa semana. ## Escrevendo Passos de Reprodução Bons passos de reprodução são a coisa mais valiosa numa escalação de bug. Seguir essas práticas: 1. **Começar de um estado limpo**: Descrever o ponto de partida (tipo de conta, configuração, permissões) 2. **Ser específico**: "Clicar no botão Exportar no canto superior direito da página Dashboard" não "tentar exportar" 3. **Incluir valores exatos**: Usar inputs específicos, datas, IDs — não "inserir algum dado" 4. **Anotar o ambiente**: Browser, OS, tipo de conta, feature flags, nível de plano 5. **Capturar a frequência**: Sempre reproduzível? Intermitente? Apenas sob certas condições? 6. **Incluir evidências**: Screenshots, mensagens de erro (texto exato), network logs, console output 7. **Anotar o que foi descartado**: "Testado no Chrome e Firefox — mesmo comportamento" "Não é específico da conta — reproduzido na conta de teste" ## Cadência de Acompanhamento Após Escalação Não escalar e esquecer. Manter a titularidade do relacionamento com o cliente. | Severidade | Acompanhamento Interno | Atualização ao Cliente | |----------|-------------------|-----------------| | **Crítico** | A cada 2 horas | A cada 2-4 horas (ou por SLA) | | **Alto** | A cada 4 horas | A cada 4-8 horas | | **Médio** | Diariamente | A cada 1-2 dias úteis | ### Ações de Acompanhamento - Verificar com o time receptor o progresso - Atualizar o cliente mesmo sem novas informações ("Ainda investigando — aqui está o que sabemos até agora") - Ajustar severidade se a situação muda (melhor ou pior) - Documentar todas as atualizações no ticket para trilha de auditoria - Fechar o loop quando resolvido: confirmar com o cliente, atualizar rastreamento interno, capturar aprendizados ## De-escalação Nem toda escalação permanece escalada. De-escalar quando: - A causa raiz é encontrada e é um problema resolvível pelo suporte - Um workaround é encontrado que desbloqueia o cliente - O problema se resolve por conta própria (mas ainda documentar causa raiz) - Novas informações mudam a avaliação de severidade Ao de-escalar: - Notificar o time para o qual escalou - Atualizar o ticket com a resolução - Informar o cliente sobre a resolução - Documentar o que foi aprendido para referência futura ## Boas Práticas de Escalação 1. Sempre quantificar o impacto — escalações vagas são despriorizadas 2. Incluir passos de reprodução para bugs — isso é a coisa #1 que os Devs precisam 3. Ser claro sobre o que você precisa — "investigar" vs. "corrigir" vs. "decidir" são pedidos diferentes 4. Definir e comunicar um prazo — urgência sem prazo é ambígua 5. Manter a titularidade do relacionamento com o cliente mesmo após escalar o problema técnico 6. Acompanhar proativamente — não esperar o time receptor vir até você 7. Documentar tudo — a trilha de escalação é valiosa para detecção de padrões e melhoria de processo