O piloto foi fechado com entusiasmo de verdade. Oito usuários nomeados, quatro semanas, um canal compartilhado e uma reunião de resultados na agenda. A primeira semana vai bem: todo mundo faz login, surgem perguntas, alguém importa um conjunto de dados real e diz que parece promissor.
A segunda semana é tranquila. A terceira é silenciosa. Na quinta-feira antes da reunião de resultados, alguém do lado do cliente pergunta se o piloto poderia ser estendido, porque o pessoal andou ocupado e quer dar uma chance justa ao produto. Às vezes a extensão gera uma decisão. Na maioria das vezes, gera um segundo mês tranquilo e uma mensagem educada, meses depois, dizendo que as prioridades mudaram.
Nada deu errado com o produto. O que deu errado é que um piloto é um problema de onboarding vestido de processo comercial, e ele foi conduzido apenas como processo comercial. Este guia mostra o que diferencia um piloto de um teste grátis e de um beta, as três coisas a acordar antes do primeiro dia, como definir o escopo, a queda de uso da segunda semana que decide a maioria dos pilotos, o checkpoint no meio do piloto, como conduzir uma reunião de resultados que gere uma resposta e o que medir enquanto ele está em andamento.
Principais conclusões
- Um piloto é definido pelo seu final. Critérios acordados, uma data e um tomador de decisão nomeado. Sem os três, é um teste estendido.
- Pilotos morrem por inatividade, não por decepção. A causa habitual do fracasso é que poucos participantes nomeados usaram o produto o suficiente para avaliar.
- Defina um escopo estreito o bastante para concluir um ciclo real. Um piloto mais amplo não gera mais provas, só mais calendário.
- O checkpoint no meio do piloto é a intervenção inteira. Na reunião de resultados, tudo já está decidido.
- Meça a participação, não a percepção. Quantos usuários nomeados chegaram a um resultado real é o número que antecipa a decisão.
O que um piloto realmente é
Programa piloto, em um parágrafo
Um programa piloto, também chamado de prova de conceito, é uma avaliação com prazo definido em que um potencial cliente usa o seu produto para trabalho real, com dados reais e um grupo nomeado de pessoas, para decidir se vai comprar. O que faz dele um piloto, e não um teste longo, é a decisão atrelada ao final: critérios de sucesso acordados, uma data fixa e uma pessoa que vai responder sim ou não. Tire qualquer um desses elementos e a avaliação vai expirar em vez de chegar a uma conclusão.
A palavra é usada de forma solta, e isso causa estragos reais, porque as três coisas com que ela é confundida exigem tratamentos opostos.
| Teste grátis | Piloto / POC | Beta | |
|---|---|---|---|
| Quem participa | Uma pessoa, por iniciativa própria | Um grupo nomeado dentro de um comitê de compra | Clientes atuais que aceitaram participar |
| O que está sendo provado | Se o produto serve para essa pessoa | Se ele entrega um resultado de negócio acordado | Se uma funcionalidade inacabada está pronta |
| Quem decide | O usuário, informalmente | Um sponsor nomeado, formalmente | O seu time de produto |
| Como termina | Ele expira | Uma reunião de resultados e uma decisão | Um lançamento |
| Fracasso típico | Um usuário nunca chega ao valor | Poucos participantes usaram para poder avaliar | Feedback escasso demais para agir |
Daí decorrem duas consequências. Primeiro, a estratégia que funciona para a conversão de testes grátis (otimizar para que uma pessoa chegue ao valor rapidamente) é necessária, mas não suficiente em um piloto, porque um piloto é julgado pelo grupo. Segundo, um programa beta tem como objetivo aprender e pode tolerar uma experiência inacabada; um piloto tem como objetivo provar, e não pode.
Três coisas a acordar antes do primeiro dia
Quase todo piloto que foi salvo acaba se revelando salvo no início, e não no meio. Esses três acordos levam uma hora e determinam se a avaliação vai conseguir terminar.
1. Critérios de sucesso nos números do cliente
Dois ou três resultados, por escrito, expressos nas unidades que o cliente já usa e observáveis dentro do período do piloto. Aprovações concluídas em menos de um dia, em vez de três. Duzentos registros processados sem nenhuma correção manual. O relatório de segunda-feira gerado sem exportar nada. Critérios como o time acha fácil de usar não podem ser refutados, o que significa que também não podem ser comprovados, e um piloto em que não é possível ser reprovado é um piloto em que não é possível ser aprovado.
Quando os critérios não são visíveis no seu produto, decida com antecedência como eles serão observados. A alternativa é uma reunião de resultados em que cada lado se lembra das últimas quatro semanas de um jeito diferente.
2. Escopo: um ciclo real, um conjunto de dados real, um time real
Escolha a menor fatia de trabalho que, se funcionar, se transfere para todo o resto. O instinto dos dois lados é provar o máximo possível, o que gera um piloto espalhado por cinco times e conclusivo sobre nada. Um piloto que prova um workflow de ponta a ponta com dados genuínos é mais convincente do que um que tocou seis workflows com registros de teste, e é muito mais fácil de concluir.
3. Uma data e um tomador de decisão nomeado
A reunião de resultados entra na agenda antes de o piloto começar, com a pessoa que vai decidir presente nessa reunião. Se ninguém consegue nomear o tomador de decisão com antecedência, essa é a coisa mais útil que você vai aprender no trimestre, e é melhor aprendê-la na semana zero. Combine também o que acontece em cada desfecho, inclusive o que um “não” significa, porque um piloto sem um desfecho negativo definido tende a terminar em uma extensão, e não em uma resposta.
Um piloto sem um final definido não fracassa. Ele evapora. Extensões parecem generosas e geralmente são o momento em que um piloto deixa de ser uma avaliação ativa e vira uma conta abandonada.
Como escolher o grupo de participantes
A lista de participantes costuma ser montada com quem estiver disponível, o que decide o resultado sem ninguém perceber. Três regras deixam o grupo representativo o bastante para provar algo e pequeno o bastante para ser acompanhado.
Pequeno e nomeado. De seis a dez pessoas, identificadas individualmente, e não como um time. “O time de operações” gera um piloto em que todo mundo acha que outra pessoa está cuidando disso. Uma lista de nomes gera responsabilidade e, tão importante quanto, dá a você uma base para medir a participação.
Inclua um cético. Um piloto formado só por entusiastas prova que entusiastas gostam do seu produto. A objeção que vai surgir na decisão de compra é melhor que surja na segunda semana, quando você ainda pode respondê-la.
Inclua a pessoa que faz o trabalho no dia a dia. Pilotos avaliados apenas por gestores medem impressões sobre o produto, e não o produto. O usuário do dia a dia também é quem, pelo seu comportamento, mostra se o valor é real, porque é o único participante para quem usar o produto não é um favor.
A queda da segunda semana
O uso em um piloto segue um padrão tão consistente que dá para se planejar para ele. A primeira semana é movimentada, porque o piloto é novidade e há um kick-off. A segunda semana despenca, porque o trabalho normal é retomado e nada no dia do participante depende do piloto. A terceira e a quarta semanas são tranquilas. Então há um pequeno pico logo antes da reunião de resultados, quando as pessoas se lembram da reunião.
O uso se concentra nas duas pontas. O meio é onde as evidências deveriam ser reunidas.
A queda não é sinal de desinteresse. É o que acontece com qualquer atividade voluntária quando a novidade passa: o participante pretendia usar o produto, aí chegou um prazo de verdade. Quando ele volta, já esqueceu a configuração que fez na primeira semana e enfrenta um pequeno custo de reaprender, que é exatamente o ponto em que as pessoas adiam.
O remédio é pouco glamouroso e eficaz: tornar a volta barata. Um participante que retorna na terceira semana deve encontrar imediatamente onde parou, com o próximo passo visível, sem precisar perguntar a ninguém. Isso significa uma orientação dentro do produto que sobreviva ao intervalo: um checklist mostrando o que ele já fez e o que falta, ajuda contextual nas telas que ele viu só uma vez e um lembrete curto no caminho até os critérios de sucesso do piloto. Tudo o que depende de um ser humano disponível vai falhar aqui, porque o reaprendizado acontece às 7h40 de uma terça-feira.
Esse também é o motivo pelo qual os participantes de um piloto devem passar por um onboarding tão cuidadoso quanto o de clientes pagantes, e não mais casual. O grupo do piloto tem menos paciência do que um cliente novo, não mais: ele ainda não se comprometeu, e o custo de abandonar em silêncio é zero. Os princípios de ativação do nosso guia sobre como aumentar a ativação de usuários se aplicam aqui, só que com o volume no máximo.
O checkpoint no meio do piloto
Marque um checkpoint no final da segunda semana, na agenda desde o primeiro dia, e trate-o como a reunião mais importante do piloto. A reunião de resultados é um evento de prestação de contas; o checkpoint é o único momento em que o resultado ainda pode ser mudado.
Leve dados de participação em vez de impressões: quantos usuários nomeados fizeram login, quantos atingiram cada critério de sucesso, onde as pessoas pararam. Esse último item é o que gera uma conversa útil, porque transforma uma preocupação vaga em algo que dá para resolver. Três participantes que pararam na mesma tela de configuração é um problema solucionável. “Não foi muito usado” não é.
A conclusão por passo transforma o checkpoint no meio do piloto em uma conversa baseada em fatos: quem atingiu qual critério e onde as pessoas pararam.
O checkpoint também protege você do pedido de extensão. Quando uma revisão no meio do piloto já mostrou que quatro de oito pessoas estão ativas, a extensão pode ser negociada como um plano de reengajamento com uma nova data, em vez de concedida como uma continuação vaga. Extensões oferecidas sem mudança no plano geralmente produzem um segundo período com o mesmo uso.
Uma disciplina útil. Se a participação estiver abaixo da metade do grupo no checkpoint, resolva a participação antes de mexer em qualquer outra coisa. Não existe objeção sobre o produto que valha a pena responder quando a objeção é que ninguém olhou ainda.
Como conduzir a reunião de resultados
A reunião de resultados funciona melhor como um encontro curto e estruturado do que como uma demonstração. Passe pelos critérios acordados um a um e diga com clareza se cada um foi atingido, inclusive os que não foram. Admitir uma falha logo no início é o que torna o resto crível, e um piloto que atingiu dois de três critérios, com uma explicação clara sobre o terceiro, converte com mais frequência do que um apresentado como um sucesso impecável.
Dois acréscimos fazem a reunião funcionar. Mostre o panorama da participação (quem usou, quanto usou, o que conseguiu), porque um sponsor que não ouviu nada durante um mês precisa saber que as evidências são reais. E leve o esboço do rollout: como seriam os primeiros noventa dias depois de um sim, quem passaria pelo onboarding e em que ordem, e o que isso exigiria deles. Um tomador de decisão que diz sim não está comprando o piloto, está comprando a implantação, e o esboço responde à pergunta que ele está de fato avaliando. Os princípios de transição do nosso guia sobre o handoff de vendas para onboarding se aplicam a partir do momento em que esse sim chega, e pilotos convertem mais rápido quando a transição já parece desenhada.
Quando o piloto caminha para uma implantação em vários times, a estrutura de contas e licenças do guia de onboarding enterprise é o formato certo para esse esboço de noventa dias.
O que medir durante um piloto
1. Participação dos usuários nomeados
A parcela do grupo acordado que usou o produto pelo menos uma vez nesta semana. É o sinal mais cedo disponível e o que tem a relação mais forte com a decisão final. Acompanhe-o como uma fração da lista de nomes, nunca como total de sessões, porque dois usuários entusiasmados podem fazer um piloto inativo parecer saudável.
2. Critérios atingidos
Para cada critério de sucesso acordado, quantos participantes de fato o atingiram no produto. Isso é a reunião de resultados montada continuamente, e não na véspera, e transforma a reunião final em uma confirmação, e não em uma revelação.
3. Tempo até o primeiro resultado real
Dias desde o acesso até o primeiro participante concluir um trabalho genuíno, não um exemplo. É a versão do piloto do time to value, e quando ele passa da primeira semana, a queda faz o resto. Quando ele é lento, a causa quase sempre é a configuração: dados, permissões ou uma integração que não tinha responsável.
4. Ponto de abandono
O passo em que os participantes mais param. Em um piloto, isso vale mais do que qualquer número agregado, porque o grupo é pequeno o bastante para que uma única tela travada explique a curva inteira. É o mesmo raciocínio por trás de um funil de onboarding, aplicado a um grupo de oito pessoas.
Sete formas pelas quais os pilotos fracassam
1. Nenhum tomador de decisão na sala
O piloto é conduzido por um defensor entusiasmado que, no fim, não controla o orçamento. Tudo corre bem e nada acontece. Nomeie quem decide antes do primeiro dia ou aceite que isso é uma exploração, e não uma avaliação.
2. Critérios escritos depois do fato
Quando o sucesso é definido na reunião de resultados, os dois lados o definem como aquilo que aconteceu, e a reunião vira uma negociação sobre interpretação em vez de uma decisão.
3. Um escopo que não tem como terminar
Cinco times, três workflows, duas integrações e quatro semanas. A amplitude parece mais segura e garante que nada seja provado de forma conclusiva.
4. Dados de exemplo em vez de dados reais
Um piloto feito com registros de demonstração prova que o produto funciona com registros de demonstração. É nos dados reais que estão os casos extremos, e os casos extremos são justamente o que o cético vai perguntar.
5. Onboarding deixado para a chamada de kick-off
Uma única sessão ao vivo, nenhuma orientação depois disso, e um participante que volta na terceira semana sem lembrar onde fica nada. Este é o mais comum e o mais fácil de corrigir dos sete.
6. Nenhuma visibilidade sobre o uso
Um piloto acompanhado apenas como uma etapa do funil de vendas significa que o primeiro sinal de problema chega na reunião de resultados, quando não há mais nada a fazer. Alguém do seu lado deve conseguir ver a participação toda semana.
7. A extensão automática
Conceder mais tempo sem mudar o plano repete o mesmo mês. Se uma extensão se justifica, ela deve vir com um novo grupo, um escopo menor ou uma nova data: alguma coisa diferente.
Como conduzir um piloto com o Kompassify
A parte do piloto que mais fica sem gestão é a experiência do participante entre o kick-off e a reunião de resultados, porque ela acontece dentro do produto, onde o processo comercial não enxerga.
Com o Kompassify, você pode dar ao grupo do piloto a sua própria camada de orientação sem trabalho de engenharia: um walkthrough curto na primeira entrada que vai direto aos critérios de sucesso acordados em vez de fazer um tour por tudo, um checklist de onboarding do piloto cujos passos são os próprios critérios, para que o progresso fique visível para o participante e para você, ajuda contextual nas telas que as pessoas viram só uma vez durante o kick-off e um lembrete que leva o participante que retorna na terceira semana de volta ao próximo passo, em vez da tela inicial. Como os fluxos são segmentados, tudo isso se aplica apenas ao grupo do piloto e desaparece quando a conta passa a ser uma implantação normal.
Os dados de conclusão por passo também transformam o checkpoint no meio do piloto em uma conversa baseada em fatos: você consegue dizer quais critérios foram atingidos e por quem, e em que ponto do fluxo as pessoas pararam, quatro semanas antes de alguém precisar formar uma opinião sobre isso.
Pare de perder pilotos na segunda semana
Dê a cada grupo de piloto um caminho guiado até os seus próprios critérios de sucesso, veja quais participantes chegaram lá e corrija o passo travado enquanto a avaliação ainda está em andamento. Sem código. Grátis para até 100 usuários ativos mensais, planos a partir de $129/mês, em conformidade com o GDPR e hospedado na UE.
Comece grátis →A versão em um parágrafo
Um piloto é uma avaliação com uma decisão atrelada, o que significa critérios acordados nos números do próprio cliente, uma data fixa e um tomador de decisão nomeado, tudo definido antes do primeiro dia. Defina o escopo como um ciclo real de trabalho real, com um grupo pequeno e nomeado que inclua um cético e alguém que faz o trabalho no dia a dia. Depois, planeje-se para o formato que o uso de um piloto realmente tem: uma primeira semana movimentada, uma queda na segunda e um pico de pânico antes da reunião de resultados. Torne a volta barata com uma orientação dentro do produto que leve o participante de volta ao próximo passo sem depender de uma pessoa, faça um checkpoint no meio do piloto ao final da segunda semana com dados de participação em vez de impressões e trate a baixa participação como o problema a resolver antes de qualquer objeção sobre o produto. Conduza a reunião de resultados critério por critério, admita o que não foi atingido e leve um esboço de rollout de noventa dias, porque o sponsor está decidindo sobre a implantação, e não sobre o piloto. Meça a participação dos usuários nomeados, os critérios atingidos, o tempo até o primeiro resultado real e o ponto de abandono, e trate qualquer extensão oferecida sem mudança de plano como o começo de um segundo mês tranquilo.
Perguntas frequentes
O que é um programa piloto em SaaS?
Um programa piloto, muitas vezes chamado de prova de conceito, é uma avaliação com prazo definido em que um potencial cliente usa o seu produto com trabalho real, dados reais e um grupo definido de pessoas, para decidir se vai comprá-lo. O que o caracteriza não é a duração nem o preço, mas a decisão atrelada ao final: um piloto tem critérios de sucesso acordados, uma data e uma pessoa nomeada que vai dizer sim ou não. Uma avaliação sem essas três coisas não é um piloto, é um teste estendido que vai expirar em silêncio.
Qual é a diferença entre um piloto e um teste grátis?
Um teste grátis é self-service, individual e aberto na intenção: uma pessoa explora o produto para ver se ele serve, e o teste termina simplesmente expirando. Um piloto é feito em comitê, tem escopo e está amarrado a uma decisão: um grupo usa o produto com base em critérios acordados, e ele termina em uma reunião em que alguém decide. Os dois também fracassam de formas diferentes. Um teste grátis fracassa quando um único usuário não chega ao valor, enquanto um piloto geralmente fracassa porque poucos dos participantes nomeados usaram o produto o suficiente para que alguém pudesse avaliar.
Quanto tempo deve durar um piloto SaaS?
O suficiente para completar um ciclo real do trabalho que o seu produto apoia, e não mais do que isso. Para a maioria dos produtos, isso significa de quatro a seis semanas; para produtos ligados a um processo mensal ou trimestral, um ciclo completo mais uma semana. Pilotos mais longos raramente produzem mais evidências, porque o uso se concentra nas duas primeiras semanas e na última. Se um piloto precisa de três meses para provar alguma coisa, a prova buscada geralmente é ampla demais, e reduzir o escopo é uma resposta melhor do que estender o calendário.
Um piloto deve ser pago ou gratuito?
Um piloto pago compra comprometimento: quando existe uma linha de orçamento, os participantes são nomeados, o tempo é reservado e alguém dentro da empresa responde por um resultado. Um piloto gratuito reduz a barreira para começar e aumenta o risco de o piloto ficar à deriva, porque ninguém na organização do cliente precisa justificar o tempo investido. Quando a implementação exige esforço real do cliente, cobrar alguma coisa, mesmo uma taxa de implementação simbólica, costuma melhorar as taxas de conclusão mais do que qualquer quantidade de follow-up.
Por que os pilotos fracassam mesmo quando o produto funciona?
Porque o produto não foi usado o suficiente. O fracasso mais comum de um piloto não é um produto que decepcionou, mas um grupo que nunca se engajou: as contas foram criadas, dois dos oito usuários nomeados fizeram login e, na reunião de resultados, ninguém conseguia falar sobre o resultado. O entusiasmo é maior nos primeiros dias e cai bruscamente quando o trabalho normal é retomado, então a tarefa prática durante um piloto é manter um grupo pequeno ativo por algumas semanas, o que é um problema de onboarding, e não de vendas.
Quais devem ser os critérios de sucesso de um piloto?
Dois ou três resultados expressos nos números do próprio cliente, acordados por escrito antes do início e mensuráveis dentro do período do piloto. Bons critérios se parecem com um processo específico concluído mais rápido, um volume específico sendo processado ou um erro específico desaparecendo. Critérios ruins são satisfação, facilidade de uso ou se o time gosta do produto, porque não podem ser refutados e, portanto, também não podem ser comprovados. Se os critérios não puderem ser observados no produto, decida antes do piloto como você vai observá-los.
Quem deve ser o responsável pelo piloto internamente?
Uma pessoa nomeada de cada lado, com o lado do fornecedor responsável pelo ritmo e o lado do cliente responsável pela decisão. A falha frequente é um piloto sob a responsabilidade de um vendedor que o acompanha como uma etapa do funil de vendas e não vê nada do que acontece dentro do produto, de modo que o primeiro sinal de problema é a própria reunião de resultados. Juntar o responsável comercial a quem consegue ver o uso, e combinar com antecedência um checkpoint no meio do piloto, resolve a maior parte do problema.