5 Erros de Arquitetura Salesforce que Custam 6 Dígitos por Ano

Salesforce é a plataforma de CRM mais poderosa do planeta. Também é a plataforma mais cara para errar.

Eu construí, herdei e resgatei implementações Salesforce por mais de 15 anos — primeiro como Sr. Technical Architect na CloudOne+ CRM Consultants, depois como co-fundador da SAASTEPS, uma plataforma de Revenue Lifecycle Management construída 100% nativa no Salesforce, no Vale do Silício. Vi orgs que rodam como máquinas, e vi orgs que custam seis dígitos por ano em licenças desperdiçadas, processos quebrados e dívida técnica que ninguém quer tocar.

A diferença quase nunca é sobre dinheiro gasto ou features compradas. É sobre cinco decisões arquiteturais que geralmente são tomadas nos primeiros 90 dias — e assombram a empresa por anos.

Aqui estão os cinco erros que vejo repetidamente. Se você é founder, CRO ou líder de receita, não precisa entender os detalhes técnicos de cada um. Precisa entender o que eles custam.

Erro #1
Estratégia de Org Errada

Essa é a decisão fundacional que erra todo o resto. Uma empresa adquire outra e cria um segundo org Salesforce ao invés de consolidar. Ou uma empresa começa com Salesforce Essentials, cresce demais, e compra Enterprise em uma instância separada. Ou diferentes regiões rodam orgs diferentes “por compliance” que na verdade são motivos políticos.

O resultado: duas (ou mais) fontes de verdade para o mesmo negócio. Dados de clientes fragmentados. Relatórios que exigem consolidação manual. Cross-sell entre unidades de negócio vira um exercício manual que ninguém faz. Trabalhei com uma empresa rodando três orgs Salesforce em duas aquisições. O time financeiro gastava 40 horas por mês reconciliando dados de pipeline numa planilha de forecast. Quarenta horas. Todo mês.

A correção: Antes de adicionar um novo org, pergunte: “Isso pode ser resolvido com um único org usando permission sets, record types e sharing rules?” Em 80% dos casos, a resposta é sim. O trabalho upfront de consolidação é real, mas o custo de fragmentação permanente é pior.

Erro #2
Over-Customization

Esse é o erro que parece progresso. Seu parceiro de implementação cria custom objects para tudo. Custom fields se multiplicam como coelhos. Cada departamento ganha seu próprio page layout com 80 campos, 60 dos quais ninguém preenche. Validation rules se empilham até que reps gastem mais tempo lutando com o sistema do que vendendo.

Herdei um org que tinha 347 custom fields no objeto Account. Trezentos e quarenta e sete. Quando perguntei quais eram usados ativamente, ninguém sabia. Qualidade de dados era péssima porque reps preenchiam qualquer coisa que passasse na validação para mover o registro adiante. Os relatórios eram tecnicamente precisos — e praticamente inúteis.

Over-customization é sedutora porque parece que você está construindo exatamente o que o negócio precisa. Na realidade, está construindo dívida técnica que torna cada mudança futura mais lenta e mais cara. Cada custom field é um compromisso de manutenção. Cada custom object é uma decisão arquitetural.

A correção: Antes de construir qualquer coisa custom, pergunte: “Salesforce já tem um standard object ou feature que faz 80% disso?” Standard objects recebem upgrades gratuitos três vezes por ano. Custom objects recebem contas de manutenção.

Erro #3
Ignorar o Modelo de Dados

O modelo de dados é o esqueleto do seu org Salesforce. Acerte, e tudo — relatórios, automação, experiência do usuário — flui naturalmente. Erre, e você gasta anos construindo workarounds em cima de uma fundação quebrada.

O exemplo clássico: uma empresa armazena todos os produtos como line items em oportunidades mas nunca constrói uma arquitetura adequada de Product-Pricebook-Quote. No primeiro ano, funciona bem. Depois precisam de CPQ. Depois de precificação multi-moeda. Depois de billing por assinatura. E de repente percebem que cada nova capacidade exige reconstruir a fundação que pularam.

Outro padrão que vejo constantemente: relacionamentos Account-Contact que não refletem como o negócio realmente funciona. Empresas B2B que vendem para organizações complexas precisam de uma hierarquia de contas adequada — parent accounts, child accounts, partner accounts, contatos influenciadores vs. decisores. A maioria das implementações achata isso em um único nível porque é mais fácil de configurar. Depois o time de vendas não consegue ver a foto completa de um deal multi-divisão, e a gestão não consegue reportar receita por família de contas.

A correção: Invista duas semanas em modelagem de dados antes de construir qualquer coisa. Mapeie cada entidade, cada relacionamento, cada lookup. Pergunte: “Em dois anos, quais perguntas o CEO vai querer respondidas? Esse modelo de dados suporta essas perguntas nativamente?” Se não, redesenhe agora. Nunca vai ser mais barato corrigir do que é hoje.

Erro #4
Parafusar Ferramentas ao Invés de Construir Nativo

Esse é o erro sobre o qual sinto mais fortemente — porque é o motivo pelo qual co-fundei a SAASTEPS.

O padrão é assim: a empresa precisa de billing, então compra uma ferramenta standalone. Precisa de assinatura eletrônica, então adiciona DocuSign. Precisa de CPQ, então acopla uma solução de CPQ. Precisa de gestão de assinaturas, então integra mais uma plataforma. Em dois anos, tem cinco ou seis ferramentas todas tocando os mesmos dados de clientes através de APIs e middleware — cada uma com seu próprio modelo de dados, seu próprio ciclo de atualização, e seus próprios modos de falha.

A camada de integração se torna a parte mais frágil de toda a operação. Quando funciona, ninguém nota. Quando quebra — e sempre quebra eventualmente — reconciliar os dados entre sistemas vira um incêndio. Já vi empresas perderem fins de semana inteiros reconciliando dados de billing depois que um problema de integração causou faturas duplicadas.

Cada integração é uma costura. Cada costura é um risco. Quanto mais você fizer nativamente na plataforma Salesforce, menos costuras você tem. Construímos a SAASTEPS 100% nativa no Salesforce não porque era mais fácil (era mais difícil), mas porque vimos o que acontece quando operações de receita são espalhadas por ferramentas desconectadas. Os dados quebram. Os processos quebram. A confiança quebra.

A correção: Antes de adicionar qualquer ferramenta nova, pergunte: “Isso pode ser feito nativamente na plataforma que já temos?” Se a resposta é sim — mesmo que exija mais trabalho upfront — o custo de longo prazo é quase sempre menor. E se precisar integrar, construa assumindo que vai falhar, e desenhe o caminho de recuperação antes de ir ao ar.

Erro #5
Sem Governança de Automação

Salesforce torna automação acessível. Flows, Process Builder (agora deprecated mas ainda assombrando milhares de orgs), triggers, workflow rules — qualquer pessoa com acesso de admin pode construir automação. E elas constroem. Com entusiasmo. Sem coordenação.

O resultado é o que eu chamo de espaguete de automação: dezenas de automações disparando nos mesmos objetos, em ordem imprevisível, sem documentação e sem dono. Um lead é criado e sete coisas acontecem simultaneamente — um e-mail envia, uma task cria, um campo atualiza, uma notificação Slack dispara, um registro atribui, um campaign member adiciona, e uma checagem de duplicatas roda. Ninguém sabe qual automação faz o quê. Ninguém sabe a ordem de execução. E quando algo quebra, ninguém sabe onde procurar.

Auditei um org no ano passado que tinha 94 flows ativos e 12 Apex triggers somente no objeto Opportunity. Quando um rep mudava o stage de uma oportunidade, 23 automações disparavam. A página levava 11 segundos para salvar. Reps começaram a evitar atualizações de stage porque o sistema era lento demais — o que destruiu a precisão de cada relatório de pipeline na empresa.

Isso não é um problema de adoção de usuários. É um problema de arquitetura.

A correção: Implemente governança de automação agora. Documente cada flow, cada trigger, cada ação agendada. Atribua um dono para cada uma. Estabeleça um processo de review para novas automações — nenhuma automação vai ao ar sem entender sua interação com as existentes. Consolide onde possível: cinco flows fazendo coisas relacionadas no mesmo objeto deveriam ser um flow com lógica de decisão clara. E pelo amor de dados limpos, aposente o Process Builder. Migre tudo para Flows.

O Fio Condutor

Repare em algo sobre os cinco erros: nenhum deles é sobre features. São sobre decisões. Decisões estruturais que geralmente são tomadas cedo, sob pressão de tempo, por pessoas pensando no que o negócio precisa neste trimestre — não no que a arquitetura precisa suportar nos próximos cinco anos.

É por isso que esses erros são tão caros. Não se anunciam com mensagens de erro. Se acumulam silenciosamente — em processos mais lentos, em dados mais sujos, em relatórios que ninguém confia, em times que trabalham ao redor do sistema ao invés de através dele.

A boa notícia: cada um deles é corrigível. Não facilmente. Não barato. Mas corrigível. E quanto antes você endereçar, menos custam.

Se seu org Salesforce parece estar trabalhando contra você ao invés de para você, o problema não é o Salesforce. É a arquitetura. E arquitetura é o que eu faço.