Isso Não São Casos Isolados
Já auditamos portais HubSpot de empresas B2B de todos os tamanhos. Startups com cinco pessoas. Scale-ups com oitenta pessoas. Indústrias diferentes, motions de vendas diferentes, estruturas de time diferentes.
E ainda assim? Os mesmos cinco erros de arquitetura aparecem em quase todos eles.
Estes não são problemas técnicos obscuros. São decisões fundamentais que foram tomadas (ou puladas) durante o setup original. Eles se acumulam ao longo do tempo. Quando um time percebe que algo está errado, geralmente já está perdendo deals, reportando receita incorreta ou queimando horas em trabalho manual há meses.
A parte frustrante: esses erros são quase sempre evitáveis. 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 importa mais do que a maioria dos times percebe.
1. Estágios de Pipeline Que Não Correspondem ao Modo Como Você Realmente Vende
Esse é o erro mais comum. Também é o mais prejudicial.
Abrimos um portal e vemos estágios de pipeline como 'Reunião Agendada', 'Qualificado para Comprar' e 'Decisor Convencido'. Esses são os estágios padrão do HubSpot. Descrevem um processo de vendas genérico que quase nenhuma empresa B2B de serviços realmente segue.
Aqui está o custo real. Quando os estágios de pipeline não correspondem ao seu motion real de vendas, os reps começam a pular estágios. Isso torna os dados do pipeline não confiáveis. Ou eles encaixam deals à força em estágios que não se aplicam. Isso torna sua previsão sem sentido.
Seu relatório de pipeline diz que você tem $200K em 'Decisor Convencido'. Mas o que isso realmente significa? Ninguém no time consegue dizer. O estágio não corresponde a nada real.
Como uma boa arquitetura se parece: estágios de pipeline que espelham os passos reais pelos quais um deal passa na sua empresa, usando as palavras que seu time já usa. Cinco a sete estágios no máximo. Cada estágio precisa de critérios de entrada claros que qualquer rep consiga explicar sem consultar nada.
Se você não consegue descrever em uma frase o que move um deal do Estágio A para o Estágio B, os estágios precisam ser refeitos. Esse é exatamente o tipo de raciocínio arquitetural que trazemos para toda implementação HubSpot: desenhar pipelines em torno de como seu time realmente opera, e não como um template assume que opera.
2. Excesso de Propriedades: Centenas de Campos Que Ninguém Preenche
Regularmente encontramos portais com 300, 400, até 500+ propriedades customizadas. A maioria está vazia em 90% dos registros.
Alguém criou 'Sub-Categoria de Indústria' seis meses atrás para um relatório que nunca foi construído. Outro alguém criou 'Origem do Lead - Detalhe' sem perceber que 'Drill-Down da Origem Original' já captura a mesma coisa. Soa familiar?
Aqui está o custo real. Toda propriedade vazia é um relatório quebrado. Quando seu time não confia nos dados, eles param de usar o HubSpot para tomar decisões. Voltam para planilhas e intuição. Você está pagando por um CRM em que ninguém confia.
Pior ainda. O excesso de propriedades torna o onboarding de novos reps doloroso. Eles abrem um registro de contato e veem 40 campos sem ideia de quais importam.
Como uma boa arquitetura se parece: menos propriedades, taxas de preenchimento mais altas. Normalmente recomendamos 15 a 20 propriedades customizadas de contato e 8 a 12 propriedades customizadas de deal como ponto de partida. Toda propriedade deve responder a uma pergunta: 'Qual decisão esse dado habilita?' Se você não consegue nomear a decisão, você não precisa da propriedade.
Um portal limpo com 20 propriedades a 95% de taxa de preenchimento dá insights dramaticamente melhores do que um portal inchado com 200 propriedades a 15%. Durante nossas implementações, auditamos e racionalizamos propriedades antes de construir qualquer coisa nova. É uma das atividades de maior ROI no 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 estão definidos.
Contatos ficam como 'Leads' para sempre. A fronteira entre MQL e SQL é 'sempre que vendas decidir ligar para eles'. Marketing não consegue reportar taxas de conversão porque os estágios não têm triggers claros.
Aqui está o custo real. Sem estágios de ciclo de vida significativos, alinhamento entre marketing e vendas é impossível. 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 fica frustrado. O jogo de empurra-empurra começa.
Já vimos times desperdiçarem trimestres inteiros discutindo qualidade de leads quando o problema real era mais simples: ninguém havia definido o que 'qualificado' significa no HubSpot.
Como uma boa arquitetura se parece: toda transição de estágio de ciclo de vida tem um trigger documentado. Um Lead vira MQL quando atinge critérios específicos (threshold de score, submissão de formulário, sinais comportamentais). Um MQL vira SQL quando vendas aceita e confirma o fit. Esses triggers são impostos via workflows e automação para que os dados permaneçam limpos automaticamente.
Esse framework 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ões de Entrada de Dados: Cada Um Faz Diferente
Abrimos os registros de empresas e encontramos 'Acme Corp', 'ACME', 'Acme Corporation' e 'acme corp'. Quatro registros. Mesma empresa. Cada um com contatos diferentes associados.
Números de telefone estão em cinco formatos diferentes. Alguns reps registram ligações no HubSpot. Outros usam o campo de notas. Outros nem registram.
Aqui está o custo real. Registros duplicados significam histórico fragmentado. Um deal associado a 'Acme Corp' não mostra a thread de e-mail anexada a 'ACME'. Seu reporting conta contatos em duplicidade. Seus envios de e-mail vão para duplicatas, prejudicando a entregabilidade.
E quando um rep sai? O conhecimento institucional fica espalhado em registros que ninguém consegue encontrar.
Como uma boa arquitetura se parece: convenções de nomenclatura, regras de formatação e processos de gestão de duplicatas estabelecidos desde o primeiro dia. O Operations Hub do HubSpot oferece formatação automatizada de dados. Mas mesmo em tiers menores, convenções simples fazem uma diferença enorme. Formatos padronizados de nome de empresa. Campos obrigatórios em cada estágio de pipeline. Uma cadência mensal de revisão de duplicatas.
Quando implementamos HubSpot para clientes, governança de dados não é uma reflexão tardia. Está embutida no setup desde o início, porque já vimos o que acontece quando não está.
5. Reporting Construído Depois Em Vez de Desenhado na Arquitetura
Esse é o padrão mais doloroso.
Um time usa o HubSpot por 6 a 12 meses. Aí a liderança pede um relatório de receita. A pessoa de ops tenta construir e descobre que a estrutura de dados não suporta o relatório que precisa. Valores de deal não foram rastreados de forma consistente. Datas de fechamento foram modificadas depois. O pipeline foi reestruturado no meio do trimestre sem snapshots históricos.
Aqui está o custo real. Você não consegue reportar sobre dados que não capturou. Correções retroativas são impossíveis ou exigem limpeza manual dolorosa de dados. Já vimos times gastarem mais de 40 horas reconstruindo relatórios trimestrais porque a arquitetura não foi desenhada com reporting em mente.
Como uma boa arquitetura se parece: comece pelas perguntas que a liderança vai fazer. 'Qual é nossa taxa de fechamento por origem?' 'Qual é nosso ciclo médio de vendas?' 'Quanto de pipeline o marketing gerou neste trimestre?' Depois trabalhe de trás para frente para garantir que as propriedades, estágios e workflows capturem os dados que esses relatórios precisam.
Todo dashboard deve estar funcional no primeiro dia da implementação. Não construído reativamente meses depois. Essa abordagem reporting-first é uma marca de como desenhamos implementações, porque o ponto inteiro de um CRM é ajudar a tomar decisões. E você não toma decisões sem dados confiáveis.
O Padrão Por Trás do Padrão
Esses cinco erros compartilham uma única causa raiz: o portal foi configurado pensando em funcionalidades, não em arquitetura.
Alguém aprendeu a criar um pipeline, construir um workflow ou adicionar uma propriedade. E fez. Mas ninguém desenhou o sistema como um todo.
O HubSpot é uma plataforma poderosa. Pode rodar 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 sob uso real.
Se qualquer um desses padrões parecer familiar, você não está sozinho. E você não está preso. Uma auditoria estruturada de portal identifica exatamente onde estão as lacunas, e um plano claro de remediação pode transformar um CRM bagunçado em um em que seu time realmente confia.
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.