Arquitetura de MAP e CRM sem a gambiarra: um playbook de reconstrução para MOps

Você abriu o gerenciador de campos e contou 247 campos personalizados. Metade pertence a pessoas que saíram em 2023. A sincronização de lead-para-contato está quebrada desde que o último admin a "consertou" lá no Q2. Dois dos picklists têm valores de texto livre que não deveriam existir. O estágio do ciclo de vida é escrito tanto pelo Marketo quanto pelo Salesforce, então 14% dos registros ficam oscilando entre MQL e Lead a cada ciclo de sincronização.

Bem-vindo ao MOps.

Se você acabou de herdar esse stack, ou se vem encarando ele por dois anos prometendo a si mesmo que iria limpá-lo "depois da próxima campanha", este é o playbook. É aquele que eu gostaria que alguém tivesse me entregado três empregos atrás. O objetivo não é um diagrama bonito. O objetivo é uma fonte da verdade por ponto de dado, um dono por campo, e uma integração que não te acorde às 3h da manhã.

Fluxo de dados de MAP para CRM: o contrato de verdade

A maioria dos times trata a integração de MAP para CRM como uma caixa-preta. Ela não é. É um contrato, e se ninguém escreveu o contrato, você tem gambiarra.

O contrato tem quatro partes. Erre essas e nada mais importa.

Lead vs Contato: o que sobrevive, o que morre

Quando um Lead converte em um Contato no Salesforce (ou seja lá como o seu CRM chame), você perde dados a menos que os tenha mapeado explicitamente. Comportamento padrão na maioria dos CRMs:

Campos padrão de Lead com campos correspondentes de Contato: sobrevivem
Campos personalizados de Lead sem um campo correspondente de Contato: desaparecem
Histórico de atividade: geralmente preservado, às vezes órfão
Campos de pontuação do lado do MAP: depende totalmente de o seu MAP escrever apenas no objeto Lead ou em ambos

O segredo sujo é que 80% dos times de MOps escrevem pontuações demográficas e comportamentais apenas no objeto Lead, e então se surpreendem quando um SDR converte um Lead e a pontuação desaparece. Se o seu MAP é o Marketo ou o Pardot, você deveria estar escrevendo os campos de pontuação tanto no Lead quanto no Contato, OU convertendo Leads em Contatos na criação (o modelo "tudo Contatos, sem Leads" que o HubSpot adota por padrão).

Escolha um. Documente. Estanque o sangramento.

Estágio do ciclo de vida: o MAP escreve, o CRM lê. Nunca os dois.

Esta é a regra mais importante de todo o playbook. Se ambos os sistemas podem escrever no estágio do ciclo de vida, você vai ter condições de corrida. Você vai ter registros que oscilam. Você vai ter um SDR fechando um negócio num Contato que o MAP acabou de rebaixar de volta para MQL por causa de um webhook de descadastro que disparou três minutos depois da atualização de Closed-Won.

Escolha um escritor. O MAP geralmente está correto porque ele vê os sinais comportamentais primeiro. O CRM lê o estágio do ciclo de vida; ele não briga por ele. Se vendas precisa sobrescrever (por exemplo, marcar alguém manualmente como SAL), construa um campo separado (sales_stage_override__c) e deixe uma automação no MAP respeitar essa sobrescrição. Não deixe dois sistemas discutindo sobre a mesma coluna.

Tempo de sincronização: tempo real nem sempre é melhor

O impulso padrão é "faça em tempo real". Isso está errado cerca de metade das vezes.

Sincronizações em tempo real fazem sentido para:

Preenchimentos de formulário (o lead tem que chegar ao CRM antes de a fila do SDR atualizar)
Transições de estágio do ciclo de vida que disparam o roteamento
Status de Closed-Won (a atribuição de receita não pode esperar)

Sincronizações em lote (15 min, de hora em hora, noturna) fazem sentido para:

Recálculos em massa de pontuação
Mudanças de associação a listas
Preenchimentos retroativos de histórico de atividade
Qualquer coisa que dispare mais de 1.000 atualizações de registro por hora

Por que isso importa? Porque "a cada 10 minutos" é a pior configuração possível para a sincronização de pontuação. É lento o suficiente para que os SDRs não confiem, rápido o suficiente para estourar os seus limites de API durante um disparo de campanha, e frequente o suficiente para tornar as condições de corrida invisíveis até a sua consulta de conciliação mensal pegá-las.

Se você só vai lembrar de uma coisa: tempo real para repasse, lote para higiene.

O repasse de MQL: um campo, um dono, uma definição

Pare. Abra o seu Salesforce. Busque por qualquer campo com "MQL" no nome. Aposto um café que você tem pelo menos três:

MQL_Date__c (definido pelo Marketo)
Marketing_Qualified__c (definido por uma workflow rule de 2022)
Lifecycle_Stage = "MQL" (definido pelo HubSpot)

Escolha um. Apague os outros dois. O repasse de MQL é um campo, um dono (MOps), uma definição (escrita num documento do Confluence que tem uma data). Se vendas não confia no campo, isso é um problema de definição, não um problema de campo. Adicionar um quarto campo nunca conserta um problema de definição.

O problema da proliferação de campos

A proliferação de campos é como os stacks de MAP+CRM morrem. Não uma única falha dramática. Um acúmulo lento de campos que ninguém é dono, usados por um relatório que ninguém abre, definidos por um workflow que ninguém documentou.

Como você chegou a 247 campos personalizados

Todo campo tem uma história de criação. Mais ou menos:

30% são reais, usados, com dono. Esses estão bem.
25% foram criados para uma campanha em 2022, ainda estão sendo escritos e não são lidos por nada.
20% foram criados por um líder de vendas que saiu, mapeados para um dashboard que foi descontinuado, mas o campo ainda está em todo layout de página.
15% são duplicatas com nomes ligeiramente diferentes (Industry__c, industry_v2__c, Account_Industry__c).
10% são "campos fantasmas" de integração criados automaticamente por uma integração que foi desconectada há 18 meses, mas o campo ficou.

Ninguém apaga campos porque exclusões parecem arriscadas. É exatamente por isso que você precisa de um processo.

O framework de auditoria de campos de 90 dias

Rode isto a cada trimestre. Reserve quatro horas numa sexta-feira. É o trabalho de limpeza de maior alavancagem em MOps.

Passo 1: puxe um relatório de uso. Para cada campo personalizado, conte:

Quantos registros têm um valor não nulo (últimos 90 dias de escritas)
Quantos relatórios referenciam o campo
Quantos workflows/automações referenciam o campo
Quantas integrações escrevem nele

Se os quatro forem zero, o campo está morto. Marque-o.

Passo 2: encontre o dono. Todo campo precisa de um nome atrelado. Puxe o "Created By" e verifique se aquela pessoa ainda está na empresa. Se não, passe o campo pelo time. Alguém o reivindica? Se ninguém o reivindicar em sete dias, é um órfão.

Passo 3: monte a lista de exclusão. Três baldes:

Exclusão definitiva: zero uso E sem dono. Apague no próximo sprint.
Descontinuar: tem algum uso, mas o dono concorda que é redundante. Marque como descontinuado na descrição, esconda dos layouts, agende a exclusão em 90 dias.
Documentar: ativo, com dono, sem ação adicional. Escreva a descrição se estiver em branco.

Passo 4: faça pegar. Adicione uma política de criação de campos: todo novo campo personalizado exige uma descrição, um dono e uma data de "revisar até". Sem descrição = sem campo. Faça o admin do CRM aplicar isso. Se ele não fizer, consiga para si direitos de admin para aquele workflow específico.

Você não vai chegar a 50 campos. Você provavelmente consegue chegar a 100. Essa é a meta.

Convenções de nomenclatura que sobrevivem à rotatividade

Se o próximo admin a herdar o seu stack não consegue adivinhar o que um campo faz em cinco segundos, o nome está errado. Renomeie.

A convenção de nomenclatura que eu uso, que sobreviveu a três mudanças de emprego:

mkt_*: escrito pelo MAP. Marketing é dono.
sfdc_*: campo nativo do Salesforce ou campo personalizado de propriedade de vendas.
ext_*: escrito por uma integração externa (Clearbit, ZoomInfo, 6sense, etc.). Somente leitura para todos os demais.
ops_*: campos operacionais/calculados (região, segmento, tier de conta).
Sem prefixo: campos padrão que você não criou.

A disciplina de picklist importa mais do que você imagina. Campos de país em texto livre onde você tem "USA", "U.S.A.", "United States", "US" e "America" todos no mesmo conjunto de dados vão destruir o seu reporting. Tranque os picklists. Se vendas reclamar, mostre a eles o relatório de segmento onde a receita dos EUA está dividida em cinco baldes.

A regra dos cinco segundos: se um novo admin abre o gerenciador de campos e não consegue adivinhar o que cust_dt_2_v3__c faz em cinco segundos, esse campo está mal nomeado. Renomeie. Sim, isso vai quebrar dois relatórios. Conserte os relatórios. O você do futuro vai mandar um bilhete de agradecimento.

Seleção de MAP: Marketo vs HubSpot vs Pardot vs Rework

Metade da dor de integração de MAP vem de escolher o MAP errado para a empresa. Veja como eu penso nisso.

Marketo (agora Adobe)

Escolha o Marketo se:

Você tem um admin dedicado de MAP (não um "gerente de marketing que também mexe no Marketo")
Os seus programas de campanha são genuinamente complexos (nutrições multitoque, jogadas baseadas em conta, dezenas de segmentos)
Você é enterprise (1.000+ funcionários) ou roda demand gen no estilo enterprise
Você aguenta o preço e a curva de aprendizado

Não escolha o Marketo se você é uma startup de 50 pessoas. Você vai usar 8% da plataforma, pagar 100% do preço, e a integração com o Salesforce vai consumir um FTE.

HubSpot

Escolha o HubSpot se:

O marketing lidera a motion de GTM
O seu time vive na UI (não em chamadas de API e SQL)
Você é mid-market (50 a 500 funcionários)
Você quer CRM e MAP do mesmo fornecedor e está de boa com o CRM do HubSpot (que é razoável para SMB, fica raso no enterprise)

A força do HubSpot é que o CRM e o MAP são um sistema só, então o problema da gambiarra parcialmente desaparece. A fraqueza é que, se você cresce além do CRM do HubSpot e acopla o Salesforce, você recriou o problema de integração com passos extras.

Pardot (Marketing Cloud Account Engagement)

Escolha o Pardot se:

Você é uma casa Salesforce-nativa e o admin do Salesforce também é dono da automação de marketing
Você não precisa de lógica de programa sofisticada
Você quer estágio do ciclo de vida e pontuação fortemente acoplados aos objetos do SFDC

A força do Pardot é que a integração com o SFDC é nativa (ela vive dentro do SFDC). A fraqueza é que o MAP em si é datado; se o seu time precisa de UX moderna, eles vão brigar com você.

Rework

Escolha o Rework se:

Você é um B2B pequeno ou médio (20 a 500 funcionários)
Vendas e marketing compartilham um pipeline e você não quer duas ferramentas brigando por ele
Você não tem um admin dedicado de MAP e não quer um
Você prefere ter um CRM com captura de leads, pontuação e roteamento embutidos a manter uma integração separada de MAP+CRM

O argumento do Rework para este problema específico: não há integração de MAP para CRM para manter porque não há um MAP separado. Captura de leads, pontuação, estágio do ciclo de vida e pipeline vivem em um sistema só. Você abre mão de parte da complexidade de programas enterprise do Marketo. Em troca, você abre mão da gambiarra.

Para um time de B2B SaaS de 30 pessoas com um generalista de MOps, o stack Marketo+SFDC custa talvez US$ 80 mil/ano em licenças mais meio FTE para manter. O mesmo fluxo de trabalho no Rework sai por US$ 12/usuário/mês no tier de CRM (cerca de US$ 10 mil/ano para um time de 30) e a integração de MAP vai de "manter" para "não existe".

Essa não é a resposta certa para todo mundo. É a resposta certa para mais times do que admitem.

A decisão de reconstruir do zero

Em algum momento, remendar custa mais do que reconstruir. A parte difícil é saber quando.

A regra dos 40%: se mais de 40% do tempo da sua equipe de MOps é gasto em consertos de integração, campos fantasmas e consultas de conciliação, e tem sido assim por dois trimestres consecutivos, você passou do ponto do remendo. Reconstrua.

Outros sinais:

Três ou mais campos de ciclo de vida "confiáveis" existem e as pessoas discutem sobre qual está correto
Os erros de sincronização passam de 0,5% dos registros por dia
Uma nova contratação de MOps leva mais de 90 dias para entregar a primeira mudança não trivial
A trilha de auditoria em campos críticos é "pergunte à Sandra, ela lembra"
A integração de MAP-CRM tem mais de dois componentes de middleware customizados (receitas do Workato, zaps do Zapier, Apex customizado)

Reconstruções não são uma operação de "explodir tudo". São uma construção em paralelo. Você levanta uma nova instância (ou um schema limpo na instância existente), migra uma campanha por vez, valida e então descontinua a antiga. Leva de 90 a 180 dias. É mais rápido do que os próximos 18 meses de remendos.

Diga ao seu chefe que é um investimento, não um projeto. Investimentos compõem. Remendos não.

Monitoramento de saúde da integração

Uma integração de MAP-CRM saudável tem telemetria. Se você não consegue vê-la, você não consegue consertá-la.

Os três alertas que todo líder de MOps deveria ter rodando:

1. Alerta de taxa de erro de sincronização. Dispara se os erros de sincronização passarem de 0,5% dos registros tentados numa janela de 1 hora. Isso pega problemas de limite de API, conflitos de regra de validação e falhas de middleware antes que vendas perceba.

2. Alerta de oscilação de ciclo de vida. Dispara se o estágio do ciclo de vida de qualquer registro mudar mais de três vezes em 24 horas. Isso pega as condições de corrida em que dois sistemas estão brigando pelo mesmo campo.

3. Alerta de latência de formulário-para-CRM. Dispara se qualquer envio de formulário levar mais de 90 segundos para chegar ao CRM. Os SDRs confiam no sistema com base nesta métrica mais do que em qualquer outra.

Uma consulta de conciliação diária também deveria rodar toda manhã às 6h e te enviar um e-mail (e só para você, até você confiar nela). A consulta que eu rodo no Salesforce + Marketo:

-- Registros no MAP sem contraparte no CRM, últimos 7 dias
SELECT email, lifecycle_stage, last_modified
FROM map_leads
WHERE crm_id IS NULL
  AND created > DATEADD(day, -7, CURRENT_DATE)
  AND lifecycle_stage IN ('MQL', 'SAL');

Qualquer coisa nesse conjunto de resultados é um lead que deveria ter chegado a um rep de vendas mas não chegou. Se a consulta retornar mais de 5 linhas num dia, você tem um problema de integração que ainda não conhece.

A variante de dashboard: uma visão semanal da contagem de erros de sincronização por tipo de erro, latência de repasse de MQL P50/P95 e total de registros sob cada estágio do ciclo de vida. Torne-a a página inicial do seu espaço de MOps no Confluence. Quando um VP perguntar "o sistema está saudável?", você aponta para o dashboard e diz "sim" ou "não" com dados.

Uma fonte da verdade, uma definição de MQL, um dono

Se este playbook tivesse uma única conclusão, seria esta: todo ponto de dado no seu stack de MAP+CRM tem exatamente uma fonte da verdade, um dono e uma definição. Todo o resto é gambiarra.

Quando um rep de vendas argumenta que um MQL "não é realmente um MQL", isso não é um problema de campo. É um problema de definição. Conserte a definição. Documente-a. Faça a liderança de vendas assinar por escrito. Então o campo se torna irrelevante, porque todo mundo concorda sobre o que ele significa.

Quando dois sistemas escrevem no mesmo campo, escolha um. O outro vira somente leitura ou ganha um campo de sobrescrição separado. Condições de corrida não melhoram com mais workflows.

Quando um campo personalizado não tem dono, mate-o. Se alguém notar que ele sumiu em três meses, você vai descobrir quem de fato o usava. Na maior parte das vezes, ninguém nota, e você tornou o sistema mais simples para o próximo admin que o herdar.

A gambiarra se acumula. Cada atalho que você toma neste trimestre é um problema que o seu sucessor herda no ano que vem. Às vezes a resposta certa é reconstruir. Às vezes é trocar para um stack que não exige a integração em primeiro lugar. Quase sempre, é apagar mais do que você adiciona.

Esse é o trabalho.

Playbooks de Marketing Ops