Not legal advice. I build the systems that enforce these rules; I am not your counsel. Requirements differ by state, change without much fanfare, and depend on facts about your business I do not know. Use this to understand the shape of the problem, then have someone qualified confirm the specifics for your operation.
Most teams I work with can recite the federal calling window. Far fewer can tell me how their dialer decides which window applies to a given lead — and that decision, not the rule itself, is where compliance is actually won or lost.
The layers
Federal. The TCPA and the FTC's Telemarketing Sales Rule set the baseline. Telemarketing calls are restricted to 8:00am–9:00pm local time at the called party's location. The TSR also caps abandoned calls at no more than 3% of answered calls, measured per campaign over a 30-day period, and requires that a live representative be connected within two seconds of the person's greeting.
State. States may be stricter, and a number of them are — narrower windows, additional restrictions on particular days, their own do-not-call registries alongside the national one, and in some cases registration or bonding requirements before you may call into the state at all.
Consent. Layered on top: prerecorded or artificial-voice messages to residential lines generally require prior express written consent, and calls to wireless numbers using an autodialer or prerecorded voice require prior express consent. Consent is a property of the record, not the campaign, which has implications below.
The rule that matters most for engineering is the one people skim past: the window is set by where the called party is, not where you are.
The problem that actually bites
To apply a local-time window, your platform needs to know the called party's location. Almost every implementation I audit derives it from the area code.
Area code tells you where that number was issued. It does not tell you where the person is.
- Number portability means a number keeps its area code when its owner moves. A 212 mobile has been in Denver for nine years.
- Mobiles move. The whole point of them.
- Several states span two time zones. State-level rules do not resolve to a single window.
- Arizona mostly does not observe daylight saving, so its offset relative to your other markets changes twice a year without the state doing anything.
So a dialer keying off area code is making a guess and recording it as a fact. Most of the time the guess is right. The exposure is entirely in the tail — and the tail is what gets litigated.
What to do about it instead
Prefer address data over area code. If the lead record has a ZIP or a verified address, that is materially better evidence of location. Where you have both and they disagree, that disagreement is itself information worth logging.
When uncertain, take the intersection. If a number could plausibly be in one of two zones, apply the narrower window — the one that opens latest and closes earliest. You lose a small amount of dialing time. You lose it deliberately, rather than discovering later that you were calling at 7:40am local for a year.
Encode rules as data, never as code. Windows, per-state overrides, consent requirements, holiday handling: all of it belongs in a table an operations person can update, with an effective date. Rules that live in the dial plan get updated late, because updating them requires an engineer and a release.
Handle DST explicitly. Store rules against a timezone identifier, not a fixed UTC offset, and let the library resolve the offset for the moment of the call. Fixed offsets are correct for about half the year.
Gate, do not audit. DNC scrubbing and window checks belong ahead of the dial, as a hard gate the list passes through. Auditing afterwards tells you how many violations you committed. Gating means there were none to count.
Log the basis, not just the outcome. Record which location signal was used, which window was applied, and why. Being able to say "we used the ZIP on the record, applied that state's window, and here is the row" is a very different conversation from "our system was configured correctly."
The abandonment rule is an engineering problem
That 3% cap is not really a policy setting. It is a consequence of how your pacing and your answering-machine detection interact.
I have written separately about why abandon rate is usually measuring two different things — genuine abandons mixed together with AMD misclassifications. If detection is mistuned, your reported abandon rate is wrong in ways that make the compliance conversation impossible to have honestly. Fix the measurement before you tune anything against it.
The two-second connect requirement is the same story from the other end: it is a property of how quickly your platform bridges an answered call to an available agent, which is a latency problem, not a compliance checkbox.
What good looks like
- Location determined from the best available signal, with the fallback documented
- The narrower window applied whenever location is uncertain
- Rules in a table, versioned, with effective dates, editable without a deploy
- DNC and window checks as a pre-dial gate
- Per-campaign abandon rate visible daily, split by genuine abandons versus detection misclassification
- A log that reconstructs, for any individual call, why it was legal to place it
None of that is exotic. It is mostly a decision to treat compliance as a property of the architecture rather than a report you run at quarter end — and the teams that get surprised are, without exception, the ones seeing these numbers quarterly.