Regulation F prohibits more than 7 calls to a consumer within 7 consecutive days for the same debt. For AI voice automation, that cap applies whether the call is answered or not — voicemails count. Automated dialers must track calls per-consumer per-debt and block outreach once the cap is hit, or until 7 days have elapsed from the most recent conversation. Most AI dialer configurations do not enforce this at the account level by default.
Collections teams often underestimate how specific Regulation F cadence control needs to be. The usual mistake is thinking of the 7-in-7 rule as just another campaign setting: one number in a dashboard, one weekly counter, one sitewide threshold. That is not how the rule operates in practice. The counting unit matters. The debt matters. Conversation timing matters. The person matters. If your dialer cannot distinguish those dimensions, the cap becomes a guess rather than a control.
AI voice automation raises the stakes because a small counting defect can affect many accounts before anyone notices. A missed join between account records, a per-number counter instead of a per-debt counter, or a voicemail path that fails to increment the attempt count can push the dialer out of policy silently. Human teams still need cadence controls, but AI systems need them earlier in the flow and with less room for exception handling on the fly.
That is why serious buyers should treat Reg F review as a data-model review, not only a legal review. Ask how the dialer counts attempts. Ask whether the counter lives at the consumer-debt level. Ask what happens when one consumer has multiple numbers, when two debts exist, when a voicemail is left, when a right-party conversation occurs, and when accounts move between campaigns. Those questions reveal whether the vendor actually built for collections or simply adapted a generic outbound stack.
On this page
What Regulation F says about call frequency
At an operating level, the 7-in-7 rule tells collections teams that call volume cannot be managed only at the campaign layer. Each debt needs its own history. If the same person has multiple debts, each debt can change the analysis. If the same debt has multiple numbers, the consumer still experiences one stream of outreach. This is why buyers should focus less on raw dialing horsepower and more on the dialer's unit of record. When the record model is wrong, the cadence model is wrong too.
Another important point is that Reg F is not just about counting up to seven and stopping at eight. The rule also interacts with the timing of a telephone conversation. A right-party conversation creates a different waiting period than an unanswered attempt. Teams that reduce the rule to “seven calls per week” usually miss that distinction, then discover later that their dialer kept calling because the counter reset incorrectly or because the conversation event was not tagged in the right place.
In AI automation, that means your voice platform and your campaign engine cannot be loosely connected. The campaign engine needs to know, quickly and reliably, whether a conversation happened and whether the call should move the debt into a protected period. A recording sitting in storage is not enough. The outcome must be structured, written back, and used before the next call is queued. Otherwise your evidence shows what happened after the fact, but not that the system prevented the next mistake.
Buyers should therefore ask to see the exact event taxonomy used by the vendor. What counts as a call attempt? What counts as a conversation? What counts as a voicemail? Which events increment the attempt counter? Which events start the post-conversation waiting period? If the answer is vague, the deployment will be vague too.
| Rule dimension | Why it matters | What the dialer must know |
|---|---|---|
| Person | One consumer may have several numbers | Identity link across numbers and accounts |
| Debt | The rule is applied in connection with a particular debt | Debt-level counters and histories |
| Attempt type | Answered and unanswered calls still affect contact pressure | Outcome labels that increment counts correctly |
| Conversation timing | A conversation changes when later calls are allowed | Immediate write-back of conversation events |
How the 7-in-7 rule works in practice
In practice, compliance teams need a rolling-window counter, not a weekly calendar shortcut. The system should look back over seven consecutive days for that person and that debt, count relevant calls, and decide whether another attempt is allowed. The counter should not depend on whether the campaign crossed a Sunday, whether one number changed, or whether the account was moved to another queue. A calendar shortcut may look fine in a dashboard while still miscounting the legal window.
That rolling logic becomes harder when call history sits in multiple tools. Many agencies still use one system for the dialer, another for call recordings, another for CRM notes, and a separate warehouse for reporting. AI adds yet another layer for voice outcomes. If the cadence decision depends on delayed data movement between those tools, the block may arrive after the call. That is why buyers should value near-real-time counters attached to call creation instead of overnight batch reporting.
The phrase “per debt” also deserves more attention than it gets. Agencies sometimes over-simplify by tracking at the consumer level only. That can create both under-contact and over-contact depending on the case. To stay close to the rule, the system needs to know which debt each call concerns and maintain that history cleanly even when multiple debts share the same consumer profile. Without that link, the counter can drift in either direction.
Finally, teams should document how special cases are handled. What if the debt is recalled and later replaced? What if the account was sold and then reloaded? What if the consumer had a conversation with a human collector, then the AI campaign resumed? Those are the scenarios that expose whether the dialer has a genuine cadence model or a thin rules wrapper.
Enter your email and we'll send you the FDCPA/TCPA/Reg F compliance checklist for AI voice deployments.
What counts as a "call" under Reg F
From a control standpoint, the safest design is to count broadly. If the dialer attempted the consumer's number and the call progressed far enough to create contact pressure, it should usually be counted. Buyers should be careful with vendor language that narrows the count too aggressively. Claims such as “ring-no-answer doesn't really count” or “voicemails are separate” may sound attractive because they preserve more calling volume, but they usually make the control system harder to defend.
Operationally, it helps to define outcome classes in advance. Answered call with right-party conversation. Answered call with no verification. Voicemail left. Live wrong-party answer. No answer. Busy. Network failure. Abandoned by platform. The point is not that each class is treated identically. The point is that the dialer should decide explicitly which classes increment the counter and why. Hidden or inconsistent treatment creates drift across campaigns.
AI makes this more complicated because the voice system can create states that older dialers did not track well, such as partial disclosure followed by hang-up or a short live interaction that never reached identity verification. Those states still matter for cadence design because they shape consumer experience and future call eligibility. A strong deployment treats them as structured events instead of dumping them into a generic “other” bucket.
When in doubt, buyers should ask for scenario tables and replay tests. If the vendor cannot show how each outcome affects the counter, your team will end up deciding those rules after launch, which is exactly when you have the least room for ambiguity.
How voicemails and abandoned calls are treated
Voicemails are one of the most misunderstood parts of cadence control. In practice, agencies should treat them as calls for counting purposes. A voicemail still reaches the consumer's number, still creates contact pressure, and still becomes part of the contact history a regulator, client, or court may review. The “but nobody answered live” argument rarely helps a team that already created a visible contact trail.
Abandoned or failed calls need explicit handling too. If the platform dropped the call after connection, if the AI failed before speaking, or if the workflow bailed out due to a mid-call error, the team needs a policy for whether that event counts and what remediation follows. Some failures should be excluded from the legal counter, but they should never disappear from the operational counter. If a platform bug caused a wave of dead-air calls, the compliance team still needs to see them even if a narrow legal analysis treats them differently.
The key is to separate legal count logic from operational risk logic without losing either. A mature dialer can store both: one field for whether the event increments the regulated count, another for whether the event counts toward internal campaign restraint. That gives teams flexibility while keeping the evidence set clean. Buyers should ask for this because it prevents false confidence built on under-counting edge cases.
What AI dialers typically get wrong
The first common failure is per-number counting. It feels intuitive because calls are placed to phone numbers, but the consumer may receive outreach across several numbers tied to the same debt. If the system only counts by number, the buyer gets a cleaner dashboard and a weaker control. The second failure is campaign-level counting that ignores debt identity. That can hide over-contact when accounts move across queues or vendors.
The third failure is delayed conversation recognition. If the human or AI conversation event takes hours to reach the counter, later calls can slip through during the waiting period. The fourth is poor voicemail handling, where the system stores the recording but does not increment the count. The fifth is weak auditability: the dialer blocked or allowed the call, but no one can later explain why because the reason code was not stored or because the calculation lived in a transient job.
There is also a release-management failure unique to AI-heavy systems. Teams change prompts, openings, or transfer logic without re-running cadence regression tests because they think those edits only affect language. In reality, those edits may alter when a conversation is tagged, when a voicemail is left, or when the workflow ends. That means the cadence layer can break from changes that looked purely conversational.
Procurement teams can surface these issues early by asking the vendor to walk through five call histories for one consumer across multiple numbers and debts. If the vendor cannot explain the count with confidence, the model behind the control is probably too loose for production collections.
Building cadence controls for Reg F compliance
A useful cadence-control design starts with a stable key for person and debt, then attaches every call event to that key before the next dial decision is made. The counter should be evaluated at call-creation time, not later. The decision should produce a reason code, whether allow, block for 7-in-7 cap, block for post-conversation waiting period, block for dispute, or block for client suppression. Those reason codes matter because they make QA and audit review much faster.
The next layer is testing. Agencies should maintain scenario tests for multiple numbers on one debt, multiple debts for one person, voicemail-heavy sequences, human-to-AI handoff cases, and queue transfers. Each release that touches outcomes, timing, or call-state logic should run those tests again. This may feel heavy compared with ordinary dialer administration. It is lighter than untangling why a bad release made thousands of calls that should have been blocked.
Finally, the cadence layer should be visible to non-engineers. Compliance managers need simple reports showing blocked attempts, top reason codes, accounts close to the cap, and any calls placed after a conversation that need review. A good system does not hide the control behind vendor support. It makes the logic inspectable so the agency can govern its own outreach.
One practical design choice is to keep a separate event ledger for cadence decisions rather than deriving them only from final call outcomes. In that ledger, each attempt writes a row with debt key, consumer key, number used, timestamp, event class, and whether the event affected the regulated counter, the internal counter, or both. That sounds technical, but it solves a very human problem: when compliance asks why one call was blocked on Thursday and allowed on Monday, operations can point to one clear history instead of reconciling several dashboards.
Another design choice is to build near-limit monitoring. Teams should not only see blocks after the cap is hit. They should also see accounts approaching the cap, scripts that produce more live conversations than expected, and queues where voicemail outcomes are rising. Near-limit reporting gives compliance teams a chance to adjust campaign strategy before the dialer starts living at the edge of the rule. Buyers who care about long-term operating stability should ask vendors whether this kind of monitoring exists or whether the product only exposes hard-stop outcomes.
The strongest programs also define ownership for exceptions. If a client asks for an unusual callback process, if a legal team approves a special workflow, or if a recalled account is reloaded after a period off-book, someone should own the cadence implications. Too many agencies assume the dialer will “just handle it,” then discover that the special case bypassed the normal counter path. A documented exception process, with approval and test evidence, makes the control system much harder to break by accident.
| Call scenario | Compliance status | Why |
|---|---|---|
| Seven unanswered attempts in six days on one debt | Next call blocked | The 7-in-7 cap has been reached |
| Voicemail left on attempt seven | Still counted | Voicemail should count toward contact pressure |
| Telephone conversation on day three | Later calls paused | Conversation starts the waiting period logic |
| Consumer has two phone numbers for the same debt | Counts combined | Per-number counting is not enough |
| Same consumer, different debt | Separate debt history required | The rule is tied to a particular debt |
| Control checkpoint | Question the system answers | Why buyers should care |
|---|---|---|
| At queue build | Is this account even eligible to enter the campaign? | Removes obviously ineligible records before dialer load |
| At call creation | Has the rolling 7-day count or waiting period been triggered? | Stops the call before it happens |
| At call completion | Did this event change the counter or waiting period? | Keeps later calls from slipping through |
| At release time | Did any logic change affect counting, conversations, or voicemail classification? | Prevents quiet regressions after prompt or flow edits |
| At audit time | Can the team explain every block and exception? | Turns compliance review into evidence work instead of speculation |
For buyers, the big takeaway is that Reg F readiness is not a single feature checkbox. It is the result of identity modeling, debt modeling, event modeling, and release discipline working together. Vendors that truly understand collections can walk through that stack calmly and specifically. Vendors that do not will stay at the level of “we support call caps.” In a regulated environment, that gap is larger than it sounds.
FAQ
What is the Regulation F 7-in-7 rule?
It is the limit on placing more than seven calls within seven consecutive days to a person in connection with a particular debt, plus an added waiting-period rule after a telephone conversation. For AI dialers, that means the counting model has to live at the person-and-debt level, not only at the campaign or number level.
Does a voicemail count as a call under Reg F?
For safe cadence control, yes. A voicemail still creates contact pressure and becomes part of the review trail. Teams should avoid designs that treat voicemail as invisible simply because the consumer did not speak live.
How should AI dialers track the 7-in-7 cap?
They should track calls per consumer per debt with rolling seven-day logic, immediate write-back of conversation events, and reason-coded blocks at call creation. Per-number counters and overnight reporting are usually too weak for machine-paced outreach.
What happens if you exceed the 7-in-7 limit?
The agency may face complaints, client pressure, internal remediation, and possible legal exposure. Because AI can repeat the same broken rule rapidly, exceeding the cap is often a systems issue rather than a one-off collector mistake.
Does Reg F apply to text messages and emails?
Regulation F reaches more than calls, but the 7-in-7 rule discussed here is about telephone frequency. Text and email still require their own policy, logging, and review logic. Buyers should not assume one channel's control model transfers cleanly to another.
Review Your Reg F Cadence Controls
If your dialer team is moving into AI voice automation, we can review counting logic, outcome mapping, and block reason design before launch.