Intro

There are a lot of good sales books. The problem is that reading them and turning them into something a salesperson can actually use on Tuesday morning are two very different things.

The JOLT Effect by Matthew Dixon and Ted McKenna is one of the best sales books I have read in recent years precisely because its central idea translates so well into real B2B sales conversations. The research behind the book analyzed millions of sales calls and arrived at an important conclusion: a huge number of deals are not lost to a competitor. They are lost because the customer decides to do nothing.

After more than a decade in sales, that finding resonates strongly with me.

Salespeople spend enormous amounts of time learning how to create urgency, uncover pain, differentiate against competitors and prove ROI. All of those skills matter. But there is another problem that appears later in many opportunities: the customer understands the problem, sees the value of your solution and still cannot bring themselves to make the decision.

That requires a different set of sales skills.

The JOLT framework describes four of them:

J: Judge the level of customer indecision
O: Offer your recommendation
L: Limit the exploration
T: Take risk off the table

I do not see JOLT as an alternative to MEDDIC, SPICED, SPIN or another sales methodology. I see these as skills that sit on top of them. MEDDIC can tell you whether you understand the economic buyer, decision criteria or champion. JOLT helps you understand whether the humans involved are actually becoming comfortable enough to make the decision.

We have incorporated these principles into our own sales playbook at Taskbase and into the way our AI sales coach works with reps. But even without an AI coach, these are four behaviors I would train in almost any B2B sales team.

1. Judge the Level of Customer Indecision

One of the most dangerous assumptions in sales is that a customer who agrees with you will eventually buy.

They may completely agree that the problem exists. They may like your product and believe the business case. But buying introduces another consideration: risk.

If I choose your software and the implementation fails, I made that decision. If I do nothing, it is often much easier to explain why nothing changed. This becomes particularly relevant in larger organizations, where the person sponsoring a project may carry real reputational consequences if it goes badly.

One way indecision manifests itself is through endless information gathering.

The customer asks for the presentation after the first meeting. Then they want another case study, a second demo, a reference call or another document for an internal stakeholder.

None of those requests is inherently problematic. Buyers need information. The question is whether that information is helping them make a decision or has become a substitute for making one.

This is why I try to establish the actual priority relatively early.

One question I have used for years is:

“From zero to ten, how important are the use cases we’ve discussed today for you?”

If somebody answers eight, nine or ten, I am usually comfortable that we are discussing something meaningful. Seven makes me more cautious because it is a wonderfully convenient number: positive enough to sound interested, but not strong enough to imply much commitment.

Rather than trying to convince someone to give me a nine, I ask:

“What would need to happen for this to become an eight?”

That answer can tell you more than another twenty minutes of product demonstration.

Perhaps the customer needs a stronger business case. Maybe the project would become strategically relevant only if we could solve another problem alongside the first one. Or they might tell me that their Salesforce implementation has priority for the next six months.

Now I understand the reality of the opportunity.

The same principle applies when a prospect finishes a meeting with, “Send me the deck and I’ll discuss it internally.”

Instead of simply agreeing, I want to know what that means.

“Absolutely. What are you planning to do with it?”

If they tell me they want to discuss it with their VP Sales, RevOps leader and CFO, I have something concrete to work with. I can understand what those people will care about and recommend that we bring them into the next conversation rather than relying on my contact to resell everything internally.

The objective is not to make the customer uncomfortable. It is to distinguish genuine progress from activity.

2. Offer Your Recommendation

One of my least favorite ways to finish a sales meeting is:

“So, how would you like to proceed?”

There are situations where that question is perfectly appropriate. As the default ending to a B2B sales call, however, I think it gives away too much responsibility.

You sell your product every day. You have seen customers buy it successfully, watched deals get stuck and learned which stakeholders usually need to become involved. You know when a business case tends to be necessary, where implementation becomes complicated and which initial use cases usually create value fastest.

Your buyer may be doing this for the first time.

One question I like asking when an opportunity becomes serious is:

“How often have you bought something like this before?”

It is also a useful champion test. Occasionally, the person has led several similar purchases and understands their organization extremely well. Great. They probably need less guidance.

Quite often, however, the answer is that they have never bought something like this before.

In that situation, I want to understand their internal buying process, but I also want to contribute my experience. One sentence I use constantly is:

“Given what you’ve told me, what I would do next is...”

Then I make an actual recommendation.

That could mean bringing the sales leadership team into the next meeting, stopping further product demos and building a business case for the economic buyer, or running a workshop because we still have not properly agreed on the use cases.

Good salespeople should have an opinion about the buying journey.

This is also where I think about micro-decisions.

The contract is obviously the decision we ultimately care about, but nobody moves directly from vague interest to signing a significant B2B agreement. Strong opportunities contain a sequence of smaller commitments.

The customer chooses two use cases out of six. They agree that solving them is an eight out of ten priority. They introduce another stakeholder. We jointly build a business case, agree on the pilot structure or book the next meeting while everyone is still on the call.

Each one is a small decision.

“Send me the presentation and I’ll have a look” is different. It is an exchange of information.

When I look backwards at a healthy opportunity, I normally see a trail of decisions. When I see five meetings, lots of documents and virtually no commitments, I become much more concerned.

3. Limit the Exploration

This skill has become considerably more important with AI because modern software can suddenly do an enormous number of things.

We experience this ourselves at Taskbase.

Our AI sales coach can support reps around their skills and customer conversations, but it can also help prepare meetings, write follow-ups, build business cases, create presentations, research accounts, generate prospecting lists, update CRM information and work with the company's sales playbook.

From a product perspective, that breadth is exciting.

From a sales perspective, it is dangerous.

I could spend an hour showing a prospect twenty different things the platform can do. They might leave impressed and still have absolutely no idea what they should buy.

That is why good discovery eventually needs to narrow.

At Taskbase, I often start with three broad problems we see across sales organizations rather than listing every possible use case.

The first is rep performance: do salespeople have the skills they need to perform well in real customer conversations?

The second is sales productivity: how much time are reps spending on preparation, research, follow-ups, CRM work and other tasks around the customer conversation?

The third is the sales playbook: has the organization actually captured how it wants people to sell, or does that knowledge still live across slides, documents and the heads of a few experienced people?

Those three areas give us enough room to discover without overwhelming the buyer.

If the playbook problem resonates, we go deeper. Where are they today? What is difficult about the current situation? Why does it matter to the sales leader? What happens over the next six months if nothing changes?

Eventually, however, exploration needs to stop.

If we have identified ten possible use cases, I might ask:

“Of these ten, which ones are actually the most important for you?”

Perhaps the customer chooses two.

Now we have made another decision.

Those two use cases should become the foundation for the rest of the process. The business case should reflect them, the pilot should test them and the implementation discussion should focus on what is required to make them work.

This does more than simplify the product story.

If I try to sell ten use cases simultaneously, I might suddenly require broad CRM access, multiple integrations, more security reviews and hundreds of users. A relatively simple software purchase starts to resemble a transformation project.

With two use cases, perhaps we need two integrations, a limited amount of data and twenty initial users.

The product has not become less capable. The customer simply has less to evaluate before making the first decision.

4. Take Risk Off the Table

This may be the most important of the four skills when you sell a relatively new product.

At some point in a good opportunity, creating more urgency stops helping.

The customer already understands the upside. Their concern is what happens if your promises turn out to be wrong.

That skepticism is rational.

In 2021, I bought Cognism partly based on an important HubSpot integration that we expected to work. It did not. To their credit, they worked hard on the problem and eventually solved it, but the experience was still frustrating because something we had expected to work immediately took months.

Most experienced B2B buyers have some version of this story.

They have bought software that looked brilliant in a demo but performed differently with real users. They have seen supposedly simple integrations become complicated implementation projects or watched adoption fall far below expectations.

You are not only selling against your competitors. You are also selling against the buyer's memory of every technology purchase that disappointed them.

This is why I like asking a simple question internally: How can the customer find out whether our product works while taking as little unnecessary risk as possible?

For many software products, that means reducing the initial scope, number of users, integrations, internal effort and financial exposure while agreeing on clear success criteria.

Ideally, the customer should be able to prove meaningful value within one, two or three months rather than committing to a nine-month transformation before seeing whether the underlying assumptions were correct.

This is also why I am not fundamentally against pilots.

Bad pilots are terrible. They consume months of sales and customer success resources and then quietly expire without a decision.

A properly structured pilot is different.

Once the product is established enough, I generally prefer an initial validation phase to sit inside the intended longer-term commercial relationship. If the customer ultimately wants one hundred users, perhaps we start with twenty and define what has to be true for the rollout to continue.

The customer has a credible way out if the agreed goals are not achieved, while both sides enter the relationship with the intention of continuing if they are.

Very early startups may need to take even more of that risk themselves.

If you have no customers, few references and little evidence that your product works consistently, expecting the buyer to carry all the uncertainty is unrealistic. A free pilot, paid proof of value with a refund mechanism or another low-risk structure can make sense because the vendor has not yet earned enough market trust to demand the same commitment as an established company.

As evidence accumulates, the commercial model can change.

The principle remains the same: do not only sell the upside. Make the downside manageable.

The Four JOLT Skills Are Really One Skill

What I like most about The JOLT Effect is that I do not experience these four ideas as independent sales techniques.

They describe one continuous process.

First, understand whether the customer is actually capable of making the decision and where indecision exists. Then use your experience to recommend what should happen next rather than making the buyer design the process alone.

As the opportunity develops, narrow the number of things they need to evaluate. Once you have agreed on the problems and use cases that genuinely matter, find a way for the customer to validate your claims without taking unnecessary risk.

That is why I do not think JOLT competes with qualification methodologies such as MEDDIC or SPICED.

MEDDIC can help me understand whether I have a champion, know the decision criteria and have access to the economic buyer. JOLT helps me think about whether those people are becoming comfortable enough to actually make the decision.

I want both.

What I Would Train in My Sales Team

If you remember only one thing from this article, I would make it this:

Look for decisions, not activity.

Another demo is activity. Sending a case study is activity. Having a fourth meeting with the same stakeholder is activity.

Selecting the initial use cases, agreeing that the problem is genuinely important, introducing the economic buyer, committing to a pilot structure or jointly building the business case are decisions.

That distinction is enormously important when coaching salespeople because a busy opportunity can still be a completely stagnant opportunity.

This is also where I think AI sales coaching becomes interesting. An AI coach should not merely analyze whether a rep said the right words on an individual call. It should understand the company's sales methodology and playbook, look at how the rep behaves across the sales process and help identify whether the customer is actually progressing from one meaningful decision to the next.

That is how we think about it at Taskbase.

The best salespeople I have worked with do not simply create more activity and hope that enough meetings eventually produce a contract. They help customers make a series of increasingly important decisions while continuously reducing the uncertainty around them.

For me, that is the real lesson behind JOLT, and it is why these four skills belong very high on the list of things I would train in almost any B2B sales team.