Automated Regional Compliance for Outbound Calling

The Business Problem

Running outbound campaigns across multiple regions means navigating a patchwork of regulations — and a single call placed at the wrong time can cost $500–$1,500 in fines per contact under laws like TCPA (US), FTSA (Florida), and CRTC/LPC (Canada). Today, most teams manage this risk manually: segment lists by timezone, build separate campaigns per region, and hope nothing slips.

This feature eliminates that manual overhead entirely. The system automatically enforces the correct calling window for each contact based on their location — across every region, in every campaign.

What Changes for You

How the System Protects You

1. It figures out where each contact is

When you upload your contact list, the system resolves each contact's timezone and jurisdiction automatically — from data you've already provided (timezone, region, phone area code, Canadian postal code, or your own geolocation API). Contacts it can't place are quarantined rather than dialled.

2. It knows the rules for each region

Pre-loaded regulatory profiles cover US Federal (TCPA), Florida (FTSA), Canada Federal (CRTC), and Quebec (LPC). Your admin can tighten any window for business preference or add custom holiday blocks. When federal and state rules both apply, the system always uses the stricter one.

3. It blocks out-of-window calls before they happen

At dial time, the system checks the contact's local time against their applicable calling window. A contact in Florida gets Florida's rules; a contact in Quebec gets Quebec's rules — automatically, on every call attempt.

4. It reschedules blocked contacts — nothing is lost

A contact outside their calling window is not removed from the campaign. The system calculates when they next become eligible and re-queues them automatically. No manual follow-up, no lost leads.

5. It generates a compliance audit trail automatically

Every call decision — dialled or suppressed — is logged with the full reasoning: the contact's resolved location, the rule that applied, the local time at the moment of the decision, and the version of the compliance profile in use. Logs are retained for 7 years and can be exported within 24 hours of a regulatory request.

Configuration

Prerequisite — Enable Timezone Resolution

Timezone and region inference is controlled by the CHECK_TIMEZONE environment variable. It must be set to true for automatic resolution to run. When disabled, contacts are not enriched with timezone or region at import time.

If you're using Bring Your Own API, it also requires its own tenant-level "Enable BYO API" toggle, separate from CHECK_TIMEZONE. See Tenant Configuration in the BYO API guide.

Step 1 — Prepare Your Contact List CSV

For best accuracy, include these columns in your CSV before uploading:

If explicit timezone and region are not both provided, the system resolves using the following priority order:

For Canadian numbers, phoneNumber + postalCode are both required to infer timezone and region. Area code alone is not sufficient.
For non-Canadian numbers (e.g. US), timezone and region can be inferred from the phone number alone, provided the area code maps to a single timezone.
Alternatively, both timezone and region can be supplied explicitly together to skip inference. Providing only one field fails resolution.

1. Explicit CSV columns (New in CX5.11.0) — both timezone and region provided together (skips all inference)

2. Bring Your Own API (New in CX5.11.0, when configured) — your registered HTTPS endpoint returns timezone and region. See Bring Your Own API for Timezone Inference.

3. Phone area code lookup (non-Canadian numbers) — e.g., +1-415 → America/Los_Angeles, US-CA

4. Phone + postal code lookup (Canadian numbers) — e.g., +1-416 + M5V 1A1 → America/Toronto, CA-ON. The phone area code and postal code must agree; a mismatch quarantines the contact.

5. Quarantine — contact cannot be resolved; timezoneConfidence is set to UNRESOLVED_TIMEZONE, timezone is null, and region is empty. Contact is excluded from dialling.

Canadian example

Resolved result: timezone = America/Toronto, region = CA-ON, timezoneSource = POSTAL_CODE, timezoneConfidence = CONFIRMED

US example (no postal code needed)

Resolved result: timezone = America/Los_Angeles, region = US-CA, timezoneSource = AREA_CODE, timezoneConfidence = INFERRED

Postal code format rules

• Format: letter-digit-letter, space, digit-letter-digit (e.g. M5V 1A1)

• Case-insensitive; spaces optional in input (m5v1a1 is accepted)

• Stored normalized as uppercase with a space: M5V 1A1

• Invalid first letters (not used in Canadian postals): D, F, I, O, Q, U, W, Z

• US ZIP codes (e.g. 12345) are rejected — this restriction applies to built-in phone+postal inference only. Postal codes passed through to a Bring Your Own API are not validated or restricted by ExpertFlow; your API can interpret them however it needs to.

Area code 867 (Northwest Territories, Nunavut, Yukon)

Area code 867 spans three provinces/territories. A Canadian postal code is required to disambiguate:

Bring Your Own API for Timezone Inference

Organizations that maintain their own geolocation data or use a third-party compliance vendor can register a custom HTTPS endpoint. When configured, ExpertFlow sends each contact record to your API and applies the returned timezone and region for calling compliance.

Full integration guide: Bring Your Own API for Timezone Inference — request/response contract, authentication, examples, and validation rules.

When BYO API is enabled for your tenant, it is attempted before built-in phone and postal-code inference. If your API returns unresolved, the contact is quarantined unless fallback to built-in inference is enabled in tenant settings.

Step 2 — Configure Calling Windows (Admin)

Go to Admin Portal → Calling Windows. Pre-loaded regulatory profiles are available out of the box:

Admins can also:

• Tighten any window — e.g., stop calls at 7:00 PM even if the regulation allows 9:00 PM

• Add split time slots — e.g., 9:00 AM–12:00 PM and 2:00 PM–8:00 PM to skip lunch hours

• Add holidays — US and Canadian federal holidays are bundled; other dates can be entered manually

• Create custom profiles — for jurisdictions not covered by the pre-loaded set

Admins can configure province-specific rules where Saturday and Sunday use different calling windows, and can fully disable Saturday or Sunday where required.

Step 3 — Add the Check Calling Window Node in Conversation Studio

In your campaign flow, place the Check Calling Window node between the INIT and DIAL nodes:

Flow order: START → CHECK UNDELIVERED → SEIZE → INIT → Check Calling Window → DIAL

The node reads each contact's resolved timezone and region, calculates their current local time, and routes to one of two outputs:

• Callable now — proceeds to DIAL

• Outside window — skips and auto-reschedules the contact

Manual Outbound Dialing Compliance

Regional calling-compliance checks are not limited to campaign flows. When an agent manually dials an outbound call, the system checks it against the same regional calling-window rules before the call connects, and bars the call if it falls outside the applicable window.

Enabling this: manual-dial compliance checking is controlled by the isCallingComplianceEnabled setting on the Unified Agent component, disabled by default. Your deployment team can enable it as part of Helm chart configuration.

Business Outcomes

• Regulatory risk eliminated at the source — non-compliant calls are blocked, not reviewed after the fact

• Operational overhead removed — no more per-region list segmentation or duplicate campaign setup

• Audit-ready by default — no additional logging effort required

• No leads lost to timing — auto-reschedule keeps every contact in play

Limitations

• Covered jurisdictions at launch: Pre-loaded profiles cover US Federal (TCPA), Florida (FTSA), Canada Federal (CRTC), and Quebec (LPC). Campaigns targeting other countries or US states with additional calling laws will require admin-configured custom profiles.

• Timezone resolution depends on data quality: Mobile numbers can cross area codes (a Chicago number carried to California will resolve as Illinois). Where precision matters, provide explicit timezone and region columns together in your CSV. As of CX5.10.0, shared Canadian area codes (e.g. 867, covering Northwest Territories, Nunavut, and Yukon) resolve to the correct province via postal code lookup.

• US ambiguous area codes: If a US area code maps to multiple timezones, the contact is quarantined (UNRESOLVED_TIMEZONE). Provide explicit timezone and region together to override.

• Phone and postal must agree (Canada): If a Canadian phone area code and postal code point to different provinces or timezones, the contact is excluded from dialling rather than risk a compliance violation.

• Unresolvable contacts are excluded, not rescheduled: Contacts with timezoneConfidence = UNRESOLVED_TIMEZONE will not dial until the data issue is corrected. Update the contact's phoneNumber or postalCode (or provide both timezone and region) and save — a full re-import is not always required.

• Regulatory profiles do not auto-update: When laws change, an admin must update the relevant calling window profile manually. The system enforces what is configured, not what the latest regulation says.

• Most-restrictive rule applies system-wide: When federal and state rules overlap, the system always applies the stricter window. There is no mechanism to elect a less restrictive rule for a specific campaign.

• Custom holiday entry is manual: The bundled holiday calendar covers US and Canadian federal holidays. Holidays for other jurisdictions must be entered by an admin.

Disclaimer: Compliance jurisdiction is determined using area code and postal code mapping libraries. Where area codes overlap across regions, postal code identification is used to disambiguate (Canadian numbers only). If a contact's phone area code and postal code do not agree, that contact is excluded from dialling rather than risk a compliance violation. ExpertFlow does not warrant the accuracy of the underlying area code / postal code mapping libraries. For enhanced accuracy, you can register your own geolocation API — see Bring Your Own API for Timezone Inference.

Setting a holiday active or inactive from the frontend fails in 5.9.0. Workaround: update the inActive value for the holiday directly in the database.

Frequently Asked Questions