By Mary Upshaw, Senior Advisor
Space…the Final Frontier… The Star Trek theme sings through my head as I contemplate implementing the policy module in a RMIS system. For a typical RMIS implementation, the policy module is one of the last feature sets to be rolled out. You’ve survived defining your locations and location hierarchy. You’ve added your claims, maybe even incidents. Your team has recovered from the go live…and now you’re wondering what else you can do with your RMIS?
Or perhaps you are a non-US company and are starting your RMIS implementation with policies or values collection for renewals first, as claims are simply not as relevant.
Wherever you are in your RMIS journey, the time has arrived to explore policies. I’ve had the pleasure of being involved with clients that heavily utilized the policy module. Today’s blog is about managing expectations and what to consider when you ponder use of this module.
Managing your expectations…you will know more about insurance than your RMIS team. There was a time when RMIS vendors hired veterans of the industry who knew both insurance and the software. The trend these days is to hire technical software analysts. The belief is that it is easier to teach a techie to understand insurance than an insurance person to be technical. Be prepared to explain what fronting and reinsurance and quota share and program layers are and why its important. If you are lucky to have a support person who knows what you are talking about, then count your blessings!
Policy implementations are rarely as straightforward as claim implementations. That’s because policies, especially cutting edge coverages or insurance for high risk exposures, can be quite complex. Add to the mix the fun of currencies when purchasing internationally (and local policies), and what you thought would be a 1 month implementations turns into a lengthy frustrating experience.
My two recommendations:
- Know what business need your are solving for
- Start small but know your end-game
Knowing the business need you are solving for will help to keep you focused when you get distracted by the various tables and options available to you. If you’re not sure, you really should not move forward with implementing policies until you have the answer to this question. Why? Because you won’t be able to clearly state if the project was a success. To inspire you, I’ve listed a few needs (in increasing complexity).
- I need a repository: If you only need a repository of base information, you’re in luck! All RMIS vendors have a simple policy table that can be easily implemented. Solving for this need should land you in the 1 month implementation timeframe, presuming you have your data in a digestible format. For several clients, we provided licenses to their brokers and let the brokers handle the data entry (if you don’t have your policy data in excel).
- I need my adjusters to validate coverage – this can be a simple as having scanned dec pages or policies in your database that can be accessed by your team. It becomes much more complex if you’re looking for those scanned documents to be fed into fields on a policy record. I recommend the former.
- I need a tool to assist with renewal workflow. I love this need -it should be more popular than it is. Most RMIS vendors have diary or task functionality that can be used to push renewals along.
- I need to a visualization of my layers On paper this is easy…but it depends on how complex your programs are.
- I need to track premium transactionally (either by location or by inception vs audited premium) or I need it to help with premium workflow (invoicing). There are few ways to handle this, depending on your business need. Easiest would be to add Premium as an exposure type (this also plays nicely with bullet 7 on allocation of your premium). All major players have premium tracking functionality (similar to the transaction table on the claim). By default this features isn’t turned on, but is easily rolled out.
- I need to track advanced policy information: Fronting, Local, Reinsurance, Captive data. This isn’t hard, but likely there aren’t ‘standard’ fields or workflows. And since your team won’t know policies, the onus is on your team.
- I need to allocate premium. Theoretically you don’t need to enter policies to take advantage of allocation functionality. The tools used in allocation are rarely straightforward, but that shouldn’t discourage you. Just map out your end game. If you are new to allocation, start simple. If you can’t explain it to your customers, you won’t be able to get buy in from the field.
- I need to track limits and premiums in multiple currencies – Now you’re getting into a slightly more complex space…most softwares can handle this, but it becomes tricky if you have agreed upon rates that are different from your claim currency rates…but typically the complexity bubbles up because really…
- I need to track policy erosion. Your sales guy will say yes, but this can be challenging. Here’s why. While every system can tie back to a policy record, most clients don’t enter in the sub-coverage deductibles and limits, excluded perils and the complexity around policies that make this achievable.
- I need underwriting. I’ve built a fairly complex underwriting process…At the end, the client was satisfied with the results but frustrated with the process. If you’re using your RMIS software in a traditional RMIS sense and are considering a launch into underwriting, just know the approach is different. There is much more time in front spent on requirements gathering – spelling out exact needs and workflows. My advice? I’d stick with the allocation module than full blown underwriting.
I’ve implemented all of this top 10 with varying degrees of success. Where things typically go sideways is when a client thought their business need was ‘I need a repository’ but in fact it was ‘I need underwriting’.
I don’t want to discourage you from implementing, which is why I conclude with my last recommendation. Start small but know your end goal. The end goal may be allocation of premium…but you start by building the repository and iterate forward. Most of the above can be iterative steps forward…Where I see the gotcha occurs is around policy erosion. If the end goal is policy erosion…then the policy repository data AND claim data have to be in sync for the correct deductible to be applied…and sometimes that deductible is at the transaction level…which means another layer of complexity.
Now…boldly go…well you get the drift.
To learn more, schedule an inquiry call with Redhand Advisors today.