(editor’s note – this is part 2 of a series on P&C Policy Admin technology. You can read Part 1 here: https://insnerds.com/pc-policy-admin-systems-take-data-in-do-things-spit-stuff-out-part-1/ . This was adapted from an e-book written by Luke Magnan of Combined Ratio Solutions)

 

PART 2 – DO THINGS

Can We Please Get to the Actual Functionality of a Policy Admin System?

 

Ok, I hear you. Every pol admin vendor’s website is full of lots of features that we should take as differentiators, but what do they really mean?

Let’s go back to the too-simplified words I heard at the onset of my career: What’s important?

Let’s apply that to the business example above (see Part 1). This will not be an exhaustive list of every function a policy administration system might have, but more a broad categorization of the types of functionality a policy administration system may contemplate.

Let’s start with how Policy Administration systems need to take in data, then we’ll move to how they spit stuff out and finally cover the “things” they need to do in between.

 

Take Some Data In

At the outset, I want to state that I am focusing this on taking data in from you and employees at your insurer.

While some policy administration systems offer functionality for agents (and even customers) to use the same system your internal underwriters and underwriter assistants use, I think that is a very separate function and warrants a separate discussion.

For our purposes, the user of the system will work for the insurer offering coverage.

 

The User Interface

Alright, so at the very least we need a Ul. A user experience. A front-end. Screens and fields. The pol admin system needs a way for users to enter data directly into it. Now there’s some movement in vendors providing “micro-service” backends that would handle processing and leave the Ul completely up to other systems, and that’s interesting, but I think the point still remains; there needs to be a way for a human being to get data into the system.

That might sound completely obvious, but I think it’s a very, very important point in evaluating your policy administration needs. I cannot count the number of times I have been scolded for the “number of clicks” it takes to do something in a pol admin system, and while it’s easy (and fun!) to roll your eyes at comments like that, for some business it is absolutely the differentiator between whether or not it’s profitable for insurers to take on certain types of risks.

Suffice to say, the user experience matters, even if it’s just the Ul that your internal employees need to use. The pol admin system I started my career maintaining was a mainframe system, built on COBOL and with an IMS/DC front-end. We’re talking black background, green text, no mouse (so no buttons), and field labels that were kept so short that you had no idea what each field actually was unless you were told. Using the system was like Neo looking into the Matrix. It took serious training and lots of experience for anybody to use appropriately, but I contend to this day that for the complexity of risks that system could support you couldn’t beat it for the speed at which you could process business.

I’ve also delivered pol admin systems that were so easy you could bring in interns who could productively use the system on their first day, but all that automation-en abled hand-holding slowed things down a bit. The point I’m making is that there are trade-offs in Ul design, you have to choose carefully.

 

Getting Data From Other Systems

Now, in addition to the Ul, policy administration systems need to be able to accept data from other systems. There are lots of ways this is done, for modern systems you’d want a robust, well-documented API, but other options exist. Bottom line is that you want to be able to integrate your policy administration system with any other systems people are using to avoid having to manually key data into multiple systems.

For example, you may want to support agency upload and take data directly from an agent’s agency management system into your policy administration system. That would dramatically cut down on your own data entry and potentially provide agents with instantaneous access to the “things” the pol admin system does without your intervention (i.e. returning an indicative premium). Or maybe you have a CRM system that you’re using and you’d like to have that data pre-populate your administration system as part of the workflow, or an agency facing quote/bind/issue portal. There are lots and lots and lots of applications, and I’m going to go out on a limb and say that being able to electronically accept data into a policy administration system is table stakes. I do want to call out that Agency Upload should be taken as a separate consideration, as that typically indicates that not only can the policy administration system take data as in input, but it can take data formatted to align with the big agency management players (i.e. some ACORD data standard). This is no small feat, and if you’re planning on integrating directly with an agency’s AMS system it might save you significant time and expense if a vendor provides this out of the box.

 

Business Rules

It’s not enough to just have fields on screens and allow web-services to sometimes populate them. You need to have business logic. First you need logic to ensure that you are entering appropriate data the right way for a given policy’s characteristics.

If you’re entering a quote for Kentucky, and Kentucky requires a municipality surcharge, the system needs to ensure that a municipality surcharge field is shown, that you can only put valid values in (or even better it is automatically calculated for you), and that the field is required at the appropriate point in the lifecycle. If you’re writing professional liability business, you might only be offering coverage for a subset of GL Class Codes, the system should only display the valid class codes. If a certain additional coverage, upon being selected, requires specific limits, an error message might be displayed if inappropriate limits have already been selected.

A PAS needs to house all the business rules required for the type of risk you’re working on, and it should signal to the user what they need to do as soon as possible. In the Kentucky surcharge example above, it would be better to notify users that field is required as soon as they set the predominant state to Kentucky, not wait until it tries to rate the policy and determine the price.

Now, there is a huge differentiator between various policy administration systems on how those rules are implemented, by which I mean how you actually get them into the system. That’s a whole separate topic (on which I have LOTS of opinions), but what I’ll say here is that it’s a good thing to have a handle on WHO you’d like to implement those rules (a vendor, your own developers, IT business analysts, the business units themselves). Most major vendors have some level of customer configuration capability, and it’s important to understand what that looks like and how important it is to you.

Finally, business rules are not just for “taking data in”. They also very much apply to “doing things” and “spitting stuff out”. But I needed to talk about them somewhere, and I believe that in most cases business rules are best when surfaced through the user interface. When accepting data electronically from another system, the rules should still apply, and instead of guiding users on the screen they should create error messages that are sent back via the service response.

 

Forms Attachment

When taking data in, we’re talking about any data that a user needs to input to create an insurance policy. Most of that data will be general policy data at various levels: limits, deductibles, locations, vehicles, class codes, etc. etc. etc. Some data, however, will only be required to produce certain forms in the policy document. It’s typically not data that impacts premium, and the system only really needs it to “spit things out” (which I’ll get to soon).

This is critical functionality, notably for US insurers, definitely for those writing admitted lines of business. An insurance policy is really a contract, and that contract is made up of separate forms. Some forms are going to be required, some are going to be optional but the system might “default” them to be selected, some will become mandatory based on certain policy criteria being met, and some of them will be totally optional, selected at the discretion of the user. Finally, some will not be able to be selected at all. Each form might have different versions, and the appropriate version needs to be the version scheduled.

 

The policy administration system needs to be able to determine which forms are on the policy and let users add/remove forms as is allowed by the policy characteristics. In addition, for any form on the policy, the pol admin system needs to let the user enter any additional data required to produce the form.

Depending on the business you write, you also may need a policy administration system to handle manuscript endorsement, or scratch-and-type forms.

Best practice here is to have some sort of a forms library. This will typically house all the forms implemented in the system, and at the very least version them and allow you to enter characteristics for attachment (i.e. effective and expiration dates, state, product, etc). The system should then use these characteristics to build the lists for Forms Attachment listed above.

 

Appetite, Eligibility, and Quick Quote

This is an optional category for various functionality that all fits into the “don’t waste people’s time” bucket. Many policy administration systems will have features that either allow you to get the system to “do things” without entering in all the data that would typically be required by business rules, or keep you from entering in all the data for a policy if the system knows you’re not going to ever quote that policy.

Quick quote is important, and tunes the user interface to require you to enter as little information as possible to get to an indicative price for a policy. This is useful if you have an agent on the phone who is asking for a ballpark price estimate, because

 

it keeps you from having to ask for information that doesn’t factor into the overall price.

Appetite and eligibility help ask questions up-front that would tell you whether or not an underwriter would ever actually quote this risk. If a submission would never get to quote, it keeps you from having to enter a whole bunch of information needlessly. It also encourages users to enter every submission into the system, as opposed to making a judgement about what submissions would be declined and bypassing the data entry, which may cause you to miss out on data that could provide you valuable insights.

 

Attachments

There are inevitably going to be files that should be attached to a submission, quote, or policy. Loss runs, pictures of buildings, the application submitted by the underwriter, and any documents created in the “Spit Things Out” section below.

Here’s an area where solutions will vary wildly. Maybe the policy administration system should store the attachments internally, or maybe it should integrate with a content management system you’re already using (think SharePoint). I would say that a policy administration system should be able to store files (either on its own or by integrating with a third-party tool) and show a list of those files in the Ul that a user can then access directly.

Some policy administration systems will offer attachment organization capabilities, like adding descriptions, being able to delete them, or even organizing them into folders. The importance of these advanced features greatly depends on your own workflows, and your preferred content management system.

 

Notes

The policy administration system needs to allow for the entry of notes, or diary entries, as part of a policy (or submission, or quote, or whatever). This is a free-form area where users can type in any notes they want and have those notes stored as part of the policy. This is particularly helpful in documenting why you did whatever crazy thing you did, for future posterity.

 

Account

Here’s another function that will vary wildly from one pol admin system to another (and one that, unsurprisingly, I have lots of opinions on). As part of “taking data in” you should understand if a policy administration system has any CRM-like capabilities that differentiate between the customer (or you could say “account” or “insured) and the risk that is being protected. Often you’ll be quoting multiple products for one customer. The agents will typically send in a different application for each different product (or line of business, if you will), but there’s value in being able to aggregate those together to an account view.

Some policy administrations will do this, and some won’t. Whether that’s important to you will probably depend on the type of business that you’re writing and whether or not you have/prefer another CRM system to do this (think Salesforce). So while your organization undoubtedly wants to have the capability to view business at this customer level, it’s very much an optional feature in policy administration systems.

 

Task Lists

Like account, workflow is another area that may or may not be handled in a policy administration system. Looking at the life cycle in the example above, there are a lot of steps, and those steps may be done by different people, introducing a lot of handoffs. Some policy administration systems will have a workflow engine in place where tasks will be assigned to users, and users can see what tasks they need to complete, reassign tasks, etc.

It’s important to look at your workflow, as well as what you already have in place to determine how important this is to you. Some insurers need the policy administration system to provide this functionality. Others might be using a third-party workflow tool (i.e. Pega) and need the policy administration system to integrate with it. Still others might just handle workflow in a completely non-automated way. There are no right-or-wrong answers, but it’s something to consider if evaluating different competing policy administration systems.

 

Part 3 will discuss “Spit Things Out” – getting data out of your systems and doing things with that data.