cs-draft-response

/cs-draft-response

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

Redigir uma resposta profissional voltada ao cliente adaptada à situação, ao relacionamento com o cliente e ao contexto de comunicação.

Usage

/cs-draft-response <contexto sobre a pergunta, problema ou solicitação do cliente>

Exemplos:

• /cs-draft-response Acme Corp perguntando quando a nova feature de dashboard vai lançar
• /cs-draft-response Escalação de cliente — integração deles está fora há 2 dias
• /cs-draft-response Respondendo a um feature request que não vamos construir
• /cs-draft-response Cliente teve erro de billing e quer resolução ASAP

Workflow

1. Entender o Contexto

Analisar o input do usuário para determinar:

• Cliente: Para quem é a comunicação? Verificar contexto de conta se disponível.
• Tipo de situação: Pergunta, problema, escalação, anúncio, negociação, má notícia, boa notícia, acompanhamento
• Urgência: É sensível ao tempo? Há quanto tempo o cliente está esperando?
• Canal: Email, ticket de suporte, chat ou outro (ajustar formalidade adequadamente)
• Estágio do relacionamento: Novo cliente, estabelecido, frustrado/escalado
• Nível do stakeholder: Usuário final, gerente, executivo, técnico, negócio

2. Pesquisar Contexto

Coletar background relevante de fontes disponíveis:

Gmail MCP:

• Correspondência anterior com esse cliente sobre esse tópico
• Quaisquer compromissos ou timelines compartilhados anteriormente
• Tom e estilo do thread existente

discord-get-messages (/discord-get-messages) e int-whatsapp (/int-whatsapp):

• Discussões internas sobre esse cliente ou tópico
• Qualquer orientação de produto, Devs ou liderança
• Situações similares e como foram tratadas

int-evo-crm (/int-evo-crm):

• Detalhes da conta e nível de plano
• Informações de contato e stakeholders principais
• Escalações anteriores ou problemas sensíveis

int-evo-crm (tickets relacionados):

• Tickets relacionados e suas resoluções
• Problemas conhecidos ou workarounds
• Status de SLA e compromissos de tempo de resposta

Notion MCP:

• Documentação oficial ou artigos de ajuda para referenciar
• Informações do roadmap de produto (se compartilháveis)
• Documentação de política ou processo

3. Gerar o Rascunho

Produzir uma resposta adaptada à situação:

## Rascunho de Resposta

**Para:** [Nome do contato do cliente]
**Assunto/Re:** [Assunto/tópico]
**Canal:** [Email / Ticket / Chat]
**Tom:** [Empático / Profissional / Técnico / Comemorativo / Direto]

---

[Texto do rascunho da resposta]

---

### Notas para Você (internas — não enviar)
- **Por que essa abordagem:** [Racional para escolhas de tom e conteúdo]
- **Coisas a verificar:** [Quaisquer fatos ou compromissos a confirmar antes de enviar]
- **Fatores de risco:** [Qualquer coisa sensível sobre essa resposta]
- **Acompanhamento necessário:** [Ações a tomar após enviar]
- **Nota de escalação:** [Se isso deve ser revisado por alguém antes]

4. Executar Verificações de Qualidade

Antes de apresentar o rascunho, verificar:

• Tom corresponde à situação e ao relacionamento
• Sem compromissos além do que está autorizado
• Sem detalhes do roadmap de produto que não devem ser compartilhados externamente
• Referências precisas a conversas anteriores
• Próximos passos claros e titularidade definida
• Adequado para o nível do stakeholder (não muito técnico para executivos, não muito vago para engenheiros)
• Tamanho adequado para o canal (mais curto para chat, mais completo para email)

5. Oferecer Iterações

Após apresentar o rascunho:

• "Quer que eu ajuste o tom? (mais formal, mais casual, mais empático, mais direto)"
• "Devo adicionar ou remover algum ponto específico?"
• "Quer que eu torne isso mais curto/longo?"
• "Devo redigir uma versão para um stakeholder diferente?"
• "Quer que eu redija a nota de escalação interna também?"
• "Devo preparar uma mensagem de acompanhamento para enviar após [X dias] sem resposta?"

---

Boas Práticas de Comunicação com Clientes

Princípios Fundamentais

1. Começar com empatia: Reconhecer a situação do cliente antes de ir para soluções
2. Ser direto: Ir ao ponto — clientes são ocupados. Bottom-line-up-front.
3. Ser honesto: Nunca prometer demais, nunca enganar, nunca esconder más notícias em jargão
4. Ser específico: Usar detalhes concretos, timelines e nomes — evitar linguagem vaga
5. Assumir responsabilidade: Assumir a responsabilidade quando apropriado. "Nós" não "o sistema" ou "o processo"
6. Fechar o loop: Cada resposta deve ter um próximo passo claro ou call to action
7. Corresponder à energia deles: Se estão frustrados, ser empático primeiro. Se estão animados, ser entusiasmado.

Estrutura de Resposta

Para a maioria das comunicações com clientes, seguir essa estrutura:

1. Reconhecimento / Contexto (1-2 frases)
   - Reconhecer o que disseram, perguntaram ou estão vivenciando
   - Mostrar que você entende a situação deles

2. Mensagem Central (1-3 parágrafos)
   - Entregar a informação principal, resposta ou atualização
   - Ser específico e concreto
   - Incluir detalhes relevantes que eles precisam

3. Próximos Passos (1-3 bullets)
   - O que VOCÊ vai fazer e até quando
   - O que ELES precisam fazer (se houver)
   - Quando vão ter notícias suas

4. Fechamento (1 frase)
   - Encerramento cordial mas profissional
   - Reforçar que você está disponível se precisarem

Diretrizes de Extensão

• Chat/IM: 1-4 frases. Ir ao ponto imediatamente.
• Resposta de ticket de suporte: 1-3 parágrafos curtos. Estruturado e escaneável.
• Email: 3-5 parágrafos no máximo. Respeitar a caixa de entrada deles.
• Resposta de escalação: Tão longo quanto necessário para ser completo, mas bem estruturado com headers.
• Comunicação executiva: Mais curto é melhor. 2-3 parágrafos no máximo. Orientado a dados.

Diretrizes de Tom e Estilo

Espectro de Tom

Ajustes de Tom por Estágio do Relacionamento

Novo Cliente (0-3 meses):

• Mais formal e profissional
• Contexto e explicação extras (não assumir conhecimento prévio)
• Oferecer proativamente ajuda e recursos
• Construir confiança através de confiabilidade e responsividade

Cliente Estabelecido (3+ meses):

• Caloroso e colaborativo
• Pode referenciar histórico compartilhado e conversas anteriores
• Comunicação mais direta e eficiente
• Demonstrar consciência dos objetivos e prioridades deles

Cliente Frustrado ou Escalado:

• Empatia e reconhecimento extras
• Urgência nos tempos de resposta
• Planos de ação concretos com compromissos específicos
• Loops de feedback mais curtos

Regras de Estilo de Escrita

FAZER:

• Usar voz ativa ("Vamos investigar" não "Isso será investigado")
• Usar "eu" para compromissos pessoais e "nós" para compromissos do time
• Nomear pessoas específicas ao atribuir ações ("O Danilo do nosso time de Devs vai...")
• Usar a terminologia do cliente, não o jargão interno da Evolution
• Incluir datas e horários específicos, não termos relativos ("até sexta-feira dia 24 de janeiro" não "em alguns dias")
• Quebrar respostas longas com headers ou bullet points

NÃO FAZER:

• Usar jargão corporativo ou buzzwords
• Transferir culpa para outros times, sistemas ou processos
• Usar voz passiva para evitar responsabilidade ("Erros foram cometidos")
• Incluir ressalvas ou hedging desnecessários que minam a confiança
• Copiar pessoas desnecessariamente — incluir apenas quem precisa estar na conversa
• Usar pontos de exclamação excessivamente (um por email no máximo, se houver)

Abordagens por Situação

Respondendo uma pergunta de produto:

• Começar com a resposta direta
• Fornecer links para documentação relevante (Notion)
• Oferecer conectar com o recurso certo se necessário
• Se não souber a resposta: dizer honestamente, comprometer-se a descobrir, dar um prazo

Respondendo a um problema ou bug:

• Reconhecer o impacto no trabalho deles
• Indicar o que você sabe sobre o problema e seu status
• Fornecer workaround se disponível
• Definir expectativas para o prazo de resolução
• Comprometer-se com atualizações em intervalos regulares

Tratando uma escalação:

• Reconhecer a gravidade e a frustração deles
• Assumir responsabilidade (sem desviar ou dar desculpas)
• Fornecer um plano de ação claro com prazo
• Identificar a pessoa responsável pela resolução
• Oferecer uma reunião ou chamada se a gravidade justificar

Entregando má notícia (sunset de feature, atraso, não-vamos-corrigir):

• Ser direto — não enterrar a notícia
• Explicar o raciocínio honestamente
• Reconhecer o impacto específico neles
• Oferecer alternativas ou mitigação
• Fornecer um caminho claro adiante

Compartilhando boa notícia (lançamento de feature, marco, reconhecimento):

• Começar com o resultado positivo
• Conectar aos objetivos ou caso de uso específico deles
• Sugerir próximos passos para capitalizar na boa notícia
• Expressar entusiasmo genuíno

Recusando uma solicitação (feature request, desconto, exceção):

• Reconhecer a solicitação e seu raciocínio
• Ser honesto sobre a decisão
• Explicar o porquê sem ser dismissivo
• Oferecer alternativas quando possível
• Deixar a porta aberta para conversa futura

Templates de Resposta para Cenários Comuns

Reconhecendo um Bug Report

Olá [Nome],

Obrigado por reportar isso — entendo como [impacto específico]
seria frustrante para o seu time.

Confirmei o problema e escalei para nosso time de Devs como
prioridade [nível]. Aqui está o que sabemos até agora:
- [O que está acontecendo]
- [O que está causando, se conhecido]
- [Workaround, se disponível]

Vou te atualizar até [data/horário específico] com um prazo de resolução.
Enquanto isso, [detalhes do workaround se aplicável].

Me avise se tiver perguntas ou se isso está te impactando de
outras formas que devo saber.

Att,
[Seu nome]

Reconhecendo um Problema de Billing ou Conta

Olá [Nome],

Obrigado por entrar em contato — entendo que problemas de billing
precisam de atenção imediata, e quero garantir que isso seja resolvido
rapidamente.

Verifiquei sua conta e aqui está o que estou vendo:
- [O que aconteceu — explicação factual clara]
- [Impacto na conta — cobranças, acesso, etc.]

Aqui está o que estou fazendo para resolver:
- [Ação 1 — com prazo]
- [Ação 2 — se aplicável]

[Se a resolução for imediata: "Isso foi corrigido e você deve
ver a mudança refletida em até [prazo]."]
[Se precisar de investigação: "Estou escalando isso para nosso time financeiro
e terei uma atualização para você até [data específica]."]

Me desculpe pelo inconveniente. Me avise se tiver alguma
dúvida sobre sua conta.

Att,
[Seu nome]

Respondendo a um Feature Request que Não Vamos Construir

Olá [Nome],

Obrigado por compartilhar esse pedido — entendo por que [capacidade]
seria valiosa para [seu caso de uso].

Discuti isso com nosso time de produto, e isso não é algo que
planejamos construir no curto prazo. O motivo principal é [explicação
honesta e respeitosa — ex: atende um caso de uso restrito, conflita
com a direção da nossa arquitetura, etc.].

Dito isso, quero garantir que você possa atingir seu objetivo. Aqui estão
algumas alternativas:
- [Abordagem alternativa 1]
- [Abordagem alternativa 2]
- [Integração ou workaround se aplicável]

Também documentei seu pedido no nosso sistema de feedback, e se nossa
direção mudar, vou te avisar.

Alguma dessas alternativas funcionaria para o seu time? Posso me aprofundar
em qualquer uma delas.

Att,
[Seu nome]

Comunicação de Incidente ou Outage

Olá [Nome],

Queria entrar em contato diretamente para informar sobre um problema
afetando [serviço/feature] que sei que o seu time depende.

**O que aconteceu:** [Explicação clara e não técnica]
**Impacto:** [Como afeta especificamente eles]
**Status:** [Atual — investigando / identificado / corrigindo / resolvido]
**Previsão de resolução:** [Horário específico se conhecido, ou "vamos atualizar a cada X horas"]

[Se aplicável: "Enquanto isso, você pode [workaround]."]

Estou pessoalmente acompanhando isso e vou te atualizar assim que tivermos
uma resolução.

Me desculpe pela interrupção no trabalho do seu time. Levamos isso a sério
e [o que estamos fazendo para prevenir recorrência, se conhecido].

[Seu nome]

Acompanhamento Após Silêncio

Olá [Nome],

Queria verificar — enviei [o que enviou] em [data] e
queria garantir que não se perdeu.

[Breve lembrete do que você precisa deles ou do que está oferecendo]

Se não for um bom momento, sem problemas — me avise quando seria melhor,
e posso me reconectar então.

Att,
[Seu nome]

Orientação de Acompanhamento e Escalação

Cadência de Acompanhamento

Quando Escalar

Escalar para seu gerente/Davidson quando:

• Cliente ameaça cancelar ou reduzir significativamente
• Cliente solicita exceção à política que você não pode autorizar
• Um problema ficou sem resolução por mais tempo do que o SLA permite
• Cliente solicita contato direto com liderança
• Você cometeu um erro que precisa de envolvimento sênior para resolver

Escalar para Produto/Devs quando:

• Bug é crítico e está bloqueando o negócio do cliente
• Gap de feature está causando uma perda competitiva
• Cliente tem requisitos técnicos únicos além do suporte padrão
• Problemas de integração requerem investigação dos Devs

Formato de escalação:

ESCALAÇÃO: [Nome do Cliente] — [Resumo em uma linha]

Urgência: [Crítico / Alto / Médio]
Impacto no cliente: [O que está quebrado para eles]
Histórico: [Background breve — 2-3 frases]
O que tentei: [Ações tomadas até agora]
O que preciso: [Ajuda específica ou decisão necessária]
Prazo: [Quando isso precisa ser resolvido]