Why a generic validation ruleset fails at agency scale

Here is a conversation we have had more than once. An agency asks what our validation rules are. We ask which of their clients they mean. There is a pause, and then somebody on the call says “ah”.

An agency running campaigns for eight clients does not have one definition of a good record. It has eight. A Director of IT at a 500-person firm is a priority target for one client, an automatic reject for the second because their RFP says C-level only, and acceptable to the third but only with a verified street address in-region attached before they will take delivery.

Push all three through one shared ruleset and you get the worst of both directions at once: rows rejected that a client would happily have paid for, and rows delivered that come straight back at you in a delivery review. Neither failure is a data-quality problem. Both are a configuration problem.

What a curated rulebook changes

So we do not ship one ruleset. Every client gets their own workspace, and every workspace carries its own rulebook drawn from the same library of 60+ rules across 40+ data points, written with them before the first run and revised as their campaigns change:

• Which conditions remove a record — tenure limits, employment types, seniority floors, and how strictly company match is enforced.
• Which RFP criteria apply — job level, job function and industry, checked against that campaign's allowed list rather than a general one.
• Which suppression and unsubscribe files are in force, matched by email, domain and company name.
• Which extra columns are appended — verified address, headquarters addresses, residential location, live phone validation — because one client's mandatory field is another's noise.
• Where the threshold sits on scored records, which is a commercial decision rather than a technical one.

A platform of your own, and a rulebook written for your campaigns — not a seat in a shared tool with someone else's defaults.

Why this also matters for data handling

The same argument applies to the file itself, and this is the part procurement teams care about. An agency handing over a client's contact database is moving someone else's asset under contract. That is a materially different situation from an individual uploading their own list into a SaaS product, and it should not be treated the same way.

So the file is pulled from your SFTP on a schedule, or dropped into your own workspace by your own team. We do not upload it for you. It is used only to validate that campaign, it is never added to our database or used to enrich anybody else's file, and it goes when the campaign goes. The security page sets out retention, isolation and the control domains behind that.

The practical difference

The output is where you actually feel it. Because the rulebook is yours, the removals are defensible to the person you have to defend them to. Not “the tool rejected it” — which is an answer nobody has ever been satisfied with — but “removed, outside your RFP job level” or “removed, contact left the company in March”, written next to the row in the audit file.

That is the difference between handing over a cleaned list and handing over a decision you can stand behind in a delivery review. In our experience it is also the difference between a client who queries every invoice and one who does not.