A venda que me ensinou a dizer não para o cliente

Durante muito tempo eu achei que ser um bom fornecedor significava tentar atender ao máximo aquilo que o cliente pedia.

Hoje penso diferente.

Algumas das melhores decisões que tomei em vendas nos últimos anos foram justamente aquelas em que tive coragem de dizer:

Se precisa ser dessa maneira, talvez a Alphacode não seja a empresa certa para fazer esse projeto.

Mas eu não aprendi isso em um livro de vendas. Aprendi errando.

Os primeiros sinais estavam na primeira reunião

No começo de 2020, recebemos um contato que me deixou particularmente animado.

Era uma rede de restaurantes que eu admirava muito. Gostava da marca, do posicionamento e, principalmente, da qualidade dos produtos. Eles estavam crescendo e queriam construir um aplicativo para melhorar a experiência dos clientes.

Para mim, havia ainda um componente estratégico importante. Pouco tempo antes, tínhamos conquistado nosso primeiro grande cliente de Food, depois de uma concorrência que durou praticamente todo o ano de 2018. Eu começava a enxergar naquele mercado uma oportunidade enorme para a Alphacode.

Quando essa segunda grande marca chegou espontaneamente até nós, pensei que talvez estivéssemos começando a construir alguma coisa ali.

E eu queria muito aquele projeto. Talvez até mais do que deveria.

O cliente já tinha estudado bastante o que havíamos desenvolvido anteriormente. Mas rapidamente percebi uma diferença importante entre os dois projetos.

No nosso primeiro grande projeto de Food, a conversa girava muito em torno do negócio. Precisávamos vender, colocar o delivery no ar e fazer aquilo funcionar.

Nesse novo projeto, desde as primeiras conversas, o foco era diferente. Falávamos muito sobre design, experiência, animações, transições de tela e detalhes visuais.

Não havia nada de errado nisso. Uma boa experiência é parte fundamental de qualquer produto digital.

O que começou a me incomodar foi perceber que estávamos discutindo tudo aquilo antes de termos uma conversa suficientemente profunda sobre a pergunta principal:

O que esse aplicativo precisa produzir para o negócio?

Mesmo assim, naquele momento eu não confrontei essa visão. Dei espaço ao cliente.

Quando o cliente começou a escolher a tecnologia

Na época, nós tínhamos bastante experiência utilizando Ionic. Não era a tecnologia mais sofisticada do mundo, mas conhecíamos profundamente aquela stack.

Sabíamos suas limitações, tínhamos equipe, projetos reais rodando e conseguíamos entregar com velocidade e custo competitivo.

O cliente, entretanto, não gostava de alguns aspectos da experiência que tinha visto em outros aplicativos desenvolvidos daquela maneira, principalmente animações e transições.

Por isso, colocou uma condição para avançarmos: o aplicativo deveria ser desenvolvido em Flutter.

Hoje Flutter é uma tecnologia absolutamente estabelecida no desenvolvimento mobile. Mas estou falando do começo de 2020.

Era uma tecnologia relativamente nova, com documentação ainda limitada em alguns pontos e um ecossistema muito menor. E havia outro detalhe ainda mais importante: a Alphacode nunca tinha desenvolvido um projeto em Flutter.

Eu sabia que estávamos saindo da nossa especialidade. E aceitei.

Por que eu aceitei?

Essa talvez seja a parte mais importante dessa história.

Não foi porque eu acreditasse tecnicamente que aquela era necessariamente a melhor decisão. Aceitei porque queria o cliente.

Eu queria crescer naquele segmento. Tínhamos conquistado nossa primeira grande rede de Food e aquela seria a segunda. Era uma marca que eu admirava. Para mim, naquele momento, conquistar aquele logo tinha um valor estratégico enorme.

Deixei a vontade de fechar a venda falar mais alto do que a nossa convicção técnica.

E pagamos o preço por isso.

O problema não foi apenas tecnológico

Logo começaram a aparecer dificuldades.

Encontrávamos obstáculos técnicos para os quais ainda havia pouca documentação. Coisas que nossa equipe resolveria rapidamente dentro de uma tecnologia que dominava exigiam investigação, tentativa e erro.

O projeto começou a se estender. E quanto mais ele se estendia, mais problemas apareciam. A estabilidade também sofreu.

Só que o efeito mais importante não aconteceu dentro do código. Aconteceu no negócio.

O cliente começou a perder confiança para colocar toda a força naquele novo canal. O aplicativo entrou em uma espécie de soft launch infinito. Estava lá, funcionava, mas nunca recebia toda a energia que um novo canal digital precisa para ganhar relevância.

E então apareceu um ciclo que, depois de tantos anos trabalhando com produtos digitais, aprendi a temer:

  • o cliente não colocava energia porque o canal ainda não vendia;
  • o canal não vendia porque o cliente não colocava energia;
  • quanto menos vendia, menor era a disposição para investir;
  • quanto menor era o investimento, menos chance o canal tinha de vender.

Apesar de termos desenvolvido e colocado aquele produto no mercado, eu nunca o considerei um case de sucesso da Alphacode.

Entregar software e gerar resultado são duas coisas muito diferentes.

O aprendizado apareceu no cliente seguinte

Algum tempo depois, estávamos negociando com outro grande grupo de restaurantes. Era uma oportunidade ainda maior.

Durante uma das reuniões, a gerente responsável pelo projeto colocou uma condição parecida. Ela queria que o aplicativo fosse desenvolvido em React Native.

A situação era curiosamente familiar: uma grande marca, um projeto que eu queria muito e uma tecnologia que, naquele momento, não fazia parte da especialidade da Alphacode.

Só que dessa vez eu tinha uma experiência anterior na bagagem.

Parei a reunião e disse, em essência:

Se a utilização de React Native for uma condição para o projeto, eu acho que não faz sentido vocês avançarem com a Alphacode.

Pode parecer estranho para um vendedor dizer isso. Eu estava diante de um cliente enorme e basicamente dizia que preferia perder o contrato a aceitar uma condição que não considerava adequada para nós.

O cliente não estava contratando a Alphacode para concordar com ele. Estava contratando nossa experiência.

Um especialista precisa saber dizer não

Existe uma tentação muito grande em vendas de tecnologia de responder sempre: “Sim, conseguimos fazer.”

  • Quer React Native? Fazemos.
  • Quer Flutter? Fazemos.
  • Quer determinada arquitetura? Fazemos.
  • Quer trabalhar daquela maneira? Fazemos.

No curto prazo, essa postura pode ajudar a fechar contratos. Mas existe uma diferença enorme entre ser uma empresa capaz de executar determinada tecnologia e ser realmente especialista naquilo que está propondo.

Quando um cliente contrata uma empresa especializada, ele não está comprando apenas horas de programação. Está comprando também os erros que aquela empresa já cometeu, os projetos que deram certo, os que deram errado, as decisões técnicas que já precisaram ser revistas e os problemas de produção enfrentados de madrugada.

Parte da responsabilidade de um especialista é justamente impedir que o cliente tome determinadas decisões, mesmo quando ele está convicto delas.

Isso não significa arrogância. Também não significa que o fornecedor sempre está certo. Significa ter coragem de colocar sua experiência na mesa, inclusive quando isso coloca a venda em risco.

Algumas vendas você precisa estar disposto a perder

Curiosamente, aquela conversa no projeto seguinte não fez com que perdêssemos o cliente. Aconteceu o contrário. Avançamos, e aquele grupo acabou se tornando um dos grandes clientes da história da Alphacode.

Mas o principal aprendizado não é que dizer não ajuda a vender. Às vezes você vai dizer não e realmente vai perder o contrato.

O aprendizado que ficou para mim é outro: existem projetos que você só deveria aceitar se estiver disposto a defender aquilo em que acredita.

Eu queria tanto conquistar aquela segunda grande marca de Food que aceitei uma condição que contrariava aquilo que nossa experiência recomendava naquele momento.

O projeto aconteceu. O aplicativo foi entregue. O logo poderia perfeitamente estar em uma apresentação comercial nossa como mais um grande case.

Mas eu sei o que aconteceu nos bastidores. E talvez seja justamente por isso que considero essa experiência tão importante na minha trajetória.

Nem todo projeto que não se transforma em um grande case foi inútil. Alguns deles servem para construir algo muito mais valioso: experiência.

Experiência para reconhecer os sinais mais cedo, fazer perguntas melhores e, quando necessário, dizer não antes que a vontade de fechar uma venda fale mais alto do que a responsabilidade de entregar resultado.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *