As investigações de suporte são, em essência, problemas de investigação. Por isso, a parte mais lenta de responder aos problemas dos clientes sempre foi reunir o contexto certo. Ao consolidar código, logs, conhecimento da equipe e conversas anteriores em uma única sessão do Cursor, eliminamos esse gargalo na maior parte do nosso trabalho.

Hoje, mais de 75% das interações de suporte da Cursor passam pelo próprio Cursor, aumentando a produtividade dos engenheiros de suporte em 5 a 10 vezes. Isso representou uma mudança significativa no que é possível para engenheiros de suporte em comparação com apenas um ano atrás.

#Começando pela base de código

Quando investigamos, normalmente começamos no modo Ask. Apontamos para o sintoma e deixamos que ele siga o rastro a partir daí pelo comportamento relevante do produto. Como toda a nossa base de código está disponível localmente, o Cursor pode indexar e usar busca semântica em código do produto, documentação e ferramentas internas na mesma sessão.

É aqui que espaços de trabalho com várias raízes se tornam poderosos. O contexto do produto quase sempre abrange vários repositórios. Responder à pergunta do usuário, "Por que este botão está desativado?" pode envolver lógica de frontend, verificações de políticas no backend e documentação que descreve o comportamento esperado. Mantemos repositórios relacionados juntos em um espaço de trabalho para que esse tipo de pergunta possa ser respondido em uma única thread.

#Integrando fontes de suporte com MCP

Usamos servidores MCP para obter contexto e trazê-lo para nossas investigações. Nossos engenheiros de suporte não precisam mais fazer busca em várias ferramentas para obter contexto pertinente, porque ele está disponível no Cursor.

Os servidores MCP nos permitem integrar:

• Bancos de dados com informações dos clientes, como nível da assinatura, configurações da equipe e configurações de privacidade
• Logs de eventos em streaming com detalhes sobre os serviços usados, erros de telemetria e problemas de rede
• Plataformas de comunicação como o Slack, repletas de threads e conversas que complementam nosso entendimento de como os clientes interagem com o produto.
• Plataformas de tickets de engenharia contendo potencialmente dezenas de equipes distintas, cada uma operando de forma diferente
• Um serviço interno de documentação que contém runbooks e guias de solução de problemas
• Um serviço de gerenciamento de contas contendo informações cruciais sobre o cliente que podem mudar o tom da forma como você aborda um cliente

Com o Cursor e os servidores MCP, nossos engenheiros de suporte podem rapidamente trazer as informações necessárias diretamente para suas investigações da base de código.

#Identificando onde a falha ocorreu

Quando um cliente relata um erro, precisamos entender: o problema que ele está enfrentando é reproduzível ou transitório, e onde exatamente o Cursor falhou (no cliente, na borda da API, em uma dependência downstream ou na autenticação). O Datadog MCP nos permite trazer os logs e rastreamentos relevantes diretamente para a thread de investigação, o que nos ajuda a começar a afunilar as possibilidades.

#Identificando casos semelhantes

Quando um novo ticket de suporte chega, é provável que o problema já tenha sido visto por outro cliente ou por alguém da nossa equipe. Um MCP que se integra à sua plataforma de suporte, bem como ao Slack, nos permite fazer busca nesse contexto diretamente e trazer as threads mais relevantes de volta para a investigação. Primeiro, fazemos busca por identificadores exatos (strings de erro, IDs de solicitação), ampliamos se necessário e procuramos a thread mais recente que inclua um status atual, uma solução alternativa e um responsável.

#Determinando se era um bug

Muitas investigações se resumem a "bug ou comportamento esperado?". O Notion MCP nos permite trazer o runbook relevante para a thread, cruzá-lo com o que estamos vendo e confirmar se o comportamento é esperado ou escalar o caso com um relatório de bug muito mais claro.

#Abrindo um relatório de bug

Quando terminamos uma investigação no Cursor, reunimos todo o material de que precisamos para registrar um ticket com a equipe de engenharia, caso algo precise ser corrigido. O Linear MCP nos permite pegar todo esse contexto e transformá-lo em um escalonamento formatado diretamente na mesma thread.

#Atualizações da documentação

Quando vários clientes têm as mesmas dúvidas, isso geralmente é um sinal de que precisamos melhorar nossa documentação. A equipe de suporte técnico está em ótima posição para implementar esse tipo de correção diretamente. Basta mencionar @Cursor no Slack informando o que precisa ser atualizado, e um agente na nuvem abrirá uma PR no repositório da nossa documentação.

#Automatizando o processo

#Comandos para etapas comuns

Usamos comandos de barra para as etapas repetidas com mais frequência no processo:

# Criar ticket de suporte
Crie um ticket no Linear para o bug relatado ou problema do usuário.

## Formato
- **Informações de quem reportou:** Email, ID da conta, plataforma, versão do app
- **Resumo:** Breve descrição em 1 ou 2 frases
- **Esperado vs. real:** O que deveria acontecer vs. o que acontece
- **Etapas para reproduzir:** Lista numerada

## Observações
- Reúna as informações do usuário nos logs antes de criar o ticket
- Inclua IDs da solicitação ou IDs de rastreamento, se disponíveis
- Adicione links para consultas de logs ou dashboards relacionados
- Use prioridade média por padrão, salvo especificação em contrário

# Rascunhar resposta ao cliente
Rascunhe uma resposta ao cliente sobre o problema dele.

## Diretrizes
- Use apenas o nome público do produto
- Evite nomes de serviços internos, codinomes ou detalhes da infraestrutura
- Não compartilhe códigos de erro internos, caminhos de arquivo ou variáveis de ambiente
- Limite-se a recursos documentados publicamente e etapas padrão de solução de problemas

## Em caso de dúvida
Pergunte: "Um cliente poderia descobrir isso pelo uso normal do produto?"
Se não, reformule usando abordagens gerais de depuração.

# Pesquisar problemas conhecidos
Pesquise no Slack para determinar se um problema já é conhecido.

## Fluxo de trabalho
1. Pesquise com identificadores (ID do ticket, código de erro, mensagem de erro exata)
2. Restrinja por canal e intervalo de tempo
3. Encontre threads com status, solução alternativa ou informações sobre o responsável

## Saída
- **Veredito:** Conhecido / Possivelmente conhecido / Não encontrado
- **Melhor thread:** Link permanente + resumo
- **Próxima busca:** Consulta para experimentar se os resultados forem fracos

# Pesquisar logs
Consulte os logs do Datadog para a solicitação, o usuário ou o erro especificado.

## Padrões comuns
- @requestId:{id} — encontrar uma solicitação específica
- @userId:{id} ou @email:{email} — encontrar atividade do usuário
- status:error — filtrar apenas erros
- service:{name} — filtrar por serviço

## Observações
- Sempre especifique um intervalo de tempo (padrão: últimos 7 dias)
- Os nomes dos campos variam de acordo com a origem — experimente vários padrões
- Comece de forma ampla e depois restrinja com base nos achados

#Regras e Habilidades para padrões repetidos

Usamos Regras e Habilidades para automatizar processos comuns em investigações de suporte.

# Habilidade: Resposta ao cliente (segura + acionável)

## Entradas de que preciso
- Sintoma do cliente (o que ele vê)
- O que encontramos (resumo baseado em fatos)
- Próximo passo/alternativa (se houver)
- 0–2 informações faltantes a solicitar

## Formato de saída
- Breve confirmação
- O que encontramos (sem detalhes internos)
- O que experimentar em seguida (etapas numeradas)
- Se necessário: no máximo duas perguntas (para destravar a investigação)
- Finalize com o que faremos em seguida do nosso lado

## Diretrizes
- Evite detalhes internos de implementação e jargão interno
- Prefira etapas concretas a especulação
- Seja conciso; priorize a "primeira resposta útil"

# Habilidade: Redigir um ticket de bug de alta qualidade

## Entradas de que preciso
- Sintoma (visível ao cliente)
- Janela de tempo
- IDs relevantes (request id, user/team id)
- Trechos de evidência (com dados sensíveis removidos)

## Formato de saída
## Resumo
## Esperado vs. real
## Etapas para reproduzir
## Evidências
## Escopo/Severidade
## Próxima etapa sugerida de depuração

## Critérios de qualidade
- Nenhuma linguagem vaga ("às vezes", "não funciona") sem uma condição concreta
- Nenhum jargão exclusivamente interno no título
- Oculte informações específicas do cliente, a menos que haja aprovação explícita

# Habilidade: Pesquisador de problemas conhecidos (Slack + Notion)

## Entradas de que preciso
- Texto exato do erro (ou a melhor aproximação)
- Palavras-chave da área do recurso
- Janela de tempo (padrão: últimos 30 dias)

## Fluxo de trabalho
- Pesquise primeiro no Slack por frases e identificadores exatos.
- Se os resultados forem fracos, amplie a busca com palavras-chave do recurso e filtros de tempo.
- Pesquise no Notion por runbooks/FAQs da mesma área do recurso.

## Formato de saída
- Veredito: Conhecido / Possivelmente conhecido / Não encontrado
- Melhores threads: 1–3 links com uma linha de "por que é relevante"
- Solução alternativa / mitigação (se houver)
- Próximo refinamento de busca: consulta exata a executar em seguida

#Subagentes para executar etapas em paralelo

Os subagentes permitem executar etapas comuns do processo de suporte em paralelo, em vez de em sequência.

• LogInvestigator busca no Datadog o ponto de falha e as evidências que o sustentam.
• KnownIssueMiner vasculha o Slack e o Notion em busca de threads anteriores e soluções alternativas.
• TicketWriter organiza as evidências em um escalonamento completo.
• CustomerReplyDrafter redige a resposta ao cliente, removendo detalhes internos.

Os resultados fazem merge em uma única saída, que revisamos e enviamos.

supportInvestigationPack:
  goal: >
    Produza um resumo fundamentado da investigação, um rascunho de ticket de bug
    e uma resposta ao cliente executando agentes especializados em paralelo.
  inputs:
    - customer_symptom
    - time_window
    - identifiers:
        request_id: ""
        user_or_team_id: ""
        error_text: ""
    - investigation_notes
  agents:
    - name: LogInvestigator
      focus: "Datadog: identificar o ponto de falha mais provável e as evidências que o sustentam."
      output:
        - suspected_root_cause
        - strongest_evidence
        - disconfirming_checks
        - open_questions
    - name: KnownIssueMiner
      focus: "Slack/Notion: encontrar referências anteriores, status atual e solução alternativa."
      output:
        - verdict
        - best_links
        - workaround
        - next_search_query
    - name: TicketWriter
      focus: "Escreva um ticket de bug voltado para a equipe de engenharia com base nas evidências + anotações."
      output:
        - title
        - summary
        - expected_vs_actual
        - steps_to_repro
        - evidence
        - suggested_next_debug_step
    - name: CustomerReplyDrafter
      focus: "Redija uma resposta ao cliente: clara, segura e acionável."
      constraints:
        - "Não inclua detalhes internos de implementação."
        - "Peça no máximo dois pontos de dados ausentes."
      output:
        - reply_text
        - questions_for_customer
  final_assembler:
    merges:
      - LogInvestigator
      - KnownIssueMiner
      - TicketWriter
      - CustomerReplyDrafter
    produces:
      - investigation_summary
      - ticket_draft
      - customer_reply

#Suporte técnico nativo de IA

Ao combinar essas ferramentas, levamos a investigação de código diretamente para o processo de suporte técnico. Estimamos que isso permita que nossa equipe seja até uma ordem de grandeza mais produtiva em comparação com as abordagens tradicionais, que exigem mais alternância entre ferramentas e equipes. Esse ganho de produtividade permite que nossa equipe pequena (mas em crescimento) de engenheiros de suporte atenda com eficácia nossa base de usuários em rápido crescimento.

Se você tem interesse em saber mais sobre como incorporar o Cursor ao seu workflow de CX, entre em contato.