Coverage Customization

Like customers provide profile information, they will also need to make coverage selections that fit their needs. Some will find our suggested coverages satisfactory. Many want to customize with fine grained control.

Offering that customization typically requires hard-coding state-by-state slightly different experiences:

1. Each state will have a slightly different offering of coverage, with different limits, deductibles, and modifiers.
2. And each state will have quite different rules dictating which combinations of coverage are allowed.

Root has provided two endpoints to solve those hurdles. When combined, they offer a responsive end user experience that guides the expert and novice alike through the complexities of insurance coverage.

1. Get available coverages provides all options per coverage type, for both policy coverages and vehicle coverages.
2. Get coverage rules describes valid coverage combinations (not all combinations from Get available coverages are valid).

The above is a demonstration front-end that knows nothing of insurance on a state-by-state basis. It's content and behavior were driven entirely by the responses from the Get available coverages and Get coverage rules endpoints.

1. Get Available Coverages endpoint

The Available Coverages endpoint returns a comprehensive list of all possible coverages available for a given market, including key attributes such as a description, deductible, per day limit, per occurrence limit, and per person limit as well as declining options if the coverage is declinable. This response provides a detailed breakdown of each coverage option, enabling partners to build user experiences that display and interact with these coverages effectively.

Available coverages may change dynamically as user profile information evolves. For instance, regulations in certain regions may require offering specific modifiers only to certain age groups or under specific conditions.

By leveraging this endpoint, partners can provide users with an accurate and up-to-date view of their coverage options, facilitating informed decision-making and ensuring compliance with market-specific regulations.

Building a generalized UI that renders all the available coverage options will provide the basics of coverage customization. The rest of this guide will walk through progressively enhancing the UX by guiding the user to valid coverage selections.

2. Get Coverage Rules endpoint

The Coverage Rules endpoint provides detailed information about the constraints and relationships governing coverage options. Designed to work in tandem with the Available Coverages endpoint, it ensures that coverage selections adhere to the rules Root must abide by in its insurance policies.

Some common rule types include:

1. Dependencies: One coverage cannot be selected if another is declined. For example, in some states, if Comprehensive is declined, Rental cannot be selected.
2. Exclusions: Where two coverages cannot both be selected at the same time. Such as Personal Injury Protection and Medical Payments (again, this rule may only apply in certain states).
3. Comparisons: Where limits or deductibles must be equal, less than, less than or equal, greater than, or greater than or equal than another coverage's.

Basic Rule Structure

The response of the Get coverage rules endpoint is a fully qualified, searchable tree in JSON starting at the root key coverageRules. It may simply be referred to as a "ruletree". There are three concepts in the ruletree:

1. The coverage symbol: such as bi for Bodily Injury, these symbols will match the symbol attributes in Get available coverages (reminder that only the name and description of coverages should be shown to end users, never the machine referenceable symbol).
2. The coverage state: such as selected, declined, or lowest.
3. And coverage comparisons: for simply describing when one selection should be greater than or less than another.

Parts of the "ruletree" that are not understood or do not apply to your specific coverage context can be safely ignored without impacting the evaluation of other rules.

The placement of these concepts on the "ruletree" structure will be covered in detail below. The summarized ordering always goes from coverage symbol to coverage state to many coverage symbols each with a coverage state or comparison. The following is a simplified example "ruletree":

json

{"coverageRules": {
    "bi": {
      "selected": [
        {
          "description": "Uninsured and Underinsured Motorist Bodily Injury selection cannot be higher than selected Bodily Injury coverages",
          "acceptableConditions": [
            {
              "umuim": "<="
            },
            {
              "umuim": "declined"
            }
          ]
        }
      ]
    },
    "coll": {
      "selected": [
        {
          "description": "Vehicles must have either both Comprehensive and Collision coverage, or neither",
          "acceptableConditions": [
            {
              "comp": "selected"
            }
          ]
        }
      ],
      "declined": [
        {
          "description": "Vehicles must have either both Comprehensive and Collision coverage, or neither",
          "acceptableConditions": [
            {
              "comp": "declined"
            }
          ]
        },
        {
          "description": "Rental cannot be selected if Collision or Comprehensive has been declined",
          "acceptableConditions": [
            {
              "rental": "declined"
            }
          ]
        }
      ]
    },
    "comp": {
      "selected": [
        {
          "description": "Vehicles must have either both Comprehensive and Collision coverage, or neither",
          "acceptableConditions": [
            {
              "coll": "selected"
            }
          ]
        }
      ],
      "declined": [
        {
          "description": "Vehicles must have either both Comprehensive and Collision coverage, or neither",
          "acceptableConditions": [
            {
              "coll": "declined"
            }
          ]
        },
        {
          "description": "Rental cannot be selected if Collision or Comprehensive has been declined",
          "acceptableConditions": [
            {
              "rental": "declined"
            }
          ]
        }
      ]
    },
    "rental": {
      "selected": [
        {
          "description": "Rental cannot be selected if Collision or Comprehensive has been declined",
          "acceptableConditions": [
            {
              "coll": "selected",
              "comp": "selected"
            }
          ]
        }
      ]
    },
    "umuim": {
      "selected": [
        {
          "description": "Uninsured and Underinsured Motorist Bodily Injury selection cannot be higher than selected Bodily Injury coverages",
          "acceptableConditions": [
            {
              "bi": ">="
            }
          ]
        }
      ],
      "declined": [
        {
          "description": "Uninsured Motorist Property Damage cannot be selected if Uninsured and Underinsured Motorist Bodily Injury has been declined",
          "acceptableConditions": [
            {
              "umpd": "declined"
            }
          ]
        }
      ]
    }
  }
}

By "searchable", we mean this tree can produce the list of acceptable coverage selections (or declinations) by traversing its structure with the current coverage selections. And by "fully qualified", we mean the interpreter can assume that it will arrive at the same rule description whether it begins with one interdependent coverage or the other; every branch has an inverse.

3. Traversing the "Ruletree"

The Ruletree can be thought through in six conceptual layers:

1. The Ruletree itself (the root),
2. its Branches (one per Coverage Symbol),
3. containing Rulesets (one per coverage State),
4. composed of Rules,
5. listing Acceptable Conditions,
6. having one or more Comparables (an expected Coverage State or Coverage Comparison for another Coverage Symbol)

Beginning at the root, coverageRules, traverse only into the Branch of the "interesting" coverage symbol (the coverage the user is currently selecting for example). Because the Ruletree is "fully qualified" (each branch has an inverse in the tree), we can safely ignore the other Branches (until they become "interesting").

On an "interesting" Branch, there will be one or more Ruleset whose Coverage State is true for the Branch's Coverage Symbol. For example, if the selected Bodily Injury coverage is the lowest offered (which can be known by cross-referencing the Get available coverages response) then the Rulesets for selected, lowest, and not_highest should all be evaluated.

For each Ruleset to evaluate, we evaluate ALL of a Ruleset's Rules (that is ALL the Rules must be satisfied by the current coverage selection). Note that if there are no Rules for a Ruleset to be evaluated, then the Ruleset can be considered satisfied.

For each Rule to evaluate, we need only ONE Acceptable Condition satisfied for the Rule to be satisfied. The description given in each Rule can be displayed to end users to help guide them in why a certain combination of coverages cannot be selected (e.g. "Rental cannot be selected if Collision or Comprehensive has been declined").

For any Acceptable Condition to be satisfied, ALL of its Comparables must be true. Each Comparable should evaluate whether the Acceptable Condition's Coverage Symbol meets the expected requirement (such as being selected, declined, or less than the Branch's Coverage Symbol), and for vehicle coverages the Comparable must be evaluated for ALL the vehicles.

Now note that interpreting the Ruletree can be implemented progressively by implementing Comparable types one at a time. Like understanding simple states like selected or declined before understanding all Coverage States. Then finally implementing Comparisons like less than or equal to. Each progressive enhancement will incrementally improve user experience.

To properly implement the Ruletree progressively, we should consider Comparables satisfied by default if our implementation does not understand how to evaluate the Comparable type. This permissive stance in our implementation will also allow future expansion to the Ruletree without completely degrading our end user experience.

4. Comparing Coverages

Coverage States

These are simpler to evaluate as they only involve a single coverage at a time (comparing to the available coverages to determine some states such as lowest). We recommend starting an implementation with the Coverage States.

The current Coverage States are as follows:

• selected - When the coverage has a limit or deductible selected
• declined - When the coverage has been explicitly declined
• lowest - When the coverage is selected at the lowest deductible or limits offered
• highest - When the coverage is selected at the highest deductible or limits offered
• not_lowest - When the coverage is selected at a level other than the lowest
• not_highest - When the coverage is selected at a level other than the highest
• enhanced - A coverage modifier only available on some coverages and only available in some states
• unenhanced - When said coverage modifier is not selected

Note for vehicle coverage that all of the coverage choices should be evaluated per vehicle.

Coverage Comparisons

Slightly more complex to evaluate are the comparisons. Thankfully there is a more limited list of these:

• == - When the Comparable's coverage is equal to the Branch's coverage
• > - When the Comparable's coverage is greater than the Branch's coverage
• >= - When the Comparable's coverage is greater than or equal to the Branch's coverage
• < - When the Comparable's coverage is less than the Branch's coverage
• <= - When the Comparable's coverage is less than or equal to the Branch's coverage
• <> - When the Comparable's coverage is NOT equal to the Branch's coverage

The complexity of comparing comes in the multi-faceted nature of coverages. Some coverages have deductibles. Some coverages have per day limits while others have per occurrence and per person limits. And either coverage in the comparison may be declined.

Coverages must be compared on each of those limits or deductibles, but cannot be compared across types. A $100 deductible cannot be compared to a $100 per day limit. A $100 per day limit is not strictly more or less than a $100,000 per occurrence limit. A $50 per day/$100 per occurrence limit could be compared to a $100,000 per person/$300,000 per occurrence limit coverage because they have a comparable overlap in the per occurrence limit. All of the limits/deductibles of the same kind between the two coverages should be compared (but none of mismatching kinds, and if there is no overlap then the comparison is not satisfied).

Only when all the sub-comparisons per limit & deductible meet the criteria should the comparison be considered met overall. If one of the coverages is declined, then it should be considered as having no limits or deductibles (and thus no sub-comparisons to compare and the comparison criteria is not met).

Note again for vehicle coverage that all of the coverage choices should be evaluated per vehicle. If both coverages are vehicle coverage, then we must compare all combinations across all vehicles, only when all those permutations are met is the comparison satisfied. For example; take this Medical Payments rule:

json

{ "coverageRules": {
  "medPay": {
    "selected": [
      {
        "description": "Medical Payments coverage election must be the same for all vehicles"
        "acceptableConditions": [
          { "medPay": "==" }
        ]
      }
    ]
  }
}

This example is only met if the selected Medical Payments limit is the same across all vehicles.

5. Provide Customer Coverage Selection

Once the "ruletree", cross referenced with available coverages, has guided a user through their customization, an updated customer selection can be submitted in an update: customer-coverage-selection. Be prepared to handle any error messages on invalid coverage combinations after updating the quote, even after fully utilizing the ruletree.

A full understanding of the available coverages and coverage rules working together enables coverage customization. Both tailored to the user's needs and ensuring all embedded experiences remain compliant across all states.