Compare the total cost with unique, approved contacts. A cheap lookup can be expensive if it returns duplicates, poor-fit accounts or unresolved data.
The cheapest first step may not produce the cheapest list
A lookup price tells you what an operation costs. It does not tell you how many useful contacts you will receive. To compare enrichment workflows, define the output first: a unique contact at a fitting account, in a relevant role, with acceptable data and an approved use. Everything else belongs in a separate outcome bucket.
This article uses invented figures to demonstrate the calculation. They are not Sync Scala prices, provider quotes, measured conversion rates or expected results. Replace each input with your own billing records and accepted-contact counts. Without that separation, a tidy calculator can make an untested assumption look like an operating forecast.
Understand what the waterfall stops on
Clay's Waterfalls documentation describes a sequence of providers used to find a data point. Its separate Actions and Data Credits documentation illustrates another distinction: workflow activity and purchased data can be metered separately. These sources explain Clay's model, not Sync Scala's pricing. Always inspect the actual product and provider terms instead of assuming one credit has the same meaning everywhere.
For your own comparison, ask when a stage stops. Does any returned value prevent the next lookup, or only a result meeting an agreed quality rule? What happens to an unknown verification result? Can a retry be charged? Can the same contact appear twice? Write these rules down before testing provider order, because changing them changes both coverage and cost.
Work through one transparent example
Suppose a fictional batch starts with 200 unique contacts. Provider A is charged at £0.04 per attempted lookup and returns 100 accepted contacts, so that stage costs £8. Provider B receives only the remaining 100 contacts, costs £0.08 per attempt and returns another 40 accepted contacts, adding £8. The two lookup stages cost £16 and produce 140 accepted contacts before the final review.
Now suppose verification costs £0.01 for each of those 140 results, or £1.40, and 20 fail the final acceptance rule. You have spent £17.40 for 120 usable contacts. Variable data cost per usable contact is therefore £17.40 divided by 120, or £0.145. Dividing by the original 200 inputs would produce a lower number, but it would answer a different question.
- Variable cost per usable contact = lookup and verification spend / unique accepted contacts.
- Incremental stage cost = additional stage spend / additional unique accepted contacts.
- Keep attempted, returned, duplicate, rejected and accepted counts separate.
- Use the billing rule actually applied, whether it charges for attempts, results or another unit.
Add the costs your spreadsheet usually misses
Continuing the fictional example, allocate £30 of platform cost and £20 of manual review effort to the batch. Fully loaded batch cost becomes £67.40. Divided by 120 usable contacts, that is about £0.562 each. These allocations are management choices, so document them. Do not mix a marginal quote from one supplier with a fully loaded number from another.
Review time matters particularly when data needs repair. A low-cost provider that frequently returns ambiguous companies can create work outside its invoice. Keep minutes spent resolving duplicate identities, replacing wrong domains and checking missing fields. You do not need a complicated financial model; a consistent time estimate is more useful than pretending the work is free.
Set the stop rule before the run
A third provider may recover difficult records, but the extra contacts can cost more than the easy ones. Evaluate that stage on its incremental accepted results, not on the blended average from earlier stages. Decide in advance what marginal cost, unresolved-result rate or maximum spend would make you stop. A budget that appears only after execution is not a control.
Test on a consistent, deduplicated sample and preserve the sequence used. If you compare different audiences, one provider can look better simply because its test contained easier records. Do not run expensive steps against already accepted contacts unless you deliberately need an independent check and have budgeted for it. Coverage is useful only when the additional data serves the campaign.
Keep commercial outcomes downstream
After outreach, add cost per qualified conversation and cost per opportunity as separate measures. Do not call every exported row a sales lead or every reply a buying signal. Data quality, targeting, offer and outreach execution affect different parts of that funnel. Keeping them separate tells you what to fix.
Sync Scala's cost records are intended to make enrichment activity reviewable. Actual availability and cost depend on configured integrations and the operations performed. Before approving a run, check the displayed scope and budget, then compare its receipts with the accepted output. The useful question is not how cheaply you can fill a spreadsheet. It is what you paid for a list your team can responsibly use.
Sources and further reading
Prepared with AI assistance and checked against the linked sources. Examples are illustrative, not customer results. See our editorial standards or request a correction.