Here's the timing problem nobody warns you about: a lot of people treat litigator scrubbing like list hygiene. Something you run on a schedule, alongside deduping and removing bad formats. Monthly, maybe weekly if you're diligent. Clean the list, keep it fresh.
That framing is wrong, and the reason is legal, not operational. The violation isn't having a TCPA litigator's number in your database. It's sending them a text. Once the message goes out, the exposure exists — and no amount of after-the-fact cleanup undoes a send that already happened. A scrub that runs Tuesday does nothing for the blast you sent Monday.
Full disclosure: I work for Ready, and we sell a standalone litigator/DNC scrub at $0.005 per contact. So I have a stake here. But the timing logic holds regardless of whose scrub you use — run it before the first send or it isn't protecting you.
The violation is the send, not the storage
TCPA statutory damages run $500 per message, and up to $1,500 if the violation is found willful. That's per text. Not per campaign, not per contact — per message.
So walk the timeline. You import a list on Monday. It contains three known litigator numbers you don't know about yet. You fire a 5,000-contact blast Monday afternoon. Those three people receive a text. Monday evening, your scheduled scrub runs and flags all three.
The scrub worked perfectly. It's also useless. The three messages already landed. Best case you're looking at $1,500 in statutory exposure; if the sends are ruled willful, $4,500 — and litigators in these lists are, by definition, the people most likely to file. That's the whole reason their numbers are on the list.
Cleaning after the send removes them from your next blast. It does nothing for the one that already triggered liability.
We covered the per-text math from the wholesaler angle in One Cold Text to a Skip-Traced Number Can Cost $500 to $1,500 — the same numbers apply here, just further upstream in your process.
How litigator numbers get into your list in the first place
If you built your list entirely from your own opt-ins, your litigator risk is low — someone who opted in generally isn't the person suing you. The problem is that most people aggregating lists at scale aren't working with pure opt-in data.
Numbers enter a list through:
- Skip tracing. You pull a property record, run the owner through a skip-trace vendor, get back three phone numbers of unknown provenance. No consent, no idea who's litigious.
- Purchased or rented lists. Someone sells you 40,000 "verified" contacts. Verified means the number connects, not that the person wants to hear from you — and not that they aren't a serial TCPA plaintiff.
- List aggregation across sources. Agencies merge client uploads, form fills, and third-party data into one sending pool. Every merge is a fresh injection of unknown numbers.
- Seeded lists. Some litigators deliberately plant their numbers into commonly-traded lists to catch senders. This is a known tactic, not paranoia.
The common thread: the risky numbers arrive at import, in a batch, from a source you don't fully control. Which is exactly why the scrub has to gate the import, not chase it.
Why "periodic cleanup" is the wrong mental model
Periodic scrubbing makes sense for things that decay over time — numbers that get reassigned, contacts who churn. Litigator status isn't like that. A litigator number is dangerous the instant it enters your list, and it's most dangerous on the first send, because that's usually your coldest, largest blast to a freshly-imported batch.
Think about the exposure curve. A weekly scrub leaves a gap of up to seven days between "number enters list" and "number gets flagged." If you send during that gap — and you almost certainly will, because you imported the list to send to it — the scrub never protected you at all. It's a fire extinguisher you check after the building burns down.
The fix is a workflow change, not a tool change: scrub is a step in your import pipeline, positioned before any send is possible. Import → scrub → suppress matches → then the list is sendable.
What a scrub actually checks (and what it doesn't)
Ready's standalone scrub runs each number against two things:
- Known TCPA-litigator lists — people with a documented history of filing.
- DNC-complainer lists — numbers that have generated do-not-call complaints.
Matches are auto-suppressed before send. You pay $0.005 per contact scrubbed — pay only for what you run, no subscription.
Be clear about the limits, because I'm not going to tell you a scrub makes you lawsuit-proof:
- It catches known litigators. A first-time plaintiff isn't on any list yet.
- It doesn't create consent. Scrubbing a number clean doesn't mean you're allowed to text it — you still need a lawful basis to message.
- It's one layer. It pairs with quiet-hours enforcement, opt-out handling, and consent capture. No single control is the whole defense.
A scrub reduces the concentration of the highest-risk numbers in your list. That's the honest claim. The sender is still ultimately responsible.
The math: scrub cost vs. one flagged send
Here's why the timing decision is easy once you price it. Suppose you import 5,000 skip-traced contacts.
| Item | Cost |
|---|---|
| Scrub 5,000 contacts @ $0.005 | $25.00 |
| Ready Standard send, 5,000 × 1 segment @ $0.02 + $0.0045 carrier | $122.50 |
| Total to scrub + send clean | $147.50 |
Now the alternative. You skip the pre-send scrub, blast all 5,000, and the list contained just two litigator numbers:
| Item | Cost |
|---|---|
| Send, 5,000 segments | $122.50 |
| 2 messages × $500 statutory minimum | $1,000.00 |
| Total if two flagged numbers slip through | $1,122.50 |
And $1,000 is the floor. Willful findings triple each to $1,500. The $25 scrub is roughly 2% of the cost of a single willful violation. On a 5,000-contact import, one flagged number pays for the scrub 40 times over. There is no volume at which skipping the pre-send scrub is the rational bet.
Where this fits in a real import workflow
For an agency or wholesaler moving lists constantly, bolt the scrub into the pipeline so it's not a decision anyone makes per-list:
- Import lands in a staging pool — not directly into a sendable segment.
- Scrub runs automatically on the staged batch. Matches are suppressed, flagged, and logged.
- Consent/attestation is recorded for the surviving contacts, building an audit trail.
- Only then does the batch become sendable, with quiet-hours enforcement and STOP handling already live.
For GHL agencies juggling client sub-accounts, this matters more, not less — every client upload is a separate injection of unknown numbers, and you're the sender of record. If you're mapping sends across locations, 50 GoHighLevel Sub-Accounts, 50 Separate 10DLC Registrations covers how the sender identity works across sub-accounts — which is exactly whose name is on the exposure.
And if your lists are cold to begin with, scrubbing is necessary but not sufficient. Consent is the bigger question, and the cold-text consent reality is worth reading before you send to anything skip-traced at all.
The practical takeaway
Litigator scrubbing isn't hygiene you do on a schedule. It's a gate that has to sit in front of the send, because the violation is the text going out — and once it's out, no cleanup reverses it.
Move the scrub to the import step. Make it a required stage, not a periodic job. At $0.005 per contact it's cheap enough that there's no import size where running it first isn't obviously correct, and the moment one flagged number would've slipped through, it's already paid for itself many times over.
If you want to wire this into your sending flow, the scrub, quiet-hours, and consent capture all live in the same place — you can see how it fits on the Ready SMS product page, or start with 2,500 free credits and scrub a test batch before you send a single message to it. That order — scrub, then send — is the whole point.