Conversão
Prova de conceito B2B: quando oferecer e como limitar o custo
Uma PoC mal delimitada consome equipe e deixa a venda parada. Veja como decidir se ela entra no processo comercial e quais critérios registrar antes de qualquer configuração.
Considere uma prova de conceito (PoC) quando uma dúvida técnica específica impede a compra e pode ser testada com prazo e custo definidos. Se a pendência é preço, prioridade interna ou falta de patrocinador, resolva essa conversa antes de envolver a equipe no teste. A proposta deste roteiro é delimitar o que a PoC precisa responder.
Quando a PoC faz sentido (e quando não)
Uma forma de avaliar é perguntar: se o teste der certo, o comprador consegue assinar sem uma nova rodada de dúvidas? Se a resposta for sim, a PoC tem função clara. Se a resposta for "talvez, ainda precisamos falar com outras áreas", o teste ainda não é o gargalo da decisão.
Vale diferenciar três coisas que costumam se misturar. A PoC é um teste técnico de escopo reduzido, feito antes do compromisso maior de compra e implantação. Ela pode ser gratuita ou ter contrato e pagamento próprios, e o que a define é o objetivo (resolver uma dúvida técnica), não a ausência de contrato. O piloto pago tem desenho comercial próprio, e a implantação é a entrega do contrato definitivo. Para esta última, o artigo sobre quanto tempo leva implantar um SaaS em cliente B2B ajuda a separar as etapas.
- Faz sentido quando a dúvida é de viabilidade: integração, qualidade de dados, desempenho em um fluxo específico.
- Faz sentido quando quem decide a compra participa e aceita os critérios antes de começar.
- Vale evitar quando o objetivo real é conhecer o produto, caso em que uma demonstração costuma bastar.
- Vale evitar quando o cliente não consegue fornecer os dados ou o acesso necessários no prazo.
Começar pela hipótese e pela tarefa do comprador
A Strategyzer propõe descrever as tarefas, os obstáculos e os ganhos esperados pelo cliente. O GitLab recomenda definir uma hipótese e testá-la rapidamente. Essas referências ajudam a construir o raciocínio abaixo, mas não são protocolos de PoC: o roteiro é uma adaptação nossa.
Na prática, isso significa escrever a PoC como uma hipótese de uma frase: "Com os dados X, nossa solução consegue cumprir a tarefa Y dentro do critério Z". Se a frase não couber em uma linha, o escopo provavelmente está grande demais.
O termo de PoC em uma página
O termo abaixo serve para alinhar expectativas. Ele não substitui análise jurídica ou contratual, que não é tratada aqui, e não garante que o teste seja conclusivo.
| Campo | O que registrar | Pergunta de controle |
|---|---|---|
| Hipótese | O que será provado, em uma frase | Um resultado positivo removeria a principal dúvida? |
| Tarefa do comprador | O trabalho que a solução deve executar | Quem usa isso no dia a dia concorda com a descrição? |
| Dados necessários | Acessos, amostras e prazo de entrega pelo cliente | Quem fornece e até quando? |
| Critério de aprovação | Evidência observável, escrita antes do teste | Duas pessoas leriam o resultado da mesma forma? |
| Prazo e custo máximos | Limite de dias e de horas de equipe de cada lado, além de eventual valor cobrado pela PoC | O que acontece se o limite for atingido? |
| Responsáveis | Um nome de cada lado | Quem pode decidir ao final? |
| Decisão pós-teste | Avançar, ajustar ou encerrar, com data da reunião | A reunião já está agendada? |
Como limitar o custo sem esvaziar o teste
O custo cresce quando o escopo se expande durante a execução. Por isso, o limite de horas deve ser fixado no início, com uma regra simples: qualquer pedido novo vira item de uma segunda rodada, com novo termo. Também ajuda usar dados de amostra em vez do ambiente completo e testar um fluxo, não a operação inteira. Ao registrar o custo, vale separar horas de equipe, despesas diretas e eventual valor cobrado do cliente, porque cada um afeta a margem e o caixa de forma diferente.
Um exemplo hipotético: uma empresa de software de conciliação financeira quer provar que consegue ler os extratos de um banco específico do comprador. O termo prevê uma amostra de extratos, um critério de leitura correta escrito pelo financeiro do cliente e um limite de horas da equipe técnica. Se o critério não for atingido, a reunião final decide entre ajustar o formato ou encerrar. Um resultado inconclusivo, por amostra pequena ou dados incompletos, não prova que a solução funciona nem que falha, e por isso pede nova rodada com novo termo. Os números e o resultado dependem de cada caso.
Vale também preparar o resultado "ajustar". Ele é legítimo quando o critério foi quase atingido por uma causa identificada, mas precisa de nova data e novo limite, e não de extensão informal.
O que resolver antes de iniciar a PoC
Pegue a negociação aberta com maior chance de depender de teste e preencha as sete linhas da tabela sem consultar o cliente. As que você não conseguir completar mostram o que precisa ser conversado antes de qualquer configuração. Se a hipótese, o critério de aprovação ou o responsável pela decisão ficarem em branco, a PoC ainda não deve começar, porque sem eles o teste não leva a uma decisão. Se apenas campos como prazo ou dados estiverem pendentes, eles podem ser fechados na conversa com o comprador. Para quem ainda avalia se a oferta encontra demanda, o texto sobre product-market fit como decisão pode complementar essa análise.
