5 Ways to Optimize Presales Enablement

There a million and one articles about how to do Revenue Enablement right.

But we don’t hear much about enabling presales and solutions teams.

That’s because even the topic was well documented, it would look different in every organization. Software sales teams have a higher emphasis on speed and technical enablement, whereas the presales process in sectors like Manufacturing, Energy, and Telecoms might involve slower timelines and a more compliance processes.

So while it may not be obvious what “good” presales enablement should look like, we’ve put together a framework for what it takes to optimize presales automation.

Good Docs = Faster Presales Workflows = Happy Solutions Engineers

Simple as.

We can’t count how many times we’ve seen Sales Engineers struggle to do their job because of old, inaccurate, and missing docs. Yes, maintaining good documentation is the responsibility of the engineering team, but it’s up to presales to make it known when docs are inadequate.

If you work in the engineering org you can kinda skirt your way around this. You’re in close proximity to the subject matter experts. But if you’re an SE on the sales island, you’re much more adversely impacted by such tribal knowledge.

This is why the impact of good documentation cannot be understated.

Not only does good documentation enable everyone to move faster, it helps presales teams achieve self-reliance and automation. In this video we demonstrate how solutions teams are automating answers to technical questions using their own product docs:

If you’re looking to improve the technical enablement side of presales, cleaning up the product docs should be at the top of your list.

Now how do you actually convince the engineering team to do this regularly? As a starting point, we recommend reading Nonviolent Communication by Marshall B. Rosenberg.

You should work closely with the sales team to disqualify bad customers.

This won’t necessarily improve automation, but it will help you optimize how you allocate precious presales resources. Before you accept the responsibility of a customer deployment, ask yourself these questions:

Far too often the sales team rushes to get a customer into the pipeline and sidelines the necessary technical validation. The result? Presales gets tasked with an uphill battle of deploying the product. Sometimes a deeper dive is necessary before taking the next step.

In the technology sector, you often hear stories of products delivered only to be shut down by a conflicting process. For example, cybersecurity products might block your solution, resulting in a complicated and bureaucratic process to resolve the conflict. Knowing the customer’s tech stack upfront can prevent these unpleasant surprises.

Your account executive should know this. The reason for asking is to understand exactly what’s at stake if the presales process gets messy. Is the purpose of your product evaluation to select a vendor, or have you already been pre-selected and are going through a deployment process? This can materially impact the level of effort a presales team will go through to “win” the deal. For example, is it necessary to perform a deep integration with the customer environment? Or can that be validated some other way without wasting cycles?

One of the cardinal sins of solutions engineering is treating your presales team like customer support.

This typically happens when following a customer deployment, the presales team remains engaged in the project as the primary point of contact. After all, if the deployment isn’t working then doesn’t that point to unfinished business on the part of the presales org?

No, not quite. The reality is that everything that happens after a deal is closed should be handled by the post-sales team.

This sounds like common sense but you’d be surprised how many organizations don’t follow it.

Another cause of this can be complex reporting structure. It should be obvious to everyone in the sales process who is in charge at what stage and when the handoff takes place between teams. An SE org that’s tasked with seeing a customer through a full-scale deployment might get bogged down by support requests beyond the scope of their role.

The same applies to the post-sales folks. Support should be close to the GTM team – but never assume the role of deployment engineers. A support team who is beholden to the Sales org will be pulled in different directions beyond where they need to focus.

As you work to automate presales, keep in mind that not everything can be solved by “more software.” Your organization should incorporate a mix of product, process, and philosophies described in this list.

What did we miss? Comment to let us know.