A few years ago, our company invested in some training for our sales team. Core to the methodology of this particular system was that product demonstrations should never be given - or, at the very least, avoided if at all possible. This runs counter to what we find our prospective clients expect, so this was a very difficult concept for us to accept.
Our company, StarCompliance, provides software that detects and mitigates employee conflicts of interest to the financial services industry, and boasts having some of the largest and most influential financial firms in the world as part of our clientele. Instead of helping our clients generate revenue directly, we help keep them in compliance with regulations enacted by the SEC, FCA, FINRA and other worldwide regulatory authorities. Without properly implementing a system like ours, these companies and their employees risk fines, prosecution and even losing of the ability to conduct certain types of business. For these clients, not witnessing that the software meets their regulatory requirements is unthinkable, and their due diligence starts with a product demonstration.
However, product demonstrations can be rigged, orchestrated to show features and functionality that don’t actually exist in the solution. Some vendors use “Smoke and mirrors” to intentionally mask deficiencies, and compound this through embellishing answers given within RFP and security questionnaire responses. So, if product demonstrations and proposals all look so similar, how do these firms determine the correct software to purchase? Contrary to advice given by our sales trainer, we believe the answer is not to forego demonstrations. Instead, firms need to go a step further and test software in a live environment to make sure all requirements are met.
As part of our sales process, we strongly recommend that prospective clients engage in a Proof of Concept (POC) testing period, where one of our Business Analysts configures a production system with the firm’s most important and complex rules and workflows. In exchange for the work we provide (which is usually free of charge), the firm commits to providing the resources to follow a provided test plan for a period running around thirty days. Weekly calls are held to field questions, make configuration changes and document perceived gaps in the system. On the rare occasion when a workaround can’t be implemented for a gap, a commitment is often made to enhance the software, especially where this new feature benefits all our clients and makes the product offering stronger.
Once a prospective client is educated on the merits of conducting a POC, we have found three possible outcomes:
Of course, any software company with confidence in its solution would prefer to be chosen as the only vendor to conduct a POC, though a head to head bake-off is a close second. We’ve had success with both scenarios, and have even won business several times where a firm selected a different vendor to conduct an exclusive POC. In these instances, the testing period illuminated product deficiencies and, just as importantly, poor support by the other vendor. If proper support was not provided during the POC testing period, how would support be if the solution was implemented? In these instances, the firms completed a successful POC with our company after the failed one concluded, and purchased our software.
Following a successfully completed POC, all of the work conducted by our Business Analyst and the firm’s business and IT resources is retained. Rules and workflows configured during the testing period are built upon to implement the solution.
There have also been times when we didn’t move forward, after conducting a POC. In that our goal is to satisfy our clients we would prefer that they not purchase our software if our solution is not right for them. Knowledge gained from POCs that don’t lead to a business agreement is used to improve the product, especially if we feel there is a need in the marketplace that is not currently being met.
Our CTO asks his team to develop software of such high quality that it sells itself. This is a lofty ambition, and one that our sales team would fully embrace. The reality, however, is that when selling a mature product into a sophisticated market, this is difficult if not impossible to achieve. What is possible, though, is to continue to improve the product to where it is highly configurable and flexible, meeting the unique needs of each client within a target market. This is the financial services industry, and we are proud to be able to demonstrate the strength of the software and support through an in depth POC testing period.
We learned a lot from the company we employed for our sales training, but decided against the advice of implementing a “no demonstration” policy. While this may work for some, we prefer to build our client base with a more transparent approach, making sure our company and our software provide the best solution for the market we serve.
Matt McGill is the Chief Revenue Officer at StarCompliance