Better Insurance Software Decisions 404 – Avoid the Assumption Trap

So, you’ve identified what you need from your next insurance software solution. After doing your research, you’ve chosen a vendor. Finally, you’ve made your buying decision. Congratulations!

Now it’s time to cover the most common post-purchase tech decision pitfall: the assumption trap.

1. Assuming they know

First on our list of common assumptions is simply that “they know.” We’re talking about the process breakdown that happens when you and your vendor fail to communicate, because each party thinks it goes without saying.

You can steer clear of this trap by articulating your business needs early, as clearly as possible.

• How does every step of your current process work?
• How do workflows play out for each department?
• What are your underwriting rules?
• What third-party data verification integrations do you require?

2. Assuming one size fits all

Next is the “it worked for them” assumption. Insurance software sales are often driven by referrals. If you know a colleague who’s happy with their solution, you may be inclined to go with the same software. Peer recommendation is strong. If it’s working for them, it’ll work for you too, right?

The problem is, sometimes it doesn’t. Insurance software solutions can be highly specific; not all lines of insurance come with the same needs. Even if your colleague is operating in the same line of business, there’s no guarantee that their fit will transfer to you. Sometimes the difference isn’t in the software’s inherent capabilities, but in your own preparedness.

If your colleague took the time to identify their needs, gather documentation, and prepare themselves for development, then it’s no wonder their solution is a fit: they set their vendor up for success.

Now let’s say another colleague witnesses that success story and chooses the same vendor, hoping to replicate the results – but in this case, they don’t do their homework. They provide the vendor with very little detail on their processes, underwriting rules and workflows. Their goals and needs are vague. The point-people they make available to the vendor are generalists. And they end up with a catastrophe. Same capabilities, different approach: the difference being that in this case, they set their vendor up for failure.

The moral of the story is the same, regardless of whether you choose the same solution as your colleagues: give your vendor great input, so they can create great output.

In other words, do your homework. Clearly identify your needs. Vet your vendor’s capabilities; ask for demos. If you take this approach, you’ll set yourself up for success no matter which solution you decide is best.

After the decision is made

We recommend dedicating a full month to discovery after hiring your vendor. This is the period of time in which your vendor will develop a clear understanding of your processes and requirements, drilling deep into the details: your business model, the markets you serve, the products you offer, how your current system came to be, where the challenges and inefficiencies lie, what’s manual, what’s not – and the list goes on.

Those questions need to be answered decisively before the programming can begin. Once you’ve worked through all that, the coding can progress quickly.