Move Sales Process Ahead With Tight POC Guide

Leadership is an important part of sales.  Especially where breakthrough technology is concerned, the sales team encourages the customer to consider a new way of doing business.

But many good ideas die, even ideas which are a great match to customer business models. 

One of the main reasons for the failure of good ideas is fear, a Click Me!powerful emotion which goes far beyond the dry concept of "risk".  What is the risk that a project will not conform to expectations -- or hopes?  In the case of software, the trade press retails stories of all-to-frequent failure.  Customer fears of project failure are not unfounded. 

Fortunately, good management practices can reduce project risk to acceptable levels.  When risk is managed, your sales project can go ahead.

One of the best tools for managing risk is the proof-of-concept.  A POC is sometimes unpopular with sales because of the perception of cost.  The reality however is that the cost of no project (i.e. sales failure) or subsequent project failure due to poor information (because the learning opportunity of the POC was missed) can be much higher.

A well-planned POC should not be exorbitantly expensive -- but the POC must require customer executive commitment and customer willingness to absorb some costs.  The vendor's own sales risk is reduced in proportion to the level of customer commitment to the POC.

The attached POC Guide is a great POC planning tool which you can use.  Versions of this Guide have been used successfully to plan and execute very nice POCs -- which then usually led to deals.

*   *   *

When is a POC completely inappropriate?  John says "I once prospected a customer that needed mainframe connectivity.  The right solution was a mainframe gateway.  The customer inquired about testing the gateway to see if it would work.  My response was 'no -- it works as advertised'.  And the customer accepted our position."

"We assisted the customer with a 1/2 hour phone call with a specialist, but otherwise there was no 'POC' prior to the customer's decision to purchase." 

John explains "that with mainframe connectivity, there are many security and connectivity issues, and a test would be difficult to conduct..  Any issues would really be customer configuration tasks.  The purpose of a POC is not to provide free customer training or free configuration and setup.  A mainframe gateway is a very well tested and proven piece of software with very specific, well-defined functionality." 

So in the case of this specialized software, a POC was inappropriate and would have been a needless expense -- and even risk.

File: Proof_Of_Concept_Guide_V_3.0.pdf