cs-customer-escalation

/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 <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:

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