Wednesday, August 29, 2007

Statistics for SE Reporting

Although there is much of an art to being a good SE, there are many ways of honing that art. To best do this we need some statistics.



These statistics should focus on how well the SEs are able to win a technical recommendation, and also how many of those recommendations turn into successful deals. You might think that this second one is the job of the commercial people, but the amount of demand the end-users of the tool have for it, will help quicken the process of the prospect becoming a customer.

Another important indicator is the size of those deals. While it is not necessarily easier to win smaller deals, it is the large deals that really matter to a business.

So at the end of every week, every SE in our organisation sends a spreadsheet to our Worldwide SE team leader, who collates the information and presents it to the VP of Sales.

The information in the report shows: Outstanding POC requests, Custom/Special Work Needed, Products to Opportunities, Demo Requests, Past Week Activity (Prospect, $ Size, Activity Type), Next Week Planned Activity (Prospect, $ Size, Activity Type). Then come Win/Loss reports, for every prospect that has moved off from the previous week.



The SE team leader presents to the VP the Number of PoC requests, All special works (Development projects) and the size of those deals, Number of Demos, % Customer time for each SE.

The SE team leader will also see from this reporting (and also by talking with the other SEs) where there is opportunities for SEs to work together to bring in deals easier.

Monday, August 13, 2007

Training for Sales Engineers

Just a brief post today, I am looking for recommendations for effective training to help develop and extend skills for SEs beyond mere technical know-how.

In particular, I am thinking of courses to help the sales/commercial side of the skills required of SEs, and the skills that would help SEs make the transition to full Enterprise Sales positions.

Once I have a few good suggestions, I will post them here of course. Let me know if I need to keep any suggestion anonymous or unpublished.

Wednesday, August 8, 2007

Getting the customer referenced

I was reading dealarchitect today, and his Burning question is a very important one: Is software sold or bought?
An aggressive answer would say that sometimes we do indeed oversell products, or get companies to buy products that they are not in a position to use. Sometimes buyers will go through a long process of testing, proofing, and accepting a product and then it gets shelved until the key people are ready to implement it.

However before this ethics question is decided, one should ask is it the buyer or the seller at fault here? The seller spends a lot of time consulting and presenting, and needs a return on investment or else they would be doing something else.

It can be quite frustrating also for the seller when the buyer does buy something that seems to never get implemented. Although you (usually) don't give the money back, a part of selling requires reference customers who are able to honestly say how they use the product, and promote its use to new customers. If your product becomes shelfware, it will be noticeable to new prospects and can be damaging if word gets around.
On top of that, the business is unlikely to get upsell or continual revenue from that customer, and this is often key for a healthy ongoing revenue figure.

Part of the process of selling, therefore should include the incentive for the customer to use what they buy, and for them to be happy referenced customers.