Who this was forA mid sized B2B provider selling into several enterprise verticals, with outbound running on two channels.
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 had the same problem. Every campaign bought a new list. There was no reusable pool and no dedupe across purchases, so the same person could be paid for twice.
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.
Suppression, eligibility, and attribution are now queries. Before, each one was a manual export.
Two honest gaps. Two tables we planned have zero rows, so those surfaces are unused. And a queue failure needed a repair pass along the way. We haven't worked out the cost per pooled person yet either, so we're not claiming a saving.
Both systems run unattended in the client's database. We operate and extend them. If we left tomorrow, the data stays.
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
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 September 21, 2026