Tales & Co.

Istanbul — San Francisco

Notes

Diagnosis before solution

6 min read

Common Sales Enablement Mistakes Are Defaults Nobody Chose

The usual sales enablement mistakes are not errors anyone made. They are defaults the function drifts into: building to the product calendar, adding without retiring, and serving only the new hire.

The common sales enablement mistakes are defaults, not decisions.

A pattern we meet in software and payments companies begins with a sensible hire. Sales has grown past the point where the head of sales can onboard every rep personally, so the company appoints its first enablement lead. The brief is loose by design: get new reps productive faster, keep the team current on the product, and make the material easier to find. Eighteen months later the function is busy and well regarded, and the sales leader cannot point to a deal it changed.

Nobody made a bad call

Reading back through those eighteen months rarely turns up a wrong decision. It turns up a series of reasonable ones, each taken under the pressure of the week it was made in. The product team shipped something, so enablement produced the launch deck. A rep asked for a case study, so one was written and added to the library. Six new hires started in the same month, so the onboarding programme was rebuilt. Each of the common sales enablement mistakes is the easiest available choice at the moment it is made, which is why it is so rarely recognised as a choice at all.

That is the difference between this pattern and the one set out in why sales enablement initiatives fail. There, the error is a programme bought to answer a diagnosis nobody tested. Here, there may be no programme at all. There is a standing function whose agenda has been set by whoever asked most recently. Three defaults account for most of it, and each one can be replaced by a decision that someone senior makes once and writes down.

Enablement that follows the product calendar teaches what the company ships, not how customers buy.

The first default is the source of the work. Product releases are the most predictable demand an enablement function receives. They arrive with dates, a sponsor and material ready to adapt, so the enablement calendar quietly becomes the release calendar. Every quarter the reps receive a briefing on what is new, a refreshed deck and a revised feature comparison.

The stages with no material

The buyer's process has stages the release calendar never touches. In payments sales to banks, the deal that stalls rarely stalls on features. It stalls in the security questionnaire, in the risk committee that meets monthly, in procurement asking for a reference the rep cannot supply, or in a business case the champion cannot defend to their own finance team. A library built from launches holds a great deal about the product and almost nothing for those moments.

Material organised around what the company ships leaves reps fluent in the product and alone at the stages where deals are actually lost. The replacement decision is to organise the work by deal stage rather than by release. Each stage gets a named owner for its material, and a release is briefed into the stages it changes instead of arriving as a separate event. The stages that lose the most deals are not always the stages a release changes, and the release no longer gets to set the calendar.

A content library that only grows becomes harder to use with every asset added.

The second default is accumulation. Producing an asset is visible work, and someone asked for it. Retiring one is invisible work, and someone might still be using it. So the library grows in one direction. Three versions of the pricing deck sit side by side, each correct on the day it was made. The case study from a customer that has since churned is still there. The battlecard for a competitor that was acquired last year is still there.

How a library loses the reps

Reps adapt in a predictable way. They stop searching the library and start asking a colleague, and the deck they send to the customer is whichever version was forwarded most recently. The seam between training and enablement, set out in sales training and enablement fail at the seam between them, widens here: the workshop teaches one method while the library holds material written for three.

The platform makes it faster

A content platform is often bought at this point, on the theory that the problem is findability. The platform indexes the library as it stands, so the contradictions become faster to find. A library with no rule for removal turns every new asset into a small tax on every rep who searches it. The replacement decision is a retirement rule written before the next asset is produced. In the functions we have seen hold up, it runs to a few lines:

  • every asset has an owner and a date on which it lapses unless the owner renews it
  • a new version replaces the old one rather than sitting beside it
  • anything not used in a live deal over two quarters is archived out of the reps' view
Producing an asset is visible work. Retiring one is invisible, so the library grows in one direction.

Enablement built for the new hire rarely reaches the reps who carry the number.

The third default is the audience. Onboarding is the clearest request an enablement function receives, and it comes with a measure everyone accepts: time to first deal. So the function's best work goes into the first ninety days, and the tenured reps are offered the release briefings and little else.

Where the practice drifts

Those tenured reps carry most of the number in most sales teams, and their practice has usually drifted furthest from the one the company now teaches. They qualify by instinct, discount by habit and run the discovery method from two leadership teams ago. New hires are trained in the current method and then sit beside them for a year, and they learn the version they see.

Enablement aimed only at the new hire teaches the official method to the people least able to keep it alive in the team. The replacement decision is to treat the established team as a cohort of its own, with its own brief, and to start from what the strongest of them already do. Reading the deals of the best performers is where useful material comes from, and it is the same reading a post-mortem relies on in what a sales enablement project with no impact leaves behind.

Where this thinking becomes work.

Each of the three decisions is small and cheap to write down. None of them is made by the enablement lead, because each one chooses between requests from people more senior than the role. That is why the defaults persist: the function is answerable to everyone and authorised by no one. In our work the first step is a short review of what the function produced over the last year, read against the deal stages where pipeline was lost. It is a diagnosis before solution exercise, and it usually shows the defaults within an afternoon.

Our consulting practice works with sales leaders on the charter that replaces the defaults: who sets the agenda, which stages the work serves, and what leaves the library. Where the review does point to a skill gap, our training work builds the programme to that brief. An enablement function with a written charter can say no to the next request, and one without a charter cannot.