/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

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.

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