Existe um tipo de reunião que se repete com uma frequência incômoda no mercado brasileiro de CRM. A diretoria senta com o time, olha para o Salesforce que comprou dezoito meses atrás e chega a uma conclusão desconfortável: o projeto não terminou, ninguém sabe dizer o que exatamente foi entregue, e a pessoa que sabia responder isso não trabalha mais na consultoria que implantou. O contrato ainda está em pé, as licenças continuam sendo pagas, e a resposta que chega quando alguém cobra prazo é sempre uma variação de “está na fila”.
O reflexo natural é achar que a solução é trocar de parceiro. Às vezes é mesmo. Mas trocar sem diagnóstico costuma produzir exatamente o mesmo resultado seis meses depois, com um custo a mais: agora existem duas camadas de customização feitas por gente diferente, sem documentação, disputando o mesmo objeto. A troca de parceiro Salesforce não é uma decisão de fornecedor. É uma decisão técnica que precisa ser tomada com dado na mão.
Este artigo é sobre como fazer isso direito: como saber se o caso é realmente de troca, o que precisa estar documentado antes de encerrar o contrato atual, e como conduzir a transição para que o investimento já feito seja aproveitado em vez de descartado.
O problema quase nunca é o Salesforce — é a camada que colocaram em cima dele
Vale começar separando duas coisas que costumam ser confundidas na mesma frase.
A plataforma raramente é a origem da falha. O Salesforce é uma das plataformas mais maduras do mercado corporativo, com ciclo de release trimestral e uma arquitetura documentada publicamente. Quando uma operação diz que “o Salesforce não funciona”, o que quase sempre está funcionando mal é a configuração específica que alguém construiu ali dentro: automações sobrepostas, campos criados para resolver um pedido pontual e nunca removidos, perfis de permissão duplicados, integrações que quebram silenciosamente e ninguém percebe até o vendedor reclamar que o pedido não chegou no ERP.
A camada de customização é o que envelhece mal. A própria Salesforce trata isso como uma disciplina de arquitetura no framework Well-Architected, que define uma solução confiável como aquela que “opera de forma efetiva e previsível” e se sustenta em três princípios — disponibilidade, performance e escalabilidade. Uma org que acumulou três anos de ajustes emergenciais sem governança falha nos três. Não porque o produto seja ruim, mas porque ninguém está mais cuidando da estrutura.
Isso muda o enquadramento da conversa. A pergunta não é “esse parceiro é ruim?”, e sim “o que existe na minha org hoje, quanto disso presta, e quem tem competência para assumir a partir daqui?”.
Números de mercado ajudam a dimensionar o quanto isso é comum: levantamentos recorrentes sobre projetos de CRM apontam taxas de insucesso próximas de 55%, com a maior parte das causas concentrada em adoção, qualidade de dado e falta de governança — não em limitação de tecnologia.
Antes de trocar, separe o que é problema de parceiro do que é problema de escopo
Nem toda frustração com um projeto Salesforce se resolve trocando quem executa. Vale um teste honesto antes de abrir a conversa.
É problema de escopo quando a empresa comprou uma coisa e esperava outra. Isso acontece mais do que se admite: a proposta previa um MVP de Sales Cloud com funil, contas e relatórios, mas a expectativa interna era ter também integração com o ERP, portal de parceiros e automação de marketing. O parceiro entregou o que foi contratado. A operação recebeu menos do que precisava. Trocar de fornecedor aqui não resolve — o novo vai enfrentar a mesma lacuna, e você vai pagar duas vezes pelo mesmo aprendizado.
É problema de parceiro quando o combinado não chega, e a explicação também não. Prazos que escorregam sem repactuação formal, entregas homologadas por e-mail sem critério objetivo, ausência de documentação do que foi configurado, rotatividade de consultor a cada dois meses e ninguém que consiga explicar por que determinada automação existe. Se você não consegue obter, por escrito, a lista do que está implantado e por quê, isso não é atraso — é falta de método.
É problema de sustentação quando o projeto terminou, mas ninguém ficou. Muita empresa acha que precisa de um novo implementador quando na verdade precisa de sustentação Salesforce — alguém responsável por manter, ajustar e evoluir a org depois do Go Live. Os sinais de que a operação precisa de sustentação são bem diferentes dos sinais de que o parceiro falhou, e confundir os dois leva a contratar o serviço errado.
Se depois desse filtro a conclusão continua sendo troca, o próximo passo é o mais importante — e o mais pulado.
O diagnóstico é o que separa uma transição de um recomeço
Trocar de parceiro sem levantar o estado real da org é o equivalente a trocar de médico sem levar os exames. O novo time vai gastar as primeiras semanas descobrindo o que já existe, e você vai pagar por essa descoberta em horas de projeto.
Um diagnóstico mínimo de takeover precisa responder cinco coisas:
Qual é o inventário real da org. Objetos customizados criados, campos por objeto, quantos deles têm dado preenchido, automações ativas (Flows, Process Builder legado, Apex triggers, regras de workflow), classes de código e cobertura de testes. A Salesforce descontinuou o Optimizer na release Winter ’26 e o substituto recomendado para esse tipo de varredura de metadados é o Org Check, distribuído gratuitamente via AppExchange. Não é sofisticado, mas transforma “acho que tem bastante coisa aqui” em uma lista.
Qual é a postura de segurança. O Security Health Check nativo do Salesforce dá uma nota de 0 a 100 comparando as configurações de segurança da org contra uma baseline padrão, e permite criar baselines customizadas. É um número objetivo, gerado pela própria plataforma, e serve muito bem como marco: essa é a foto do dia em que o novo parceiro assumiu.
O que está integrado e como. Quais sistemas trocam dado com o Salesforce, por qual mecanismo, com qual frequência e o que acontece quando falha. Integrações com ERP são, na nossa experiência, o ponto onde a documentação some primeiro e onde a ausência dela custa mais caro.
Quem usa e como usa. Licenças contratadas versus licenças ativas, login nos últimos 30 dias, percentual de oportunidades atualizadas no mês. Adoção baixa muda completamente o plano de trabalho: não adianta refatorar automação se o time comercial abandonou a ferramenta.
O que está fora de escopo mas foi prometido. Vale a pena listar, com nome e data, o que foi verbalmente prometido e nunca contratado. Isso não serve para litígio; serve para o novo parceiro não repetir a promessa.
O que você precisa ter em mãos antes de encerrar o contrato atual
Aqui está a parte que quase ninguém organiza a tempo, e que determina se a transição vai ser cara ou não.
Acesso administrativo pleno, no nome da empresa. Parece óbvio e frequentemente não é o caso. Existem orgs em que o único usuário com perfil System Administrator pertence à consultoria. Antes de qualquer conversa de encerramento, garanta pelo menos dois administradores internos ativos, com e-mail corporativo da sua empresa.
Os repositórios e artefatos de código. Se houve desenvolvimento Apex, LWC ou integração customizada, o código-fonte e o histórico de versões precisam estar em um repositório sob controle da sua empresa. Contrato de implementação sério prevê isso; se o seu não previa, esse é o momento de negociar a entrega, ainda com o contrato vigente.
Credenciais e configuração de integrações. Named Credentials, Connected Apps, chaves de API, endpoints de homologação e produção, e o desenho de quem chama quem. Perder isso é o que transforma uma transição de quatro semanas em um projeto de reintegração de três meses.
A documentação funcional do que foi construído. Nem que seja precária. Um mapa de processos, os critérios de homologação aceitos, as decisões de arquitetura tomadas e o motivo delas. Se não existir, peça a extração antes do encerramento — depois do fim do contrato, a boa vontade evapora.
O contrato lido com atenção. Cláusulas de propriedade intelectual das customizações, prazo de aviso prévio, obrigações de transição e o que acontece com as horas de banco não consumidas. Vale a leitura por alguém do jurídico, não só do time de TI.
Como é uma transição bem conduzida
Uma troca de parceiro bem feita tem uma característica que a distingue de um recomeço: em nenhum momento a operação comercial para.
Semana 1 a 2 — levantamento e foto do estado atual. O novo parceiro roda o inventário de metadados, o Health Check, o mapa de integrações e entrevista as áreas usuárias. O entregável é um relatório com o que existe, o que está quebrado, o que é dívida técnica tolerável e o que é risco.
Semana 2 a 4 — plano de estabilização. Antes de evoluir qualquer coisa, para o sangramento: automações duplicadas, integrações falhando em silêncio, permissões abertas demais. Estabilização primeiro, roadmap depois. Parceiro que chega propondo redesenho completo na primeira reunião não olhou a org.
A partir da semana 4 — governança e backlog priorizado. Aqui entra a rotina que provavelmente faltava no arranjo anterior: ritual de priorização, critério de aceite escrito, ambiente de homologação de verdade e responsável nomeado de cada lado. É o assunto de governança e adoção do CRM — e é o que evita que a próxima troca aconteça daqui a dois anos.
Em paralelo — decisão sobre o que reaproveitar. Nem tudo precisa ser refeito. Boa parte da configuração de uma org problemática é aproveitável; o que costuma ser descartado são automações redundantes e campos órfãos. Um parceiro que propõe reconstruir do zero está, na maioria das vezes, evitando o trabalho de entender o que já existe.
Os três erros que transformam a troca em um segundo projeto problemático
Encerrar o contrato antes de contratar o próximo. O intervalo sem ninguém responsável pela org é onde as coisas quebram sem que ninguém perceba. Sobreponha as duas relações por pelo menos duas semanas, mesmo que custe.
Escolher o substituto pelo preço da proposta. A proposta mais barata para um takeover geralmente é a que não incluiu o diagnóstico — e vai cobrar por ele depois, como aditivo, quando você já não tiver alternativa. Compare escopo, não valor final. Esse é o mesmo raciocínio que vale na hora de escolher um parceiro Salesforce para qualquer projeto.
Contratar quem promete sem ter olhado a org. Se a consultoria fecha proposta de takeover sem acesso ao ambiente, o número dela é chute. Ou vai virar aditivo, ou vai virar entrega parcial. Peça um diagnóstico pago e curto antes do projeto grande — é a forma mais barata de testar o método de quem você está contratando.
Vale também verificar o histórico do candidato no diretório de consultores da AppExchange, onde as listagens trazem avaliações de projetos verificadas pela própria Salesforce. Não é garantia, mas é uma checagem que custa dez minutos.
O que muda quando o novo parceiro assume com diagnóstico em vez de promessa
A diferença prática aparece no terceiro mês. Uma transição feita com levantamento na frente chega ao fim do primeiro trimestre com a org estabilizada, o backlog priorizado com a área de negócio e um número de Health Check melhor do que o do dia da entrada. Uma transição feita na base da promessa chega ao terceiro mês com um roadmap bonito e os mesmos problemas do começo.
Na Levora, projetos de takeover começam sempre pelo diagnóstico, não pela proposta de implementação. É uma escolha comercial que às vezes custa a venda rápida — mas é a única forma de dar um número que se sustenta até o fim.
Perguntas frequentes
Posso trocar de parceiro Salesforce no meio de um projeto?
Pode, e às vezes é o certo a fazer. O ponto de atenção é contratual: verifique cláusulas de rescisão, aviso prévio e propriedade das customizações já entregues. Do lado técnico, o requisito é garantir acesso administrativo interno, o código-fonte e as credenciais de integração antes do encerramento. Com isso em mãos, a troca no meio do caminho costuma ser menos traumática do que terminar um projeto que já se sabe que não vai funcionar.
Vou perder o que já foi implementado se trocar de consultoria?
Não. A org, os dados e as customizações são da sua empresa e permanecem na sua instância Salesforce — o que muda é quem administra. O risco real não é perder a configuração, é perder o conhecimento sobre ela: por que cada automação existe, o que cada integração faz. Por isso a documentação e a sobreposição de contratos importam tanto.
Quanto tempo leva uma transição de parceiro Salesforce?
Para uma org de porte médio, o diagnóstico leva de duas a quatro semanas e a estabilização inicial mais quatro a seis. Orgs com muitas integrações ativas ou dívida técnica acumulada de vários anos levam mais. O que não é razoável é um parceiro prometer assumir “imediatamente” sem período de levantamento — isso significa que ele vai descobrir a org enquanto cobra por horas de projeto.
Como sei se o problema é o parceiro ou a minha própria operação?
Um teste simples: peça ao parceiro atual a lista do que está implantado, os critérios de homologação aceitos e o desenho das integrações. Se vier em uma semana, o problema provavelmente é de escopo, priorização ou adoção interna — e é resolvível sem troca. Se não vier, a resposta já é a resposta.
Vale contratar sustentação em vez de um novo projeto de implementação?
Em muitos casos, sim. Quando a org está funcional mas negligenciada, o que falta é rotina de manutenção e evolução, não uma nova implementação. Os modelos de preço da sustentação Salesforce costumam ser bem mais previsíveis do que um projeto de refazimento, e resolvem a maior parte dos casos de abandono.
| Herdou uma org Salesforce que ninguém sabe explicar? A Levora é consultoria boutique parceira Salesforce, com 8 anos de experiência e mais de 70 projetos entregues — incluindo takeovers de projetos travados por outras consultorias. Começamos sempre pelo diagnóstico, com número fechado, antes de qualquer proposta de evolução. Agende seu diagnóstico gratuito |
Fontes citadas neste artigo
Salesforce Architects — Well-Architected: Reliable
Salesforce Admins — Optimizer Is Sunsetting: Learn How To Use Org Check
Salesforce Help — Salesforce Security Health Check
Salesforce AppExchange — Salesforce Consultants
Johnny Grow — The CRM Failure Rate is 55%