Win loss analysis: como fazer em cinco passos, com planilha grátis e motivos reais de negócios

Publish date: 4 de nov. de 2026
Uma win loss analysis pergunta aos compradores por que escolheram você, um concorrente ou nada. Depois, transforma as respostas em contagens que permitem agir. Você precisa de três coisas: um registro com um código de motivo por negócio fechado, um roteiro curto de entrevista e uma revisão mensal que mude alguma coisa. Este post entrega as três.
Os dez códigos de motivo vêm do registro da própria Spona, com 137 negócios fechados, e as oito perguntas vêm de 29 entrevistas pós-decisão da Spona. A planilha grátis do Google Sheets, em inglês, traz cada um desses negócios como linhas de exemplo. Você vê as fórmulas funcionando antes de apagar os dados. Faça uma cópia da planilha e siga os cinco passos abaixo.
Get thousands of leads in 4 minutes.
Stop stitching tools together.
Start with verified sales data, delivered in minutes.
No contracts · No setup · No onboarding
Win loss analysis: o que ela responde
A análise responde a três perguntas: por que você ganha, por que perde e por que negócios travam sem decisão. A maioria dos times pula a terceira. Dixon e McKenna analisaram milhões de conversas de vendas gravadas para o livro The JOLT Effect. Eles concluíram que de 40 a 60% dos negócios perdidos terminaram sem decisão.
Se o seu registro só tem Ganho e Perdido, cerca de metade das suas perdas pode estar escondida na coluna errada. Conte cada negócio fechado como ganho, perdido ou sem decisão e dê a cada resultado os seus próprios códigos. Um comprador que pausou um projeto não rejeitou você. Um comprador que assinou com o fornecedor atual rejeitou, e os dois casos pedem correções diferentes.
A segunda coisa que a análise responde é o quanto o seu CRM está errado. A Clozd conduz programas de entrevistas para fornecedores. Ela relata que os motivos de comprador e vendedor para negócios perdidos coincidem só 15% das vezes. O vendedor escreve “preço”; o comprador diz que o time não conseguia mudar o seu processo.
Só a versão do comprador mostra o que mudar. Por isso, o método abaixo mantém duas fontes para cada motivo: o código que o vendedor escolhe no fechamento e a resposta que o comprador dá algumas semanas depois. A planilha registra as duas e mostra com que frequência elas coincidem.
O registro da própria Spona mostra isso em números. Ele tem 137 negócios fechados. Desses, 85 terminaram como ganhos e 25 como perdas. Os outros 27 terminaram sem decisão.
Com base nessas contagens, a Spona ganhou 62,0% de todos os negócios fechados e 77,3% dos negócios que chegaram a uma decisão. São os negócios sem decisão que abrem a distância entre as duas taxas. Um registro só com Ganho e Perdido nunca mostra isso. A planilha mostra isso primeiro.
Como conduzir uma win loss analysis?
Cinco passos, na ordem em que a planilha espera. Cada passo termina em uma linha, um código ou uma contagem, então nada depende da memória.
- Puxe todos os negócios fechados, inclusive os sem decisão. Exporte cada oportunidade fechada do seu pipeline de vendas com o histórico de etapas. Mantenha os negócios que esfriaram depois de uma proposta. Eles entram no registro como Sem decisão (No decision), não como pipeline aberto. O guia da Klue diz que você precisa de pelo menos 10 negócios semelhantes antes que um padrão signifique algo. O registro da Spona somou de 32 a 40 negócios fechados por mês ao longo de quatro meses. Mesmo assim, quatro dos seus dez códigos ficaram abaixo de 10 negócios. Um time menor deve puxar pelo menos um trimestre. Um time que fecha poucos negócios por mês deve puxar um ano.
- Codifique um motivo principal no CRM. O HubSpot traz duas propriedades de negócio padrão para isso: Closed won reason e Closed lost reason. Limite as duas a uma lista fixa dos seus códigos e crie um conjunto de códigos para No decision. Um código por negócio, escolhido no fechamento pelo vendedor que cuidou dele. Um negócio com dois motivos fica com o que o comprador citou primeiro. Registre também de onde veio o código: o campo do CRM, um relato do vendedor ou uma entrevista com o comprador. Se o seu CRM é uma planilha, o nosso template de CRM tem um campo de motivo de perda que você pode ligar à mesma lista.
- Entreviste os compradores depois da decisão. O código do vendedor é uma hipótese; a resposta do comprador é o dado. A Clozd sugere entrevistar dentro de 30 a 90 dias após a decisão, com uma divisão igual entre ganhos e perdas. A User Intuition defende duas a quatro semanas, enquanto a memória está fresca. A Klue recomenda chamadas de 30 minutos com uma hora bloqueada na agenda. Espere que 15 a 30% dos compradores aceitem a entrevista. Questionários ficam em 3 a 5%. Quem pergunta deve ser outra pessoa, não o vendedor. O Pragmatic Institute coloca gente de produto na chamada, porque os compradores podem esconder más notícias para proteger a relação com o vendedor. No Brasil, o art. 37 da LGPD exige que controlador e operador mantenham registro das operações de tratamento de dados pessoais que realizarem, especialmente quando baseado no legítimo interesse. Liste nesse registro as gravações e as falas dos compradores, e guarde uma fala só quando a coluna Permissão de citação (Quote permission) da aba Roteiro de entrevista (Interview guide) estiver preenchida.
- Registre e conte. Uma linha por negócio fechado: o resultado, o código, a origem do código e as palavras do comprador. Depois, conte os negócios por trás de cada código. Um código com três negócios é uma anedota. Um código com onze negócios é um padrão. Mantenha as palavras do comprador curtas e literais; uma paráfrase perde a palavra que importava. Defina um mínimo antes de ler qualquer código e trate tudo o que ficar abaixo dele como “ainda não”. A planilha faz a contagem por você e sinaliza qualquer código abaixo do mínimo definido.
- Dê a cada código principal um responsável e uma mudança. A regra da Liminal é que os insights devem atualizar três coisas todo mês: battlecards, perguntas de descoberta e tratamento de objeções. Atribua o principal código de cada resultado a um time. Escreva a mudança e confira no mês seguinte se a contagem se moveu. A pesquisa da Clozd concluiu que só 39% das empresas fazem win loss como um programa contínuo e multifuncional. E 72% dos programas ficam com os times de go-to-market, divididos igualmente entre vendas e marketing. Escolha um responsável agora e a data da revisão antes de sair da sala.
Perguntas de entrevista win loss: as oito que fazemos
A Klue sugere escrever de 20 a 30 perguntas e contar com usar cerca de metade. O roteiro da Spona tem oito. Elas cobrem o gatilho, as alternativas, a evidência, a ordem dos critérios, as pessoas, o quase-não, a mudança que faltou e o depois. Seis vão para todos os compradores; uma vai só para quem escolheu a Spona e outra só para quem não escolheu.
A tabela mostra as perguntas palavra por palavra, com o número de entrevistas que incluíram cada uma. Troque “Spona” pelo nome da sua empresa nas perguntas 6 e 7. A aba Interview guide da planilha tem uma coluna para o seu texto ao lado do nosso. Faça as perguntas em ordem: a classificação da pergunta 4 só faz sentido depois que as alternativas da pergunta 2 estão na mesa.
| Nº | Pergunta | Feita a | Entrevistas |
| 1 | O que primeiro fez este projeto valer o tempo investido? | Ambos | 29 |
| 2 | Quais alternativas vocês avaliaram a sério? | Ambos | 29 |
| 3 | Que evidência mudou a sua visão sobre a qualidade dos dados? | Ambos | 29 |
| 4 | Como registros utilizáveis, fluxo de trabalho e condições comerciais se classificaram na decisão? | Ambos | 29 |
| 5 | Quem influenciou a decisão e o que importava para cada pessoa? | Ambos | 29 |
| 6 | O que quase impediu vocês de escolher a Spona? | Ganho | 17 |
| 7 | O que a Spona precisaria ter mudado para ganhar? | Perdido | 12 |
| 8 | O que aconteceu depois que vocês tomaram a decisão? | Ambos | 29 |
As contagens vêm de 29 conversas pós-decisão agendadas, separadas das próprias chamadas de venda. Delas, 17 vieram depois de negócios ganhos e 12 depois de negócios perdidos. O grupo não inclui nenhum comprador cujo negócio terminou em No decision. Essa é a lacuna que fecharíamos primeiro.
Os códigos de sem decisão (um projeto pausado, uma data de lançamento que muda, uma análise de compras) são difíceis de codificar só com um campo do CRM. O vendedor vê o negócio esfriar e precisa adivinhar. Só o comprador sabe se o projeto morreu ou apenas mudou de data. Coloque esses compradores na sua lista de entrevistas desde o primeiro mês.
A pergunta 1 merece o seu lugar porque separa um gatilho real de um desejo vago. A pergunta 2 diz contra quem você realmente disputou, que pode não ser o fornecedor que está no CRM. A pergunta 3 pede evidência, não opinião, então a resposta cita uma amostra, um teste ou o arquivo de um concorrente. A pergunta 4 força uma classificação, e é assim que você descobre se “preço” queria dizer o preço ou a impossibilidade de comprar pouco.
As perguntas 6 e 7 são a dupla que muda o playbook de vendas. O quase-não de um comprador que fechou é o motivo de perda de amanhã. A mudança que faltou para um comprador perdido é uma lacuna de produto ou uma prova que você não conseguiu mostrar. A pergunta 8 capta o que aconteceu depois da assinatura ou da desistência, que é onde moram as referências e os riscos de churn.
A pergunta 5 importa mais em contas maiores. O Gartner coloca o grupo de compra típico de uma compra B2B complexa em seis a 10 tomadores de decisão. Esses compradores passam só 17% do tempo de compra reunidos com possíveis fornecedores. O vendedor pode ter conhecido dois ou três deles.
A entrevista é a sua única chance de ouvir o que importava para os outros. Registre o cargo de cada pessoa, não o nome. Depois, leve os cargos para o seu template de buyer persona, para que a próxima chamada de descoberta peça por essas pessoas pelo cargo.
Os 137 negócios da Spona por motivo
A maioria das listas de códigos publicadas é genérica. A AskElephant sugere cinco motivos de perda: preço, momento, aderência, concorrente e falha de processo. O template da Unkover separa os motivos em cinco grupos: precificação, produto, pessoas, processo e posicionamento. Nenhuma das listas vem com contagens reais de negócios, e nenhuma dá aos negócios sem decisão códigos próprios.
O CRM da Spona usa dez códigos nos três resultados: quatro para ganhos, três para perdas e três para sem decisão. Cada negócio fechado leva exatamente um. Os códigos são específicos de um fornecedor de dados, então renomeie-os para o seu produto. Mantenha a estrutura: um código nomeia um motivo que o comprador reconheceria, não uma etapa de vendas nem uma sensação.
A tabela traz cada código, a regra de uso e as palavras do comprador registradas para ele no registro da Spona. Cada código tem uma única fala registrada. Leia a citação como a formulação típica, não como algo que todo comprador disse.
| Resultado | Código de motivo | Quando usar | Palavras do comprador registradas |
| Won | Cobertura verificada (Verified coverage) | os registros das contas-alvo do comprador foram confirmados | “Encontramos as pessoas certas no território em que realmente vendemos.” |
| Won | Compra flexível (Flexible purchase) | o comprador podia começar pequeno ou pagar pelo que usasse | “Conseguimos bancar um piloto focado sem comprar mais dados do que precisávamos.” |
| Won | Encaixe no fluxo de trabalho (Workflow fit) | o resultado se encaixou nas ferramentas e etapas que ele já tinha | “O arquivo foi simples de usar no fluxo de trabalho que já tínhamos.” |
| Won | Suporte e agilidade (Support and speed) | dúvidas e correções foram resolvidas rápido | “A definição da lista e as correções foram resolvidas rapidamente.” |
| Lost | Contrato vigente (Existing contract) | um contrato com o fornecedor atual cobre este período orçamentário | “Já temos compromisso com o fornecedor atual neste período orçamentário.” |
| Lost | Restrição de orçamento (Budget constraint) | não há orçamento para mais uma ferramenta paga | “Não podemos adicionar mais um fluxo de trabalho pago neste trimestre.” |
| Lost | Mudança no fluxo de trabalho (Workflow change) | o time não conseguiu mudar o processo durante a avaliação | “Nosso time não conseguiu mudar o processo durante a migração.” |
| No decision | Projeto pausado (Project paused) | o projeto perdeu o seu responsável | “As contratações mudaram e ninguém é dono do projeto de outbound agora.” |
| No decision | Sem urgência (No urgency) | a necessidade existe, mas a data que a motiva continua mudando | “Precisamos dos dados, mas a data de lançamento continua mudando.” |
| No decision | Atraso em compras (Procurement delay) | a decisão depende de uma análise de fornecedores ou de compras | “Estamos esperando a análise interna de fornecedores.” |

Verified coverage foi o código em 31 dos 137 negócios, a maior fatia individual. Pelas nossas contas, isso equivale a 36,5% dos ganhos. Do lado das perdas, Existing contract foi o código em 11 das 25 perdas. A fala registrada cita o período orçamentário, não o produto.
Procurement delay foi o código em 11 dos 27 negócios sem decisão. Os três maiores motivos para não ganhar estão todos dentro da empresa do comprador: um contrato, uma análise e um responsável que falta. É por isso que o roteiro pergunta o que aconteceu depois da decisão, e por isso que o passo 1 mantém os negócios sem decisão no registro.
Flexible purchase, o segundo código de ganho com 23 negócios, é o que você pode conferir contra preços públicos. O plano Pro da Spona custa US$ 99 por mês e inclui 10.500 créditos. Uma nova sessão de busca usa 1.000 créditos, o que deixa 9.500. A Standard Search só com e-mail custa de 3 a 7 créditos por lead.
Pelas nossas contas, esse primeiro mês compra cerca de 1.357 a 3.166 leads verificados. Toda busca começa com uma amostra grátis. A mensalidade é reembolsável por 14 dias, desde que você não tenha gastado nenhum crédito. É esse o tipo de compra que a fala registrada do código descreve.
Planilha grátis: o que cada aba responde
A planilha do Google Sheets, em inglês, tem cinco abas. Faça uma cópia e ela abre com os 137 negócios da Spona já na aba Registro de negócios (Deal log). Todas as contagens e alertas das outras abas funcionam antes de você digitar qualquer coisa. Apague as linhas de exemplo quando estiver pronto, ou mantenha-as por um mês para aprender as fórmulas.
| Aba | O que responde | O que tem dentro |
| Instruções (Instructions) | Como configuro a planilha e mantenho o registro honesto? | Seis passos de configuração, o mínimo de negócios, todas as listas suspensas em um só lugar |
| Deal log | O que aconteceu em cada negócio fechado, e por quê, em um código? | Uma linha por negócio: resultado (Outcome), código de motivo (Reason code), origem do código (Source of reason), palavras do comprador (Buyer wording), próxima pergunta feita (Next question asked), entrevistado (Interviewed) sim ou não |
| Códigos de motivo (Reason codes) | O que cada código significa, com que frequência aparece e quem é dono da correção? | Dez códigos com a regra, as palavras do comprador e a próxima pergunta; contagens e parcelas ao vivo; as contagens da Spona como referência; um alerta para códigos com poucos negócios |
| Interview guide | O que os compradores dizem depois da decisão, e isso bate com o código no CRM? | As oito perguntas com o seu próprio texto ao lado; um registro com uma coluna Coincide (Match) que compara o motivo do comprador com o código no CRM |
| Resumo (Summary) | Onde ganhamos, perdemos e travamos, e isso está mudando? | Contagens por resultado e taxas de ganho, os três principais motivos por resultado, resultados por faixa de porte e por concorrente, taxa de coincidência das entrevistas, negócios fechados por mês |

Três coisas na planilha impedem que o registro se desvie. Primeiro, a coluna Verificação do código (Code check) do Deal log testa o código de cada linha contra o resultado com COUNTIFS. Ela mostra “Código não combina com o resultado” (“Code does not fit outcome”) quando um vendedor registra um motivo de ganho em um negócio perdido. Segundo, as colunas Outcome, Faixa de porte (Size band) e Reason code são listas suspensas a partir de um intervalo que rejeitam qualquer valor fora da lista.
A coluna Concorrente citado (Competitor named) só avisa, então “ZoomInfo + Sales Navigator” continua aceito. Terceiro, a aba Reason codes sinaliza qualquer código com menos negócios que o mínimo definido na aba Instructions. O alerta diz “Poucos negócios para ler” (“Too few deals to read”), e o mínimo começa em 10. Com as linhas de exemplo, quatro códigos recebem esse alerta.
A aba Reason codes também guarda as contagens da Spona em duas colunas fixas, para referência. As suas contagens ao vivo ficam ao lado, para você ver se as suas perdas se concentram onde as nossas se concentraram. Cada código tem um time responsável sugerido, escolhido em uma lista suspensa: Vendas (Sales), Marketing, Produto (Product), Preços (Pricing) ou Liderança (Leadership). Renomeie os códigos para o seu produto, e o responsável continua na linha.
A aba Interview guide é onde o problema dos 15% de coincidência fica visível. Cada linha de entrevista puxa do Deal log o resultado e o código no CRM do negócio. Ela pega o motivo principal do comprador em uma lista suspensa com os mesmos códigos e mostra Coincide (Match) ou Diverge (Mismatch). A aba Summary transforma isso em uma taxa de coincidência.
Se a sua for baixa, os seus vendedores não estão mentindo. Eles estão adivinhando, e a correção é o passo 3, não uma bronca. A aba Summary também separa os resultados por faixa de porte da empresa e pelo concorrente citado. Quando você adicionar as datas de fechamento, ela conta os negócios fechados por mês.
Mais duas colunas do Deal log mantêm o registro honesto. Source of reason mostra se o código veio do campo do CRM (CRM field), do relato do vendedor (Rep debrief) ou da entrevista com o comprador (Buyer interview), e quanto do registro é palpite. Interviewed marca os negócios com entrevista concluída, e a aba Summary conta esses negócios. Filtre o Deal log por resultado para comparar as suas entrevistas de ganhos e de perdas com a divisão igual que a Clozd recomenda.
Outros templates grátis sobre o tema são mais rasos: o da Mural é um quadro branco que exige cadastro, e a planilha da Klue exige um formulário. O XLSX da Unkover tem oito campos e nenhum dado de exemplo. Quem usa Excel pode baixar o nosso arquivo em Arquivo, Fazer download, Microsoft Excel (.xlsx). As fórmulas usam COUNTIFS, INDEX, MATCH e SUMPRODUCT, então o Excel e o LibreOffice as recalculam sem ajustes.
Como transformar motivos em mudanças
Uma contagem não é uma mudança. A aba Reason codes dá a cada código um time responsável sugerido. O Deal log guarda a próxima pergunta que o vendedor fez quando o código ficou claro. Essas perguntas são o começo da correção, porque testam se o motivo era real ou uma saída educada.
Os seis códigos que custaram negócios à Spona, com o responsável que sugerimos e a próxima pergunta que o vendedor fez:
| Código de motivo | Responsável sugerido | Próxima pergunta feita |
| Existing contract | Sales | Quando acontece a decisão de renovação, e podemos testar uma lacuna antes disso? |
| Budget constraint | Pricing | Que ferramenta ou custo de pesquisa atual um piloto bem-sucedido precisaria substituir? |
| Workflow change | Product | Que parte poderia ser testada sem mudar o fluxo de envio atual? |
| Project paused | Sales | Quem deve ser o dono da próxima decisão e quando devemos retomá-la? |
| No urgency | Marketing | Que evento tornaria este um projeto ativo? |
| Procurement delay | Sales | Que evidência ajudaria o revisor a concluir a decisão? |
Três das seis perguntas tratam de prazo: uma data de renovação, uma data para retomar, um evento que torna o projeto ativo. Isso aponta para uma correção de qualificação, não de produto. Pergunte pela data de renovação do fornecedor atual e pelo responsável do projeto já na primeira chamada. O nosso checklist de qualificação de leads é o lugar dessas duas perguntas.
Workflow change aponta para produto e onboarding. O comprador perdido não conseguia mudar o processo no meio da migração, então a mudança é um piloto que roda ao lado do fluxo atual em vez de substituí-lo. Budget constraint aponta para preços. A pergunta desse código quer saber que custo atual um piloto substituiria, o que transforma “sem orçamento” em uma comparação.
Os códigos de ganho merecem o mesmo tratamento. Verified coverage ganhou mais negócios. A prova por trás dele, um teste nas próprias contas-alvo do comprador, deve estar na primeira chamada, não na terceira. Flexible purchase ganhou 23 negócios, o que é um argumento para começar pelo piloto pequeno e não pelo contrato anual.
Revise as contagens em um calendário fixo. A Clozd recomenda uma revisão fixa mensal ou trimestral. A mensal serve para um time que fecha 30 ou mais negócios por mês; a trimestral, para um time menor. O relato prático da Cotera descreve um resumo mensal de uma página em três parágrafos: os números, o padrão e as ações.
A aba Summary entrega o primeiro parágrafo. O segundo parágrafo é o código cuja contagem mais se moveu. O terceiro diz quem mudou o quê, e a data em que você vai conferir de novo.
Get thousands of leads in 4 minutes.
Stop stitching tools together.
Start with verified sales data, delivered in minutes.
No contracts · No setup · No onboarding
Perguntas frequentes sobre win loss analysis
Quem deve conduzir as entrevistas de win loss?
Não o vendedor que cuidou do negócio. A orientação da Klue é um entrevistador imparcial, com o time de vendas fazendo a apresentação inicial. O Pragmatic Institute quer que o pessoal de produto conduza, porque os compradores podem guardar críticas que prejudicariam o vendedor.
A pesquisa da Clozd concluiu que times que usam um terceiro têm mais que o dobro de chance de dizer que o seu feedback é profundo o bastante. Um líder de vendas que não participou do negócio é a opção intermediária prática para um time pequeno.
Quantos negócios uma win loss analysis exige?
A Klue põe o piso em 10 negócios semelhantes por padrão. Para entrevistas, a Clozd vê as respostas chegarem à saturação com 25 a 30 por segmento. A User Intuition coloca o mínimo para padrões direcionais em 20 a 30 entrevistas.
A Liminal observa que a maioria dos programas entrevista 8 a 12 compradores por trimestre, pouco demais para ver uma mudança. As 29 entrevistas da Spona em quatro meses ficam dentro das faixas da Clozd e da User Intuition, lidas como um único segmento.
Como se calcula o win loss?
A taxa de ganho é o número de negócios ganhos dividido pelo de negócios fechados. O exemplo da Klue divide 40 ganhos por 100 negócios fechados. Os mesmos 40 ganhos contra 60 perdas dão uma razão de ganho e perda de dois para três. Decida se “fechados” inclui os negócios sem decisão e diga isso no relatório.
O registro da Spona calcula duas taxas a partir das mesmas contagens: 62,0% de todos os negócios fechados e 77,3% dos negócios decididos. A planilha mostra as duas, porque a distância entre elas vem dos seus negócios sem decisão.
Os motivos de win loss do CRM substituem as entrevistas?
Não, mas mantenha os dois. O código do CRM é barato, imediato e cobre todos os negócios, o que faz dele o denominador certo para as contagens. No HubSpot, a primeira correção é limitar as propriedades padrão de motivo a uma lista fixa dos seus códigos.
A entrevista é lenta e cobre uma amostra, mas é a única fonte que o comprador controla. O dado de 15% de coincidência da Clozd é o motivo de a planilha ter uma coluna Match. Ela mostra com que frequência as duas fontes concordam nos seus próprios negócios.
Share this article
GET FREE LEADS





