Como vender quando o usuário não é o comprador
(writings.founderlabs.io)- Em situações em que o usuário usa o produto, mas não é quem tem autoridade para pagar, o ponto central é identificar quem realmente tem autoridade e influência
- A pessoa tomadora de decisão com autoridade real pode não ser necessariamente a compradora ou a primeira usuária
- Em organizações pequenas, economizar tempo é crucial, então há grande chance de o próprio desenvolvedor adotar a ferramenta e a compra acontecer após convencer a liderança
- Em organizações grandes, as restrições de segurança e de processo são fortes, então a decisão de compra fica com o CTO ou a liderança executiva, e é necessário um ciclo de vendas longo
- Quem tem autoridade de compra nem sempre coincide com quem controla o orçamento, e o alvo principal passa a ser a pessoa que mais percebe o valor do produto e consegue impulsioná-lo
- Uma estratégia eficaz é fornecer dados concretos e materiais de convencimento para que o usuário consiga persuadir a liderança, apoiando esse processo
- O sucesso final está em desenhar um processo que sustente o usuário no papel de vendedor interno
Introdução – o ponto de partida da pergunta
- Como abordar a situação em que a pessoa que realmente usa o produto e o cliente que toma a decisão de compra são diferentes?
- O contexto é o de vendas de software B2B em que, tipicamente, desenvolvedores testam o produto e o CTO ou o Director of Engineering tomam a decisão final
A pergunta essencial sobre autoridade
- A pergunta “quem realmente tem poder?” é o ponto mais importante de todos
- Não se trata apenas de ter autorização para pagar no cartão ou de definir a prioridade para testar o produto, mas de influência real e motivação, que são decisivas no fluxo de compra
Cenários por estrutura organizacional
No caso de organizações pequenas: estrutura mais horizontal e decisões rápidas
- Muitas vezes, o desenvolvedor descobre o produto e lidera de fato a adoção
- A principal motivação do CTO é chegar mais rápido ao mercado e iterar, então a sugestão de ferramenta feita pelo desenvolvedor exerce grande influência na decisão
- É comum surgir uma disseminação no estilo Trojan horse, em que o desenvolvedor testa a ferramenta gratuitamente e rapidamente e depois isso evolui para uma conversão paga
No caso de organizações grandes: segurança e conformidade são as principais restrições
- Existem restrições além do tempo, como segurança, e a decisão da liderança tem papel crucial em todo o processo
- Não se permite que o usuário (desenvolvedor) instale ou compre por conta própria, e o ciclo de vendas é longo e complexo
- Os critérios de percepção de valor/risco se concentram mais em segurança e no resultado final do que em UI/UX ou DX
A perspectiva da influência real e do valor
- Quem controla o orçamento nem sempre é quem tem o poder real
- O importante é entender “quem tem alavancagem” e “de quem são os incentivos que mais impulsionam o andamento do processo”
- É preciso identificar de forma realista quem é o agente capaz de trocar valor de fato na mesma medida do preço cobrado
Exemplo concreto de fluxo de adoção do produto
- O usuário/desenvolvedor faz o cadastro no produto
- Usa o trial gratuito em ambiente local
- Vivencia diretamente o valor real da funcionalidade (ex.: comparação antes/depois de Pull Request, destaque de problemas)
- Percepção de valor → expectativa de eficiência no trabalho e automação
- O usuário convence a liderança da necessidade
- A liderança aprova ou rejeita após testes internos e análise de orçamento
- A liderança aprova a compra final
- Compra concluída e expansão adicional dentro da organização
A questão dos incentivos dos dois lados
- Entender a motivação essencial do desenvolvedor ao propor a ferramenta (comodidade no trabalho, destaque da própria capacidade, alcance das metas da empresa etc.)
- Entender a motivação da liderança para comprar (aumento da eficiência de desenvolvimento, alcance mais rápido dos objetivos da empresa etc.)
- Se essas motivações centrais existirem, recomenda-se a seguinte estratégia
Estratégias práticas de resposta
- Fornecer ferramentas de convencimento, como relatórios precisos de comparação antes/depois, para que o usuário consiga persuadir a liderança
- Nesse processo, o importante não é conselho abstrato, mas resultados baseados em dados quantitativos
- Números concretos, como “quanto tempo foi economizado em relação ao método anterior”, são a chave da persuasão
- Entender, por meio de entrevistas com clientes (desenvolvedores), como a conversa real de compra acontece, e resolver de antemão os obstáculos do processo de convencimento
- Em outras palavras, em vez de tentar persuadir diretamente quem tem a autoridade de compra, é preciso fornecer todo o suporte ambiental e os materiais concretos para que o usuário desempenhe com sucesso o papel de vendas internas
- Nesse processo, o sucesso do usuário leva diretamente ao sucesso do fornecedor (uma estrutura de ganho mútuo entre usuário, fornecedor, liderança e empresa)
Conclusão e resumo
- A melhor estratégia é apoiar o usuário para que ele desempenhe com sucesso o papel de vendas internas do produto
- É preciso focar em fornecer evidências quantitativas e materiais concretos de valor necessários para convencer a liderança
- Antes de tudo, é necessário analisar cuidadosamente a estrutura de decisão de acordo com o porte da organização e suas restrições
- Em última instância, destaca-se que, quando o usuário tem sucesso, fornecedor e empresa também têm sucesso ao mesmo tempo
1 comentários
Comentário no Hacker News
Fico exausto quando tento baixar alguma coisa e pedem meus dados de contato, e logo depois vendedores começam a ligar ou mandar e-mails sem parar; mesmo recusando educadamente, ignoram isso e continuam insistindo em reuniões. Eu não tenho poder de compra, mas consigo espalhar a insatisfação dentro do time, então no fim a imagem do produto piora. Quando um engenheiro pede recomendação, é óbvio que vou mencionar isso. Já aconteceu com Veeam, AWS e Keyence.
Como IT Manager, passo por isso quase toda semana. Como não conseguem resposta minha, às vezes tentam contornar mandando e-mails aleatórios para colegas ou outras pessoas da empresa, e isso costuma fazer com que eu bloqueie rapidamente o domínio inteiro. E eu realmente gostaria que parassem de forçar demo só para conseguir passar um orçamento. Se eu já pesquisei o produto e, quando necessário, até testei um trial, o razoável é me informar primeiro o preço, não me empurrar apresentação de vendas ou demo.
Auth0 e Okta também sofrem do mesmo problema. Eu realmente tinha autoridade de compra e orçamento, mas o volume de contato foi tão excessivo que simplesmente peguei antipatia.
Adorei o conceito de "poder do ressentimento". Mesmo quando algo é oferecido de graça, se o time de vendas ou marketing for entusiasmado demais, isso pode piorar a percepção da empresa. É preciso contatar o cliente da forma que ele quer, não apenas do jeito que a empresa prefere, senão o efeito pode ser o oposto. Mas isso é difícil do ponto de vista de desenho de incentivos.
Já tive experiências extremas com alguns times de marketing SaaS mandando e-mail a cada 5 a 15 minutos. Às vezes pode ser uma atitude isolada de algum funcionário, mas também parece haver casos em que a liderança ou o próprio CEO configura a ferramenta de e-mail marketing no máximo.
Também é preciso incluir os produtos da Microsoft nisso. Para se registrar, você precisa criar uma "conta profissional", e há barreiras de entrada como não aceitar conta do Gmail. Às vezes você quer usar um trial de 30 dias para avaliar o produto, mas nem consegue acessar por causa de problemas com a conta. Se até o trial já é difícil por esse nível de atrito, nem quero imaginar como seria o processo real de adoção. Isso me tira qualquer vontade de usar AI-based CRM, ERP, Dataverse etc.
Esse fenômeno vem do problema principal-agente. A liderança da empresa controla o orçamento, mas quem realmente usa o produto ou a ferramenta são os desenvolvedores e o pessoal da operação. Do ponto de vista de um fundador, costumam aconselhar que você conquiste o usuário para que ele convença a liderança. O ponto central é que, como você não consegue falar com quem de fato tem o cartão de crédito, precisa dar o máximo de suporte para que o usuário convença a liderança. Ou seja, fazer com que o usuário/desenvolvedor atue, na prática, como força de vendas. Essa abordagem pode funcionar em modelos como freemium, mas tenho curiosidade sobre como superar isso em setores como sistemas hospitalares e EHR (prontuário eletrônico), em que a decisão de compra é unilateralmente administrativa e o usuário real muitas vezes nem tem chance de experimentar o produto.
Na prática, em campo, o oposto também acontece com frequência. Um vendedor sofisticado mira quem tem autoridade sobre o orçamento, bloqueia a comunicação com os usuários reais e fecha o contrato primeiro. Quando os usuários reclamam e apontam os problemas, o dinheiro já foi pago.
Para colocar em prática o conselho de "dar a melhor oportunidade para o usuário convencer a liderança e fazer com que ele se destaque apenas por conseguir comunicar essas opções à liderança", nós até criamos uma "CEO Page" separada: https://www.rsync.net/products/ceopage.html
Complementando sobre vendas enterprise: às vezes nem o próprio decisor entende bem a dinâmica real de poder dentro da empresa. Além disso, é preciso observar se essa pessoa está num centro de custo ou numa área geradora de receita, se está promovendo adoção de nova tecnologia ou lidando com um produto padronizado, e quem pode enxergar esse produto como ameaça ao risco ou ao próprio poder. Essas informações precisam entrar na estratégia para decidir para quem vender, de quem manter distância, e quando abordar de forma discreta ou em larga escala.
Uma abordagem usada com frequência por Slack e Postman é algo como: "96% do seu time já usa nosso produto. Não faz sentido comprar agora?"
A resposta costuma ser: "Se todo mundo já usa, por que precisaríamos comprar?" Essa pergunta mostra o nível de desconexão entre comprador e usuário, especialmente em ambientes de pequenas e médias empresas.
É pelo mesmo motivo que oferecem software de graça para estudantes.
Isso também acontece muito com times pequenos dentro de grandes empresas. Se houver um time de segurança, o uso espalhado em vários workspaces do Slack pode virar problema, então funciona um argumento como "em vez de 400 pessoas usando 12 workspaces, vamos gerenciar tudo com uma conta oficial".
Uma vantagem oculta de open source comercial ou de modelos parecidos é que, quanto mais cresce a adoção individual, mais cresce também a adoção em nível corporativo.
A empresa que fundei anteriormente também enfrentou esse problema. Precisávamos vender para times de desenvolvimento que não tinham poder real de compra. Em empresas menores, ou nos casos excepcionais em que a pessoa tinha autoridade, fechar contrato era fácil, mas na maioria das vezes havia um ciclo de vendas longo e a necessidade de convencer decisores superiores com argumento de redução de custos. No fim, esse processo levava muito tempo e tinha baixa taxa de sucesso, sendo uma das principais causas do fracasso da empresa. Fico feliz que esse tema esteja sendo discutido mais abertamente. Muitas pequenas empresas passam por isso, mas surpreendentemente há pouca orientação formal sobre o assunto.
Esse modelo funciona bem quando o usuário pode usar o produto diretamente e pertence à mesma organização. Mas fico curioso sobre como abordar casos em que o usuário não tem relação direta com o decisor ou em que é difícil provar a justificativa da compra, como um pop de entrada sem chave para carros. É um grande benefício para o motorista, mas do ponto de vista do CTO da Ford, um convite para reunião pode parecer totalmente desnecessário. Numa situação assim, depois de desenvolver o produto, como entrar no mercado?
Nesses casos, uma estratégia bottom-up é atraente. Em vez de mirar a matriz da Ford, pode ser eficaz começar com concessionárias de usados, oficinas e lojas de acessórios automotivos. Usando partida remota como exemplo: o usuário queria, mas a montadora não ligava muito, então o mercado se formou primeiro via venda cruzada em lojas de som automotivo, e depois os fabricantes passaram a oferecer isso como opcional. Eu mesmo tive experiência parecida com dispositivos antifurto: começar pequeno, construir base de clientes e então se aproximar gradualmente das grandes empresas costuma funcionar.
Outra possibilidade é destacar que concorrentes já estão adotando o pop, provocando FOMO (medo de ficar para trás).
Em enterprise, não basta vender só para o CTO. Se a empresa tem um papel realmente central, como AWS ou Azure, convencer o CTO e os principais engenheiros pode até viabilizar uma mudança organizacional ampla. Mas, para a maioria dos softwares, quem decide costuma ser o gerente de linha, diretor ou chefe de área. Em muitos casos, cada departamento adota softwares diferentes, então é preciso segmentar o alvo.
Marketplaces B2B2C são especialmente interessantes. Num modelo em que não se cobra do usuário "B2B" e se retém apenas uma taxa por transação, esses usuários funcionam como uma força de vendas distribuída. Você precisa ajudá-los a atrair clientes B2C por meio de suas próprias instâncias. Para a equipe fundadora, isso muitas vezes parece confuso e aumenta bastante o que precisa ser desenvolvido, mas a vantagem é a baixa barreira de entrada inicial e o fato de que, sempre que cada conta consegue entregar valor ao cliente final, a receita cresce de forma orgânica.
Isso também ressoa com a nossa empresa. Estamos criando uma API de business intelligence relacionada a entity resolution, e como engenharia, produto e data science estão todos envolvidos, a separação entre comprador e usuário fica complexa. Os engenheiros entendem intuitivamente a dificuldade de fazer matching de dados corporativos complexos, mas os executivos apenas veem o projeto atrasado. Por isso, ultimamente tem funcionado melhor abordar como "seu time está gastando meses com matching de dados". Uma empresa tentou construir isso internamente por 10 anos e ainda não funciona direito. Claro, também sentimos que a abordagem varia conforme a empresa e o contexto.
Um modelo como o do TikTok, em que você fica apenas com uma porcentagem por transação, também pode ser uma alternativa.