A história se repete com frequência inquietante: empresa investe meses em uma implementação Salesforce, passa pelo go-live, e seis meses depois a situação não melhorou da forma esperada. Os usuários ainda reclamam. Os relatórios ainda não batem com a realidade. Os vendedores ainda usam planilhas.
Nesse ponto, a conversa costuma ir para dois lugares: ou "o sistema não é bom" ou "a equipe não aderiu". Na maioria das vezes, nenhum dos dois está certo.
O que está errado é a implementação.
Na 3DES, fazemos auditorias de implementações Salesforce regularmente — algumas realizadas por outras consultorias, algumas por equipes internas. E os problemas que encontramos seguem padrões muito reconhecíveis. Estes cinco sinais são os mais frequentes e os mais reveladores.
Sinal 1: O sistema exige trabalho manual demais
O Salesforce foi implementado. Mas a equipe ainda:
·Exporta dados para Excel para fazer análises que "o sistema não consegue mostrar"
·Preenche o mesmo dado em dois lugares diferentes (CRM e planilha de controle)
·Precisa de múltiplos cliques e etapas manuais para completar um processo que deveria ser automático
·Cria relatórios fora do Salesforce porque os do sistema "são lentos" ou "não mostram o que precisamos"
Quando o trabalho manual se acumula ao redor de um sistema que foi implementado para eliminá-lo, o sinal é claro: as automações estão ausentes onde deveriam existir, mal configuradas, ou o sistema foi configurado sem entender o processo real de quem o usa.
O que a auditoria vai encontrar:
Automações ausentes: processos que deveriam ser automatizados mas nunca foram configurados, porque o escopo da implementação foi cortado ou porque o processo não foi mapeado corretamente antes do desenvolvimento.
Automações quebradas que ninguém reportou: Flows com erros que estão gerando registros incorretos ou falhando silenciosamente. Em orgs sem monitoramento ativo de automações, erros ficam semanas sem ser detectados — e a equipe compensa manualmente sem perceber que é um bug.
Integrações que nunca funcionaram corretamente: a integração com ERP, email marketing ou ferramenta de suporte foi prometida no escopo mas nunca foi testada com dados reais, ou foi implementada sem tratamento de falhas.
Layout de página que não reflete o fluxo de trabalho: campos importantes enterrados em seções que nunca aparecem, campos obrigatórios que os usuários não preenchem porque o processo real começa em outro lugar.
Custo de não resolver: equipes que trabalham em paralelo ao sistema — metade no CRM, metade nas planilhas — nunca criam dados de qualidade suficiente para que o CRM seja útil. É um ciclo vicioso que se agrava com o tempo.
Sinal 2: Os usuários não confiam nos dados do CRM
Esta é a forma como o sinal aparece na prática: você pergunta ao gestor de vendas "qual é o pipeline atual?" e ele não abre o Salesforce — ele abre uma planilha. Ou pior: ele abre o Salesforce e começa a explicar por que os números que aparecem "não são exatamente isso".
Quando as pessoas que deveriam usar o sistema como fonte de verdade não confiam nos dados que ele mostra, há um problema fundamental de qualidade de dados ou de processo.
O que a auditoria vai encontrar:
Dados duplicados: o mesmo lead, contato ou conta cadastrado múltiplas vezes. Sem Duplicate Rules configuradas ou com Duplicate Rules muito permissivas, a base vai acumulando duplicatas que distorcem relatórios e criam confusão sobre qual registro é o "oficial".
Campos sem padronização: segmento do cliente em 12 variações diferentes ("Financeiro", "Fin", "Financial", "Setor Financeiro"...) porque não havia picklist controlada. Isso torna filtros e segmentações impossíveis de confiar.
Dados históricos incorretos migrados na implementação: migrações de dados feitas sem limpeza adequada trazem inconsistências do sistema anterior. O problema fica invisível por meses até que alguém tenta usar esses dados para uma análise importante.
Campos preenchidos incorretamente por necessidade: usuários que preenchem um campo obrigatório com qualquer valor só para conseguir salvar o registro — porque o campo não faz sentido para o processo deles ou porque o dado real ainda não existe naquele momento.
Custo de não resolver: dados em que ninguém confia criam um problema de adoção que é muito mais difícil de reverter do que um problema técnico. Quando a cultura da organização estabeleceu que "o CRM não é confiável", recuperar essa confiança exige evidência consistente de que os dados estão corretos — e isso leva tempo.
Sinal 3: Relatórios e dashboards não refletem a realidade
O diretor abre o dashboard de vendas e os números não batem com o que ele sabe que é verdade. O forecast do CRM mostra R$ 2 milhões de pipeline, mas o time sabe que desse valor apenas R$ 800 mil estão realmente ativos.
Ou há dois relatórios diferentes — criados por pessoas diferentes para responder à mesma pergunta — que mostram números diferentes. E ninguém sabe qual dos dois está certo.
O que a auditoria vai encontrar:
Critérios de filtro inconsistentes: relatórios usando campos de data diferentes para responder à mesma pergunta. "Oportunidades fechadas este mês" pode usar Data de Fechamento, Data de Última Modificação ou Data de Criação — cada um produz um número diferente. Sem padronização de quais campos são usados para quais análises, os relatórios produzem resultados inconsistentes.
Métricas sem definição formal: o que conta como "oportunidade ativa"? Só oportunidades em estágio de Proposta para frente? Qualquer oportunidade aberta? Oportunidades com atividade nos últimos 30 dias? Se não há uma definição formal, cada relatório usa um critério diferente.
Campos de forecast mal configurados: probabilidades por estágio que não refletem a realidade histórica de conversão da empresa. Se o sistema sugere 90% de probabilidade para oportunidades em Negotiation, mas a conversão real nesse estágio é de 40%, o forecast vai ser sistematicamente errado.
Registros em estágio incorreto: oportunidades que não avançaram de estágio porque ninguém atualizou, ou que foram movidas para "Fechado-Ganho" antes do contrato estar assinado. A limpeza de pipeline raramente acontece de forma sistemática sem processo definido.
Custo de não resolver: decisões de negócio tomadas com base em dados incorretos. Contratações baseadas em forecast equivocado. Comissões calculadas de forma errada. Estratégia de produto construída sobre análise de base de clientes que não reflete a realidade.
Sinal 4: Cada mudança no sistema é um projeto de alto risco
Alguém quer adicionar um campo novo. O admin faz a mudança e, na semana seguinte, um Flow começa a falhar porque estava usando a ausência daquele campo como lógica implícita. Ou uma Validation Rule que ninguém lembrava que existia começa a bloquear registros de uma forma que ninguém esperava.
Quando qualquer mudança de configuração — mesmo uma aparentemente simples — exige horas de testes e gera ansiedade sobre o que pode quebrar, a arquitetura foi construída de forma frágil, sem separação de responsabilidades e sem documentação de dependências.
O que a auditoria vai encontrar:
Automações com dependências implícitas não documentadas: um Flow que funciona corretamente só porque outro Flow rodou antes e preparou os dados de uma certa forma. Quando o primeiro Flow é modificado ou desativado, o segundo quebra de forma inesperada.
Campos críticos usados em muitos lugares sem documentação: um campo de Status que é referenciado em 15 Flows, 8 Validation Rules, 3 relatórios e uma integração. Qualquer mudança nesse campo — renomear um valor de picklist, torná-lo obrigatório, alterar o tipo — tem efeitos cascata não mapeados.
Ausência de sandbox atualizado: mudanças sendo testadas diretamente em produção porque o sandbox está desatualizado ou não existe. Ou sandbox existe mas não tem dados representativos suficientes para que os testes sejam significativos.
Código sem testes automatizados: Triggers Apex com cobertura de teste mínima (75%) que não testam casos de borda. Um teste que apenas chama o código sem validar se o resultado é correto não oferece proteção real.
Custo de não resolver: equipes técnicas que gastam metade do tempo evitando o sistema em vez de evoluí-lo. Velocidade de entrega que vai caindo conforme a complexidade acumulada torna cada mudança mais arriscada.
Sinal 5: A adoção pelos usuários está estagnada ou caindo
Seis meses depois do go-live, a taxa de login caiu 30%. As oportunidades não estão sendo atualizadas. Atividades não estão sendo registradas. Os usuários fazem o mínimo necessário para não receber uma reclamação — e voltam para as ferramentas que conhecem.
Baixa adoção é frequentemente diagnosticada como "problema de treinamento" ou "resistência à mudança". Na maioria das vezes, é sinal de que o sistema não está funcionando para quem precisa usá-lo — seja pela usabilidade, pela utilidade percebida ou pela falta de conexão entre o que o sistema pede e o que o processo real demanda.
O que a auditoria vai encontrar:
Layouts de página que não refletem o fluxo de trabalho: campos mais importantes enterrados em seções que exigem scroll, campos irrelevantes ocupando espaço premium no topo da página. Se o usuário precisa rolar 3 vezes para encontrar o campo que usa 10 vezes por dia, ele vai evitar o sistema.
Campos obrigatórios que criam atrito sem agregar valor: campos tornados obrigatórios na implementação por "boa prática" mas que os usuários não têm como preencher no momento em que o registro é criado. O resultado é preenchimento com valores fictícios ou recusa em criar registros no sistema.
Falta de mobile adequado: vendedores externos que precisam registrar atividades no celular, mas o layout mobile nunca foi configurado. A experiência mobile padrão do Salesforce é funcional — não é boa o suficiente para adoção.
Ausência de valor percebido pelos usuários: o CRM foi vendido internamente como benefício para a empresa (relatórios melhores, visibilidade do pipeline), mas não como benefício para o vendedor (menos trabalho administrativo, lembretes automáticos de follow-up, visão do histórico do cliente). Quando o usuário não vê o "por que isso me ajuda", a adoção é por obrigação — e obrigação não sustenta.
Custo de não resolver: um CRM com baixa adoção não é apenas um investimento desperdiçado — é um passivo. Os dados que entram são de baixa qualidade, o que torna o sistema ainda menos útil, o que reduz ainda mais a adoção. O ciclo se fecha e reverte só com intervenção ativa.
O que fazer se você se reconheceu em dois ou mais desses sinais
Esses sinais não desaparecem com o tempo — eles se agravam. E o custo de remediar aumenta conforme mais dados incorretos entram no sistema e mais processos são construídos em cima de uma base frágil.
A primeira etapa é um diagnóstico estruturado: entender exatamente quais são os problemas, qual a causa raiz de cada um e qual a prioridade de endereçamento. Não adianta corrigir a qualidade de dados antes de corrigir o processo que está gerando dados ruins.
Perguntas frequentes sobre auditoria de Salesforce
O que uma auditoria de Salesforce analisa?
Uma auditoria técnica e funcional cobre: arquitetura de dados (objetos, campos, relacionamentos), automações (Flows, Triggers, código Apex), qualidade de dados (duplicidade, completude, consistência), segurança e permissões, integrações e adoção pelos usuários. O resultado é um relatório priorizado com problemas identificados e plano de remediação.
Quanto tempo leva uma auditoria de Salesforce?
Para orgs de médio porte (50-200 usuários, complexidade moderada), uma auditoria completa leva tipicamente de 2 a 4 semanas. Orgs maiores ou com mais complexidade técnica podem levar de 4 a 8 semanas.
Minha implementação foi feita há dois anos. Ainda vale a pena auditar?
Especialmente depois de dois anos. Implementações que funcionaram bem no início acumulam débito técnico com o tempo: automações adicionadas sem planejamento, dados que se degradaram, permissões que nunca foram revisadas. Uma auditoria após 18-24 meses é uma manutenção preventiva que evita crises.
O que é o ROI de uma auditoria de Salesforce?
Difícil quantificar de forma genérica — depende dos problemas encontrados. Mas no mínimo: implementações com adoção baixa têm custo de licença por usuário que não está sendo aproveitado. Dados incorretos geram decisões de negócio erradas. Automações quebradas criam trabalho manual que tem custo de tempo. A remediação desses problemas tem retorno direto e mensurável.
Preciso de uma auditoria para implementar Agentforce ou IA?
Sim — essa é a preparação mais crítica antes de qualquer iniciativa de IA. Um agente de IA produz resultados proporcionais à qualidade dos dados que alimentam suas respostas. Implementar Agentforce sobre uma base de dados com os problemas descritos acima produz um agente que dá respostas incorretas ou genéricas — o que é pior do que não ter o agente.
