Patch 10.1.4 – Rewrites, Renewals, Primaries, Ancillaries and Bundles

Alexander Conroy | November 15, 2024 2:43 AM

Rewrites & Renewals

To foster easier tracking of Rewrite and Renewals we have added two fields that automatically update when a Rewrite is Refused. This action occurs when a Policy is Saved and is not tied to dispositions.

While it is already possible to find Policies sold within a certain range and filter out those that have been refused, it is not simple to figure out WHEN it was refused.

The addition of these new fields will make it easier to track and who was the person to mark the refusal. These fields are automatically populated when Rewrite Refused is set to One.

• New Fields
  • date_refused
    • This is the Date that a User set Rewrite Refused from No to Yes (0,1)
  • refuser_id
    • This is the User that set the Rewrite as Refused
• New Action Logs
  • refused
    • Logs when setting Rewrite Refused to Yes
  • unrefused
    • Logs when setting Rewrite Refused to No when it was Yes Before.
• New Rewrite Tab
  • Found in Explore -> Policies
  • All Rewrite Related Filters can be found here.

New Policy Pseudo Fields

This is in preparation for an Expansion / Rewrite of the Analytics CPA Reports that have now become standard across all accounts. We are making efforts to take the Features from the old Agent CPA Report and Migrating them more efficiently into a new joint report that is more query efficient for longer timespans along with some new tracking features revolving around primary and ancillary sales as well as rewrites. Most of these new fields are for easier summation in future reports.

• New Fields
  • Base Fields
    •  sale_id
      • This is a Concatenation of  Date (Sold, Verified, Converted, Created, depending on stage) + the Lead ID for Grouping a “Sale” by Day which is a unique Lead sold Regardless of Policy Count
      • Format: {YYYY-MM-DD}-{LEADID}
      • Example: 2024-01-01-12345678
    • ancillaries
      • Count of Ancillary Policies related to a Policy
    • ancillary_premium
      • Sum of Ancillary Premiums on a Policy
        • respects Premium Subsidy Rules
    • ancillary_enrollment_fee
      • Sum of Ancillary Enrollment Fees related to a Policy
    • ancillary_admin_fee
      • Sum of Ancillary Admin Fees related to a Policy
    • ancillary_initial
      • Sum of Ancillary Premiums, Enrollment Fees, and Admin Fees related to a Policy
      • Respects Premium Subsidy Rules
  • Primary Policies: For Policies that are Primary Policies the following will have Data other wise it will be Null. These Fields support the “Always Treat Ancillary Products as Ancillary Policies” Rule if set. These are useful for Counting and Summing Aggregate Information without Filtering.
    • primary_policy_id
      • Returns Policy ID only when Policy is Primary
    • primary_lead_id
      • Returns Lead ID only when Policy is Primary
    • primary_sale_id
      • Like sale_id except only when Policy is Primary
    • primary_premiums
      • Returns Premium only when Policy is Primary
  • Ancillary Policies: For Policies that are Ancillary Policies the following will have Data other wise it will be Null. These Fields support the “Always Treat Ancillary Products as Ancillary Policies” Rule if set. These are useful for Counting and Summing Aggregate Information without Filtering.
    • ancillary_policy_id
      • Returns Policy ID only when Policy is Ancillary
    • ancillary_lead_id
      • Returns Lead ID only when Policy is Ancillary
    • ancillary_sale_id
      • Like sale_id except only when Policy is Ancillary
    • ancillary_premiums
      • Returns Premium only when Policy is Ancillary
  • Bundles
    • is_bundle
      • Yes or No (0, 1) if the Policy has more than one Policy Attached as Primary ID
    • is_bundled
      • Yes or No (0, 1) if the Policy is Attached to another Policy via Primary ID
    • bundled
      • If Policy Is a Bundle, Returns Total Count of Policies Bundled including Primary
    • bundle_premium
      • If Policy Is a Bundle, Returns Total Premium of Policies Bundled including Primary
      • Respects Premium Subsidy Rules
    • bundle_enrollment_fee
      • If Policy Is a Bundle, Returns Total Enrollment Fees of Policies Bundled including Primary
    • bundle_admin_fee
      • If Policy Is a Bundle, Returns Total Admin Fees of Policies Bundled including Primary
    • bundle_initial
      • If Policy Is a Bundle, Returns Total Premium, Enrollment Fee, Admin Fee of Policies Bundled including Primary
      • Respects Premium Subsidy Rules
• New Filter Tab
  • Moved Primary / Ancillary Related Filters under “Ancillary” tab.

What is a Sale ID?

A Sale ID is a way of Grouping Unique Sales particulary for the specific day when aggregating data over mulitple days. On future reports for those of you who use sales counts instead of policy counts, you will be able to toggle wether or not you consider a sale a unique Lead ID, or a Unique Lead ID sold on the same day. As an Example, if you sold the same person 1 policy twice in span of a month, while you would have 2 policies, you would have 1 sale aggregating by lead_id. Using sale_id you would see 2 sales and 2 policies as they are split by day sold.

What is a Bundle?

Bundles are Policies that have other Policies Attached via the Policies Primary ID, regardless of Primary / Ancillary Classification. To be considered a Bundle it must have at least one policy attached and not trashed.

What’s the Difference Between ancillary_premium and ancillary_premiums?

• ancillary_premium is a sum so you can get the total premiums for that one policy all in the same column.
• ancillary_premiums only returns the premium if the Policy is Ancillary, so when using Summation on the Column, we only count ancillary premiums, which we can then do in the same query along side primary_premiums when grouping data.

New Advanced Call Log Pseudo fields

• inbound_call
  • Yes / No (0,1)
• outbound_call
  • Yes / No (0,1)

Bugfixes and Improvements

• Add Tag on Policy Change should work more Consistently now.