| 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 | <resumo do problema> [nome do cliente] |
/cs-customer-escalation
Se encontrar integrações não configuradas, verifique 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 <descrição do problema> [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:
- Começar de um estado limpo: Descrever o ponto de partida (tipo de conta, configuração, permissões)
- Ser específico: "Clicar no botão Exportar no canto superior direito da página Dashboard" não "tentar exportar"
- Incluir valores exatos: Usar inputs específicos, datas, IDs — não "inserir algum dado"
- Anotar o ambiente: Browser, OS, tipo de conta, feature flags, nível de plano
- Capturar a frequência: Sempre reproduzível? Intermitente? Apenas sob certas condições?
- Incluir evidências: Screenshots, mensagens de erro (texto exato), network logs, console output
- 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
- Sempre quantificar o impacto — escalações vagas são despriorizadas
- Incluir passos de reprodução para bugs — isso é a coisa #1 que os Devs precisam
- Ser claro sobre o que você precisa — "investigar" vs. "corrigir" vs. "decidir" são pedidos diferentes
- Definir e comunicar um prazo — urgência sem prazo é ambígua
- Manter a titularidade do relacionamento com o cliente mesmo após escalar o problema técnico
- Acompanhar proativamente — não esperar o time receptor vir até você
- Documentar tudo — a trilha de escalação é valiosa para detecção de padrões e melhoria de processo
