Skip to content


July 9, 2013

Northern Virginia, 1 Metro stop outside DC.  A darkened conference room, no windows, a revolving beacon over the door signifying someone in the room didn’t have a security clearance.  Our sales rep, doing his job, says, “Let’s all get to know each other, my name is Dave”.  Complete silence, until a woman in the back said “let’s just say everyone in this room is named Dave, ok?”  Software sales ain’t easy, but then again, neither is buying.

Insurance systems are hot.  No one was writing a check for much of anything besides toner from 2008 through this year.  Many vendors are hoping the second half of this year will see a run of buying decisions, some of which will keep the vendor viable, others will add one more notch to the sales reps handle. Some vendors with a presence at the recent IASA show are saying they got over 100 leads, where only a year ago, the pickings were slim.  Life’s good, vendors need to sell and insurers want to upgrade older system, right? Here’s the disjoin – the vendor wants to sell with minimal time, effort  and cost while the insurance company wants to buy at minimal risk, at the lowest cost, and at a time in line with their corporate speed of decision making.  Now that we’re all back in the buying decision mindset, how do we bridge the gap?

How vendors sell software and services

Vendors need to scale to survive, and they accomplish this by selling as many copies or licenses/subscriptions as they can, with the least amount of modifications to the basic package, not touching the core code. Good packages are designed to be parameterized for particular situations and have some kind of API or Service Call architecture for tight integration.

Projects go bad when the sales rep/vendor is too eager to make a deal and overstates either the maturity of the product or the extent of current flexibility and functionality.  Why would they do this?  Many vendors are investor backed or barely public and are measured Quarter to Quarter. Founders know if they miss 2 Quarters, it’ll be another Board of Directors root canal session.

Therefore, combining least cost and maximum revenue into a sales cycle yields the standard

 high level discussion>high level demo>paid Proof of Concept (known as the ‘POC’ by vendors) using customer data> hammer the deal closed for the Quarter.

Nice, neat, not too many questions, low cost and let the Professional Services team bill as needed to satisfy the customer, so it’s good money all the way around for the vendor.  In my own experience, I ran Global Professional Services for a software company where there was so much sales force turnover; the prospects demanded I write the proposal and deal terms since they knew I would have to live with the reality of making the package operate as required.  From a legal standpoint, vendors love the No Fitness for Purpose clause, where they say the package operates per published specifications, and they are not responsible if it doesn’t do your job.

A further complication for vendors comes from the consulting research firms, who know the market is flooded with competitive offerings and are emphasizing having the vendors mentioned in their research reports (for a fee). References and site visits are tricky based on competitive pressures and their appreciation you’re not going to tell them of your ‘disasters’.

How customers buy software and services

Customers have a specific business need, to be addressed by new software.  They also do not need a complex piece of insurance processing software ripped apart for their modifications as overlaying new releases becomes extremely complex, time consuming and risky.   Still, the package or SaaS product has to do the job and be flexible enough for the future, but still not fully dimensioned, uses.   Using online video product overviews helps dimension the range of options to be explored; it eliminates some vendors and does not sell any one product.

The consulting research firms are encouraging the value of their services to help narrow down the number of potential vendors to be evaluated, as a way to reduce acquisition Level of Effort.  In general, this is not a crummy idea, but in reality, each sector has their own Tier 1 (default winner), Tier 2 (near default winner, a strong #2) and Tier 3 (others, with varying level of financial stability).  For example, the June/July 2013 issue of Insurance Network News has a grid showing 331 broad criteria spanning 175 vendors.  There are safe choices, future focused choices, and some ‘still hanging on for dear life’ choices.   This is not a slam dunk.

Therefore, the preferred buying cycle combines least interruptions to daily operations, lowest cost, maximum contractual protection and a strong agreement with the vendor the new software will fit a specific need, and be sufficiently flexible for future ‘unknowns’. Paying for the Proof of Concept is undesirable, as the prospect sees it as the vendor’s cost of sales and everyone understands their data is a tangible asset and releasing it, even for a pilot, is not an easy decision.

The sales cycle, from the prospective customer’s point of view, should be,

 a high level discussion>high level demo>deeper understanding of the needs, and how it fits into the remaining Enterprise architecture>free Proof of Concept using mockup data>end user acceptance>proposal>negotiation>decide on go-forward at a pace acceptable to the customer.

As a customer, it’s not in my best interest to have a virtual open checkbook for my vendor’s Professional Services group and so I want everything nailed tight into the proposal and contract, and the idea of a vendor making their Quarter is not that strong a motivator.  References are not exceeding crucial, but performing a deep background check to uncover the delta between proposed and final implementation costs, time overruns, people quality and of course, the troubled projects, is essential when the software is in the $250K to $3M range and the business impact is immense.

How to bridge the gap, i.e. both sides agree on a sales evaluation approach

Both sides have a problem to solve – close new business on one side and not make a poor decision on the other.    Where’s the common ground to bridge this gap?

We recommend you strongly consider 4 factors when selecting and buying Enterprise or business critical software, either installed or SaaS based:

Focus on a pilot (the POC mentioned above) where you do the driving.

The vendor will ask for a paid proof of concept, more as a demonstration of commitment than a cost recovery.  Most POC’s are developed by the pre-Sales staff, and that’s their job, so cost should not be a big factor.  You are committing your time, knowledge and resources to the pilot; you are also educating the vendor in your business which they will then apply towards selling to your competitors.  Hence, your contribution is more valuable than the vendor’s.  Use this to your advantage.  The pilot should be free; the data should be yours but modified to protect the business information. You should use the pilot, on your own, for a month and protect your IP transfer in the build-out process.  If the vendor insists and you agree to a paid for pilot, ask for a credit towards the purchase price.

Have their Professional Services group build the pilot. 

You need to know these people, whom you will live with for the next 6 months to a year, listen well and are committed to your success.  You’ll also get to see if you are getting their A team or a bunch of newbies. Most importantly, by having their Professional Services people build the pilot, the vendor can then confirm their proposed Level of Effort, ideally preventing underbidding, and avoiding surprises down the road.

Review their financials. If they say they are private and do not reveal their financials, take a deep breath and ask again.

There a lots of smart people in this world, hence there are over 60 Policy Administration Systems, about the same number of Claims systems, numerous financial systems, etc.  The question is which are viable for the next 10 years.  As regulations and technology changes,  will your chosen vendor have the bandwidth in terms of talented people and financials to modify today’s codebase, or develop their next gen system for 18 months out? Are their new hires overwhelmingly Marketing or Finance based, or are they nurturing their technology delivery capability as well?

Ask to speak to their Product Manager for your proposed application.

This is the interface person aligning developing market needs with the product roadmap (and the resulting budget implications).  Does this person understand the trends in your business?  If they don’t have a formal Product Manager position, definitely satisfy yourself with their explanation why not. You have to live with this investment for the next 10 years and you should know their vision for that period of time and their ability to execute.

This also applies to a vendor growing too quickly, and which does not yet have a strong implementation partner ecosystem.  How will they scale? Will they pull the best resources from your project to help land a new customer (especially if that new revenues will make their Quarter)?  I had a situation where exactly that occurred and it derailed our project for 2 months.  Is this fast growing vendor known for painful implementation, over budget by a large percent?

Buying Insurance software is not trivial – there are safe choices, but also the up and down escalators of emerging and lagging vendors.  In the end, it’s not a battle between 2 parties, but a joint effort for mutual success spanning 10 years.

Richard Eichen is the Founder and Managing Principal of Return on Efficiency, LLC,
, focusing on companies, initiatives and products where technology is the primary means of delivery and revenue. He is one of their senior turnaround, transformation, Program Rescue and Process Rescue leaders.  As a Change Agent, Trusted Advisor, Program Leader and Interim Executive, Rich has over 25 years hands-on experience reshaping companies, Operations, IT/Systems Integration and strategic initiatives.  He can be reached at, and followed on Twitter, @RDEgrowroe.

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: