BANT é uma estrutura de qualificação de vendas usada para identificar e buscar as perspectivas mais qualificadas com base em seu orçamento, autoridade, necessidades e linha do tempo.
Todo mundo já ouviu falar de BANT até agora. Mas o BANT ainda se aplica a vendas recorrentes e de alta velocidade – ou é necessária uma versão mais moderna do BANT.
Neste artigo, gostaria de oferecer uma versão modernizada do BANT que possa ser aplicada a equipes de vendas internas (SDRs, AEs) que lidam com acordos de receita recorrentes.
Você pode chamá-lo de qualificação de vendas BANT para uma nova era.
Table of Contents
Origens do BANT
O BANT foi concebido pela IBM como uma maneira de identificar uma oportunidade. O site da IBM nos diz o seguinte :
Critérios de identificação da oportunidade BANT
As oportunidades são identificadas conversando com possíveis clientes ou clientes para determinar suas necessidades de negócios e soluções. A orientação da IBM para identificação de oportunidades é usar uma abordagem padrão chamada BANT. De acordo com as orientações, uma oportunidade é considerada validada se o possível cliente atender a três dos quatro itens da BANT. Como equipe, o ISR e o representante de vendas podem decidir sobre uma forma mais restrita ou mais flexível de BANT.
- Orçamento – Qual é o orçamento do cliente em potencial?
- Autoridade – O cliente em potencial tem autoridade para tomar decisões ou é um influenciador?
- Necessidade – Qual é a necessidade comercial do cliente em potencial?
- Prazo – em que prazo o cliente em potencial estará implementando uma solução?
Desafios com o BANT aplicados às vendas de SaaS
- Orçamento – Hoje, o SaaS é um modelo de assinatura extraído dos orçamentos do OpEx, enquanto tradicionalmente as compras saíam de um orçamento do CapEx … Isso muda alguma coisa?
- Autoridade – As organizações de hoje ainda tomam decisões de compra com uma única voz de autoridade sênior que impõe a decisão?
- Necessidade – O que é uma necessidade versus uma necessidade e um desejo? O SaaS realmente atende a uma necessidade ou a maioria dos serviços é apenas um ” bom de se ter “?
- Prazo – O conceito de prazo é diferente para um acordo SaaS com um ciclo de vendas medido em dias e uma implementação de um único “clique”?
Acima de tudo, ainda vivemos em um mundo centrado nas vendas, em que procuramos clientes com Budget que podem ser vendidos em uma solução ou mudamos as coisas para onde agora vivemos em um mundo mais centrado no cliente, onde ajudamos um cliente na identificação, diagnóstico e resolução de um problema? Se sim, o que muda? E à luz dessa mudança, como posso qualificar um acordo SaaS?
O que descobrimos é que, quando aplicamos o BANT às vendas tradicionais de SaaS, existem alguns desafios:
- Problema para os SDRs: quando os SDRs recebem BANT para qualificar um negócio, ele sai pela culatra, pois basicamente eles estão começando a vender enquanto um cliente ainda está no modo “educacional”.
- Problema para os EAs: quando os EAs executam o BANT para qualificar um negócio, eles obtêm respostas afirmativas, mas o negócio ainda não está qualificado.
Como exemplo, vamos dar uma olhada em uma conversa típica do BANT, mas dramatizá-la para obter efeito:
Mike SaaS Salester Jennifer, a cliente
Jennifer, então, se eu resumir seus
desafios, você precisará solucionar o problema
X e o problema Y. Eu entendi direito?
Sim isso está certo!
Parece que essa é uma grande necessidade
para vocês.
Sim, por isso visitamos a recente
Conferência SalesHacker, onde
aprendemos sobre sua empresa.
Impressionante. Bem, parece que você
garantiu o orçamento para este projeto?
Sim, com certeza.
Impressionante. Impressionante. Posso perguntar quem
é o tomador de decisão?
Eu sou o tomador de decisão, a
compra também se envolverá
Ótimo. E quando você precisa
ter uma solução?
Nas próximas 8 semanas,
mas até 1 de julho!
Mike acabou de se qualificar de acordo com a BANT e reporta à sua chefe Nicole :
Nicole, acabei de ligar para Jennifer. Você deve se lembrar dela, ela era líder da conferência Sales Hacker, procurando uma solução para os problemas X e Y. Ela confirmou que é a tomadora de decisões no projeto “Melhoria”. Jennifer precisa de uma solução até 1º de julho e confirmou ter orçamento para gastar.
Isso resulta em SQLs de baixa qualidade ou, pior ainda, acordos de baixa qualidade no pipeline de vendas qualificado que devem ser fechados nas próximas 8 semanas. E embora eu tenha simplificado demais o exemplo, na maioria dos casos é assim que esse “acordo” fraco entra no funil como um acordo qualificado. Por quê? Bem, vamos dar uma olhada …
Regra nº 1 do SaaS: trata-se de prioridade, não de orçamento
Definição de orçamento do Google : uma estimativa de receita e despesa por um período definido.
A situação do SaaS: a maioria dos serviços SaaS custa uma fração de suas contrapartes permanentes de licença / hardware. Uma taxa de US $ 500 a US $ 5.000 por mês não deve ser um problema para uma empresa saudável que tem uma necessidade real. Isso pode chegar a US $ 40.000 / mês sem problemas para grandes empresas. Sempre existe um orçamento. Nunca foi sobre o orçamento, sempre foi sobre ser uma prioridade. Uma prioridade que varia ao longo do tempo.
Conceito explicado: Na figura acima, você percebe que, com o tempo, a prioridade aumenta de agradável para ter , de ter e, a certa altura, chega a ser obrigatório . É fundamental determinar onde você está nesta imagem.
À medida que a prioridade diminui, um cliente pode ficar escuro, levando você a acreditar que o “orçamento é gasto”, sem perceber que as condições podem mudar a seu favor, no qual a prioridade aumentará novamente. Ainda melhor … Entendendo a situação deles, você pode descrever o impacto total do seu serviço e como ele pode resolver outros desafios que o cliente pode enfrentar e, com ele, você poderá aumentar a prioridade!
O que fazer como SDR / AE: No início do processo de vendas, seu cliente ainda está no modo de descoberta, este é o momento ideal para perguntar: “Essa é uma das principais iniciativas da sua empresa?” E “Onde esse ranking está? ? ”E“ Você vê essa prioridade mudando ao longo do tempo? ”Pergunte:“ Isso é bom de ter, necessário ou necessário? ”
# 2 No SaaS, a autoridade é distribuída e não hierárquica
Definição de autoridade do Google : o poder ou o direito de dar ordens, tomar decisões e impor obediência.
A situação do SaaS: com o SaaS (e cada vez mais em qualquer venda), vemos um afastamento da tomada de decisão hierárquica (de cima para baixo) . Em muitos casos, um único usuário pode relatar que o serviço não funciona como anunciado, alterando o curso da ação. Hoje, muitas empresas constroem uma equipe que precisa chegar a um consenso. A equipe pode ser composta por 1 a 2 usuários, um gerente, alguém do financiamento etc.
Conceito explicado: Na figura acima, você vê à esquerda uma “árvore de decisão” tradicional. Os usuários se juntam aos gerentes, que, por sua vez, se dirigem a um executivo que reúne as informações e toma a decisão. No entanto, muitos serviços SaaS são realmente “orientados pela experiência do usuário”. Essa é uma das muitas razões pelas quais a UI / UX se tornou tão importante nos últimos anos.
À direita, você vê que o que você pensava ser uma árvore de decisão era realmente um comitê. Em muitos casos, nos comitês, o executivo não é a pessoa que decide (eles dão a bênção à decisão final), mas um usuário que precisa trabalhar com ela todos os dias. O usuário será orientado no processo de decisão pelo gerente (com suas próprias necessidades) e pelo executivo (garantindo que um processo de decisão adequado seja seguido).
O que fazer como SDR / AE: Sua primeira prioridade não é determinar quem é o tomador de decisão, mas que tipo de processo de decisão está sendo seguido. Você pode descobrir fazendo perguntas como “Quem mais está envolvido neste projeto que pode se beneficiar deste <insira artigo com insights>?” E “Quem mais posso convidar para a próxima reunião …?”. Outra ótima pergunta é: “Você esteve envolvido em outras compras recentes nessa área, como <x> e <y>?”
# 3 Impacto sobre a necessidade
Definição de necessidade do Google : exigir (algo) porque é essencial ou muito importante.
A situação do SaaS: o SaaS se tornou extremamente competitivo, já que quase todos os serviços ficam na mesma “infraestrutura de nuvem”, usam um esquema de cores muito semelhante (azul para social, verde para preditivo), para que a competição possa rapidamente se tornar um combate recurso a recurso. Isso não é benéfico para o cliente, uma vez que, muitas vezes, são enganados a pagar por recursos dos quais nunca vão precisar. Como SDR / AE, você pode desempenhar um papel fundamental ajudando a evitar isso desde o início, identificando o impacto.
Conceito explicado: Na figura acima, você observa à esquerda um foco tradicional na necessidade do cliente de traduzir seus requisitos em recursos e benefícios. À direita, você vê que a necessidade do cliente é mais como uma cebola com camadas infinitas que, através da arte de fazer perguntas, precisam ser descascadas … até o âmago. Geralmente, de 6 a 7 camadas (de 6 a 7 perguntas!), É possível encontrar o impacto subjacente da necessidade.
Esse impacto determina a diferença entre o que é bom de se ter e o que se deve ter; e entender esse conceito é o que separa um bom EA de um EA excelente.
O que fazer como SDR / AE: O impacto de um serviço é melhor encontrado ao conversar com um cliente. Portanto, organize uma reunião de clientes / vendas. Peça às equipes de SDR / AE que apresentem uma lista de perguntas significativas para perguntar sobre o impacto do serviço. IMPORTANTE!
Como SDR, você não pode descascar a cebola inteira na primeira chamada – o cliente ainda não confia em você! Mas você pode descascar mais uma camada fazendo mais 1-2 perguntas ; “ Posso perguntar qual é o impacto desse serviço além de oferecer melhores painéis? ”… Isso dará ao seu AE uma vantagem incrível, pois ele é capaz de diagnosticar melhor as verdadeiras necessidades do cliente:“ Meu SDR me informou sobre a necessidade deste impacto no serviço … capturamos isso corretamente? Posso perguntar .. ”
Evento crítico nº 4 sobre a linha do tempo
Definição de linha do tempo do Google: um período de tempo, especialmente um período especificado em que algo ocorre ou está planejado para ocorrer.
A situação do SaaS: o desafio descrito aqui não é exclusivo apenas do SaaS; é um erro comum que os profissionais de vendas cometem o tempo todo . Nas vendas de SaaS, geralmente estamos interessados em ” Quando você precisa disso até … ” ou ” Qual é a data de ativação deste serviço … ” a partir da qual estabelecemos uma linha do tempo. No entanto, a linha do tempo é realmente inversa. Veja o próximo diagrama.
Situação Explicada: Em vez de determinar quando você precisa do P / O do cliente, você precisa começar com as necessidades do cliente – por exemplo, quando o cliente precisa do IMPACTO desejado? Então trabalhe o seu caminho de volta. Por exemplo, se o cliente tiver um pontapé inicial de vendas em 7 de julho, ele precisará da sua nova solução de aceleração de vendas para a equipe, até o final de junho.
Isso significa que eles precisam enviar sua cotação legal até 15 de junho para execução em 22 de junho. Se você não receber a P / O em 22 de junho, não ligue para eles e diga ” Jennifer, onde está minha P / O? Precisamos iniciar a instalação ” ”… mas, em vez disso, você pergunta “ Jennifer, estou ligando para garantir que ainda estamos no lançamento do seu serviço em 7 de julho ”. O evento crítico não é você obter um P / O, é o cliente que está no ar no momento certo (resolva o problema deles!).
O que fazer como um SDR / AE: A chave para resolver isso é para o SDR (!!) é estabelecer qual é o evento crítico. A principal pergunta a fazer ao SDR é “ Quando você precisa que este serviço esteja no ar ” ENTÃO, seguido de “ … o que acontece se você perder essa data? ”Essa pergunta simples informará se o evento é“ atraente ”ou“ crítico ”.
Como o cliente é transferido do SDR para o AE , agora ele pode fornecer ao cliente o resumo: “ Minha colega me disse que você deve colocá-lo no ar até {{date}} para obter esse {{impact}} ou caso contrário, você {{conseqüência}} … como podemos ajudá-lo a evitar isso? Agora você pode voltar da data e começar a descascar a cebola.
BANT ainda é válido, só precisa ser modernizado
O que espero ter mostrado a você é que a qualificação de vendas da BANT ainda é muito válida, só precisa ser modernizada para uso nas vendas de SaaS e em uma ordem diferente:
- N = Necessidade = Impacto nos negócios do cliente
- T = Linha do tempo = Evento crítico para o cliente
- B = Orçamento = Prioridade para o cliente
- A = Autoridade = Processo de decisão pelo qual o cliente passa
Lá vai você… aposto que alguém vai descobrir como renomear esta versão modernizada do BANT em uma frase mais cativante que sai da língua um pouco melhor que a NTBA… alguma sugestão?
Antes de deixar você, espero que você note que fizemos uma mudança enorme e crítica para todas as vendas de SaaS! Não se trata mais de enviar um serviço para um cliente e lidar com as objeções – mas de ajudar o cliente a identificar o problema real e diagnosticar o impacto subjacente. Faça isso e o resto se resolverá!
