By recognizing the difference between a customer story that “Sells” vs. a story that “Doesn’t Sell,” you can see for yourself how your own customer stories can be changed so that they inspire prospective customers to buy, instead of providing them with no reason to change.
The mistakes made in the story that “Doesn’t Sell” are common. Because the effects of not having the Seller’s capabilities are abstract, the story doesn’t make the Buyer want to change, because the risks don’t feel real.
Without making the risks of not having the Sellers capabilities feel more real than the risk of change, the Buyer will stick with the status quo.
In fact, the greatest leverage to a Seller’s future sales growth is to reduce the number of deals lost to no decision. In a recent survey of 3,500 sales organizations by the Sales Benchmark Index, for example, it was discovered that in complex sales 28% of deals are won, 14% are lost to the competition, and 58% are lost to no decision.
That’s why we teach our customers how to tell stories about how real people solved real problems before they offer the solution. To be receptive to change, a story must first help customers to realize that they are not ankle deep in problems, but that they are actually out in the middle of the lake before trying to rescue the Buyer with the Seller’s solution. If the customer doesn’t feel like they are really drowning, then they are not going to feel the value of the rescue/solution.
So, look at the story that “Sells” and the story that “Doesn’t Sell,” and see which story one of your salespeople could repeat back to you after hearing it only once. If these stories are easy for your salespeople to deliver, then they will be easy for your customers to remember long after the details of your presentation have been forgotten.
Example of a story that “Doesn’t Sell”
Rob Jones, Deputy Manager of Operations for the City of Allentown was looking at innovative ways to increase productivity and create efficiencies in all their business processes.
To do this he wanted to coordinate work with Engineering Land development to optimize resources and improve his operational budget by reducing service requests.
Using technology and workflows available to the City temp staff was hired to review work orders and service requests and place pins on a map to illustrate where problems occurred. This was a lengthy and resource intense process that delayed capital improvement planning (CIP) for Engineering. With the growth of the City and increased demands placed on limited City resources something had to change.
Using a Geo-centric approach to managing and maintaining all infrastructure assets Operations decided to implement GISworks. Capital Engineering was also experiencing problematic workflows due to the fast paced growth and change within the City.
Once implemented and history began to compile within GISworks, Capital Engineering was able to leverage historical maintenance data/history from the system to help make better decisions with regards to long term, sustainable capital planning. They did this by using Geospatial Corp’s GIS to overlay all WO and SR from GISworks with the CIP for more accurate and realistic analysis.
Rob Jones stated that while workflow issues between operations and capital planning groups are not uncommon in local government organizations, in Surrey these 2 often disparate thinking groups where brought together through the use of this software. Both groups now have a far better understanding and appreciation of how their decisions impact the entire system at a high level.
Example of a story that “Sells”
Rob Jones, Deputy Manager of Operations at the City of Allentown, was looking to reduce the number of service request by 25%.
The problem was that he had the same level of staff that he had 15-years ago, but the infrastructure that they managed had doubled. As a result, they were now only able to handle 75% of the service requests.
Because the Engineering Land Development and the Capital Engineering departments were already very efficient, Rob felt that they would need new tools if they were going to further reduce the service requests.
This became apparent to Rob when a new toll was put on the city bridge. Instead of paying the toll, the truckers diverted through the city streets. Because the city streets were not designed to handle the increased traffic and weight of the trucks, there was a surge in pothole service requests.
Although Capital Engineering could not possibly have planned for this, Rob felt that if they had a new tool that would have allowed them to overlay their service requests onto a map, then they could have been alerted early to the trucker’s new route. With this new information, Capital Engineering could have altered their capital plan to reinforce the road before it was damaged, and before the surge in pothole service requests.
Sure Rob could have hired temporary staff to place pins on a map to illustrate where the service requests occurred. But transferring 20,000 service requests onto a map with pins would have taken months, and even worse, the data could have been up to 12-month old. Because of these delays, the changes to the capital plan would have occurred after the road was already damaged, and after the surge in pothole service requests.
So, Rob concluded that with the ability of GISworks to overlay service requests onto the capital plan with the click of a button, they could not only optimize their plans for roads, but also for water-mains and sewers. Within 18-months of using GISworks, Rob’s team was able to reduce the number of service request by 25%.
But that’s Rob’s story, what’s yours?