
September 2023 Releases
Dialing compliance seems like a solved problem (just follow the law!) until you consider how complicated the law is, and how complex automated validation is at scale. At Regal, we power outbound calling for some of the largest brands in the country across all 50 states.
We’ve powered over 500 million calls across highly regulated industries, including insurance, education, and financial services. In these industries, compliance is the foundation of every customer interaction. One misstep can mean regulatory fines, loss of consumer trust, or an enterprise customer walking out the door. That's why we've invested deeply in making compliance seamless, auditable, and scalable.
Behind a fragmented and ever-changing regulatory landscape is a simple goal: protecting people from unwanted or poorly timed outreach and giving them control over how they’re contacted. In practice, that responsibility translates into a set of checks that must be validated before every call:
.png)
The first two problems have straightforward solutions:
But state telecommunications laws are another story. As we scaled, they introduced a new layer of complexity that required a more flexible approach with greater compliance nuance. We chose to refactor our architecture to meet those demands, and it paid off exceptionally well. In this blog, we’ll discuss how that evolution unfolded and the design decisions that made it possible.
We initially approached regulatory compliance with a centralized, time-based evaluation model. Every 15 minutes, a scheduled cron job would:
We then determined whether calls should be in "quiet hours" or "available hours" based on whether the contact's local timezone fell within the brand's general time-of-day restrictions.
If there was a mismatch between the call's currently configured quiet/available hours status and the newly determined one, we updated that call record and propagated the change throughout our system.

This approach was a deliberate choice for where we were as a company.
It prioritized simplicity and determinism. The cron job was simple, testable, and easy to reason about. For instance, you could write a database integration test that would perfectly simulate all calls moving from quiet to available hours at a specific time.
It also allowed us to defer complexity. With a small number of early customers, we didn't need state-level nuance baked into the system itself. Instead, we handled edge cases like state holidays and per-state calling windows operationally: coordinating agent staffing around restrictions, and using our journey builder to push updates to pending call records when rules changed.
At the scale we were at, performance was not a concern and additional complexity wasn’t required. More importantly, this approach lets us ship a reliable compliance foundation quickly.
As we scaled our dialing volume by 5x and brought on enterprise customers who needed better reliability and automation, the scope of what our compliance system needed to handle expanded significantly.
Performance Considerations: The number of calls fetched and updated grew so large that we got on-call alerts from its impact on our database multiple times a day.
The core query took several minutes to run, and only after it completed would calls begin transitioning into available hours. This led to agents waiting a couple of minutes every morning before they started receiving calls to dial, with the final subset of tasks becoming available up to 30 minutes later.
With scale, this approach became inefficient — a call's dial-ability changed ~2 times a day, but we were recalculating it 360 times a day.
Functionality Expansion: Enterprise customers couldn't rely on staffing adjustments and pieced-together automations to stay compliant. They needed a productized approach to state law compliance that was auditable and turnkey.
We prototyped adding full state-level logic to the existing cron job's query, but the approach became increasingly complex. It grew to 300+ lines and became nearly impossible to test, debug, or extend. A few specific problems stood out:
We pivoted from a "do everything all at once" cron to a design pattern we call a "recursive queue".
.png)
That last step:enqueuing a new job on a delay, is what makes this queue recursive. In the recursion analogy, the first step: checking if we've already dialed the call, is the base case.
Each design decision maps directly to a V1 failure mode:
Instead of sweeping all calls on a fixed schedule, each call now owns its own lifecycle. When a call is created, we enqueue a job that evaluates its dial-ability. That job checks whether the call still needs to be made, gathers the full compliance context (state holidays, quiet hours, emergency rules, call volume limits), updates its quiet or available status if needed, and determines when that status could change next.
Crucially, each job schedules the next evaluation at that exact point in time. For example, if it’s 5 p.m. Monday, the next job might run at 9 a.m. Tuesday; if it’s the day before a holiday, it might run after the holiday window. This is what makes the system recursive: each evaluation schedules the next, rather than relying on a global cadence.
This shift distributes work across calls instead of large database scans, ensuring the system scales without introducing contention or delays. By only recomputing when a state can actually change, calls become available exactly when expected, without the lag we previously saw. Moving compliance logic into TypeScript also makes the system easier to test and extend, while isolated evaluations make every decision traceable. The result is a system that maintains the simplicity and determinism of the original approach, but at a scale and level of reliability the initial design wasn’t built to support.
The biggest wins were for our customers. By handling the full spectrum of state regulations seamlessly in product, we achieved best-in-class compliance with minimal setup. We can now see a call's current quiet hours status, its full status history, and exactly when it will next be evaluated. For compliance teams, that audit trail alone was a major unlock.
On top of that, the efficiency gains are dramatic: we reduced the number of times we recompute a call's status by ~99.5%. As a result, after some fine-tuning, we completely eliminated on-call alerts.
Why the fine-tuning? Efficiency gains don't come out of the box with that architecture. After all, processing a new job for each call creates new overhead for our servers. But it also gave us better tooling to measure and optimize that overhead:
Compliance at scale is an engineering problem, not just a legal one. The systems that handle it well share a few things in common: they evaluate only when needed, they make the logic readable and extensible, and they produce audit trails that compliance teams can actually use.
Regal offers engineers the opportunity to own features across the stack and throughout the full feature lifecycle. We look for engineers who are just as capable of iteratively shipping MVPs as they are of maintaining and scaling them, just like we did with dialing compliance.
If that sounds like you, check out our openings. Let's chat.
Regal evaluates each call individually against the relevant state regulations at the exact time it might be placed, including time-of-day windows, state holidays, states of emergency, and daily call-volume limits. This logic runs in TypeScript, making it auditable, extensible, and testable as laws change.
Yes. Every evaluation of a call's dial-ability produces its own log entry. Compliance teams can see the current quiet hours status for any call, its full history, and the exact time it will next be re-evaluated.
Because Regal's compliance logic is written in modular TypeScript rather than embedded SQL, adding or updating a state regulation is a focused, targeted code change. It doesn't require touching unrelated compliance logic.
Regal's compliance system accounts for states of emergency as a factor in evaluating whether a call can be placed. When an emergency is declared in a state, calls to contacts in that state are automatically routed through the appropriate quiet-hours determination.
Yes. Regal validates contacts against do-not-call lists before any outbound call is placed, alongside opt-in verification and state-level regulation checks.
Ready to see Regal in action?
Book a personalized demo.



