Prospeo

Prospeo is one step in an email finding waterfall, not the whole of it. No provider covers a whole list, so the question is never which one is best. It is which order to try them in, and what to do with the rows the first one misses.

How I use it

Early in the waterfall, never alone. It runs first on rows that have a person and a company, and a second provider is gated to fire only where it came back with nothing. The result of each attempt is extracted into its own column, and a final column takes the first valid answer. Every step is visible, which is what lets you tell a bad provider from a bad input.

Charged on results, so a miss is cheap. Credits are only spent when it actually returns something, and repeated lookups of the same person cost nothing. That changes the economics of a waterfall: putting it early costs very little on the rows it cannot help with, so there is no reason to be clever about the ordering.

Verification is separate from finding. A found address is not a deliverable address. The verification result is what the send gate reads, not the presence of a string that looks like an email.

Its errors are the one class I ignore. When it runs out of credits it errors and does no damage. Every other enrichment error in a run gets investigated. That one gets left alone, because the alternative is disabling the column, and a disabled email finder is a person who never gets contacted.

What I have learned the hard way

A fallback gated on the word “success” skips the errors. I had a second provider set to fire when the Prospeo cell status contained “success”, which correctly caught the ran-and-found-nothing state. It did not catch out of credits, because that status does not contain the word. So exactly the rows where the first provider was unavailable were the rows that never got a second attempt, and they looked in every report like people with no findable email. The fix is to fire the fallback on any finished state rather than on a matched word.

A forced re-run does not override a gate. When the gate is wrong, re-running the column does nothing, because the condition is evaluated first. The gate has to be fixed and then the rows re-run. This is easy to misread as the provider being broken.

Never hand exclude a finder because you believe it is out of credits. I did that once, carrying a belief from an earlier session that was no longer true. It cost real people a real attempt. Letting a column run and error is free. Deciding in advance that it will fail is not.

Zero results and no attempt look identical downstream. Both leave the cell empty. Only the run status tells them apart, and an exported file does not carry it.