Measuring Sales Engineering

Measuring the Impact of Sales Engineering

A great sales engineer can navigate the challenges and pitfalls of even the most complex sales opportunity and a junior sales engineer can jeopardize even the most mundane of tasks. How do you consistently measure their effectiveness? This is incredibly important information for a number of reasons. How can sales engineering leadership grow and manage their teams if they don’t know how well they are performing? What education and training dollars are you requesting and rationalizing? How are sales engineers adding value to the sales cycle?

In this post we focus on measuring Sales Engineers Output.

To a large extent what we are measuring depends greatly on who the consumer of the data is and where it rolls up. For instance, do you think that the VP of Sales is interested in how many product demo’s were performed this week? Or would the head of marketing be interested in how many introductory sales calls the sales engineer attended? Most likely not, to the consumer of quantifiable data its only data, so we need to ask a few questions. What are we measuring, How we are measuring, and Who is the consumer (WHW).

First and foremost lets agree that sales engineering metrics can vary greatly based on sales organizations, organizational structure, types of products being sold, sales methodology’s and how companies utilize their sales engineering’s.

For instance, we’ve all heard of “Throwing it over the fence” this is when sales simply provides limited details on an opportunity to sales engineering and its up to the SE to pick it up and run with it. In a environment like this sale engineers may dedicate more time to Discovery and Product Demonstrations, you know the old “Just demo it for us” line. So if you are measuring demonstrations that would be a much poorer interpretation of sales engineering value.

I mean if sales/customers are just asking for a “Demonstration” without any discovery then all that can be demonstrated are product features, and no one buys product features only solution value. In this case the actual value of the sales engineer is diminished as all they are doing is walking through the product and not aligning it to customer buying criteria.

Proof of Value (Concept)

For those that are new to the term, historically referred to as “Proof of Concept” but over the last several years transformed into “Proof of Value”. This is the proverbial test drive of the software for a customer, driving the car around the block, checking underneath the hood, kicking the tires. These vary greatly from organization to organization, some do more others less.

This is an opportunity to “Show the Value” of the product, how it aligns to a customer’s needs, addresses their must haves and demonstrates it within their environment, ideally with their data etc. Think buying a car but the dealer lets you take the car and drive the family to Colorado for two weeks and then decide if its right for you. Big difference right?

Anyone that has ever participated in a POV will tell you that a POV can make or break a deal. The number of POV’s is a good indication as a baseline, Duration, Conversion Rate to Win, Conversion Rate to Lose, Number of Success Criteria (fewer is always better), Rate of Closure without a POV (Nice denominator). These metrics assist the sales leadership in where to allocate time and resources and how to utilize POV’s.

Typically (Best Practice) POV’s should be used as closing tools, versus simply just the next step in the sales cycle. This is also where a robust sales methodology (MEDDIC/SANDLER/CHALLENGER) can play a key role in feeding metrics and decision criteria into the POV.

POV Metrics:

-      Value Influenced: Number of POV's tied to deal/deal value

-      Closure Rates: SE Closure when deal has POV included versus no POV

-      POV closure rates between Sales Engineers and groups. For instance, Steve’s closure rate is 95% when a POV is delivered versus Larry’s who only maintains a 30% closure rate. This can point to quality and training needs.

Product Demonstrations

Now, I’m a big advocate of performing a full discovery, understanding the customers buying criteria, decision criteria, and must haves before demoing anything. Think of it like this, the customer says that the software must absolutely do X and you demonstrate X then why would they in turn also need a POV? Better demonstrations feed increased closure rates not just more demonstrations.

The number of product demonstrations per week is a great starting metric as long as its tracked along with the opportunity. For instance, demonstrations at the first meeting versus at the second after the deal is truly qualified makes a big difference. Additional metrics include, time spent on demonstration, was a discovery completed, was it a tailored demonstration or generic. Lets be clear, the number of demonstrations alone isn’t necessarily the best metric if sales engineers are bypassing critical steps in understanding the customers’ needs.

This rush to demo can lead to poor demonstrations and in some cases making the product appear overly complex or even too generic and the customer thinking significant customization would be required. So you would need to start out with a baseline and start to adjust the knobs to find that right quantity and quality of demonstrations a given SE can complete in a week to determine positively impact closure rates.

As we begin to look at the data points we can make more informed decisions about the actual impact of sales engineers on the sales cycles.

Product Demonstration Metrics:

-      Value Influenced: Number of demonstrations tied to deal value

-      Discovery’s completed compared to deal closure rates = Value of Discovery

-      Type: Customized demonstration versus generic compared to closure rates

-      Number of demonstrations required for each deal

-     Product: drives complexity and sales cycles by product.

This is the sort of information that Sales leadership finds extremely valuable.

Only the beginning

This is only an sample of the many tasks sales engineers own and deliver within a typical sales organization. I’ve personally managed teams that dedicate forty percent of their time on support calls alone so it’s important to track and report on that data as well as it impacts everything sales engineers are doing. Additional metrics I manage closely include ecosystem support, product and sales marketing time spent, trade shows attended, demo environments developed, documentation delivered, training delivered and sales calls.

Any ongoing tasks or repeated task owned or where time is dedicated by our teams should be considered as a potential data point for further analysis.

I look forward to hearing your thoughts and perspective.

Jon Burton, has held numerous positions within Sales and Sales Engineering ranging from Road Warrior, International Event Speaker and Strategic Sales to Director of Sales Engineering. He has a passion for building and training pre-sales professionals and sales organizations. If you are interested in the world of pre-sales please reach out and connect with him on LinkedIn.