TLD CRM BoostPatch 6.9.9

Custom Minute and Cascading List Resets for TLDialer & Admin123 Billing Integration!

Admin123 Integration

We are happy to announce our Admin123 Integration is live and now working! Please contact us if you have a product that is sold through Admin123 that you would like TLDCRM to Submit for Billing! The system supports many dynamic options for Admin123. We are working on status syncs as well, our first phase is submission and storage of Policy Numbers and Member ID’s. See More Details at the Bottom!

TLDialer Cascades and Resets

We are also happy to announce that our List Cascade and List Reset system is now operational! You can now take fine grain control of the intervals and reasons for your Dialer lists to reset besides just at certain times of the day! Ask us how it use it! The interface is simple but the ideas a little complicated!

Minute Resets

Runs every minute on the minute! Reset your leads back to Not Called based on Status, Lead Entry Date, Last Called Time, and Total Call Attempts! You can even reset specific leads the very next day at the same time they originally inquired! Set as many resets as you like and create effective call patterns! All resets are logged in our robust custom logging system so you can see exactly what happened!

List Cascades

The best way to give your prime agents the best run of your leads. Runs once a day, choose what days of the week and at what time! Change List ID from primary lists to Cascade lists, which can also have their own resets! Manage the Vici list right from the Vendors Panel, right on the cascade as well. Split your Lists into Cascades and assign different Lists to different campaigns so you can control exactly the quality and age of the lead your agents get! Cascades are also logged! Cascades however, do not reset the leads back to Not dialed, you would need to use the Minute system for that.

Multi-Term Policy Options

We have added some new features specifically regarding Multi-Term policies. There is now a Workflow option for using a single policy to track all the policy numbers and lapse dates for the Multi-term policy.

  • This Option can be found in Settings -> Options -> Data under Multi-Term Policy
  • When a Duration and Terms are set, the system will automatically add Terms – 1 Policy Number fields under the primary Policy Number field for tracking purposes. You can fill them in at any time.
  • The Policy Lapse will be calculated based on the Duration mulitplied by the Terms, instead of just the Duration. This will allow you to get a more accurate Lapse date for the policy. This change is system wide when the setting goes into effect as we have baked it into the TQL Schemas similar to the Ancillary features in the same option menu.
  • If you have an effective date set, the current term will automatically correct itself to the current term, and will override the manual entry method. You can still try to change it, but the system will always query the correct term.
  • We added a new Display Field to Policies called multi_term or Multi-Term. If a Policy has Terms and a Duration, it will show up as DxT for example 4×2, 3×2, 6×2, 3×4.
  • As you could before, you can search for these fields in the Policies / Customers section. If you enable this setting, you may find new or missing policies in the Renewals and Lapsed section based on how your company decided to manage multi-term policy data.
  • We are recommending you use this approach for Multi-term Policies, unless you are already too used to doing it the old way. This is why we have made it optional.

Automated IVR Integration Features

Along with Admin123, we also have some new custom features related to using third party IVR’s. We are working on our own IVR solution, and are hoping to merge it with our Survey system sometime in the future!

  • When a Product has IVR Enabled, the Verify Button will be replaced by the IVR Buttons enabled.
    • Phone Number ( Call IVR )
    • Field DTMF
      • This fields format is for example: {policy_id}#
        • This will send the Policy ID of the Current Policy as a DTMF Tone, for the IVR to Lookup using the Egress API. Buttons
    • Start / Yes DTMF
    • Stop / No DTMF
    • Restart
  • By default, Agents can see and use the IVR System, as it is intended for Agents to Self Verify.
  • Only Managers or Higher can Override the IVR when it is enabled for a product, unless different Manual Override Roles are checked in the product Configuration. A second, Override: Verify button will be shown if it is possible to override.
  • When enabled, the Egress API will show an additional IVR JSON Column with pertinent data for an IVR.
  • When successful, the Ingress API may be used to Submit the Policy by passing in status = 2 along with the Policy ID. A Record ID may also be submitted for reference to the IVR Recording. This process may get more flexible in the future.

The workflow for the IVR is pretty simple. Once the “Sale button” has pressed you will then use the forthcoming buttons to do the following:

  1. Call an IVR System and Transfer them into your conference with your client.
  2. Pass a Data Point from the TLD Policy to the IVR via DTMF Tone.
  3. Start the IVR via DTMF Tone from the buttons.
  4. Wait for the Client to finish Verifying.
  5. Wait for the IVR to Update TLD, and Update the Policy as Verified.
  6. Leave the Conference and finish the Sale.

Contact Form

  • Fixed bug where when choosing a new product and locking that field, the field would retain an uneditable value.
  • Fixed a bug where after resetting convertible text from drop down to text, would not keep the order of select menus.
  • New Options Save Unknowns Phones – When loading unknown phone number, allow save without touching form instead of requiring some input.
    • This can be found in Settings -> Options -> Contact Form.
  • Added “Record ID” to the system. It was always there, just never showing up.
  • Moved Validations Messages to under the Submit Buttons when present.
  • Lots of Mods to Policy Validator. Should be cleaner now.
  • Rewrote Policy Status Button Methods yet again for Policy Statuses. Should be more Consistent now. Using a Lock System now.
  • When Verifying an Admin123 Policy with a IVR Set, a button will show in red the Error as to Why it is not valid.
  • When Converting, Verifying or Submitting a Product with Pricing Matrix Configured and Enabled, the system will now prevent you from submitting invalid policies if Pricing is Enabled.
  • Added “Nointegration” button for Submit when Overridable.

TLDialer

  • Can now Transfer to Self…for queueing reasons.
  • Fixed a bug with Reset Now in TLDialer Lists
  • Reset Times now has a Multi-checkbox on TLDialer Lists instead of relying on the user typing in dash separated times.
  • Reorganized the TLDialer Lists Panel.

Users

  • Changed Users section to have the same Filters header as newer sections.
  • TLDialer Users can now be filtered by TLDialer Ingroup, User Level, User Group, and Active / Inactive.
  • User Table now has a new icon that shows the Users TLDialer Level. It will be Red if the user is inactive. Clicking the User Level will show the current Active Status as well as the User Level and User Group for the user. The user group has a link to open in the Vicidial Admin Panel.
  • User Action buttons should be more even now.
  • User Quote Tools can now be configured like Global Quote tools with POST Options.

TQL

  • Vicidial Dash-array is now a TQL Schema property that allows for us to do searches with Multi-checkboxes.
  • Added: Fields, Labels, Configs to TQL Egress API.

Products

We have a new Theory on how Product Validations operate. They operate on a series of “Locks”. A Lock means that the Policy must be valid for that reason in order to continue, or the user must have the appropriate override permissions based on their role or other criteria on the Product config itself. The Product Matrix was the first to introduce the concept of a “Lock”.

For example, if you have Admin123 Enabled and Configured, but are missing a Benefit ID or Product ID or the Product Combo is Invalid, it will be locked. Managers or Higher can usually override this setting, unless otherwise specified.

The types of locks that exist now are the following, each Lock has Override settings in the system now.

  • Post Date Lock
  • IVR Lock
  • Admin123 Conversion Lock
  • Admin123 Verification Lock
  • Admin123 Submission Lock
  • Validation Locks

Also, we have made the following changes and fixed to Product.

  • Changed Products Menu to look like rest of system.
  • Fixed an Issue with Multi-checkboxes on Products when using the Set Stages to All.
  • Add more Copy from Product Menus to the Products Section. Can now be used in the Embedded, Points, Emails, Pricing and all Validation Subsections as well as Admin123. Added Merge from Feature. So you can merge instead of overwrite Into a specific Product Config.
  • Added address validation as required fields for accounts with service objects Enabled. This works on Leads, Policies and Dependents.
  • Recombined the Matrix Fields and Other fields into “Fields” split into two vertical sections for use with Mass Updating.
  • Added Filter Select boxes to Copy Menus, Emails and Embedded sections
  • Added New Filters to Products table to determine what is configured and what isnt.
  • Cleaned up Icons and Buttons in the Products table to be more descriptive.
  • Added Override Option for Post Dates in Submission Validation in Product Settings in the Options Multiu-checkbox
  • You can set the product to allow certain roles to Override certain locked Stages, and by default Managers or Higher (Level 70+) can Override the stage changes. When a stage is invalid, those with Override capabilities will see an Override: prefix on the Buttons.

Fields

  • Changed Fields section to look like rest of the system.
  • Made it so that Prohibited Customizable Fields do not load at all.

Other Bugfixes & Updates

  • Fixed an issue with Modal Resizing, now should remove the full class when changing back to a different size other than full.
  • Fixed an issue with Renewals section and Rewrite Refused.
  • Fixed issue with Links inside Flaps. They can be clicked again.
  • Cleaned up Error screen when Error happens during HTML Generation. No more extra html!
  • Fixed an issue with Contact Validation Errors showing Twice. Now only shows once.
  • Made Multi-checkboxes slight more performant.
  • Fixed an issue with Post Date Policy buttons from the last patch.
  • Fixed an issue with Custom Policy Statuses from the last patch.
  • We now have JSON Search Capability! Yay!
  • Improved TQL Schema Generation Times by reducing Iterations. Still working on a non-cached lag solution.
  • Websocket transport emits disconnecting eventSip.JS Updated to .11.4 => .12. Maybe more stable? That’s what they say anyways.
  • Fixed a Bug with Transfers from TLDialer Contact causing browser crash. Removed conflicting tldialer-command class.
  • Register expires can be 0
  • Fix connection timeout issue where connection promise could be hanging and Transport be left in an unusable state
  • Websocket disconnect default code is now 1000
  • Prevent processing multiple ACK’s with SDP
  • Fix edge cases related to unexpected Websocket disconnects
  • Fix potential out of bounds error with addMidLines modifier
  • Modified Select Menu’s and Multi-checkboxes to support Overridden Fields, to show what would be checked if this was not checked, or if blank.

Service Objects & Address Validation

We have an Address Validation Service we have integrated with Service Objects. It basically allows you to click a button on an Address to Validate it and stores the results. When used with the Validation tools in Products, it double checks to see if any of the data has changed before trying to revalidate.

We are working on figuring out the best way to offer this service to others, as it is a third party API and currently we are using a clients credentials that would not be able to handle the volume of requests. If you have an account with ServiceObjects, please let us know and we can enable this for you immediately.

Admin123

Admin123 is now Generally available! It does take some configuration, as most people require more or less fields to be passed to Admin123, and some use the new Automated IVR in conjuction with it. If you sell a product on Admin123, give us a ring and we can help get you setup so that you can Manager Your Leads, Dial Your Clients, and Submit new Policies all without leaving the CRM!

Every Product in the System can be configured to be an Admin123 Product. A product can run with it’s Standalone configuration. Be sure to use the Validation Rules for Conversion, Verification and Submission to validate your data before you send it to the system. The Admin123 integration does not do any data validation besides key points such as the presence and absence of Benefit ID’s Product ID’s, and Config values. It is imperative you rely on the Product Validation system instead.

Admin123 Integration Field

As an alternative to Configuring each individual product, you can now customize the field known as admin123_integration in the fields section with a generic integration mapping for your products. You can then set that Field as an Integration in each product instead of filling it out multiple times. This makes it easier to update passwords and configuration information. Products still need to be configured with a Product ID and Benefit ID however to function.

Individual Admin123 User Credentials

Each User can have their Admin123 Enroller ID and other pertinent user fields set when editing users under the Third Party tab. This configuration will Override Product and Integration Field settings.

How do the configs work? What order do they take precedence?

The order of overrides between user, product and integration config is as follows:

  1. User Config
  2. Product Config
  3. Integration Config

The user config trumps all of them, as it usually contains the unique Enroller ID of the User. Product and Integration Configs have more information set than the User, as long as we have a complete configuration, the submission process will go through.

If you have chosen the Conversion, or Verification Locks, valid Admin123 Configs, Benefit ID’s and Product ID’s will be required before passing Sale or Verification, however, a Submission Lock will always be forced active, as you cannot submit a Product that is not configured correctly.

How does submitting Work?

Basically, when you get to Submit, if you have the proper Permission ,you just click “Submit” And you are done!

The following are some changes since our last configuration update:

  • Added “Name” to Admin123 Config Panel so that the Messages and Buttons will use that name instead of Admin123. You can set it to “Billing System” for instance.
  • Admin123 Benefit ID should show up always in Mass Update Matrix when Admin123 is Enabled. Please note that Disabling a product will remove the Benefit ID entries. If you want to deactivate a configured product, please use the “Active” dropdown. Only Products with Admin123 Enabled and Active will be use the API Submission.
  • Admin123 now can have User Group Allow permissions on the Integration and the Product configs. What this means is you can limit a certain subset of users to using the Submission Tool, regardless of Role. Otherwise, normal roles will see the Submission button.
  • Policy Admin123 Config can now have a preset set.
  • Added admin123_integration field. By default added 2: USA Dental Club and A1.
  • Fixups to Admin123 API.
  • Rewrote Admin123 User Fields.
  • Updates to Admin123 Config Reader.