/cs-ticket-triage

Se encontrar integrações não configuradas, verifique CONNECTORS.md.

Categorize, priorize e encaminhe um ticket de suporte ou problema de cliente. Produz uma avaliação de triagem estruturada com uma resposta inicial sugerida.

Usage

/cs-ticket-triage <texto do ticket, mensagem do cliente ou descrição do problema>

Exemplos:

• /cs-ticket-triage Cliente diz que o dashboard está em branco desde esta manhã
• /cs-ticket-triage "Fui cobrado duas vezes na minha assinatura este mês"
• /cs-ticket-triage Usuário não consegue conectar SSO — erro 403 na callback URL
• /cs-ticket-triage Solicitação de feature: exportar relatórios em PDF

Workflow

1. Parse do Problema

Leia o input e extraia:

• Problema central: O que o cliente está realmente vivenciando?
• Sintomas: Qual comportamento ou erro específico está vendo?
• Contexto do cliente: Quem é? Há detalhes de conta, plano ou histórico disponíveis?
• Sinais de urgência: Está bloqueado? É produção? Quantos usuários afetados?
• Estado emocional: Frustrado, confuso, neutro, escalando?

2. Categorizar e Priorizar

Usando a taxonomia de categorias e o framework de prioridade abaixo:

• Atribuir uma categoria primária (bug, how-to, feature request, billing, conta, integração, segurança, dados, performance) e uma secundária opcional
• Atribuir uma prioridade (P1–P4) com base em impacto e urgência
• Identificar a área de produto a que o problema se refere

3. Verificar Duplicatas e Problemas Conhecidos

Antes de encaminhar, verificar nas fontes disponíveis:

• int-evo-crm (/int-evo-crm): Buscar tickets similares abertos ou resolvidos recentemente
• Notion MCP: Verificar problemas conhecidos ou documentação existente
• int-linear-review (/int-linear-review) ou Linear MCP: Verificar se há bug report ou feature request existente

Aplicar o processo de detecção de duplicatas abaixo.

4. Determinar Encaminhamento

Usando as regras de routing abaixo, recomendar qual time ou fila deve tratar com base na categoria e complexidade.

5. Gerar Output de Triagem

## Triagem: [Resumo em uma linha do problema]

**Categoria:** [Primária] / [Secundária se aplicável]
**Prioridade:** [P1-P4] — [Breve justificativa]
**Área de produto:** [Área/time]

### Resumo do Problema
[Resumo em 2-3 frases do que o cliente está vivenciando]

### Detalhes Chave
- **Cliente:** [Nome/conta se conhecido]
- **Impacto:** [Quem e o que está afetado]
- **Workaround:** [Disponível / Não disponível / Desconhecido]
- **Tickets relacionados:** [Links para problemas similares se encontrados]
- **Problema conhecido:** [Sim — link / Não / Verificando]

### Recomendação de Encaminhamento
**Encaminhar para:** [Time ou fila]
**Por quê:** [Breve raciocínio]

### Resposta Inicial Sugerida
[Rascunho da primeira resposta ao cliente — reconhecer o problema,
definir expectativas, fornecer workaround se disponível.
Usar os templates de auto-resposta abaixo como ponto de partida.]

### Notas Internas
- [Contexto adicional para o agente que pegar o ticket]
- [Dicas de reprodução se for um bug]
- [Gatilhos de escalação a observar]

6. Oferecer Próximos Passos

Após apresentar a triagem:

• "Quer que eu redija uma resposta completa para o cliente?"
• "Devo buscar mais contexto sobre esse problema?"
• "Quer que eu verifique se é um bug conhecido no Linear?"
• "Devo escalar? Posso montar o pacote com /cs-customer-escalation."

Taxonomia de Categorias

Atribuir a cada ticket uma categoria primária e opcionalmente uma secundária:

Dicas para Determinação de Categoria

• Se o cliente reportar tanto um bug quanto um feature request, o bug é primário
• Se não consegue logar por causa de um bug, a categoria é Bug (não Conta) — a causa raiz define a categoria
• "Funcionava antes e agora não funciona" = Bug
• "Quero que funcione de forma diferente" = Feature request
• "Como faço para funcionar?" = How-to
• Em caso de dúvida, optar por Bug — é melhor investigar do que descartar

Framework de Prioridade

P1 — Crítico

Critérios: Sistema em produção fora do ar, perda ou corrupção de dados, brecha de segurança, todos ou a maioria dos usuários afetados.

• O cliente não consegue usar o produto de forma alguma
• Dados estão sendo perdidos, corrompidos ou expostos
• Um incidente de segurança está em andamento
• O problema está piorando ou expandindo em escopo

SLA esperado: Responder em até 1 hora. Trabalho contínuo até resolver ou mitigar. Atualizações a cada 1-2 horas.

P2 — Alto

Critérios: Feature principal quebrado, workflow significativo bloqueado, muitos usuários afetados, sem workaround.

• Um workflow central está quebrado mas o produto é parcialmente utilizável
• Vários usuários são afetados ou uma conta-chave está impactada
• O problema está bloqueando trabalho sensível ao tempo
• Nenhum workaround razoável existe

SLA esperado: Responder em até 4 horas. Investigação ativa no mesmo dia. Atualizações a cada 4 horas.

P3 — Médio

Critérios: Feature parcialmente quebrado, workaround disponível, usuário único ou equipe pequena afetada.

• Uma feature não está funcionando corretamente mas existe um workaround
• O problema é inconveniente mas não bloqueia trabalho crítico
• Um usuário único ou equipe pequena é afetada
• O cliente não está escalando urgentemente

SLA esperado: Responder em até 1 dia útil. Resolução ou atualização em até 3 dias úteis.

P4 — Baixo

Critérios: Inconveniência menor, problema cosmético, pergunta geral, feature request.

• Problemas cosméticos ou de UI que não afetam funcionalidade
• Feature requests e ideias de melhoria
• Perguntas gerais ou de how-to
• Problemas com soluções simples e documentadas

SLA esperado: Responder em até 2 dias úteis. Resolução em ritmo normal.

Gatilhos de Escalação de Prioridade

Elevar prioridade automaticamente quando:

• Cliente esperou mais do que o SLA permite
• Vários clientes reportam o mesmo problema (padrão detectado)
• O cliente escalou explicitamente ou mencionou envolvimento de executivo
• Um workaround que estava em vigor para de funcionar
• O problema se expande em escopo (mais usuários, mais dados, novos sintomas)

Regras de Routing

Encaminhar tickets com base em categoria e complexidade:

Detecção de Duplicatas

Antes de criar um novo ticket ou encaminhar, verificar duplicatas:

1. Buscar por sintoma: Procurar tickets com mensagens de erro ou descrições similares
2. Buscar por cliente: Verificar se esse cliente tem um ticket aberto para o mesmo problema
3. Buscar por área de produto: Procurar tickets recentes na mesma área de feature
4. Verificar problemas conhecidos: Comparar com problemas conhecidos documentados

Se uma duplicata for encontrada:

• Linkar o novo ticket ao existente
• Notificar o cliente que é um problema conhecido sendo rastreado
• Adicionar novas informações do novo relato ao ticket existente
• Elevar prioridade se o novo relato adiciona urgência (mais clientes afetados, etc.)

Templates de Auto-Resposta por Categoria

Bug — Resposta Inicial

Obrigado por reportar isso. Entendo como [impacto específico]
pode ser disruptivo para o seu trabalho.

Registrei isso como um problema [prioridade] e nossa equipe está
investigando. [Se houver workaround: "Enquanto isso, você pode
[workaround]."]

Vou te atualizar em até [prazo SLA] com o que encontrarmos.

How-to — Resposta Inicial

Boa pergunta! [Resposta direta ou link para documentação]

[Se mais complexo: "Deixa eu te guiar pelos passos:"]
[Passos ou orientações]

Me avise se isso ajudou, ou se tiver perguntas de acompanhamento.

Feature Request — Resposta Inicial

Obrigado pela sugestão — entendo por que [capacidade]
seria valioso para o seu workflow.

Documentei isso e compartilhei com nosso time de produto.
Embora não possa me comprometer com um prazo específico, seu feedback
informa diretamente as prioridades do nosso roadmap.

[Se houver alternativa: "Enquanto isso, você pode achar
[alternativa] útil para alcançar algo similar."]

Billing — Resposta Inicial

Entendo que problemas de billing precisam de atenção imediata. Deixa
eu verificar isso para você.

[Se simples: detalhes da resolução]
[Se complexo: "Estou revisando sua conta agora e terei
uma resposta em até [prazo]."]

Segurança — Resposta Inicial

Obrigado por sinalizar isso — levamos questões de segurança
a sério e estamos revisando imediatamente.

Escalei isso para nossa equipe de segurança para investigação.
Vou te retornar em até [prazo] com nossos achados.

[Se ação for necessária: "Enquanto isso, recomendamos
[ação protetora]."]

Boas Práticas de Triagem

1. Leia o ticket completo antes de categorizar — contexto em mensagens posteriores frequentemente muda a avaliação
2. Categorize pela causa raiz, não apenas pelo sintoma descrito
3. Em caso de dúvida na prioridade, errar para o lado mais alto — é mais fácil de-escalar do que recuperar de um SLA perdido
4. Sempre verificar duplicatas e problemas conhecidos antes de encaminhar
5. Escrever notas internas que ajudem a próxima pessoa a pegar contexto rapidamente
6. Incluir o que você já verificou ou descartou para evitar investigação duplicada
7. Sinalizar padrões — se estiver vendo o mesmo problema repetidamente, escalar o padrão mesmo que os tickets individuais sejam de baixa prioridade