Salesforce funciona, mas a operação não confia nele
O CRM está no ar. Mesmo assim, vendedores mantêm planilha paralela, integrações criam duplicados, dashboards discordam da reunião e a equipe chama tudo de “problema do Salesforce”.
A pergunta útil é mais específica:
A falha está numa parte corrigível, no desenho inteiro da implantação ou na escolha da plataforma?
Resposta curta: corrija quando processo e modelo central ainda fazem sentido e a falha é localizada. Reimplemente dentro de Salesforce quando a plataforma continua adequada, mas objetos, permissões, automações e integrações foram montados sobre um desenho ruim. Avalie migrar quando um piloto no destino atende melhor ao trabalho e o benefício esperado justifica reconstruir dados, relações, rotinas e integrações.
Se ninguém consegue localizar a falha, ainda não compre nenhum dos três projetos. Faça o diagnóstico primeiro.
Para quem ainda vai implantar Salesforce
A Salesforce descreve implementação de CRM como avaliação de necessidades, configuração, integração, migração, testes, treinamento e acompanhamento. Comprar licença não entrega essas etapas.
Antes de comparar propostas, delimite uma jornada: oportunidade até proposta, caso até resolução ou pedido até confirmação. Liste objetos, campos mínimos, responsáveis, permissões e sistemas que precisam conversar. Depois escreva como a equipe vai aceitar cada entrega — a tabela de aceite abaixo vale tanto para a primeira implantação quanto para recuperação.
Se etapa, dono e próxima ação ainda não têm definição, o primeiro trabalho é organizar a rotina. A matriz entre planilha, CRM e helpdesk ajuda a comparar categorias sem assumir que Salesforce é a resposta. Salesforce merece avaliação quando seus requisitos de dados, acesso, integração e operação entre áreas cabem na plataforma; o tamanho da empresa sozinho não decide.
Montar meu briefing de CRM é uma opção sem contratação. Ele fica no navegador e pode ser usado com sua equipe ou qualquer consultoria. Participo da MakeITSimple; a empresa aparece como opção comercial, não como ranking de fornecedores.
Um fluxo e dez registros antes de abrir projeto
Escolha um trabalho que deveria atravessar o CRM de ponta a ponta. Pegue dez registros recentes e anote:
| Pergunta | Evidência mínima |
|---|---|
| O registro entrou por onde? | origem identificável, não memória da equipe |
| Quem era o dono do próximo passo? | usuário ou fila responsável |
| Qual etapa mudou? | mudança com significado operacional |
| Qual sistema escreveu o dado? | CRM, ERP, formulário, WhatsApp ou intervenção manual |
| A automação fez o quê? | execução e resultado observáveis |
| O cliente recebeu a ação certa? | confirmação no canal ou sistema de destino |
| A gestão consegue reconciliar? | relatório que volta aos registros de origem |
Dez registros são um ponto de partida para localizar a falha, não uma amostra estatística nem auditoria da empresa inteira. Trabalhe com acesso autorizado e não copie dados pessoais para ferramentas ou ambientes sem os controles necessários.
O template de limpeza de CRM dá uma estrutura para registrar campos, donos e regras antes de mexer no ambiente.
Matriz de decisão
Sinais: uma automação problemática, permissão localizada ou integração com erro conhecido.
Caminho: corrigir o trecho, testar os efeitos e manter o restante.
Não basta: uma correção pequena que esconda modelo de dados incoerente.
Sinais: objetos duplicam conceitos, automações se contradizem e permissões cresceram por exceção.
Caminho: redesenhar uma jornada em ambiente de teste, transicionar por etapa e desativar o legado com aceite.
Não basta: trocar telas sem reconstruir regra, dado e responsabilidade.
Sinais: requisitos cabem melhor no destino e um piloto comprova o fluxo crítico.
Caminho: testar dados e relações, planejar corte, reconciliação e recuperação em caso de falha.
Não basta: migrar só porque a implantação atual irrita.
Sinais: etapa sem definição, dono ausente e atualização atrasada.
Caminho: definir poucos campos e responsáveis, corrigir registros e repetir o teste.
Não basta: comprar migração para fugir de uma decisão de gestão.
Quando corrigir — e quando reconstruir dentro de Salesforce
Uma correção localizada é candidata quando a equipe consegue reproduzir o erro, delimitar os registros afetados, testar efeitos colaterais e manter a mudança depois. Exemplo construído: o pipeline funciona, mas uma regra antiga muda a etapa quando um campo secundário é preenchido. Se o restante do fluxo continua coerente, isso pede teste de correção antes de migração.
Equipe interna pode vencer aqui. Quem administra o ambiente conhece usuários, exceções e calendário. Se tem acesso, competência e tempo para testar, chamar consultoria antes de delimitar o defeito pode só aumentar a reunião.
Reimplementar merece avaliação quando o mesmo conceito virou vários objetos concorrentes, automações disparam efeitos sem explicação e integrações escrevem sem autoridade de origem definida. A condição é que Salesforce continue atendendo aos requisitos futuros. Preservar a plataforma por costume não é justificativa.
Uma jornada crítica primeiro, em ambiente de teste, com dados conhecidos e comparação lado a lado. O fluxo anterior só deve ser desativado quando o novo passar no aceite e tiver responsável pela sustentação. Não teste uma correção diretamente em produção para descobrir quem ela afeta.
Quando outro CRM merece um piloto
Migração não corrige automaticamente o processo. Antes de escolher destino, confira se:
- os requisitos críticos cabem no novo modelo;
- a equipe consegue administrá-lo;
- as integrações necessárias existem ou têm plano viável;
- objetos, históricos, anexos e relações importantes podem ser preservados;
- permissões e obrigações de acesso podem ser refeitas;
- corte, convivência e recuperação foram desenhados;
- o custo de reconstruir foi comparado com manter e corrigir o ambiente atual.
Licenças são só uma parte: inclua diagnóstico, implementação, migração, integração, treinamento, sustentação e eventual operação paralela. Não some o mesmo trabalho duas vezes entre propostas. Este guia não estima preço nem prazo; sem inventário, uma tabela universal esconderia o escopo.
HubSpot: uma alternativa com recurso de transferência e limites
A documentação do Smart Transfer lista Salesforce como fonte suportada. Descreve auditoria de objetos, campos, pipelines, usuários e contagens, configuração, sincronização, erros, limpeza e reversão. É uma força para quem avaliou o modelo de destino — não prova de que todo ambiente pode ser movido sem perda.
O acesso exige Super Admin. A transferência é de mão única para HubSpot e mapeamentos personalizados exigem assinatura Data Hub. Dados movidos em etapas de transferência única não ficam atualizados automaticamente. A cobertura depende do aplicativo e do tipo de dado; confira o inventário, não apenas a lista de recursos.
Se Salesforce vai continuar em uso, há um cuidado específico: HubSpot orienta usar sua integração Salesforce, em vez de Smart Transfer. A documentação avisa que os dois usam identificadores diferentes e que executá-los simultaneamente cria duplicados. Planejar convivência não é ligar as duas ferramentas e esperar que concordem.
A reversão documentada de uma transferência não deve ser tratada como restauração de toda a operação. Automações, integrações e ações feitas depois do corte precisam de um plano próprio de recuperação.
Se o piloto no destino atende o fluxo e a equipe consegue sustentá-lo com menos trabalho, migrar pode fazer sentido. Se regras, objetos e integrações complexas já cabem bem em Salesforce, a mudança pode apenas trocar dívida conhecida por dívida nova.
O aceite que impede uma implantação bonita e inútil
As boas práticas oficiais de migração da Salesforce recomendam inventariar objetos e campos, respeitar dependências, carregar um registro antes do lote, guardar IDs legados e validar contagens, amostras e erros. A documentação do Data Import Wizard informa que campos não mapeados não entram e que opções de importação podem disparar workflows e processos.
“Importou sem erro” não basta. Esta é uma proposta de aceite operacional para discutir com sua equipe ou fornecedor:
| Frente | Critério de aceite |
|---|---|
| Objetos e campos | escopo lista o que entra, fica e será aposentado |
| Relações | conta, contato, oportunidade, caso e demais dependências continuam ligados corretamente |
| IDs e reconciliação | origem e destino podem ser comparados sem depender de nome parecido |
| Contagens | totais por objeto batem ou cada diferença está explicada |
| Amostra | registros conhecidos preservam valores, dono, histórico necessário e próxima ação |
| Exceções | erros têm lista, causa, responsável e decisão de reprocessamento |
| Automações | efeitos da carga e do uso normal foram testados |
| Permissões | cada papel acessa e altera somente o necessário |
| Integrações | entrada, saída, duplicidade, atraso e indisponibilidade têm teste |
| Operação | usuários concluem o fluxo sem planilha paralela obrigatória |
| Sustentação | existe dono para corrigir regra, dado e integração depois do go-live |
| Corte e recuperação | está claro quando parar o legado e como responder se o destino falhar |
Para cada linha, registre quem aceita e qual evidência vê. “Aprovado pela TI” é insuficiente quando vendas ou atendimento não conseguem concluir o trabalho. Nem todos os dados devem migrar: registre também o que não precisa sobreviver e por quê, respeitando obrigações aplicáveis.
Um diagnóstico de sete dias sem contratar
O calendário abaixo organiza uma primeira investigação; não promete resolver uma implantação em uma semana. Se faltar acesso ou competência técnica, pare na documentação e peça avaliação antes de testar mudanças.
- Escolha o fluxo. Uma jornada crítica e dez registros recentes, com acesso autorizado.
- Defina a origem confiável. Qual sistema deveria determinar cliente, pedido, status, preço, consentimento e próxima ação?
- Reproduza a falha. Em ambiente seguro, observe onde dado, permissão, automação ou integração diverge.
- Revise o modelo. Objeto e etapa representam o trabalho ou apenas a tela configurada anos atrás?
- Teste a mudança menor. Ela resolve o trecho sem quebrar o restante? Não teste em produção.
- Compare o destino. Desenhe o mesmo fluxo numa reimplementação Salesforce e numa alternativa. Compare campos, ações, acesso, integrações e manutenção.
- Escreva a decisão e a condição de recusa. “Corrigir se o erro ficar restrito a X”; “reimplementar se Salesforce continuar atendendo Y”; “migrar se o piloto preservar A, B e C”; ou “não abrir projeto se a rotina manual resolver”.
Isso não substitui auditoria técnica. Impede que ela comece com a conclusão pronta.
Quem executa: equipe, ferramenta ou consultoria
| Caminho | Quando pode vencer | Onde não basta |
|---|---|---|
| Equipe interna | conhece o ambiente e tem capacidade de testar e manter uma correção delimitada | falta de tempo, conhecimento concentrado ou desenho estrutural sem revisão |
| Ferramenta de transferência | inventário, mapeamento e carga dentro do escopo suportado | não decide processo, responsável, retenção necessária nem aceite da operação |
| Consultoria especializada | o trabalho cruza processo, dados, integração e mudança | pode propor projeto maior que a falha ou entregar algo que ninguém mantém |
Peça diagnóstico separado da solução proposta, alternativas rejeitadas, dependências do cliente, critérios de aceite, sustentação e itens fora do escopo. Uma ferramenta de migração não elimina essas perguntas.
Quando pedir ajuda à MakeITSimple — com o vínculo declarado
Participo da MakeITSimple. A página pública de Salesforce da empresa oferece modelagem, integração, automação, indicadores, governança, treinamento e sustentação. Declara começar por processo, dados e integrações, colocar um caso crítico no ar e evoluir por etapas. Isso é oferta do fornecedor, não prova de resultado no seu caso nem comparação independente.
A empresa é uma opção quando o trabalho cruza objetos, dados, permissões e integrações. Não é vencedora automática. Se a falha é pequena e sua equipe consegue corrigir e testar, faça internamente. Se outra plataforma atende melhor e o piloto comprova a transição, escolha quem tem competência para preservar o que importa.
Avaliar implantação ou recuperação do CRM com a MakeITSimple é uma opção comercial explícita, não requisito para usar a matriz ou o checklist.
Fontes e limites
- Salesforce Brasil — implementação de CRM: etapas de implantação e acompanhamento declaradas pelo fornecedor.
- Salesforce — boas práticas de migração: inventário, dependências, IDs e validação.
- Salesforce — Data Import Wizard: mapeamento e efeitos da importação.
- Salesforce — integração de CRM: conexão de dados e rotinas, com riscos de compatibilidade, segurança, duplicidade e manutenção.
- HubSpot — Smart Transfer: recursos, requisitos e alerta sobre uso simultâneo com a integração Salesforce.
- MakeITSimple — Salesforce: oferta comercial declarada pela empresa.
Fontes conferidas em 2 de outubro de 2026. Não estimei preço, prazo, volume de busca ou “melhor CRM”. Não usei caso de cliente. O exemplo é construído; a matriz, a tabela de aceite e o diagnóstico são propostas práticas, não procedimentos certificados por esses fornecedores.
Nenhum vídeo foi usado como evidência. Para esta decisão, a matriz e os critérios escritos permitem comparar o ambiente sem depender de um tour de produto. Uma demonstração de importação não comprovaria que seu processo merece migração.
Antes de transformar a decisão em projeto
Comece pelo template de limpeza de CRM e pela amostra de registros. Se o problema é dado, leia CRM sujo mata automação. Se outra plataforma é candidata, compare o fluxo com HubSpot para atendimento e vendas, sem assumir que mais simples será suficiente.
Uma decisão boa informa o que mudar, o que preservar e qual teste pode mostrar que a escolha estava errada.