The direct answer
Cost per sales-ready B2B account is the total cost of producing an account that passes your written acceptance gate for its named next action—not the price of a row, credit, email, or database search. Include discovery, research, contact lookup where needed, reviewer time, tool cost allocated to the pilot, and rework. Divide by accounts that were accepted with the evidence required for that action.
The formula is deliberately simple:
cost per sales-ready account = (discovery + research + contact lookup + review labour + allocated tooling + rework) ÷ accepted accounts
It is not a forecast of pipeline or revenue. It is a way to discover whether a cheap input creates expensive rejection and cleanup later.
1. Define “sales-ready” before calculating
The acceptance gate should be stricter where the next action is costly or irreversible. Do not lower it after seeing a disappointing denominator; report both the number selected and the number accepted.
2. Capture every cost component
Use stable IDs so discovery, research, decision, reviewer time, and later returns can be joined. A person’s name is not a stable test key.
3. Keep two denominators visible
Suppose a pilot selects 120 candidates. It spends €300 on access/research, €540 in reviewer time, and €160 in attributable tooling. Eighty accounts pass the written handoff gate.
- Total pilot cost = €1,000.
- Cost per selected candidate = €1,000 ÷ 120 = €8.33.
- Cost per sales-ready account = €1,000 ÷ 80 = €12.50.
Both numbers are useful, but they answer different questions. The first shows intake cost; the second shows the cost of a usable outcome. Report no-result, review, and rejection shares beside them. Otherwise a low cost per row can hide a weak accepted yield.
Use a transparent input ledger
Replace every example input with your own verified pilot values. This ledger is planning arithmetic, not a Leadbase ROI claim; it must not be used to infer pipeline from unmeasured conversion rates.
Download the sales-ready account cost ledger. It contains a non-zero illustrative row: 30 review minutes at a fully loaded hourly cost of 60 contributes 30 to total cost, because the formula divides minutes by 60. Replace the illustrative inputs with measured values, then duplicate the entire candidate row—including the formulas in row_total_cost and accepted_count—for every added candidate. Insert copied rows above pilot-summary; do not type over the summary row. Include rejected rows and no-results, then calculate only after preserving the linked decision and review time. The summary calculates total pilot cost, selected count, accepted count, cost per selected candidate, and cost per sales-ready account. The values are illustrative, not a benchmark or pricing estimate. Keep the ledger alongside the test protocol so a different method cannot quietly use a looser acceptance gate.
Calculate cost per sales-ready account
Calculate fully loaded cost per selected and per sales-ready account without dropping rejected or no-result rows from the numerator.
Accepted accounts are capped at selected accounts. All direct, reviewer, and rework costs remain in the numerator even when a row is rejected or returns no result.
The pilot costs €3,300.00 across 100 selected accounts and 40 accepted accounts. Rejected and no-result work remains included.
| Unit-economics measure | Result |
|---|---|
| Selected accounts | 100 |
| Accepted accounts | 40 |
| Direct costs | €1,800.00 |
| Reviewer labour | €1,200.00 |
| Rework costs | €300.00 |
| Total pilot cost | €3,300.00 |
| Cost per selected account | €33.00 |
| Cost per sales-ready account | €82.50 |
The cost mix keeps reviewer labour and rework visible beside direct tool and data costs.
Reviewer labour equals total review minutes multiplied by the loaded hourly cost and divided by 60. Total pilot cost adds direct costs, reviewer labour, and rework. Cost per selected uses every selected account; cost per sales-ready account divides by accepted accounts only.
This is an input-only planning model, not a Leadbase price, benchmark, ROI promise, or forecast. Use one currency and document allocation rules before comparing providers or workflows.
4. Run sensitivity before you choose a process
Change one input at a time: accepted yield, reviewer minutes, field cost, and duplicate rate. Ask which input moves cost per accepted account most. This tells you whether to improve account definition, source quality, review design, or enrichment selection.
For example, halving a €1 per-row lookup may matter less than reducing 15 minutes of avoidable review on a rejected account. Conversely, a stricter account gate can raise the headline cost per accepted account while lowering costly downstream waste. The model does not decide the trade-off; it makes it explicit.
5. Compare methods fairly
Use the same ICP, time window, answer key, acceptance gate, and reviewer protocol for every method. Include rework and no-result. Do not compare a polished vendor sample with a routine self-service workflow, or a raw database export with a source-reviewed shortlist. For a complete supplier evaluation, pair this unit-economics model with the two-stage European provider-test protocol.
6. Freeze a small test protocol before anyone sees the result
An economic comparison is only as fair as its starting conditions. Write a one-page protocol before the first candidate enters either process. It does not need to be complex, but it needs to make later changes visible.
Record exceptions rather than silently fixing them. If a candidate turns out to be the wrong legal entity, mark the reason and apply the same entity rule to both methods. If a reviewer is unavailable, note the substitution. An honest protocol allows you to say what the test did and did not establish: it measures the defined workflow in a defined segment, not every customer, geography, or future quarter.
A useful pilot sequence
- Freeze a candidate list and an answer key for the account rule.
- Assign anonymous method labels if the team can do so without disrupting the workflow; this reduces the temptation to review one source more generously.
- Capture actual spend and minutes as work happens, not from memory at the end of the week.
- Review records against the same acceptance gate before comparing costs.
- Reconcile duplicate entities, no-results, and retries before calculating denominators.
- Publish the ledger, protocol version, and unresolved exceptions together.
This is deliberately stricter than comparing prices on a procurement page. A lower price per credit can coexist with more reviewer work, higher rejection, or hidden rework. Conversely, a more expensive input can be justified if it changes a measured acceptance or labour outcome. The ledger helps make that trade-off testable; it does not decide it in advance.
7. Use an illustrative worked example, then replace every input
The following scenario is illustrative arithmetic, not Leadbase performance, vendor pricing, a benchmark, or a promise. A team evaluates two internal research methods for 100 preselected accounts in the same segment. Both use the same account rule and handoff gate.
The result is not “Method B is universally better.” It says that, in this fictional pilot, Method B produced more accepted accounts with less measured total cost. A responsible reviewer would still ask whether both methods had the same freshness standard, whether contact lookup was required for every accepted account, and whether the sample represents the work the team expects next month.
The example also shows why direct price is a weak proxy. Method B has more direct research and contact spend (€315 versus €220), yet it has lower total cost because the illustrative review and rework costs are lower. If those minutes were estimated rather than recorded, the apparent advantage would not be credible. Replace every number with your own observed cost and preserve the calculation, rather than copying the conclusion.
8. Measure labour, retries, and no-results without hiding the work
Review time is often the largest untracked component. Use a simple start/stop or sampled-time method, but apply it to both methods. Record the activity as well as the minutes: entity resolution, evidence review, duplicate merge, role clarification, accepted handoff, rejection reason, and rerun. That lets a team improve the costly step rather than arguing about a single blended total.
Treat a no-result as an observed outcome, not zero work. It may have a direct request cost, reviewer minutes, or a follow-up research task. Record whether it happened before or after the account passed its gate. Do not turn it into an accepted record merely because an account could still be worked manually.
Retries need their own rule. A retry caused by a temporary technical failure may be attributable to the same research attempt; a retry caused by a vague field definition is usually process rework. Whichever rule you use, define it up front and retain the reason. Otherwise one method can look efficient by moving its failures outside the pilot ledger.
9. Add decision thresholds, not invented ROI
Before the test, decide what action each result could support. A team might choose to continue a method only if the cost per accepted account remains within a stated pilot budget and the accepted records meet a minimum evidence standard. Another team may accept a higher cost for a strategic country where coverage is harder. These are business choices, not universal thresholds that this guide can supply.
Use a small decision table:
If the sample is small, say so. Do not calculate false precision from a few records or present a one-week pilot as a universal rate. Repeat the protocol on another predeclared segment when the first test would drive a material buying, staffing, or process decision.
10. Read the ledger as a process-improvement tool
The useful question after a pilot is not only “Which method cost less?” Ask where accepted accounts were created or lost. A high duplicate share points to entity-resolution design. A high “missing evidence” rejection share points to the research brief or source rule. Long review minutes on otherwise good accounts may justify simplifying the handoff packet. Low contact availability may be a role-hypothesis problem rather than a data-provider problem.
Make one change per retest where possible. If you change the ICP, reviewer, required fields, allocation rule, and tool at once, the new total cannot teach you which change mattered. Keep previous versions of the cost ledger and note the change made. This gives the sales-operations or research owner a traceable record instead of a retrospective slide with unexplained totals.
Why Leadbase changes the unit economics
Data-provider offers commonly foreground price per credit, record, or seat. The expensive part can sit elsewhere: accounts that never matched, fields nobody used, no-results that still required review, and sales time spent discovering that a “lead” was not ready. A price-per-row comparison does not capture those costs unless the buyer measures them separately.
Leadbase changes more than the measurement unit. It changes when the team pays the expensive parts of the workflow. The product can discover candidates by meaning, research the custom conditions that decide fit, qualify the accounts, and only then add the relevant decision-makers. The useful unit is therefore the account that passed your own sales-readiness rule, not a row that happened to exist in a database.
Cheap data is not cheap when your team pays downstream to discover that it never fit. Leadbase moves custom qualification before contact cost and rep time.
Selected-row enrichment also lets the team limit which rows enter a run instead of researching every candidate by default. A no-result can still have a measured research cost, so it belongs in the numerator; the product does not promise automatic row-level cost attribution, which is why the accompanying ledger keeps those inputs explicit.
Leadbase does not promise a universal cost advantage, conversion rate, or ROI. The shared Sheet and ledger let you test whether this earlier qualification actually reduces waste in your segment instead of inferring savings from a price page. Test a controlled sample and compare cost per accepted, contact-ready account—not cost per delivered row.
Keep the calculation decision-safe
Keep source invoices, run dates, time records, the acceptance file, and the ledger version together. A result is decision-safe only when another reviewer can trace a displayed total back to its inputs and see which rows were excluded. Round presentation figures only after calculation, retain the unrounded inputs, and state whether tax, currency conversion, or shared-team overhead is included. If a cost cannot be measured, label it as unknown rather than silently setting it to zero.
For a material supplier or process choice, have someone who did not build the ledger review a small sample of accepted and rejected rows. They should be able to reproduce the denominators and challenge the allocation rule without needing to agree with the preferred outcome. That check is more valuable than an overly precise spreadsheet total.
Check three common calculation errors
Wrong denominator: Dividing cost only by returned contacts or only by the best subgroup changes the question. The denominator here is accepted accounts after the predeclared gate.
Mixed time period: Charging a full annual contract to one pilot week, or hiding it entirely, makes a comparison arbitrary. Document the time-bound allocation and use the same rule for both methods.
Omitted rework: Manual entity resolution, stale-source review, duplicate correction, and follow-up questions can appear later but are still part of the process cost. Record them with date and reason. If they happen after the pilot, label them as follow-on work rather than erasing them from the record.
When a second test is needed
Repeat a pilot when a change to the offer, country, ICP, required field, or acceptance gate materially changes the work. A result from one scoped segment can support a reasoned next sample; it cannot support a general claim about every market. Predeclare the second sample and change only one documented factor per retest where possible. That turns the economics work into a traceable learning loop rather than a one-off justification number.
The question behind the metric
The metric does not answer how valuable an account will become. It answers only which measurable resources were needed for an account to pass today's defined handoff for its named next action. Keeping that boundary visible lets a team discuss cost, quality, and strategic priority separately instead of using one number as proof of pipeline or product superiority.
Calculation checklist
- Acceptance gate and test IDs are frozen before the run.
- Selected candidates and accepted accounts are separate denominators.
- Labour and rework are measured, not assumed away.
- Costs are allocated fairly to the pilot.
- No-result and rejection shares are reported.
- Sensitivity identifies the biggest economic driver.
