--- name: cs-draft-response description: Redige uma resposta profissional voltada ao cliente adaptada à situação e ao relacionamento. Use para responder uma pergunta de produto, responder a uma escalação ou incidente, entregar uma má notícia como atraso ou won't-fix, recusar um feature request, ou responder a um problema de billing. / Draft a professional customer-facing response tailored to the situation and relationship. Use when answering a product question, responding to an escalation or outage, delivering bad news like a delay or won't-fix, declining a feature request, or replying to a billing issue. argument-hint: "" --- # /cs-draft-response > Se encontrar integrações não configuradas, verifique [CONNECTORS.md](../../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 ``` 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 | Situação | Tom | Características | |-----------|------|----------------| | Boa notícia / conquistas | Comemorativo | Entusiasmado, caloroso, parabenizador, orientado ao futuro | | Atualização rotineira | Profissional | Claro, conciso, informativo, amigável | | Resposta técnica | Preciso | Preciso, detalhado, estruturado, paciente | | Entrega atrasada | Responsável | Honesto, empático, orientado à ação, específico | | Má notícia | Direto | Direto, empático, orientado à solução, respeitoso | | Problema / incidente | Urgente | Imediato, transparente, acionável, tranquilizador | | Escalação | Executivo | Composto, assumindo responsabilidade, apresentando plano, confiante | | Billing / conta | Preciso | Claro, factual, empático, focado na resolução | ### 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 | Situação | Timing de Acompanhamento | |-----------|-----------------| | Pergunta sem resposta | 2-3 dias úteis | | Problema de suporte aberto | Diário até resolver para crítico, 2-3 dias para padrão | | Action items pós-reunião | Dentro de 24 horas (enviar notas), depois verificar no prazo | | Check-in geral | Conforme necessário para problemas contínuos | | Após entregar má notícia | 1 semana para verificar impacto e sentimento | ### 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] ```