Driver assignment; everyone's favorite topic! It's easily one of the most complex topics to discuss (and write about) related to Oracle Insbridge and the Personal Auto line of business in general. We've recently helped a customer who was dealing with a specific issue related to driver assignment and it opened our eyes to possibilities that are worth sharing. Let's talk about some of the issues related to Oracle Insbridge's driver assignment functionality, specifically with the pre-built use percentage inputs, and how to get around them.


Fair warning: In the interest of time, this post is geared towards relatively experienced Insbridge users that are familiar with the Personal Auto line of business. As much as I'd love to write about driver assignment and explain all of its nuances, it would rival War and Peace in length. So, let's get right to it!


A Very Brief Introduction

For Personal Auto customers, Oracle Insbridge comes equipped with pre-built driver assignment functionality that can make it relatively easy to implement. Most of the pre-built functions lean very heavily on use percentage inputs on either the Driver or Vehicle categories. These Insbridge-specific inputs are named DrvUsePctOnVehX and VehUsePctOnDrvX, where X is a number between 1-18. The use percentage inputs can have a value between 1-100 and in some cases should total 100, depending on the driver assignment function you're implementing. When trying to assign principal and/or occasional operators, we've seen customers utilize these inputs with a percentage value of 75 for principal and 25 for occasional.


What are some of the drawbacks related to these inputs and their associated functions? Are they avoidable?


Drawbacks Associated with Use Percentage Inputs

There are a few problems with the use percentage inputs:

  1. You're limited to 18 drivers or 18 vehicles, depending on the Vehicle Usage Option you select on your Driver Assignment Scenario. In the world of Personal Auto, 18 drivers and 18 vehicles should cover a majority of policies. However, customers want to be able to say they can rate any number of drivers and vehicles.
  2. With the use percentage inputs being very specific to the 1-18 drivers or vehicles, you don't have the luxury of categories at your disposal if you need to evaluate and perform logic on these inputs. This creates a scenario where you might have to repeat logic for each input, rather than letting categories handle the repetition.
  3. There are no driver assignment functions that easily assigns drivers to vehicles they occasionally operate, or simply operate. Almost all of them are geared towards drivers who principally operate vehicles, or drivers who operate the vehicle most frequently. It may be possible to assign occasional operators with an incredible amount of steps, but the logic can be too cumbersome to maintain.


A Way Around Use Percentage Inputs

To avoid these issues, it's possible to eliminate the use percentage inputs by taking advantage of the Assign Vehs Using DA Override Fields assignment function. This function requires 2 inputs: AssignedDriver (ID 17) and AssignmentOverride (ID 400), both on the Vehicle category. This assignment function was originally intended to allow front-end systems to override any assignment that is done by the rating engine, but it is possible to set these inputs in your program during rating (setting inputs in your program is generally not good practice, but the pros outweigh the cons in this specific case).

By using a combination of variables/algorithms, you can determine each vehicle's assigned driver without using any of the flagging/ranking/assigning functions you would typically use with Oracle Insbridge's driver assignment feature.


Implementing a Solution

Here's an example of what you could implement to take advantage of the override assignment function. This scenario is specific to assigning drivers to vehicles they operate based on driver-level information. If vehicle-level information factors into your particular assignment rules, then these steps are not going to be enough and you will need to consider additional or different logic.

  1. At the Vehicle level, add a category called Operator. This category can have inputs for OperatorID (values should match the DriverID sent at the Driver level) and OperatorType (values of Principal or Occasional).
  2. At the Operator level, add calculated variables and Get Category Item steps to get data from the Driver level, such as Youthful Indicators or Class Factors. By using the Get Category Item step type, you avoid duplicating data and logic at both the Driver and Operator levels. The Get Category Item step should use a WHERE clause to get data from the driver "where DriverID = OperatorID."
  3. At the Vehicle level, add an additional calculated variable or algorithm that ranks the Operator categories based on the variables added in #2 to determine the best match for the vehicle.
  4. At the Vehicle level, set the AssignedDriver input equal to the highest ranked OperatorID. The AssignmentOverride input should also be set to 1 for every vehicle, as this tells the engine that you want to assign the vehicle based on the AssignedDriver input.
  5. In a Driver Assignment scenario, add 1 step for the Assign Vehs Using DA Override Fields function. The Driver Assignment Scenario is where the assignment actually takes place and it produces Driver-Vehicle categories, on which premiums can be calculated.


Advantages to the Solution

  1. By using the override fields, you're essentially building your own assignment functions beyond what Oracle provides. While Oracle provides plenty of options for customers, sometimes the options don't quite fit.
  2. With the Operator category on each Vehicle, you're not limited to a specific number of drivers or vehicles. One of the biggest drawbacks of the pre-built use percentage inputs is the limitation of 18 per driver or vehicle.
  3. The logic to determine an assigned driver utilizes variables and algorithms that every RateManager user is familiar with. Driver assignment functionality in Oracle Insbridge is very unique and has its own set of nuances, which takes additional time and experience to grasp.


Conclusion

When it comes to use percentage inputs and their associated assignment functions in Oracle Insbridge, customers can find themselves not being able to make them work for what they need. Using the available Assign Vehs Using DA Override Fields assignment function could be an option to build assignment logic that fits your requirements. If you're interested in more information, reach out in the comments below or contact us at info@secondphaseinc.com!