Today’s blog is about allocations – what I consider the pinnacle in the use of a RMIS. You usually land here after you’ve been out of implementation for several years, when you’ve collected all this lovely data and now want to do something with it. If your RMIS vendor’s implementation team has served you well, you won’t have to completely rework the system to use this portion of the software. Now you understand why so much time is spent discussing locations, hierarchies, levels and all that fun! Allocation or apportionment is taking a fee (typically premium, but it doesn’t have to be) and spreading that across your entities, divisions, locations, vehicles. While you can do a flat allocation (everyone gets an equal share), there’s absolutely no fun in that! After years of building and explaining allocations, I have concluded that while you can (and many clients do) make allocations incredibly complex, at least initially the KISS rule (keep it simple, stupid) definitely applies. Because if you can’t explain to a store why they’re getting $X, then you’re in trouble.

I built my first allocation at Snelling when I held the title of Information Manager in the Risk Management Department. I wasn’t managing people, but since everyone else had manager in their title, my title was changed (thus began my annoyance with titles). The biggest cost for the company (and for many companies in the US) was Workers Compensation Premium. We had a high per occurrence deductible (I believe at the time it was $250k) which basically meant we were responsible for all claim damages.

Some may consider allocation a science, I consider it art. What I have seen consistently is an allocation model that produces a raw allocation and then the humans intervene and manipulate. Don’t view this as bad at all. 90% of manipulation is because there’s a desire either to not have a big swing in a participant’s allocation amount year over year or to eliminate administrative headaches (i.e., it’s not worth it to invoice the store in Bakersfield $1.27 annually).

In the first scenario, the insurance company charged different flat rates per job class code. That’s the starting point. We then applied a modifier based on each store’s claims experience. We chose to evaluate every 6 months based on Incurred data as of the prior month. That meant at least 3 months prior, I was notifying each store through a communication that they better look at the incurred (they did receive monthly loss runs). This drove many claims adjuster nuts, but did reduce unnecessary reserves, which is always a good thing. The final manipulation was to look at the prior period’s modifier and not allow a swing of more than 25%. This allowed stability for the store as they priced out to their clients. I say the final manipulation…but there’s always the manipulation that occurs immediately after the release of the final numbers, where a store manager calls the CFO and screams and we look to see if we can massage the numbers more. Sometimes we can. Sometimes we can’t.

In the second scenario, for a different company we had General Liability premium to allocate based on revenue. This is a very straightforward (and common) allocation. The additional complex logic we built it was for a zero premium and a minimum premium. As an example, if the raw premium produced $500 or less, set the premium for the location to $0. But if the raw premium produced a premium of more than $500 but less than the minimum of $1000, then set the premium to $1000. What can then occur is either too much or too little premium collected. At this point you can stop and accept that overage or underage within corporate budget. Or you can do what I built out and re-allocate the overage or underage so that you collect the exact premium, no more no less. I’ve seen client’s accept overage but not underage, but that becomes hard to explain if your savvy field members identify that more money is being collected.

There is of course more that you can do…and most systems can handle it. For example, I’ve built the following: allocate differently for domestic vs international premium; allocate primary layer differently from excess or umbrella layers; reward for entities that have attended safety trainings; reward for no losses; reward for locations willing to take on a higher deductible themselves; allocate based on windzone/floodzone; allocate more for certain states.

Similar to ‘if you build it, they will come’, my slightly lengthier mantra for allocation is ‘if you can articulate your need AND if your data is stored correctly in your RMIS, I can build it.’

2 Comments

  1. Awesome and simple to understand. In training the trainer, they taught us “be the guide on the side rather than the sage on the stage,” and youve always been a great example of that!

    1. Thanks Dana! Allocation is not the prettiest piece of software in any RMIS system. I would say it is the most challenging space of a RMIS, but data conversions may be vying for that honor. Every client thinks there’s an easy button that they hit and data is scrubbed and loaded. You and I both know that isn’t the case!

Leave a Reply

Your email address will not be published. Required fields are marked *