Insurance systems – particularly policy and claims administration software systems – are born from a perspective. Some systems’ initial perspective was transactional, which typically meant the accountants wanted to make sure their reports were accurate. Many systems were document-oriented, focused on making sure policies, invoices and other records were both produced accurately and easily retrievable. Others, especially more recently, are based on a customer relationship management concept, assuring that, at the very least, marketing staff have the data they need to ‘touch’ the prospect or policyholder. The originating perspective gives one a clue as to what a software package will do well. The bells and whistles that are tacked on then build a broader impression: ‘Our software can do everything, and do it very well indeed’.
Maybe so. Maybe not. When a software vendor talks about how easy it is to get output from their system – when they talk about issuing policies, or creating reports, or doing analysis, or asking queries – they’re talking about retrieving data. When they talk about portals – uploads, or integration or even fillable PDF’s – they’re essentially talking about data input. All functions are essential; all, in some sense, are CORE. All are packaged in a glitzy shell that tries to differentiate what every system already should be doing.
None relates to what we consider is the more central CORE: how does the insurance system organize a person’s work? Our analogy is a football training camp, where coaches focus players on the fundamentals of blocking and tackling. There are proper ways to do both, and there are improper ways to do both. Doing the fundamentals well makes even the most physically gifted athlete better, and certainly makes his or her life a lot easier on any number of levels. So it is with policy and claims systems. The blocking and tackling of insurance systems is to allow the user to easily get to their work, quickly get that work done, and distribute it expeditiously. It begs a few questions:
- How intuitive is the interface? When I open the system, do I have a good idea of its organization, and what the buttons and tabs mean, or do I need to learn the roadmap first to get where I want to go? Do I have to navigate through a series of dropdowns?
- How quickly can I get to my work? How many clicks does it take to get to where I need to go? Do I have to remember policy or claim numbers? Do I have to navigate through a series of dropdowns (again)?
- How accessible is the information I need? Is the information needed to make a decision readily at hand (within a click), or do I need to search for it? If I go looking for it, is it easy to get back where I was? Do I need to navigate through a series of dropdowns (again II).
- How perceptive is the software? If I’m changing, for example, an address or a coverage limit, do I have to first tell the software what I’m going to do, or if I go ahead and make the change, will the software know what I just changed, and execute the next steps automatically?
There are more, but you get the gist. For us, it seems like insurance software was always designed for someone else. Good software should make us more effective and make our work easier, just like good fundamentals for a linebacker should make him a better player. That’s really the essence of efficiency: allowing a user to not just get more work done, but to spend more time on the quality of the decision and less on the tedium that takes them to the decision-point.
Software designed for the person actually doing the work. Why does that seem like such a novel perspective?
What do you think? Join the conversation by following us on LinkedIn.
Bill Montei, CEO, founded Megalodon Insurance Systems with a simple yet BIG idea: provide small and mid-sized insurance companies powerful policy & claims management software solutions at a price that is within reach. To talk to Bill directly, please call: (608) 709-2154.