BANT is a sales qualification framework used to identify and pursue the most qualified prospects based on their Budget, Authority, Needs, and Timeline — BANT. Everyone’s heard of BANT qualification by now.
But does BANT still apply for high velocity, recurring sales – or is a more modern version of BANT needed?
In this article, I’d like to offer a modernized version of BANT that can be applied to Inside Sales Teams (Sales Development Reps, Account Executives) that deal with recurring revenue deals.
You might call it BANT sales qualification for a new era.
What is BANT Qualification?
BANT was conceived by IBM as a way to identify an opportunity. According to IBM’s guidance, an opportunity is considered validated if the prospect meets three of four of the BANT items. As a team, the ISR and sales representative may decide on either a tighter or looser form of BANT.
- Budget – Does the prospect have the budget to buy the product?
- Authority – Does the prospect have the decision-making authority or is she an influencer?
- Need – Does the prospect have a business need for the product?
- Timeframe – Will the prospect be implementing a solution in a suitable timeframe?
Modern Challenges with BANT applied to SaaS Sales
Budget – Today, SaaS is a subscription model that draws from OpEx budgets whereas traditionally, purchases came out of a CapEx budget… Does this change anything?
Authority – Do organizations today still make purchase decisions on a single senior authoritative voice enforcing the decision?
Need – What is a Need vs. a Must and a Want? Does SaaS really address a Need or are most of the services just a “Nice-to-have”?
Timeframe – Is the concept of timeframe different for a SaaS deal with a sales cycle measured in days and an implementation of a single “click”?
Most of all, do we still live in a sales-centric world where we look for clients with a budget who can be sold on a solution?
Or have things changed to where we now live in a more customer-centric world where we assist a customer in identifying, diagnosing, and resolving a problem?
If so, what changes? And in light of this shift, how do I qualify a SaaS deal?
What Are The Problems With BANT?
What we have found is that when we apply BANT to traditional SaaS Sales qualification there are a few challenges:
The problem for SDRs: When SDRs are given BANT to qualify a deal, it backfires as they essentially are starting to sell while a client is still in “education” mode.
The problem for AEs: When AEs are executing BANT to qualify a deal, they are getting affirmative answers yet the deal is still not qualified.
As an example, let’s take a look at a typical conversation along BANT, but dramatize it for effect:
Mike SaaS Salester Jennifer the Client
Jennifer so if I summarize your
challenges you need to solve a problem
X and problem Y. Did I get that right?
Yes that is right!
It sounds like this is a big need
for you folks.
Yeah hence we visited the recent
Sales Hacker Conference where we
first learned about your company.
Awesome. Well it sounds like you
secured budget for this project?
Yup sure have.
Awesome. Awesome. May I ask who
is the decision-maker?
I am the decision-maker,
purchasing will get involved too.
Great. And when do you need to
have a solution in place?
In the next 8 weeks,
but no later than July 1st!
So it sounds like we’re a great fit for you.
Shall I arrange a demo with a specialist?
Maybe. Let me talk to my team.
I’ll get back to you later this week.
Sure. Look forward to hearing from you.
Mike just qualified according to BANT and reports back to his boss Nicole:
Nicole, I just got off a call with Jennifer. You may remember her, she was a lead from the Sales Hacker conference looking for a solution for problems X and Y. She confirmed she is the decision-maker on the “Improvement” project. Jennifer needs a solution in place by July 1, and confirmed to have a budget to spend.
Sounds perfect? But then the deal goes cold? Why? Because Mike didn’t ask the right questions. Mike didn’t really ask any questions about what Jennifer needed. He just asked for information he needed to know.
It turns out that Jennifer took the decision back to consult with her team, but the staff using the product intervened, and told her there were other SaaS products doing other things that they needed more urgently. The project was postponed in favor of other software, which met a more urgent need.
Basing sales calls too heavily on BANT results in either low-quality SQLs, or worse, low-quality deals in the qualified sales pipeline expected to close in the next 8 weeks.
And although I have severely oversimplified the example, in most cases this is pretty much how a weak “deal” enters the funnel as a qualified deal.
Why? Well, let’s take a look…
[Tweet “In SaaS, using just BANT is not going to cut a PO @IndoJacco”]
#1 Rule of SaaS: It Is About Priority, NOT Budget
Google’s Definition of Budget: An estimate of income and expenditure for a set period of time.
The SaaS Situation: Most SaaS services are priced at a fraction of their perpetual license/hardware counterparts. A $500-$5,000 per month fee should be no problem for a healthy business that has a real need. This can extend to as much as $40,000/month without a hitch for large enterprises. There is ALWAYS budget. It never was about the budget, it has always been about it being a priority. A priority that fluctuates over time.
Concept Explained: In the above picture you notice that over time the priority increases from nice-to-have to need-to-have and at one point even reaches must-have. It is critical to determine where you are in this picture.
As the priority drops, a client may go dark, leading you to believe that the “budget is spent”, not realizing the conditions may change in your favor in which the priority will increase again. Even better…
Understanding their situation, you may outline the full impact of your service and how it can solve other challenges the customer may experience and with it, you will be able to increase the priority!
[Tweet “In SaaS, decisions are based on priority NOT on budget”]
What to do as an SDR/AE: Early on in the sales process, when your client is still in discovery mode, this is an ideal time to ask: “Is this one of the top initiatives at your company?” And “Where does this rank?” And “Do you see this priority changing over time?” Ask, “Is this a Nice-to-have, a Need-to-have, or a Must-have?”
#2 In SaaS the Authority is Distributed and not Hierarchical
Google’s Definition of Authority: The power or right to give orders, make decisions, and enforce obedience.
The SaaS Situation: With SaaS (and increasingly so in any sales) we see a move away from hierarchical (top-down) decision making. Often executives will defer to the staff using the products, who may themselves be highly paid experts.
In many cases a single user can report back that the service does not work as advertised, changing the course of action. Many companies today build a team that has to come to a consensus. The team can consist of 1-2 users, a manager, someone from financing, etc.
Concept Explained: In the picture above you see on the left a traditional “decision tree”. Users roll up into managers, who in turn roll up toward an executive who gathers the info and makes the decision. However, many SaaS services are actually “user experience-driven”. This is one of the many reasons why UI/UX has become so important in recent years.
On the right, you see that what you thought was a decision tree actually was a committee. In many cases in committees, the executive is not the person who will decide (they give the final decision their blessing). The final decision maker may be an expert user who has to work with the software every day. The user will be guided in the decision process by the manager (with her own needs) and the executive (making sure a proper decision process was followed).
[Tweet “Stop pitching. Start asking questions. @IndoJacco”]
What to do as an SDR/AE: Your first priority is not to determine who is the decision-maker but rather what kind of decision-making process is being followed. You can find out by asking questions such as:
“Who else is involved in this project that can benefit from this <insert article with insights>?”
and…
“Who else can I invite to the next meeting…?”
Another great question to ask is…
“Have you been involved in other recent purchases in this area such as <x> and <y>?”
#3 Modern Sales Qualification = Impact over Need
Google’s Definition of Need: Require (something) because it is essential or very important.
The SaaS Situation: SaaS has become extremely competitive as almost every service sits on the same “cloud infrastructure” and uses a very similar color scheme (blue for social, green for predictive), so competing can quickly become feature-to-feature combat. This is not to the benefit of the customer as they are often bamboozled into paying for features they’re never going to need. As an SDR/AE you can play a key role in helping to avoid this early on by identifying the impact.
Concept Explained: In the picture above you notice on the left a traditional focus on the client’s need translating their requirements into features and benefits. On the right, you see that the client’s need is actually more like an onion with endless layers that through the art of asking questions has to be peeled… to the core. Often 6-7 layers deep (6-7 questions deep!) you can find the underlying impact of the need.
This impact determines the difference between nice-to-have vs. must-have and understanding this concept is what separates a good AE from a GREAT AE.
[Tweet “The ABC of SaaS sales – Always Be Curious”]
What to do as an SDR/AE: The impact of service is best found by talking to a customer. So organize a client/sales get-together. Ask your SDR/AE teams to come up with a list of meaningful questions to ask about the impact of the service. IMPORTANT!
As an SDR, you cannot unpeel the entire onion on the first call – the customer does not trust you yet! But you may be able to unpeel one more layer by asking 1-2 more questions
“May I ask what is the impact of this service beyond giving you better dashboards?”
This will give your AE an incredible advantage, as they are able to better diagnose the client’s true needs:
“My SDR briefed me on you needing this service to impact … did we capture that correctly? May I ask..”
#4 Critical Event over Timeline
Google’s Definition of Timeline: A period of time, especially a specified period in which something occurs or is planned to take place.
The SaaS Situation: The challenge described here is not unique to just SaaS, this is a common mistake sales professionals make all the time. In SaaS sales we are often interested in “When do you need to have this by…” or “What is the go-live date for this service…” from which we establish a timeline. However, the timeline is actually in reverse. See the next diagram.
Situation Explained: Instead of determining when you need the P/O from the client, you need to start with the client needs in mind – e.g. when does the client need the desired IMPACT? Then work your way back. For example, if the client has a sales kick-off on July 7, they need your new sales acceleration solution for their team in place by end of June.
This means they need to have your quote submitted to legal by June 15 for execution on June 22. If you do not receive the P/O on the June 22nd, you don’t call them up and say “Jennifer where is my P/O? We’ve got to start the installation” … but instead you ask “Jennifer, I am giving you a call to make sure we are still on for the launch of your service on July 7th”.
The critical event is not you getting a P/O, it is the client being on-air at the right time (solve their problem!).
[Tweet “The critical event is not about getting a PO but a client being on-the-air”]
What to do as an SDR/AE: The key to solving this is to establish what the critical event is. The key question to ask is “When do you need this service to be on the air” THEN followed by “… what happens if you miss that date?” This simple question will let you know if the event is “compelling” or “critical”.
As the client is transferred from the SDR to the AE, the AE can now provide the client with the summary: “My colleague tells me you have to have this on-air by {{date}} to get this {{impact}} or otherwise you face {{consequence}} … how can we help you avoid that?”
You can now work your way back from the date and start peeling the onion.
BANT is still valid, it just needs to be modernized
What I hope to have shown you is that BANT qualification is still very much valid, it just needs to be modernized for use in B2B sales, and in a different order:
- N = Need = Impact on the customer business
- T = Timeline = Critical event for the customer
- B = Budget= Priority for the customer
- A = Authority= Decision Process the customer goes through
There you go… I bet someone will figure out how to rename this modernized version of BANT sales qualification in a more catchy phrase that rolls off the tongue a little better than NTBA… any suggestions?
Before I leave you, I hope you notice that we have made an enormous change, and one that is CRITICAL to all sales qualification.
It is no longer about pitching a service to a customer and handling the objections – but rather about helping a customer identify the real problem and diagnosing the underlying impact. Do that and the rest will solve itself!
[Tweet “Make how you sell as important as what you sell and the way you sell will become your USP”]