TLD CRM BoostPatch 10.6.0 – New Features: TLIntel – AI QA Dialog Processing & Outbound Compliance

In Partnering with OnScriptAI, we have now launched a native integration and first entrant into our AI Suite, TLIntel Dialogs

Features Include:

  • Access to Dialogs in TLD
  • Agent Dashboard + Agent Coaching
  • Admin Dashboard
  • PHI Redacted Recordings
  • PHI Redacted Transcripts

These are just the few initial features on our baseline launch. We will be collecting feedback over time. Details on how to use TLIntel will be provided in another post as it’s a bit too much to go through here in the patch notes. We will be working with people using the current OnscriptAI Integration on enabling the features.

TLIntel launches at $.03 per minute. It is completely optional. You can configure it to send all calls for processing, all calls over a certain duration, or you can manually send calls via Explore -> Calls. We will be adding other ways to trigger Dialog processing in the near future as we get ideas and desires from users.

In order to use TLIntel, you have to accept the TLIntel Terms of Service to accept charges for this AI processing as well as Enable the Feature otherwise dialogs will not process.

You can find the Feature Settings in TLIntel -> Settings

Compliance API Launch & Overview

On 11/11/2025 we launched a single point-of-entry compliance API that validates every outbound call, manual and auto. This prevents unusual dialing patterns that concerned our Telco, improves visibility into misconfigurations, and increases outbound connectivity rates.

Compliance Decision Logs can be found under Logs -> Compliance and you should also have an outbound call record for any rejections with the appropriate status.

  • 11/11/2025 – Launched to first problematic client cluster server
  • 11/12/2025 – Deployed to 8 additional clusters
  • 11/13/2025 – Deployed to all client clusters

The Compliance App validates phone numbers against multiple compliance criteria before allowing them to be dialed, ensuring adherence to TCPA, DNC, and telecom standards. It is the global, mandatory, non-bypassable entry point for all outbound compliance checks.

Dialer Execution Workflow

  1. Dialplan performs an HTTP API check via internal ALB with Account ID, Phone Number, DID, Consent Date.
  2. If API returns OK, allow the dial.
  3. If API times out, allow the dial (fail-open).
  4. If API returns any other disposition:
    • Dial is not attempted.
    • A synthetic call log is created with the disposition.
    • Lead/contact is updated.
    • Autodial continues; manual dial plays a message to the agent, hangs up, and auto-dispositions.

Checker Execution Flow

1. Payload Extraction & Validation

Extracts and validates request parameters.

2. Number Validation (Destination Number)

Validates destination number using NANPA standards.

Rejection Dispositions (NUM*):

  • NUM10D – Not a 10-digit number
  • NUM555 – 555 area code (reserved)
  • NUMACI – Invalid area code (first digit not 2-9)
  • NUMACR – Reserved area code (500, 600, 700, 710, 900, or ends in 11)
  • NUMPI – Invalid prefix (first digit not 2-9)
  • NUMPR – Reserved prefix (211, 311, 411, 511, 611, 711, 811, 911, 950, 958, 959, 976, or toll-free specific reservations)
  • NUMJEN – Jenny’s number (867-5309)

Returns early: Yes

3. DID Validation (Caller ID)

Validates outbound caller ID using NANPA standards.

Rejection Dispositions (DID*):

  • DID10D – Not a 10-digit number
  • DID555 – 555 area code
  • DIDACI – Invalid area code
  • DIDACR – Reserved area code
  • DIDPI – Invalid prefix
  • DIDPR – Reserved prefix
  • DIDJEN – Jenny’s number

Returns early: Yes

4. Ban List Check

Checks ban_list for active bans.

Rejection Dispositions (BAN*):

  • BAN{code} – Where {code} is from the ban record’s code field
  • BANNED – Default if no code found, or for traceback numbers
  • BANHNY – RND / Telnyx Reported Honeypot
  • BANLIT – Known Litigator Number

Returns early: Yes

5. CDR Rejection History Check

Checks up to 50 call entries for SIP codes 404, 603, 607, 608 between Consent Date → Now. Computes {code}.count, {code}.sameDid, and sets last_call.

Rejection Logic:

  • 404.count ≥ 1 → reject
  • 607.sameDid ≥ 1 → reject
  • 608.sameDid ≥ 1 → reject
  • 603.sameDid ≥ 1 → add 1 hour per occurrence (max 50h) to last_call; if now < adjusted time → reject

Rejection Dispositions (SIP*):

  • SIP404 – Missing
  • SIP603 – Rejected
  • SIP607 – Unwanted
  • SIP608 – Declined

Returns early: Yes

6. RND Check (Reassigned Number Database) – Disabled

Would check reassigned number database status based on Consent Date + number.

Rejection Dispositions (RND*):

  • RNDNDT – RND Reported no_data
  • RNDYES – RND Reported yes

RND Decision & Issues

All RND complaints reviewed had consent dates after the number was disconnected, causing RND to return NO (“safe to dial”). This contradicts the claim that RND prevents honeypot dials. Avoiding honeypots 100% would require access to the RND honeypot list, which is not available. Costs are significant and benefit is minimal since RND cannot prevent these hits. We may allow optional RND usage via client API keys in the future.

Summary on RND Honeypot Vendors

RND honeypot vendors misrepresent efficacy. RND results depend on consent date, so honeypots can appear safe. If honeypots consistently returned no_data or yes, their claims would be accurate—but they do not, so the claim “RND prevents honeypot dials” is false.

Their argument is that “you should know” that this number is owned by a FCC Honeypot Partner, but in our opinion, if a number was disconnected 2 years ago, and yet a person filled out a form to dial putting in this number after those 2 years, knowingly or not, there is no way to validate or know that the phone number is owned by this vendor, not without having some expensive third party vendor to validate the data against. As an example, one of the honeypot contacts to call was provided directly to our client by United HealthCare.

Other Changes

  • Made Changes to JSON Viewer to allow for searches and debouncing when dealing with large objects
  • Fixed API Logs Viewer
  • Fixed API Logs Metrics
  • Fixed “View Policy Users” ability, should now work properly on contact policies without edit capability.
  • Ingress Add Hoppper API now supports passing in vendor_lead_code (CRM lead_id) as well as lead_id (CRM dialer_id) for ease of use.
  • Areas where you can click to copy will now check if you are highlighting a portion of the text to copy and only copy that.
  • Took a pass at a bit more mobile friendly explore menus.
  • Added Callgrid to Vendor API Platforms
    • Fixed an issue for CallGrid where we were showing tag:CallerID instead of tag:CallerId causing problems when copy pasting the URL.
  • Added day_effective to Policies Schema
  • Updated the Media -> Data Tools -> Deduper to now be a Job, you should get real time updates now!
  • Fixed an issue when Disabling PHI / PCI Globally causing some fields to disappear from Vendor Maps.
  • Fixed a LONG standing issue, where Dispositioning a lead while NOT on a call was not updating the Dialer Lead Status. It now should do so as that is the intended behavior.
  • FTP Backups can now pull Sales based on Conversion, Verification or Submission Dates, this makes it work better with Sunfire / IntelligenceX
  • Added Vendor List Status Filter to Vendor Sources
    • Refactored the way we lookup TLDialer Data related to Vendors
  • On Ingress Add Policy API, returning dupe = true when it’s a dupe.
    • Now returning policy_id and lead_id so you can take further action
  • Vendor API
    • Fixed an issue with the Vendor API Ping where if you were returning a count of agents and it rejected for any other reason it would still return the count so it was bypassing policy checks and other callerid based checks (10/17/2025)
    • ack, prk, usk parameters always allowed to modify keys since it’s something a vendor should be able to always do.
    • Some Adjustments made to auto-update ping Feature when switching between inbound call modes. (BATMAN, State Route, Ingroup)
    • Fixed a bug when adding a DID that was cloned from a non-similar Vendor to adjust the ping.
  • Policy Statuses TLDialer Triggers
    • Copy and Move List Triggers had Dupe Protection option added.
    • Add to Hopper Feature added
      • Add Hopper now checks if lead is added already before adding again