If Sales Enablement Isn't Working, Check the Deals First

The complaint rarely arrives as a finding. It arrives as a sentence in a leadership meeting: enablement isn't working. The function has been running for a year or more, its budget is up for renewal, and someone senior has decided the reps are no better than they were. The enablement lead is asked to come back with an answer in two weeks.

The dashboard is the nearest evidence

The answer that comes back is almost always built from the function's own records. Content usage, course completion, platform logins, kickoff attendance, a satisfaction survey. These are the numbers closest to hand, and they are the numbers the enablement lead controls. They are also the check that rules out the least, because they describe the function and say nothing about the deals the complaint was really about.

High usage does not show that enablement is working, and low usage does not show that it is not. A rep may open the pricing deck every day because it is the only correct version, and still lose the deal in procurement. Another may never open the library and close above quota, because the material that matters at their stage was never written. The dashboard can explain a finding once there is one. It cannot be the finding.

A different order

The method we use runs the checks the other way round: from the complaint, to the deals, to the function. Each step is cheap, and each either ends the inquiry or narrows the next. This note sits between two others. Why sales enablement initiatives fail covers the diagnosis before a programme is bought, and what a sales enablement project with no impact leaves behind covers the reading after one is closed. This is the check for a function that is still running.

The phrase "isn't working" carries an expectation, and the expectation is usually unwritten. In the companies we have worked with, the same sentence hides quite different complaints depending on who says it:

• the head of sales means late-stage win rates have not moved
• the finance lead means new hires still take too long to reach quota
• the front-line managers mean reps still come to them for every answer
• the product team means the last launch never showed up in pipeline

Each of these is a legitimate expectation. Few of them were in the brief the function was given, and some pull against each other. A function charged with onboarding speed will have spent its year on new hires, and will look idle to a sales leader who wanted the tenured team's late-stage conversion to change. That drift is one of the defaults set out in common sales enablement mistakes.

Writing the complaint down

The first check is therefore a short written statement from whoever raised the complaint: which number, measured how, compared with when, and what result would count as working. If nobody can write that statement, the function is not failing at its job, because nobody has defined the job. That is a finding in itself, and it belongs to the executive team rather than to the enablement lead.

When the statement can be written, it sets the scope for everything that follows. A complaint about late-stage win rates sends the review to late-stage losses. A complaint about ramp time sends it to the first two quarters of recent hires. Without it, the review samples everything and finds nothing.

The second check is the one most reviews leave out. Take a small sample of recent deals lost at the stage the complaint names, perhaps a dozen, and read each one for a single question: at the point where it was lost, was there anything enablement could have supplied that would plausibly have changed the outcome?

Reading for the point of loss

The CRM loss reason is rarely enough. It records what the rep chose from a dropdown on the day, usually price or timing. The useful record is the deal itself: the notes, the email thread, the last call recording, and a short conversation with the rep. In payments and banking sales the answers tend to cluster. The deal stalled in a risk committee that wanted evidence the rep could not produce. A reference customer was needed and none existed in that segment. The discount needed approval above the rep's authority, and the approval took six weeks. The product lacked an integration the buyer required.

Only some of those are enablement problems. Missing evidence for a risk committee is one. A slow discount approval is a decision architecture problem. A missing integration is a product problem. When most of the sample was lost to causes enablement does not touch, the function cannot be the reason the number has not moved, however its dashboard looks.

A function cannot be failing at a loss it was never in a position to prevent.

Had it, or used it

Where enablement was relevant, the same reading answers a second question: did the rep have what was needed, and did they use it. The two answers point to different owners. If the material or the skill did not exist, the gap is in the function's agenda, and the next question is why that stage was never served. If it existed and went unused, the gap is in the rep's working week, in the template, the stage criteria and the manager's review. That is the seam described in sales training and enablement fail at the seam between them.

Only now does the dashboard earn its place. The review now knows which complaint it is answering, which stage matters, and whether the losses there were enablement's to prevent. Usage and completion data can be read against a question. Low usage of late-stage material means something specific once the deal reading has shown that reps lost deals for want of exactly that material.

What the order protects against

Running the checks in this order changes what the review is likely to conclude. Starting from the dashboard tends to produce one of three answers: relaunch the content, buy a better platform, or replace the enablement lead. Each responds to the function's own numbers, and none was tested against a lost deal. Starting from the complaint and the deals produces answers that are narrower and often cheaper: write one stage's material, change one review agenda, settle one approval right, or tell a senior stakeholder that the number they care about was never in the brief. The order matters because each check decides what the next one is allowed to look at.

When the answer is that it is working

Sometimes the review ends with the function largely vindicated. It was asked to shorten ramp time, ramp time shortened, and the complaint came from someone who expected something else. That result deserves to be stated plainly in writing, with a decision about whether the brief should now change. Otherwise the same complaint returns at the next budget cycle, and the function spends another year serving one expectation while being judged against a different one.

The check is short, but it is hard to run from inside. The enablement lead has a stake in the dashboard, the sales leader has a stake in the complaint, and neither can easily tell the other that the loss sits in their territory. Our consulting work runs this sequence as an independent diagnosis before solution exercise: the complaint is written down, the lost deals are read, and the function's numbers are read last, against both.

Where the reading does locate a capability gap at a named stage, the response is a small programme with a measured baseline, and our training practice builds it to that brief. More often the first useful change sits outside enablement entirely, and the review says so.