Não São Casos Isolados
Já auditamos portais HubSpot de empresas B2B de todos os tamanhos. Startups de cinco pessoas. Scale-ups de oitenta. Setores diferentes, processos de venda diferentes, times estruturados de formas diferentes.
E adivinha? Os mesmos cinco erros de arquitetura aparecem em praticamente todos.
Não estamos falando de problemas técnicos obscuros. São decisões de fundação que foram tomadas — ou puladas — lá no setup original. E elas se acumulam com o tempo. Quando o time percebe que algo está errado, geralmente já vem perdendo negócios, reportando receita errada e queimando horas em trabalho manual há meses.
A parte frustrante: esses erros são quase sempre evitáveis. Eles acontecem porque o portal foi configurado às pressas, ou por alguém que conhecia as funcionalidades do HubSpot mas não entendia o processo de negócio por trás delas. A ferramenta funciona bem. A arquitetura, não.
Aqui está o que encontramos — e por que isso importa mais do que a maioria dos times imagina.
1. Estágios de Pipeline Que Não Refletem Como Você Vende de Verdade
Esse é o erro mais comum. E também o que mais machuca.
Abrimos um portal e encontramos estágios como 'Reunião Agendada', 'Qualificado para Compra' e 'Decisor Convencido'. São os estágios padrão do HubSpot — e descrevem um processo de vendas genérico que quase nenhuma empresa B2B de serviços segue de verdade.
O custo real disso: quando os estágios não refletem o seu processo de vendas, os vendedores começam a pular etapas — e os dados do pipeline deixam de ser confiáveis. Ou encaixam negócios à força em estágios que não se aplicam — e a sua previsão de vendas perde o sentido.
O relatório de pipeline diz que você tem US$ 200 mil em 'Decisor Convencido'. Mas o que isso significa na prática? Ninguém no time sabe responder. O estágio não corresponde a nada real.
Como é uma boa arquitetura: estágios de pipeline que espelham as etapas reais pelas quais um negócio passa na sua empresa, com as palavras que o seu time já usa. Cinco a sete estágios, no máximo. E cada estágio com um critério de entrada claro, que qualquer vendedor explica de cabeça.
Se você não consegue descrever em uma frase o que move um negócio do Estágio A para o Estágio B, os estágios precisam ser refeitos. É exatamente esse tipo de raciocínio arquitetural que levamos para toda implementação de HubSpot: pipelines desenhados em torno de como o seu time realmente opera — não de como um template assume que ele opera.
2. Excesso de Propriedades: Centenas de Campos Que Ninguém Preenche
Encontramos com frequência portais com 300, 400, até mais de 500 propriedades customizadas. A maioria vazia em 90% dos registros.
Alguém criou 'Subcategoria de Setor' seis meses atrás, para um relatório que nunca saiu do papel. Outra pessoa criou 'Origem do Lead - Detalhe' sem perceber que o detalhamento de origem original já capturava a mesma coisa. Soa familiar?
O custo real disso: cada propriedade vazia é um relatório quebrado. Quando o time não confia nos dados, para de usar o HubSpot para decidir. Volta para a planilha e para o feeling. Você está pagando por um CRM em que ninguém confia.
E piora: o excesso de propriedades torna o onboarding de novos vendedores um sofrimento. A pessoa abre um contato, vê 40 campos e não faz ideia de quais importam.
Como é uma boa arquitetura: menos propriedades, taxas de preenchimento mais altas. Como ponto de partida, costumamos recomendar de 15 a 20 propriedades customizadas de contato e de 8 a 12 de negócio. Toda propriedade deve responder a uma pergunta: 'que decisão esse dado habilita?'. Se você não consegue nomear a decisão, não precisa da propriedade.
Um portal limpo, com 20 propriedades e 95% de preenchimento, gera insights muito melhores do que um portal inchado com 200 propriedades e 15%. Nas nossas implementações, auditamos e enxugamos as propriedades antes de construir qualquer coisa nova. É uma das atividades de maior ROI do projeto inteiro.
3. Estágios de Ciclo de Vida Que Não Significam Nada
Os estágios de ciclo de vida do HubSpot (Subscriber, Lead, MQL, SQL, Opportunity, Customer) são poderosos — quando bem definidos.
Na maioria dos portais que auditamos, eles simplesmente não foram definidos.
Contatos ficam como 'Lead' para sempre. A fronteira entre MQL e SQL é 'quando vendas resolver ligar'. E o marketing não consegue medir conversão, porque os estágios não têm gatilhos claros.
O custo real disso: sem estágios de ciclo de vida bem definidos, alinhar marketing e vendas é impossível. O marketing não consegue provar quais campanhas geram pipeline qualificado. Vendas não consegue dizer ao marketing quais leads valem o tempo deles. Todo mundo se frustra — e começa o jogo do empurra-empurra.
Já vimos times perderem trimestres inteiros discutindo qualidade de lead, quando o problema real era mais simples: ninguém tinha definido o que 'qualificado' significa no HubSpot.
Como é uma boa arquitetura: toda transição de estágio tem um gatilho documentado. Um Lead vira MQL quando atinge critérios específicos (pontuação de lead, envio de formulário, sinais de comportamento). Um MQL vira SQL quando vendas aceita e confirma o fit. E esses gatilhos são garantidos por workflows e automações, para que os dados se mantenham limpos sozinhos.
Essa estrutura de ciclo de vida é parte central do nosso trabalho de fundamentos de RevOps. É uma das primeiras coisas que desenhamos, antes de tocar em qualquer configuração técnica.
4. Sem Padrão de Cadastro: Cada Um Faz de Um Jeito
Abrimos os registros de empresas e encontramos 'Acme Corp', 'ACME', 'Acme Corporation' e 'acme corp'. Quatro registros. A mesma empresa. Cada um com contatos diferentes associados.
Telefones salvos em cinco formatos diferentes. Alguns vendedores registram as ligações no HubSpot. Outros usam o campo de notas. Outros não registram nada.
O custo real disso: registros duplicados significam histórico fragmentado. Um negócio associado à 'Acme Corp' não mostra a conversa de e-mail anexada à 'ACME'. Seus relatórios contam contatos em dobro. Seus e-mails vão para duplicatas — e a entregabilidade sofre.
E quando um vendedor sai da empresa? O conhecimento fica espalhado em registros que ninguém encontra.
Como é uma boa arquitetura: convenções de nomenclatura, regras de formatação e um processo de gestão de duplicatas desde o primeiro dia. O Operations Hub do HubSpot oferece formatação automática de dados, mas mesmo nos planos menores, convenções simples já fazem uma diferença enorme: formato padronizado de nome de empresa, campos obrigatórios em cada estágio do pipeline, uma revisão mensal de duplicatas.
Quando implementamos o HubSpot para um cliente, governança de dados não é detalhe para depois. Ela entra no setup desde o início — porque já vimos o que acontece quando não entra.
5. Relatórios Construídos Depois, em Vez de Desenhados na Arquitetura
Esse é o padrão mais doloroso.
O time usa o HubSpot por 6 a 12 meses. Aí a liderança pede um relatório de receita. A pessoa de ops tenta montar e descobre que a estrutura de dados não sustenta o relatório: valores de negócio não foram registrados de forma consistente, datas de fechamento foram alteradas depois, o pipeline foi reestruturado no meio do trimestre sem nenhum registro histórico.
O custo real disso: não dá para gerar relatório de dado que não foi capturado. Correções retroativas ou são impossíveis, ou exigem uma limpeza manual dolorosa. Já vimos times gastarem mais de 40 horas reconstruindo relatórios trimestrais porque a arquitetura não foi pensada para reporting.
Como é uma boa arquitetura: comece pelas perguntas que a liderança vai fazer. 'Qual é a nossa taxa de fechamento por origem?' 'Qual é o nosso ciclo médio de vendas?' 'Quanto pipeline o marketing gerou neste trimestre?' Depois, trabalhe de trás para frente, garantindo que propriedades, estágios e workflows capturem os dados que esses relatórios precisam.
Todo dashboard deve estar funcionando no primeiro dia da implementação — não construído às pressas meses depois. Essa abordagem de começar pelos relatórios é uma marca de como desenhamos implementações. Afinal, o propósito de um CRM é ajudar a decidir. E ninguém decide bem sem dados confiáveis.
O Padrão Por Trás do Padrão
Esses cinco erros têm uma única causa raiz: o portal foi configurado pensando em funcionalidades, não em arquitetura.
Alguém aprendeu a criar um pipeline, montar um workflow ou adicionar uma propriedade. E criou. Mas ninguém desenhou o sistema como um todo.
O HubSpot é uma plataforma poderosa. Ele consegue rodar a sua operação de receita inteira — quando é arquitetado com intenção. Mas a mesma flexibilidade que o torna poderoso também torna fácil construir algo que parece certo na superfície e desmorona no uso real.
Se algum desses padrões soou familiar, você não está sozinho. E tem saída: uma auditoria estruturada do portal mostra exatamente onde estão as lacunas, e um plano claro de correção transforma um CRM bagunçado em um CRM em que o seu time confia de verdade.
We offer HubSpot implementation services for teams starting fresh and ongoing optimization support for teams that need to fix what is already there. If you want to see where your portal stands, let's talk.