Imagine needing to change the policy effective date after having entered a quote or policy application with all the required information. If the rules for the new date are different, your policy administration system will probably tell you to reenter most or all of the information because some of what you just entered may now be inconsistent with the new rules. For example, under the new rules, a coverage may no longer be applicable, another coverage may become required, and the valid choices for a limit or deductible may not match those already entered.
One may find reentering information annoying but may consider it a low priority issue if it happens infrequently. However, this situation occurs rather often because it does not only arise by changing the policy effective date. Similar inconsistencies can result when changing any data item that affects the rules.
These data items are not limited to the well-recognized policy determinants such as state, business class, or vehicle type; even a simple “yes or no” question may impact the relevancy and permitted values of other data items.
More importantly, the same situation arises at renewal time when the policy effective date is typically changed by one year. The rules may change considerably within a year due to regulation and product evolution. Before issuing each policy renewal, the inconsistencies brought about by these changes must be detected and addressed.
How does your policy administration system handle this? Having users manually review and adjust information on each renewed policy is not operationally attractive. Worse yet is continuously adding custom programming to automatically detect and address each potential inconsistency that may arise at renewal. After a few years, the software becomes clogged and unmanageable due to the accumulation of custom programming additions that are analogous to the plaque build-up in our bodies.
Unfortunately, a combination of these two approaches is practiced today even with the “state-of-the-art” policy administration systems. In contrast, with PolicyWriter, whenever the value of any data item on a policy (or quote) is changed, all the necessary adjustments to the rest of the policy are automatically made. For example, a coverage that becomes required will be added, a coverage that is no longer offered will be removed (unless it is grandfathered), new data items that become applicable will be added, and data items that are no longer applicable will be removed. PolicyWriter will also ensure that the value of each data item is valid. This is controlled by configuration for each individual data item. For example, if a particular coverage limit value is no longer valid, the configured instruction options include setting it to the nearest value, nearest higher value, nearest lower value or requiring user intervention.
This indispensable feature named “Rule Reapplication” completely eliminates the data inconsistency issue mentioned above without the need for any manual work. PolicyWriter is specially architected from the ground up to be able to implement this innovative data and rule alignment as a general algorithm that applies to all insurance products and does not need to be changed or adjusted when existing products are changed or new products are introduced. The resulting avoidance of the need for custom programming to address each special situation is what sets PolicyWriter apart.
Contact us to learn more about PolicyWriter, and what it can do for your business.
Register or login for access to this item and much more
All Digital Insurance content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access