Cost per replied lead, not cost per contact

Every outbound budget is quoted in the wrong unit. A contact database quotes per record, a seat licence quotes per person, a verification tool quotes per lookup - and none of them quote the only number that decides whether the channel works: what one reply costs you.

Why cost per contact is not the number

Cost per contact answers "how cheaply can I buy rows". It has no opinion on whether a row belongs to a person, whether the mailbox still exists, or whether anybody will answer. Two campaigns can pay exactly the same per contact and land at costs per reply that differ by an order of magnitude, because the money spent on addresses that bounce never had a chance to produce a reply.

The published numbers make the gap concrete: verified lists bounce 2-5%, static resold databases bounce 10-35% (TAPAC). On a 5,000-contact send that difference is the difference between roughly 100-250 dead addresses and 500-1,750 of them - every one of those paid for, exported, and never reachable.

The arithmetic, with the inputs you control

Cost per replied lead = price per usable contact ÷ reply rate. Both sides are yours to set, so the table below is arithmetic, not a benchmark:

Read it in the direction that matters: the price per contact moves the result by a factor of five, the reply rate moves it by a factor of five as well - but only one of the two can be improved by cleaning a list. That is the whole argument for paying for verification instead of paying for volume.

The same money, read as a seat

Published entry prices of the seat-based tools, converted to contacts at $0.30 each:

The point of the third and fourth columns is not that one side is cheaper. It is that a seat is paid for on a calendar and a contact is paid for on a decision: if the campaign pauses, the seat invoice does not, and those contacts were never looked up at all.

Three leaks that inflate cost per reply

1. Paying for records that bounce. At a 10-35% bounce rate you buy the dead addresses at the same price as the live ones. The correction is not a discount - it is checking the address before it enters the list.
2. Paying twice for the same contact. A contact database finds the address, a separate verifier confirms it, and the export has to be reconciled between the two. That is a second invoice for a step that can happen inside the search that found the address.
3. Paying for a stored snapshot. 23% of contacts change jobs every year (ZoomInfo, 2025) and 40% of addresses are dead within two years (NeverBounce), while fresh data outperforms stored databases by 42% (Harvard Business Review, 2024). A snapshot bought in January is not the list you are sending to in June.

How TAPAC returns a contact

One request finds the address and checks it over SMTP in the same call, so what you pay for is a contact with a state as of that moment - not a row from a snapshot. Each contact comes back with the source page or profile it was found on, which is what makes the list auditable later. Catch-all domains come back as unknown and are never folded into the usable count.

npx -y @tapacapi/mcp        # tools: tapac_find_contacts, tapac_status
# or hosted: https://tapacapi.com/mcp
# or REST:   POST https://tapacapi.com/v1/contacts/search

100 free searches to start, then $0.10-0.50 per verified contact, pay-per-use. See also what a verification actually costs and what a verification log has to record.