Prospeo: What It Does, and Why It Sits Second in Our Waterfall

Prospeo is the second stage of the email waterfall we run. The published order is MillionVerifier brute-force first, then Prospeo, then Findymail, with no fourth paid stage. That is a policy statement rather than a recommendation, and it is worth opening with because it sets the terms of everything below: we use this tool, so we can tell you exactly why it sits where it sits, and we are not going to publish performance numbers to justify the placement.

This page covers what Prospeo does, the property that decides its position in a sequence, what its pricing page will and will not tell you, and how to evaluate it against rows you already hold.

What Prospeo is

Prospeo is a B2B contact-data platform. Its own site describes the surface as people and company search, an email finder, mobile-number lookup, domain-level contact discovery, CRM and CSV enrichment, intent signals, a Chrome extension, an API and an MCP server for connecting AI tooling.

The part relevant to an outbound stack is narrow: given a person and a company, return a work email address. Everything else on that list is adjacent product surface, and a team can use the finder without touching any of it.

The property that decides where it belongs

The reason a finder sits at a particular point in a sequence is rarely coverage. It is usually a behavioural property that changes what a miss costs you.

The property that matters here, and the reason our published order puts Prospeo where it does, is that it only returns addresses on the domain we asked about. A miss comes back as a miss rather than as a plausible-looking address at some other company.

That sounds like a small distinction and it is the most consequential one in this whole category. There are two ways a data provider can fail, and they cost you completely different things.

A missCheap and visible

• No address is returned for the row
• The row falls through to the next provider
• You know exactly which rows failed
• Costs a lookup and some latency

A wrong matchExpensive and invisible

• A real, deliverable address is returned
• It belongs to a different person or company
• It passes every verification check you run
• Costs you the prospect, and sometimes the domain

A wrong match is the failure nobody instruments. The address exists, the server accepts it, the verifier says it is fine, and nothing in your open, bounce or reply data distinguishes it from a correct one. The only way to detect it is to audit the domain of each resolved address against the company the row claimed, which is a check almost nobody runs and which we do run.

A provider constrained to the domain you asked about cannot produce that class of error in the first place. That is a structural guarantee rather than a quality claim, and structural guarantees are worth more than percentages because they do not vary with your market.

What we will not publish

We use this tool, which means we hold operational data about it, and we are not going to print that data here.

Our hit rates, match rates, cost per resolved address and any comparison of one stage against another are internal figures produced on our own lanes with our own ICPs. Publishing them would be publishing a number that looks like a benchmark and is actually a description of our client mix. That is exactly the kind of figure this category is full of and exactly the kind we decline to add to.

What we do publish is the policy: the order we run, why the order is what it is, and the fact that there is no fourth paid stage because past the third provider the marginal cost per additional address climbs while quality falls. The reasoning is set out in full in our waterfall enrichment guide.

What its pricing page will tell you

Less than you would like, if you are fetching it rather than browsing it.

Prospeo's pricing page renders its plan table in the browser rather than serving it in the HTML. A plain request returns a document containing the site chrome and no plan names, prices or credit allowances at all. We do not quote figures we could not load ourselves, so there is no ladder reproduced on this page.

One figure is verifiable from the vendor's own served markup: the email finder page's title reads "Email Finder - Get 100 Free Credits", so a free allowance of 100 credits is published in bytes rather than only in a rendered table.

For the rest, two routes. Open the vendor's pricing page in a browser, where the plan table renders normally. Or read our guide to email finder tools, which recorded the ladder and the per-credit arithmetic at the time it was written, with the date attached. Prices in this category move, so treat any figure with a date on it as a reading rather than a fact, including ours.

Where a finder sits relative to a verifier

The most common sequencing mistake is running a finder first and a verifier afterwards on everything it returns.

Verification is roughly two orders of magnitude cheaper per operation than finding. Running a cheap bulk verifier across every address you already hold, before you pay any finder anything, resolves a large share of a list at a fraction of the cost and leaves the finder to work only on genuine gaps. That is why our order starts with a verifier rather than a finder, and our page on MillionVerifier covers what a bulk verifier's result buckets actually mean.

1. Step 1MillionVerifier brute-force

   Check addresses we already hold before paying any finder. Verification costs a fraction of a lookup, so this stage removes the cheapest rows first.

2. Step 2Prospeo

   Resolve the genuine gaps. Returns are scoped to the domain asked about, so a miss arrives as a miss rather than as somebody else's mailbox.

3. Step 3Findymail

   The final finding step, seeing only what the previous two stages could not resolve.

4. Step 4Bank the tail

   No fourth paid stage. Accept-all and unresolved rows are preserved rather than guessed at, and volume comes from fresh sourcing.

The limit of that approach is accept-all domains, where a server accepts mail to every address so any address verifies and no service can evidence a specific mailbox. Our position is that the catch-all tail gets banked as a preserved artifact rather than mailed, and volume comes from fresh sourcing instead. The mechanics are in our guide to email verification tools.

What a stage in a sequence is actually being asked to do

It helps to be precise about the job, because the way finders are marketed obscures it.

A provider running alone is being asked to resolve as many rows as possible, and coverage is the whole story. A provider running as a stage in a sequence is being asked for something narrower: resolve the rows the previous stages could not, without introducing errors the later stages will inherit. Those are different jobs and they reward different properties.

The second job is why a provider with lower raw coverage can be the better middle stage. Anything it resolves is removed from the list before the next, usually more expensive, stage sees it. Anything it declines to resolve costs nothing beyond the lookup and passes cleanly downstream. Anything it resolves incorrectly, though, is worse than useless, because the row leaves the sequence looking finished and no later stage will ever re-examine it.

That asymmetry is the argument for evaluating providers on correctness before coverage when you are designing an order, and for treating raw hit rate as the least informative number a vendor can hand you.

Evaluating it yourself

Nothing above tells you whether this tool works on your market, and no page can, because coverage varies by geography, seniority, company size and how recently people moved jobs.

The test that answers it takes an afternoon. Take 300 to 500 rows where you already hold an independently verified address. Run them through every provider you are considering, on the same day, using the same rows. Then score three things separately: how many resolved, how many matched the address you already held, and how many came back on an accept-all domain. Judge on cost per correct address rather than hit rate.

Run the domain-agreement audit as part of it. Compare the domain of each resolved address against the company the row claimed, and read the disagreements by hand. That is the only step that surfaces wrong matches, and it is the step that should decide your ordering. A provider that misses more but never mismatches usually belongs earlier in a sequence than one with better raw coverage.

If you are comparing against vendors that bill only for deliverable results, our pages on Skrapp and Voila Norbert cover two of them.

The short version

Prospeo is a B2B contact-data platform whose email finder is the second stage of the waterfall we run, after MillionVerifier brute-force and before Findymail, with no fourth paid stage. The property that earns that position is that it returns addresses only on the domain asked about, so a miss arrives as a miss rather than as a deliverable address belonging to somebody else, which is the failure mode no verification check and no delivery metric will ever show you. We hold operational data on it and deliberately do not publish hit rates or stage comparisons, because those figures describe our client mix rather than your market. Its pricing page renders in the browser, so a fetch returns no plan table; the free allowance of 100 credits is published in the vendor's own page title.

If you would rather see the whole motion running on your own ICP without assembling a data stack first, start a free campaign and we will build the list, the copy and the sending infrastructure around it.

Pricing and features verified as of August 2026. Verify current terms with the vendor before relying on them.