A prospect database that lives in the client's own estate

The problem

Prospect state was spread across two sequencers, a CRM, and a pile of exports. Nobody could answer a simple question fast: who have we contacted, on which channel, in which campaign, and what happened?

Sourcing worked campaign by campaign. Every campaign bought a new list, with no reusable pool and no dedupe across purchases.

What we built

Two things, both inside the client's own database, not ours.

The first is a prospect table with activity per prospect, membership per campaign, platform state mirrored in, and duplicate detection.

The second is a prospect engine. It holds seed companies and a people pool with a dedupe registry. It also has a find people queue with provider rates, cooldowns, and a spend log.

What it produced

• More than 35,000 prospects in one table, with more than 55,000 logged activities and more than 27,000 campaign memberships.
• A reusable pool of more than 75,000 people, alongside more than 85,000 companies.
• The prospect table grew about 13 percent in four weeks.

Suppression, eligibility, and attribution are now queries. Before, each one was a manual export.

We haven't worked out the cost per pooled person yet, so we're not claiming a saving.

What runs now

Both systems run unattended in the client's database. We operate and extend them. If we left tomorrow, the data stays.

Your scenario

If your prospect history lives in three tools and a folder of CSVs, start with the one table. Tell us which tools you're running and we'll sketch what goes in it.

Related tools: Clay, Prospeo, Prospect Engine, Suppression Architect, Prospect Engine on the Apify Store, People Finder & Email Verifier on the Apify Store, People Finder & Email Verifier

Some of the links on this page are affiliate links.

Client names are always kept confidential at MMG, so they have been removed from this case study.

Published September 21, 2026

Last updated November 2, 2026