La grille d’analyse BANT est un standard pour la qualification de vos leads. Mais reste-t-elle d’actualité en 2017 ? L’exemple de la vente des logiciels SaaS a permis de souligner un certain nombre de ses limites, notamment dans l’importance qu’on accorde au budget client. Ne serait-il donc pas temps de moderniser le framework BANT pour améliorer vos conversions ?
Sommaire
Les origines du framework BANT
Si l’acronyme BANT n’évoque rien chez vous, nous vous invitons à jeter un coup d’œil à notre guide complet de qualification de leads.
BANT fut conçu par IBM dans l’optique d’identifier une opportunité. Voici ce que leur site web nous dit :
Des opportunités sont identifiées en échangeant avec les prospects ou les clients afin de déterminer leurs besoins business et solution. Le processus IBM pour identifier une opportunité est d’utiliser une approche standardisée nommée BANT.
Une opportunité est considérée validée si les prospects remplissent 3 des 4 items du BANT. C’est ensuite aux équipes en charge des ventes de décider avec quel niveau d’exigence elles voudront l’appliquer.
- Budget – Quel est le budget du prospect ?
- Authority – Est-ce que le prospect a un pouvoir de décision, ou est-il un influenceur ?
- Need – Quel est le besoin du prospect pour son business ?
- Timeline – Quel est l’échéancier voulu par le prospect ?
Les limites de la grille d’analyse BANT pour qualifier vos leads dans l’univers du SaaS
- Budget – Les ventes SaaS sont désormais des OPEX, alors que traditionnellement ces achats étaient des CAPEX… Qu’est-ce que cela change exactement ?
- Authority – De nos jours les entreprises prennent-elles ce genre de décisions sous l’unique ordre d’un exécutif ?
- Need – Qu’est-ce qu’un Need comparé à un Must ou à un Want ? Est-ce qu’un SaaS correspond réellement à un besoin, ou plus souvent à un Nice-to-Have ?
- Timeline – Est-ce que le concept d’échéancier est-il toujours d’actualité en SaaS, avec des cycles de vente mesurés en jours et une implémentation qui peut se faire en un simple clic ?
Mais plus généralement, vivons-nous toujours dans un monde centré sur les ventes, où ce que l’on cherche est un client avec un budget précis qu’il peut attribuer à une solution ?
Ne vivons-nous pas dans un monde centré client, où nous devons aider celui-ci à identifier, diagnostiquer et résoudre un problème ?
Si c’est bien le cas, qu’est-ce qui change ? Et comment peut-on maintenant mieux qualifier un prospect en SaaS ?
#1 Le SaaS est une question de priorité, et non pas de budget
Définition Budget : une estimation de revenus et de dépenses pour une période de temps donnée.
Situation en SaaS : La plupart des services SaaS sont facturés à une fraction de leur équivalent hardware. Une tarification de €500 – €5000 par mois ne devrait pas être un problème pour un business en bonne santé qui a un réel besoin. Cela peut aller jusqu’à €40,000 par mois pour les plus grandes entreprises, mais encore une fois, il y a TOUJOURS un budget. La vrai question n’est pas celle du budget, mais de la priorité. Une priorité qui évolue à travers le temps.
Sur le graphique ci-dessus, nous voyons que la priorité évolue, entre nice-to-have, need-to-have et jusqu’à must-to-have. Il est fondamental de déterminer à quel endroit du graphique vous vous situez.
Si la priorité est au point bas, le client peut refuser l’offre, arguant qu’il n’y a plus de budget disponible, ne réalisant pas que les conditions peuvent changer et la priorité augmenter à nouveau.
Si vous comprenez bien le contexte et son problème, vous pouvez lui faire comprendre l’impact qu’aura votre service pour son business, et ainsi faire augmenter la priorité que votre solution représente pour lui.
Que faire en tant que SDR/AE (sales development representative et account executive) : Au début du processus de vente, lorsque le client est encore en phase de découverte, c’est le moment idéal pour demander : “Cette initiative est-elle déterminante pour votre entreprise ?” ; “A quel niveau se situe-t-elle” ; “Voyez-vous sa priorité pour vous évoluer à travers le temps ?”.
#2 En SaaS, l’autorité est distribuée et non hiérarchisée
Définition Autorité : Le pouvoir ou le droit de donner des ordres, prendre des décisions, et forcer l’obéissance.
Situation en SaaS : En SaaS, et plus généralement dans n’importe quelle vente, nous sommes témoins de la disparition progressive d’un processus de décision hiérarchisé. Dorénavant un simple avis d’utilisateur peut changer la conclusion d’une vente. Beaucoup d’entreprises forment maintenant des équipes réduites qui doivent parvenir à un consensus. Elles sont souvent constituées de 1 ou 2 utilisateur(s), d’un manager, d’un financier, etc.
On peut voir sur cette image un arbre de décision très classique à gauche. Les utilisateurs remontent des informations au manager, qui transmet cela à un exécutif qui prend la décision finale. Pourtant, beaucoup des solutions SaaS sont maintenant centrées utilisateurs. Cela explique pourquoi l’UX et l’UI sont devenus si importants ces dernières années.
A droite sur l’image, le processus de décision est fait de façon partagé, par une équipe restreinte. C’est rarement l’exécutif qui va décider, mais bien l’utilisateur, guidé dans son cheminement par le manager et l’exécutif (qui valide le processus dans son ensemble).
Que faire en tant que SDR/AE : La priorité n’est donc pas de savoir qui prendra la décision, mais comment celle-ci sera prise. Voilà quelques questions pertinentes dans cette optique : “Qui d’autre est impliqué dans ce projet et pourrait en bénéficier ?” ; “Qui d’autre pourrais-je inviter à notre prochaine réunion ?” ; “Avez-vous été impliqué récemment dans d’autres commandes du même type ?”.
#3 En SaaS, l’impact prend le pas sur le besoin
Définition Besoin : Vouloir quelque chose car il est essentiel ou très important.
Situation en SaaS : Le SaaS est devenu un secteur extrêmement compétitif, tous les services reposant sur la même infrastructure cloud, avec les mêmes codes couleurs, etc. et la concurrence se résume bien souvent à qui aura les meilleures fonctionnalités. Ce qui ne va pas réellement dans l’intérêt du client, qui devra souvent payer pour des fonctionnalités qu’il n’utilisera jamais. En tant que SDR/AE, vous pouvez jouer un rôle clé pour éviter cette surenchère en identifiant l’impact que peut avoir la solution sur le business du client.
A gauche, une vision traditionnelle de l’approche client, où chacune de ses exigences est traduite en fonctionnalité avec ses bénéfices inhérents. L’image de droite nous montre que les besoins d’un client sont plutôt similaires à… un oignon, avec de nombreuses couches qu’il faut peler jusqu’au cœur. Après souvent 6 ou 7 couches (et donc 6 ou 7 questions !), vous pourrez finalement accéder à l’impact pour son business, la véritable source du besoin client.
Cet impact détermine la différence entre un nice-to-have et un must-to-have, et comprendre ce concept est ce qui sépare un bon AE d’un excellent AE.
Que faire en tant que SDR/AE : Vous pourrez déterminer l’impact d’un service en discutant avec le client ; organisez donc des réunions en demandant à vos équipes de préparer une liste de questions préparées avec soin. En tant que SDR, vous ne pourrez pas peler l’oignon en entier dès le premier appel (le client ne vous fait pas encore confiance). Mais vous pourrez avancer en posant 1 ou 2 question(s) supplémentaire(s) : “Puis-je vous demander quel sera l’impact pour votre équipe au-delà de vous offrir de meilleurs dashboards ?” ; “Mon SDR m’a briefé sur l’impact de votre service (…), avons-nous bien cerné la situation ?” (AE).
#4 Plutôt qu’un échéancier, un événement butoir
Définition Échéancier : Une période spécifique durant laquelle quelque chose se produit ou est planifié pour se produire.
Situation en SaaS : Le problème ici ne concerne pas seulement les ventes SaaS, mais c’est une erreur que tous les professionnels de la vente commettent bien trop souvent. Ils posent la question au client, “Quand aurez-vous besoin d’avoir cette solution ?”, et à partir de là établissent un échéancier avecune date à laquelle ils devront recevoir l’ordre d’achat. Pourtant, c’est le raisonnement inverse qu’il faut avoir.
Plutôt que d’essayer de déterminer quand aurez-vous besoin de l’ordre d’achat du client, vous devez avoir en tête les besoins du client (à quel moment le client aura besoin de l’impact désiré ?).
Prenons un exemple simple : si le client a un pic d’activité le 7 juillet, il aura besoin que votre solution de Sales Hacking soit en place à la fin du mois de juin. Si jamais vous ne recevez pas d’ordre d’achat le 22 juin, n’appelez pas en demandant “Jennifer ? Où est l’ordre d’achat ? Nous devons commencer l’installation…”, mais demandez plutôt “Jennifer, je vous appelle pour vérifier que vous désirez toujours voir notre solution installée pour votre pic d’activité le 7 juillet”.
L’événement butoir n’est pas que vous receviez un ordre d’achat, mais bien que le client ait votre nouvelle solution en place lorsqu’il en a besoin.
Que faire en tant que SDR/AE: Vous devez identifier cet événement butoir. La question clé à poser est “Quand aurez-vous besoin que notre solution soit opérationnelle”, puis ensuite “Qu’arrive-t-il si vous ratez cette date ?”. Lorsque l’AE prend en charge le client, il pourra demander : “Mon collègue m’a dit qu’il vous fallait notre solution d’ici (…) afin de (…) ou sinon vous risqueriez de (…) ; nous allons réfléchir ensemble à comment l’éviter”.
Le modèle BANT est toujours valide, il doit seulement être modernisé pour optimiser la qualification de vos leads
Vous l’aurez compris, bien que de nombreuses nouvelles techniques ont vues le jour pour la qualification de vos leads, le framework BANT est bien valide et toujours très utile, mais doit être modernisé pour une utilisation en ventes SaaS.
- Need = Impact sur le business du client
- Timeline = Événement butoir pour le client
- Budget = Priorité pour le client
- Authority = Processus de décision du client
Le travail effectué ici pour la redéfinition du framework BANT est loin d’être anecdotique. Si vous travaillez dans le secteur des ventes, cet article peut avoir une importance capitale pour vous et pour votre approche des ventes SaaS (mais pas que !).
Il ne s’agit plus de proposer une solution à un client en récoltant ses objections – mais plutôt de l’aider à identifier un réel problème et à le résoudre. Faites ça, et le reste suivra !
