/cs-customer-escalation

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](../../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, pre