O seu CPQ não é lento, os seus especialistas estão sobrecarregados

“Estamos prontos para comprar. Porque tenho de esperar três dias para a engenharia aprovar uma opção de armário?”

Já perdi a conta às vezes que ouvi isto. O negócio está no ponto. A equipa do cliente está alinhada. E, de repente, a proposta fica parada numa fila porque uma simples opção na configuração precisa do olhar de um perito.

A equipa de vendas chama-lhe “CPQ lento”. A de TI ouve “a ferramenta não funciona”. Nenhuma é verdade. O que estás a sentir é um estrangulamento invisível: um pequeno grupo de especialistas de produto e engenheiros de soluções a validar silenciosamente o trabalho que o sistema deveria fazer sozinho.

Se a engenharia tem de rever todas as propostas, não tens um sistema — tens uma fila de espera.

Essa fila é o preço que pagas por um problema de distribuição de conhecimento. E não o vais resolver com mais workflows, mais botões ou uma interface mais bonita.

O Custo Oculto da Validação por Peritos

Quando um vendedor de topo espera dias pela aprovação de um negócio chave, o custo não é apenas tempo. O ímpeto perde-se. A concorrência volta a ter uma oportunidade. A confiança diminui. E, internamente, todos aprendem uma lição: vender a versão “segura” do produto é mais rápido. É assim que a fuga de margens acontece à vista de todos.

Na maioria das vendas B2B complexas, o padrão repete-se:

• O tempo dos peritos é racionado, por isso os vendedores evitam configurações com maior margem que não conseguem ver validadas rapidamente.
• As soluções improvisadas multiplicam-se — Excel, modelos antigos, regras tribais — porque são mais rápidas que o processo oficial.
• A governação transforma-se em controlo de acesso. As mudanças exigem atos heroicos, e por isso as pessoas deixam de as pedir.

Segundo a Gartner, as compras B2B modernas envolvem 6 a 10 pessoas e 77% dos compradores consideram o processo “muito complexo ou difícil”. Se juntares a tua fila de validação interna a isto, estás a agravar a complexidade externa com fricção autoimposta. Os negócios não morrem de forma dramática — simplesmente arrefecem enquanto todos esperam.

O CPQ raramente falha à vista de todos. Falha silenciosamente — através de filas de peritos e de soluções improvisadas.

A verdade desconfortável é que muitas equipas tentam resolver um problema de distribuição de conhecimento com uma ferramenta de automação de processos. Um workflow pode mover tarefas, mas não consegue gerar confiança na correção do produto.

Porque é que Isto Continua a Acontecer

As ferramentas de CPQ tradicionais foram criadas para garantir a correção. E fazem-no — até certo ponto. Mas se o conhecimento sobre o teu produto reside apenas em algumas cabeças, o teu CPQ acabará por funcionar como uma interface para quem já sabe as respostas. Os outros ficam à espera.

Existem algumas razões estruturais para isto persistir:

• O efeito herói. Um punhado de peritos é, hoje, mais rápido que o sistema, por isso a empresa otimiza-se à volta deles. Obténs rendimento agora e um estrangulamento maior mais tarde.
• Proliferação de regras. Cada exceção torna-se uma regra. Com o tempo, a lógica de configuração transforma-se num labirinto impossível de testar, e as equipas voltam a recorrer a pessoas por segurança.
• Falta de explicabilidade. O sistema pode dizer “inválido”, mas não consegue mostrar porquê. As vendas perdem a confiança, escalam para os peritos e o ciclo vicioso reforça-se.

Nada disto tem a ver com más pessoas ou más ferramentas. Tem a ver com onde reside o conhecimento e como circula. Se o conhecimento só viaja através de peritos, estarás sempre a adicionar pessoas à parte mais congestionada do funil.

O trabalho não é automatizar cliques. É fazer o conhecimento especializado circular sem necessidade de reuniões.

Faz o Conhecimento Circular Mais Rápido

Se queres que as propostas avancem de forma rápida e segura, para de pedir ao sistema que seja inteligente e começa a pedir-lhe que seja claro. Quatro regras que uso com as equipas:

1) Quantifica a fila, não os cliques. Mede o tempo de intervenção de um perito por proposta, não apenas o “tempo para obter proposta”. Se 40% do tempo do ciclo é passado à espera de uma pessoa, é aí que tens de agir. Exemplo: etiqueta cada proposta quando entra e sai da “validação de engenharia”. Torna isto visível semanalmente.

2) Bloqueia erros cedo — e explica-os instantaneamente. Não esperes pela validação final para rejeitar uma opção. Mostra a restrição no momento da escolha, com uma justificação de uma frase e uma alternativa segura. Se uma regra não pode ser explicada numa frase, divide-a.

3) Separa a interpretação da verdade. Deixa que as pessoas capturem a intenção do cliente nas suas próprias palavras — e só depois passa isso pela lógica de produto explícita e testável. O texto livre serve para perceber; as regras para validar. Quando os misturas, a fila aumenta.

4) Desenha para a mudança, não para a perfeição. Nunca conseguirás modelar tudo no primeiro dia. Começa com um núcleo de alta confiança, publica testes e adiciona lógica todas as semanas. Cada pequena atualização deve reduzir a intervenção de peritos num cenário conhecido.

Anti-padrão a evitar: Validação de Heróis. O sistema parece rápido nas demos, mas depois cada proposta real passa por uma “verificação rápida” feita sempre pelas mesmas três pessoas. A produtividade parece alta — até eles irem de férias.

O que funciona é, por natureza, mais simples: lógica de produto explícita, justificações visíveis e ciclos de mudança curtos. Quando as regras são legíveis e testáveis, os peritos passam de controladores a mentores. O seu trabalho passa a ser melhorar os carris, não desimpedir os comboios.

De Estrangulamento a Vantagem Cumulativa

Está a ocorrer uma mudança maior. Os compradores esperam poder avançar sem depender do teu organograma. Querem clareza sobre opções, compromissos e entregas — agora. As equipas que correspondem a essa expectativa vencerão por defeito.

O mecanismo é direto:

• Faz com que o sistema se explique. Mostra porque é que as escolhas são válidas ou não, e que mudanças as tornariam válidas. A confiança vale mais que a velocidade.
• Integra opções seguras por defeito. Em caso de dúvida, o sistema deve propor o caminho mais seguro e exequível. Os peritos devem tratar apenas do que é genuinamente novo.
• Aperta o ciclo de feedback. Faz revisões semanais das propostas falhadas ou escaladas. Todas as semanas, elimina uma solução improvisada e uma intervenção recorrente de um perito.

Já vi esta abordagem inverter a narrativa em grandes projetos. Na Siemens Healthineers e em vários fabricantes industriais que apoiei, o avanço não foi uma nova funcionalidade. Foi tratar a lógica de produto como um ativo vivo, com donos, testes e uma cadência de mudança. Os resultados parecem pequenos no início — menos cinco escaladas, dois dias mais rápido em SKUs específicos — e depois acumulam. Passado um trimestre, a fila diminui. Passado um ano, o sistema é outro.

A investigação Challenger da Gartner afirma há anos que a parte mais difícil das vendas B2B não é a procura, mas sim a tomada de decisão. Se o teu CPQ ainda exige uma segunda decisão dentro da tua empresa, duplicaste a probabilidade de atraso. Remove essa decisão interna, transferindo o raciocínio dos peritos para o sistema e tornando-o auditável.

A adoção é a única métrica que importa.

Quando a equipa de vendas confia realmente no sistema, deixa de pedir atalhos. E quando os peritos confiam no sistema, deixam de precisar de rever todas as propostas. Esta é a dinâmica que queres criar.

O que Fazer Esta Semana

Não comeces um programa. Começa com três ações.

• Instrumenta uma fila. Escolhe uma linha de produtos com grande volume. Regista o tempo de entrada e saída da “revisão por perito”. Partilha um gráfico com as vendas, o produto e a TI. Identifiquem juntos o estrangulamento.
• Publica três explicações. Para as três combinações inválidas mais comuns, escreve uma justificação de uma frase e uma substituição segura. Coloca essas explicações no fluxo onde as escolhas são feitas.
• Cria um horário fixo de 30 minutos para mudanças. Todas as semanas, elimina uma intervenção recorrente de um perito adicionando ou melhorando uma regra — e adiciona um teste. Pequeno, simples, implacável.

O objetivo não é culpar os peritos. É libertá-los para o trabalho que só eles podem fazer — definir as regras do jogo — em vez de dar passagem a cada carro no cruzamento.

As propostas aceleram quando o conhecimento circula sem reuniões. A única questão é se vais fazer esse conhecimento circular de propósito ou continuar a pagar o imposto de uma fila de espera permanente.

Se o teu melhor engenheiro desaparecesse durante um mês, as propostas continuariam a fluir?