Without automation, insurance commission schemes and their calculation can prove complex, time-consuming, and error-prone. In addition, it’s necessary to manually distribute commission statements, making data corrections difficult and reducing transparency.

In this blog post, we describe common challenges associated with insurance commissions. We’ll explain why Sales Cookie is the only solution capable of automating complex insurance commission structures.

When most providers ask you to alter your commission structure to accommodate their technical limitations, Sales Cookie can handle the most complex insurance commission schemes without requiring any adjustment or changes.

Point-Based Commission Schemes

Many insurance companies pay policy commissions based on their Gross Written Premiums (or other related amounts). However, some of our insurance clients use a point-based system to pay commissions.

For example, they may establish a point-based scheme such as this one:

  • Hospitalization policies = 7.0 points
  • Medicare Advantage policies = 5.5 points
  • Short-Term Medical policies = 4.0 points
  • Vision policies = 3.5 points
  • Etc.

Earned points may be converted to attainment or converted into a commission payout.

Now, you want to be able to do the following:

  • Change policy point allocation (at any time)
  • Evaluate different models using different point allocations
  • Track and compare rep attainment in terms of points
  • Apply specific rules to categorize policies into buckets

Using Sales Cookie, you can define time-dependent custom variables with lookup tables. Those custom variables are super easy to reference in formulas! You can change them at any time. You can timestamp each version and track changes.

You can also apply rules to categorize policies based on certain fields. In the example below, we’re looking for certain keywords to classify a policy as “Vision”. We then lookup a number of points from a lookup table which can change over time.

Policy Duplicate Detection

It’s common for insurance providers to experience policy duplication events. For example, one agent records a policy for a given customer, but the customer requests a change to the policy. Often, the agent will create a new policy (instead of editing the original) – but it’s really a duplicate. Another common scenario occurs when a customer contacts 2 different insurance agents, and each inputs a new policy.

Your CRM system may include duplicate detection capabilities. However, policy duplicate detection rules are often more complex than what any CRM system can handle. Here is an example of duplicate detection rules a CRM system would NOT be able to handle:

  • If 2 policies have been submitted, the later submitted policy wins. The older policy is the duplicate and is not commissionable.
    • However, if the older policy already received some commission payment, then the rule is reversed. The later policy becomes the duplicate and is not commissionable.
  • Policies are considered duplicates if the policy product is the same, the customer name is the same, and the US state is the same. If any of those are different, then the policy is not a duplicate.
    • Also, a policy will not be considered a duplicate of another if their submission dates differ by more than 1 year.
    • Also, policies with a product type of “Medicare” should be treated as equivalent to product “Medicare Advantage”.

Those types of rules are too complex for a CRM system to handle. Which means you will likely pay commissions over duplicates! This can prove costly and can even encourage reps to game the system.

Using Sales Cookie, we can configure very complex duplicate detection rules (the sky is the limit). We have ways to perform fast duplicate detection computations, even when comparing millions of records. In the example below, we’re applying duplicate policy detection rules based on different fields.

Clawbacks and Reversals

Often you will pay a commission, and later realize that the policy was in fact NOT commissionable. This can be for the following reasons:

  • A policy received a commission – however:
    • Later, this policy was deemed a duplicate of another policy
    • Later, this policy was found to be incorrectly entered and is invalid
    • Later, this policy experienced a rapid disenrollment
    • Etc.

In those cases, you may want to claw back the original commission. Sales Cookie is able to handle all types of claw backs. Sales Cookie can use its “memory” of commission history to reverse commissions when those events occur.

True-Up Commission Calculations

Let’s face it – policy data input by hundreds of insurance agents can be messy. We already talked about duplicates, but here are some other problems you may encounter:

  • A policy was recorded as submitted in January. You already paid a commission over this submission in January. Later, the policy is corrected – the new submission date is February! You should NOT pay another commission for submission in February.
  • A policy was recorded as a “Vision” policy. You already paid a $100 commission based on this policy type. Later, the policy is corrected – the new product type is “Hospitalization”. You should have paid $150 instead of $100!

Using Sales Cookie, we can implement commission true-up logic. Each time, we will re-process ALL policies in your system, and calculate the difference between a/ what is owed (based on the latest facts) and b/ what has been paid (based on our “memory” of commissions). This true-up system is very useful when dealing with ever changing (corrected) insurance policy data. In the example below, we’re calculating the difference between what is owed and what has been paid so far to issue a true-up amount.

In Conclusion

Sales Cookie is familiar with, and can handle, the most complex scenarios related to insurance policy commissions. If some of the challenges discussed above resonate with you, you can unleash the power of automation to streamline your commission process. Visit us online here!