Reunião de descoberta com cliente: como conduzir a primeira call sem parecer júnior nem dar consultoria de graça

Você recebeu o contato. O cliente quer "marcar uma call para explicar o projeto". Você aceita, entra na reunião sem roteiro, ouve por quarenta minutos, responde tudo o que perguntam, promete um orçamento e desliga. Uma semana depois, silêncio. Ou pior: o cliente pegou suas ideias, levou para um dev mais barato e você trabalhou uma hora de graça sem perceber.

Se você já entrega bem, o seu problema não é técnico, é comercial. E a reunião de descoberta é o momento mais comercial da vida de um dev freelancer. É ali que o cliente decide, em poucos minutos, se você é alguém que executa tarefas ou alguém que resolve o problema dele. Vou te falar como funciona do lado de quem recebe os leads: na OCA, dezenas de contatos chegam por semana, e a diferença entre lead que fecha e lead que some quase nunca está no preço. Está em como a primeira conversa foi conduzida.

A verdade desconfortável: quem faz as perguntas controla a reunião

A maioria dos devs entra na primeira call em modo entrevista de emprego. O cliente pergunta, o dev responde. "Você já fez algo parecido?", "Quanto tempo demora?", "Consegue fazer por quanto?". No fim, o cliente tem tudo o que precisa para cotar com outros três devs, e você não sabe nem qual é o problema real do projeto.

Inverta a dinâmica. Quem faz as perguntas certas demonstra senioridade sem precisar citar anos de experiência. Um médico não deixa o paciente ditar o tratamento na primeira consulta. Ele investiga antes de prescrever. Cliente bom reconhece esse comportamento na hora, porque é exatamente o que ele não encontrou nos outros orçamentos.

O roteiro da call de descoberta em 5 blocos

Este é o esqueleto que usamos na OCA para a primeira conversa. Funciona em 30 a 45 minutos. Mais do que isso, a call vira consultoria gratuita.

Bloco 1: contexto do negócio (10 minutos)

Antes de falar de software, entenda de onde vem o dinheiro. Perguntas que abrem a conversa certa:

• "O que a empresa faz e como ela ganha dinheiro hoje?"
• "O que acontece se esse projeto não sair do papel? Qual é o custo de não fazer?"
• "Alguém já tentou resolver isso antes? O que aconteceu?"

Essa última pergunta vale ouro. Se a resposta for "contratamos um dev que sumiu no meio do projeto", você acabou de descobrir o medo principal do cliente. Sua proposta inteira deve responder a esse medo.

Bloco 2: o problema, não a solução (10 minutos)

O cliente vai chegar com a solução pronta: "quero um app com login, dashboard e notificações". Não aceite o pedido de cara. Pergunte o que está por trás:

• "Quem vai usar isso no dia a dia? Quantas pessoas?"
• "Qual é a tarefa mais dolorosa hoje, a que consome mais tempo ou gera mais erro?"
• "Se só uma funcionalidade pudesse existir na primeira versão, qual seria?"

Aqui você separa o essencial do desejável, e o cliente percebe isso acontecendo. É o momento em que você deixa de ser "mais um orçamento" e vira a pessoa que entendeu o problema. Isso não é teoria, é literalmente como a OCA cresceu: cliente que se sente entendido não escolhe pelo preço.

Bloco 3: restrições reais (5 minutos)

Três perguntas que todo dev tem vergonha de fazer e que definem se o projeto é viável:

• "Existe um prazo que não pode passar? Por quê?" (evento, investidor, contrato)
• "Vocês já têm uma faixa de investimento reservada para isso?"
• "Quem decide? Você aprova sozinho ou precisa passar por mais alguém?"

Sobre orçamento: você não precisa de um número exato, precisa de uma faixa. Se o cliente espera resolver por R$ 3 mil algo que custa R$ 40 mil, é melhor descobrir na call do que depois de escrever a proposta. Falar de dinheiro cedo não é grosseria, é respeito pelo tempo dos dois.

Bloco 4: o que você NÃO entrega na call

Aqui mora a linha entre vender e dar consultoria de graça. Na call de descoberta você entrega diagnóstico, não prescrição:

• Entregue: "pelo que você descreveu, o núcleo do problema está no fluxo de agendamento, e é por aí que a primeira versão deveria começar".
• Não entregue: arquitetura detalhada, escolha de stack justificada, estimativa de horas por funcionalidade, wireframe verbal do sistema inteiro.

Se o cliente insistir em detalhes técnicos profundos, a resposta honesta funciona: "isso faz parte do escopo que eu detalho na proposta, junto com prazo e investimento". Quem quer o mapa completo antes de assinar qualquer coisa geralmente quer o mapa, não o guia.

Bloco 5: encerramento com próximo passo definido

Call que termina com "depois te mando um orçamento" morre ali. Termine com data e formato: "vou consolidar o que conversamos e te envio a proposta até quinta. Ela vem com escopo da primeira versão, prazo e investimento. Podemos marcar 20 minutos na sexta para eu apresentar?". Proposta apresentada ao vivo fecha muito mais do que PDF jogado no WhatsApp, porque você responde a objeção na hora em vez de deixá-la matar o negócio em silêncio.

As armadilhas que queimam dev na primeira call

• Falar de stack antes de falar de problema. Cliente não técnico não compra React ou Node, compra o problema resolvido. Tecnologia entra na proposta, não na abertura da conversa.
• Dar preço no susto. "Quanto custa?" no minuto dez merece uma faixa ampla e honesta ("projetos desse tipo costumam ficar entre X e Y, e a proposta fecha o número"), nunca um valor cravado sem escopo.
• Aceitar call sem pauta com quem não decide. Se quem marcou a reunião não aprova orçamento, peça para o decisor participar. Senão você fará a mesma call duas vezes, e a segunda será por telefone sem graça.
• Estender a call para provar valor. Duas horas de reunião gratuita não demonstram senioridade, demonstram que seu tempo não custa nada. Quarenta e cinco minutos, agenda cumprida, próximo passo marcado.
• Não registrar nada. Saia da call com anotações e mande um resumo por escrito no mesmo dia. Esse e-mail vira a base do escopo e evita o clássico "mas na reunião você disse que...".

O que a call de descoberta revela sobre o cliente

A reunião é uma via de mão dupla: enquanto o cliente avalia você, você avalia o projeto. Preste atenção nos sinais. Cliente que não sabe responder "como a empresa ganha dinheiro com isso" está comprando uma ideia, não um produto, e o risco de o projeto ser abandonado no meio é alto. Cliente que desvia três vezes da pergunta de orçamento provavelmente não tem orçamento. Cliente que trata sua pergunta como afronta ("você é o técnico, você que me diga") vai tratar o projeto inteiro assim.

A conta é simples: uma hora de call bem conduzida economiza semanas de projeto mal fechado. Recusar na descoberta é barato. Recusar depois do contrato assinado é prejuízo.

E quando o lead nem chega até você?

Roteiro de call só funciona se existir call para fazer. E aqui entra uma alternativa que muitos devs seniores não conhecem: entrar num fluxo onde a descoberta já foi feita por outra equipe.

Na OCA, a visibilidade no Google e nas IAs traz mais leads do que o time consegue atender. Esses projetos passam exatamente pelo processo descrito neste artigo: call de descoberta, qualificação, escopo cercado, orçamento validado. Os que não conseguimos absorver são repassados para uma rede de parceiros, devs e times seniores de confiança, já com o trabalho comercial feito. O parceiro recebe um projeto qualificado e entrega; a parte mais difícil, transformar contato frio em escopo fechado, já veio pronta.

O que esperamos de um parceiro é o que qualquer cliente espera: entrega no prazo, comunicação clara e código que não envergonha em code review. Se você entrega nesse nível, os dois caminhos se complementam: conduzir suas próprias descobertas e receber projetos já qualificados.

Entre para a rede de parceiros da OCA

O próximo passo desta semana

Independente da rede: pegue os 5 blocos deste artigo e monte seu roteiro de descoberta num documento de uma página. Perguntas do bloco 1 ao 3, lista do que você não entrega de graça, frase de encerramento com data. Na próxima call, siga o roteiro. A diferença na reação do cliente aparece na primeira reunião, e no primeiro contrato fechado sem guerra de preço.