Uma operação com HubSpot e Salesforce integrados abre uma conta recém-fechada no CS e encontra, no campo de responsável, o nome do usuário da integração.

Não é erro de configuração. É o comportamento documentado. A Salesforce exige dono em todo registro, e quando um registro sem responsável atribuído sincroniza e cria um registro novo do outro lado, o dono passa a ser o usuário técnico que executa a sincronização.

O sync está verde. O relatório de integração não acusa nada. E a pessoa que vai atender aquele cliente na primeira semana não existe em nenhum campo.

Esse é o tipo de falha que a integração de dados não resolve, porque ela não é de transporte. O valor atravessou a borda entre os dois sistemas corretamente. O que não atravessou foi a decisão sobre quem responde pela conta.

Vale separar dois problemas que costumam aparecer com o mesmo nome. Alinhamento entre áreas é uma questão de gestão, sobre meta compartilhada, prioridade e dono de cada etapa, e está tratado em onde RevOps, Sales Ops e Marketing Ops se atritam. Integração de dados é uma questão técnica, sobre qual registro representa qual empresa e qual sistema escreve qual campo. Este texto trata da segunda, e mostra onde ela para de ser técnica.

O que o conector resolve bem

Vale reconhecer o escopo antes de apontar o limite, porque o conector faz o que promete.

A HubSpot descreve a integração com a Salesforce como a sincronização de contatos, empresas, negócios e atividades entre as duas plataformas, para que os times trabalhem com informação consistente entre sistemas. Isso elimina exportação manual, reduz a latência entre o evento e a visibilidade dele, e acaba com a versão paralela em planilha que cada área mantinha.

A Salesforce, no guia de decisão de integração de dados, vai além e recomenda evitar replicação desnecessária: quando o dado já vive num sistema e outro precisa dele, o caminho preferível é acessar via API em vez de copiar. A recomendação é correta e resolve duplicidade de registro.

Os dois materiais são precisos no que descrevem. Informação consistente entre sistemas é a promessa, e ela é cumprida. Sistema, porém, não é área. A promessa de consistência técnica não cobre a negociação que acontece entre marketing, vendas e CS no momento em que a conta muda de mãos.

Três coisas que o conector não decide

Os três casos abaixo estão documentados no comportamento padrão das ferramentas. Nenhum deles é falha de produto, e os três aparecem na operação como discussão recorrente.

O dono derivado

O caso da abertura. Por padrão, o campo de dono de um registro na Salesforce sincroniza para a propriedade correspondente na HubSpot, e vice-versa. Quando o registro chega sem dono, o sistema de destino atribui um.

O resultado é um dono que existe no campo e não existe na operação. Marketing pode ter um responsável pela nutrição, vendas um responsável pelo negócio, e o CS um responsável pela carteira, e os três são legítimos ao mesmo tempo. O conector precisa de um valor único no campo, então escolhe um, e a escolha não tem relação com quem pega a conta na semana seguinte.

O rótulo que bate sem o critério bater

Para sincronizar estágio de negócio entre as plataformas, o rótulo do campo em um sistema precisa corresponder ao rótulo da propriedade no outro. Fechado Ganho de um lado exige Fechado Ganho do outro.

Rótulo idêntico não é critério idêntico. Marketing lê Fechado Ganho como conversão da campanha, vendas lê como receita comprometida, e o CS lê como cliente pronto para entrar. Os três abrem o mesmo valor no mesmo campo e operam três passagens diferentes. O que precisa circular junto com o estágio é a definição vigente dele, e isso é assunto de normalização de dados entre áreas.

A regra de conflito que decide por tempo

A configuração bidirecional mais comum determina que o valor mais recente sobrescreve o anterior. É a regra correta para resolver conflito de escrita entre dois sistemas, porque precisa haver um critério de desempate e o tempo é o único disponível ao conector.

Na operação, isso significa que a definição acordada na segunda-feira desaparece na terça se alguém editar o campo depois, sem saber que existia um acordo. O conector não distingue uma correção deliberada de uma edição de rotina, porque ele não conhece a intenção por trás da escrita.

Identidade e propriedade são decisões, não campos

Os três casos têm a mesma raiz. O conector move valores entre campos, e identidade e propriedade não são valores, são decisões que precisam ser tomadas antes de qualquer mapeamento.

Identidade responde quando dois registros representam a mesma empresa. Essa pergunta não tem resposta técnica universal: uma subsidiária com CNPJ próprio pode ser a mesma conta comercial ou não, dependendo de como a empresa vende e cobra. A decisão precede o campo, e o campo apenas registra o resultado dela.

Propriedade responde quem age agora. Marketing, vendas e CS podem ter responsáveis simultâneos e legítimos pela mesma conta, em etapas diferentes. Um campo único de dono comprime três respostas em uma, e a compressão é feita pela regra de sincronização em vez de por decisão da operação.

Quatro coisas precisam viajar junto com o registro para que a passagem funcione:

‍A entidade primária e a regra de resolução: Qual chave decide que dois registros são a mesma conta, e o que acontece quando duas chaves discordam.

O dono por etapa, nomeado: Quem responde em cada momento do ciclo, declarado em vez de derivado do último sync.

A versão do critério: Sob qual definição aquele registro foi criado, gravada nele. Sem isso, comparar períodos não é interpretável.

O motivo quando a passagem não acontece: O registro que fica parado entre duas áreas precisa gerar sinal, e esse ponto está detalhado em como deve ser uma passagem de oportunidades estruturada.

Na Strataflow os quatro ficam na camada de Organização, com a entidade normalizada, o catálogo comercial e a estrutura operacional que as Iniciativas herdam, e na camada de Operação, com a regra do Ciclo, o playbook e a ação carregando a origem da decisão. O CRM continua sendo o registro do negócio, e a automação continua sendo o canal.

Como iniciar um processo de integração entre áreas

A decisão de identidade e de propriedade pode ser tomada com as ferramentas que a empresa já tem, e ela precisa ser tomada antes de qualquer novo mapeamento.

Passo 1: Escolher a entidade primária e escrever a regra de resolução. Qual campo decide identidade, domínio, raiz do CNPJ ou identificador externo, e qual é o desempate quando dois candidatos discordam. Uma frase por regra, com exemplos de dois casos reais que a operação já enfrentou.

Passo 2: Criar um identificador próprio da empresa, independente de qualquer ferramenta, e propagá-lo para todos os sistemas como campo somente leitura. Enquanto a identidade depender do ID de um fornecedor, trocar de fornecedor significa refazer a decisão.

Passo 3: Nomear o dono por etapa numa tabela explícita, com marketing, vendas e CS separados. O campo de dono do CRM passa a registrar apenas o dono da etapa comercial, e para de tentar representar os três.

Passo 4: Definir direção de escrita campo a campo, em vez de bidirecional em tudo. Cada campo tem um sistema que manda e os demais que leem, com a lista escrita e acessível a quem opera.

Passo 5: Instrumentar a falha. Um relatório semanal de registros cujo dono é o usuário da integração, mais um de registros parados na mesma etapa acima do prazo. Os dois transformam a falha silenciosa em item de fila com responsável.

O passo 5 é o que costuma faltar, e é o mais barato dos cinco. Ele revela, em uma semana, o tamanho real do problema que a operação vinha atribuindo a disciplina de time.

Cuidados nessa abordagem

A decisão escrita resolve o presente. O que falha é a manutenção dela ao longo do tempo, e a falha aparece sem erro visível.

O maior risco é o mesmo da normalização, agravado pela quantidade de sistemas. A regra de resolução envelhece: um cliente é adquirido por outro, uma subsidiária passa a comprar separado, um domínio muda depois de rebranding. A regra escrita continua no documento, os registros criados sob ela continuam no banco, e nenhum dos dois se atualiza sozinho. A partir daí, a contagem de contas mistura dois critérios sem que nenhum relatório acuse divergência.

Três agravantes tornam isso provável em vez de eventual.

O número de pares cresce mais rápido que o número de sistemas: Com dois sistemas, a direção de escrita cabe numa página. Com quatro, são doze direções possíveis por campo, e ninguém consegue enunciar de cabeça qual sistema manda em qual atributo. A lista escrita no passo 4 fica desatualizada silenciosamente a cada nova integração.

O dono nomeado não acompanha a mudança de carteira: A tabela do passo 3 envelhece a cada mudança de território, saída de vendedor ou reorganização de segmento. Quando ela desatualiza, a operação volta ao dono derivado, e o problema original reaparece sem que ninguém tenha decidido voltar atrás.

A regra não reprocessa o histórico: Mudar a definição de identidade hoje não corrige os registros criados sob a regra anterior. Sem a versão gravada em cada registro, a base passa a conter dois critérios convivendo, e qualquer série histórica mistura os dois.

O ponto em que os três aparecem juntos é previsível: mais de dois sistemas escrevendo no mesmo registro, mais de uma frente comercial com carteiras distintas, e uma regra de identidade que já precisou de exceção.

A partir dali, a integração deixa de ser um mapeamento a manter e passa a exigir um sistema que participe da decisão. Identidade com regra versionada e histórico reprocessável, propriedade declarada por etapa em vez de derivada do sync, direção de escrita que a operação consulta sem abrir documentação, e falha de passagem que vira item de fila com responsável. Um conector não entrega isso, porque ele transporta valor sem conhecer a decisão que produziu o valor.

Perguntas frequentes

Integrar a API resolve a integração entre marketing, vendas e CS?

O conector resolve o transporte, eliminando exportação manual e reduzindo latência entre sistemas. Identidade, que responde quando dois registros são a mesma conta, e propriedade, que responde quem age agora, são decisões anteriores ao mapeamento, e continuam sendo negociadas na passagem depois que o sync entra no ar.

Por que o dono da conta aparece como usuário da integração?

Porque a Salesforce exige dono em todo registro, e quando um registro sem responsável sincroniza e cria um registro novo, o sistema atribui o usuário técnico da integração. O comportamento é documentado, e o efeito é um dono que existe no campo sem existir na operação.

Sincronizar o estágio do negócio garante que as áreas usem o mesmo critério?

A sincronização de estágio exige que os rótulos correspondam entre os sistemas. Rótulo idêntico não implica critério idêntico, e marketing, vendas e CS podem ler o mesmo valor como conversão de campanha, receita comprometida e cliente pronto para entrar.

O que é uma regra de resolução de identidade?

É a decisão escrita sobre qual chave determina que dois registros representam a mesma conta, domínio, raiz do CNPJ ou identificador externo, com o critério de desempate quando duas chaves discordam. A decisão precede o mapeamento de campos.

Por que a sincronização bidirecional apaga acordos entre áreas?

Porque a configuração mais comum determina que o valor mais recente sobrescreve o anterior. É o desempate correto para conflito de escrita entre sistemas, e ele não distingue uma correção deliberada de uma edição de rotina, já que o conector não conhece a intenção por trás da escrita.