RD StationApp PublisherApp StoreBlogSuporte
API
Acesse sua conta

Casos de Uso

Esta seção fornece o conteúdo para a seção "Guias e Casos de Uso" da documentação. Cada caso de uso é apresentado como um tutorial autocontido, descrevendo um cenário de negócio, o fluxo de trabalho passo a passo e como as entidades da API V2 do RD Station CRM são utilizadas para resolver o problema.

Estes casos de uso cobrem fluxos de trabalho comuns e de alto valor, conectando o RD Station CRM a outras ferramentas essenciais do ecossistema SaaS.

Dicionário de termos:

Webhook - É uma notificação automática que um sistema envia para outro quando algo acontece. Em vez de você perguntar por novidades, o sistema te avisa sozinho e em tempo real.

Endpoint - É o "endereço" exato onde um sistema busca uma informação ou executa uma tarefa específica. Pense nele como um ramal direto para falar com o setor certo de uma empresa.

Payload - É o pacote de dados real que você envia em uma comunicação. Se a comunicação fosse uma carta, o payload seria a mensagem escrita dentro dela.

Middleware - Pense nele como uma plataforma de segurança para a comunicação entre dois ou mais sistemas, encarregada de verificar permissões para requisições e de correlacionar entidades idênticas em diversas plataformas.

Sincronização Bidirecional de Contatos com uma Plataforma de Automação de Marketing

Cenário de Negócio: Uma empresa utiliza uma ferramenta de automação de marketing (como Mailchimp ou ActiveCampaign) para capturar leads e nutrir sua base de contatos. Ao mesmo tempo, a equipe de vendas gerencia esses contatos no RD Station CRM. É crucial que ambas as plataformas estejam sempre sincronizadas: novos assinantes da ferramenta de marketing devem ser criados no CRM, e as atualizações feitas no CRM (como uma mudança de cargo ou estágio no funil) devem ser refletidas na ferramenta de marketing para segmentação de campanhas.

Fluxo de Trabalho e Mapeamento da API:

Este fluxo de trabalho demonstra uma sincronização bidirecional e orientada a eventos, que é mais eficiente do que a verificação periódica (polling), ou seja: o sistema trabalha quando é acionado e não a cada 10 em 10 segundos, por exemplo.

  • Passo 1: Novo Assinante na Plataforma de Marketing → Criar Contato no RD Station CRM

    • Gatilho: Um novo usuário subscreve a uma newsletter no site da empresa. A plataforma de marketing captura essa informação.
    • Ação: A plataforma de marketing (ou um middleware como o Zapier) aciona uma chamada para o endpoint POST /contacts da API V2.
    • Mapeamento de Entidades:
      • Contato: O corpo da requisição deve conter os dados básicos do novo assinante. O campo email é essencial. Campos como name e custom_fields podem ser preenchidos com informações adicionais coletadas no formulário de inscrição.
      • Bases legais: Um ponto crucial para a conformidade com LGPD/GDPR é o preenchimento do objeto legal_bases. A requisição deve incluir a base legal para o contato, como consentimento para e-mails de marketing. Exemplo: {"legal_bases": [{"category": "consent", "type": "marketing_email", "status": "active"}]}.

  • Passo 2: Contato Atualizado no RD Station CRM → Atualizar Assinante na Plataforma de Marketing

    • Gatilho: Um vendedor no RD Station CRM atualiza o cargo (title) de um contato ou altera um campo personalizado que indica um novo interesse de produto.
    • Ação: Esta atualização dispara o webhook crm_contact_updated, que foi previamente subscrito pela integração.
    • Mapeamento de Entidades:
      • Webhook: A integração recebe um payload do webhook contendo o objeto Contact completo e atualizado.
      • Contact: O sistema de integração extrai o id ou email do contato do payload e os campos que foram alterados. Em seguida, ele usa a API da plataforma de marketing para encontrar e atualizar o assinante correspondente.

  • Passo 3: Lead Qualificado para Vendas → Criar Negociação no RD Station CRM

    • Gatilho: Um contato na plataforma de marketing atinge um determinado score de engajamento (lead scoring), tornando-se um "Marketing Qualified Lead" (MQL).
    • Ação: A automação de marketing aciona uma chamada para o endpoint POST /deals da API V2.
    • Mapeamento de Entidades:
      • Deal: Uma nova negociação é criada. O nome da negociação pode ser padronizado (ex: "Nova Oportunidade para [Nome do Contato]"). A negociação deve ser associada ao Contact existente (via contact_id, que pode ser obtido no passo 1 ou 2), a um user_id (o vendedor responsável) e a um deal_pipeline_id e deal_stage_id iniciais.
      • Source: O deal_source_id pode ser definido para indicar que a negociação originou-se da campanha de marketing específica, permitindo uma análise de ROI mais precisa.

Sincronização de Oportunidades com um Sistema ERP

Cenário de Negócio: Uma empresa gerencia seu processo comercial inicial no RD Station CRM, onde as negociações são criadas e qualificadas. Ao chegar em um determinado ponto do funil de vendas, como a solicitação de um orçamento, é necessário transferir as informações da empresa e da negociação para o sistema de gestão (ERP), onde o orçamento ou pedido de venda é formalmente gerado. Para manter a visibilidade e o controle do vendedor no CRM, o número do orçamento gerado no ERP precisa ser registrado de volta na negociação. Além disso, o status final da negociação (ganha ou perdida) no CRM deve refletir no status do orçamento no ERP, garantindo que ambos os sistemas estejam sincronizados.

Fluxo de Trabalho e Mapeamento da API: Este fluxo de trabalho demonstra uma sincronização bidirecional e orientada a eventos, garantindo que as informações fluam do CRM para o ERP e vice-versa em momentos chave do processo de vendas.

Passo 1: Oportunidade Atinge Estágio de Orçamento → Criar Orçamento no ERP

  • Gatilho: Um vendedor no RD Station CRM move uma negociação para uma etapa específica do funil, como "Orçamento Solicitado".
  • Ação: Esta atualização dispara o webhook crm_deal_updated, que foi previamente subscrito pela integração. O middleware (plataforma de integração) recebe a notificação e utiliza os dados da negociação e da empresa associada para criar um novo orçamento no sistema ERP.
  • Mapeamento de Entidades:
    • Webhook: A integração recebe um payload contendo o objeto Deal completo e atualizado.
    • Deal: O sistema de integração extrai o id da negociação, seus contact_ids e outras informações pertinentes.
    • Contact e Organization: A partir dos contact_ids, a integração pode buscar os dados dos contatos associados (via GET /api/v2/contacts/:id) e, a partir deles, obter o organization_id para buscar os detalhes da empresa (via GET/api/v2/organizations/:id). Essas informações são então usadas para cadastrar a empresa no ERP, se ela ainda não existir.

Passo 2: Orçamento Criado no ERP → Atualizar Negociação no RD Station CRM

  • Gatilho: O sistema ERP finaliza a criação do orçamento e retorna um número de identificação único.
  • Ação: O middleware recebe essa informação do ERP e realiza uma chamada para o endpoint PATCH /api/v2/deals/:id da API V2 para atualizar a negociação original no RD Station CRM.
  • Mapeamento de Entidades:
    • Deal: O corpo da requisição de atualização deve conter o objeto custom_fields. Para que isso funcione, um campo personalizado (ex: "ID do Orçamento no ERP") precisa ser previamente criado na entidade Negociação no CRM.
    • Custom Fields: A chave do objeto deve ser o identificador do campo personalizado, e o valor será o número do orçamento retornado pelo ERP. Exemplo: {"custom_fields": {"id_orcamento_erp": "ORC-2025-00123"}}.

Passo 3: Negociação Ganha/Perdida no RD Station CRM → Atualizar Status do Orçamento no ERP

  • Gatilho: Um vendedor altera o status de uma negociação no RD Station CRM para won (ganha) ou lost (perdida).
  • Ação: A alteração de status dispara novamente o webhook crm_deal_updated. O middleware recebe a notificação, identifica o novo status da negociação e o ID do orçamento no ERP (armazenado no campo personalizado) e, em seguida, aciona a API do ERP para atualizar o status do orçamento correspondente para "Vendido", "Cancelado" ou "Perdido".
  • Mapeamento de Entidades:
    • Webhook: A integração recebe o payload com o objeto Deal completo.
    • Deal: O sistema de integração extrai o valor do campo status, que pode ser
    • won ou lost, e também o valor do campo personalizado que contém o ID do orçamento no ERP para saber qual registro específico deve ser atualizado no outro sistema.

Criação de Ticket de Suporte e Sincronização de Contexto do Cliente

Cenário de Negócio: Quando um cliente abre um ticket de suporte numa plataforma de helpdesk (como Zendesk ou Freshdesk), o agente de suporte precisa de uma visão completa desse cliente para oferecer um atendimento rápido e contextualizado. O agente deve ver as informações de contato, a empresa e, crucialmente, se existem negociações de vendas em andamento com aquele cliente, tudo dentro da interface do helpdesk.

Fluxo de Trabalho e Mapeamento da API:

Este fluxo de trabalho demonstra como o RD Station CRM pode atuar como a "fonte da verdade" para o contexto do cliente, enriquecendo outros sistemas de negócio.

  • Passo 1: Novo Ticket Criado na Plataforma de Helpdesk

    • Gatilho: Um cliente envia um e-mail para o suporte, que gera um novo ticket no sistema de helpdesk.
    • Ação: A plataforma de helpdesk, através de uma aplicação de integração (middleware), extrai o endereço de e-mail do cliente do novo ticket.

  • Passo 2: Buscar Contexto do Cliente no RD Station CRM

    • Ação: A integração faz uma chamada para GET /contacts?email={email_do_cliente} para encontrar o registro do contato correspondente no CRM
    • Mapeamento de Entidades:
      • Contact: Se um contato for encontrado, a integração obtém seu id, name, title, e, mais importante, os IDs de suas associações, como organization_id e o array deal_ids, que contém informações sobre empresa e negociações deste contato.

  • Passo 3: Exibir o Contexto Completo na Interface do Helpdesk

    • Ação: Com os IDs obtidos no passo anterior, a integração faz chamadas adicionais à API V2 para enriquecer o perfil do cliente na tela do agente de suporte.
    • Mapeamento de Entidades:
      • Organization: Faz uma chamada GET /organizations/{organization_id} para obter o nome e outros detalhes da empresa do cliente.
      • Deal: Itera sobre o array deal_ids do objeto Contact. Para cada deal_id, faz uma chamada GET /deals/{id} para buscar detalhes da negociação, como name, amount_total e status. A integração pode optar por exibir apenas as negociações com status "ongoing".

  • Passo 4: Registrar a Interação de Suporte no RD Station CRM

    • Gatilho: O agente de suporte resolve e fecha o ticket.
    • Ação: A integração cria um registro dessa interação no RD Station CRM para que a equipe de vendas tenha visibilidade.
    • Mapeamento de Entidades:
      • Note ou Task: A integração faz uma chamada para POST /notes ou POST /tasks. O corpo da requisição (text ou notes) pode conter um resumo do ticket ou um link para ele. O registro deve ser associado ao contact_id e, se relevante, ao deal_id da negociação mais importante, garantindo que o histórico do cliente seja completo e acessível para todas as equipes.