How accurate is Swordfish? A cynical buyer’s connect-rate test (with variance)

Definition (buyer-grade): Outcome-based accuracy = connect rate (did the call connect) + right-party answer outcomes (did you reach the intended person), segmented by mobile vs direct dial and by recency.

Byline: Ben Argeband, Founder & CEO of Swordfish.AI

Author note: Buyers don’t experience “accuracy” as a percentage on a slide. They experience it as reps reaching the right person. This page defines accuracy as outcomes (connect/answer), explains why results vary (recency, list quality, seats, API/integration), and shows how to test Swordfish without paying for stale data and integration drift.

Who this is for

This is for prospects comparing Swordfish who want a credible way to judge data quality without marketing math. It’s also for operators who have already paid for stale numbers, “verified” labels that didn’t translate to an answer rate, and integrations that quietly stopped refreshing.

If your definition of success is “we exported a CSV with lots of rows,” you’re optimizing for the wrong thing. If your definition is “our reps reached the right person and booked meetings,” this is the evaluation method.

Quick verdict

Core answer

How accurate is Swordfish depends on the outcome you measure. Use connect rate and right-party answer outcomes on a controlled sample, not “records returned.” Swordfish is designed to improve reachability using ranking and verification signals, but your results will vary with recency, list quality, and how you integrate and refresh.

Key measurement

Report outcomes by segment: mobile vs direct dial, ICP slices (industry/region/seniority), and data age (recency). A single blended “accuracy %” hides the variance that drives cost.

Ideal user

Teams that care about accurate mobile numbers and direct dials for outbound, and want an evaluation that exposes hidden variance from seat count, API usage, list quality, and industry.

What Swordfish does differently

Most contact tools optimize for coverage because it demos well. Buyers pay later when reps dial dead numbers and ops teams spend weeks figuring out why “verified” didn’t mean reachable. Swordfish is designed to improve reachability by ranking returned numbers and applying verification signals so reps start with the best candidate first.

We won’t give you a universal accuracy percentage because it varies by list quality, industry, and refresh cadence. If a vendor insists their number is “the” truth, they’re usually averaging away the segments where you’ll bleed time.

Ranking + verification improve reachability. In practice, this means Swordfish can present ranked mobile numbers or prioritized direct dials so your team doesn’t waste the first attempt on the worst option. The business outcome is fewer wasted dials and more conversations per rep-hour.

True unlimited + fair use. A lot of “accuracy” arguments are really usage arguments. If your plan forces you to ration lookups, you refresh less often, and your data decays. Swordfish’s unlimited contact credits approach (with fair use) is meant to remove the incentive to under-refresh. The business outcome is straightforward: higher refresh frequency reduces the share of stale numbers you dial.

If you want a fast proof point instead of a vendor narrative, use reverse search on a small set of contacts you can independently confirm. It won’t prove global accuracy, but it will catch obvious mismatches before you waste time on a full rollout.

Decision guide

What buyers really mean by “accurate”: not “did the tool return a phone number,” but “did we reach the intended person.” That’s outcome-based accuracy, and it’s the only definition that maps to revenue activity.

Use this method to evaluate data accuracy without getting fooled by coverage stats. It’s designed to surface variance and integration failure modes that show up after procurement, not during the demo.

How to test with your own list (7 steps)

1. Define outcomes up front. For calling, track connect rate (call connects to a working line) and right-party outcomes (intended person or their business line). Keep answer outcomes separate from connect outcomes so you don’t confuse “working number” with “right person.”
2. Build a controlled sample. Pull 200–500 contacts from your ICP. Split by seniority (IC vs exec), industry, region, and company size. Include a mix of “known good” and “unknown” contacts so you can detect both false negatives and false positives.
3. Separate mobile vs direct dial. If you blend them, you’ll hide where the tool is strong or weak. If your motion depends on mobile reachability, measure mobile separately.
4. Standardize the dialing workflow. Same dialer, same call windows, same rep behavior, same disposition rules. If you change the workflow between vendors, you’re measuring your process, not the data.
5. Score outcomes consistently. Use a small set of dispositions: connected-right-party, connected-wrong-party, disconnected, voicemail, and unknown. Don’t let reps invent categories mid-test.
6. Repeat to test recency. Re-run the same sample after a few weeks. If outcomes drift, that’s recency and refresh frequency showing up in your numbers. If your team is rationing lookups, you’re choosing drift.
7. Explain variance before you sign. If results differ, attribute the gap to variables you can control: seat count/workflow, API usage/integration depth, list quality, and industry/geography. If you can’t explain variance, you can’t forecast ROI.

Common test mistakes that fake “accuracy”: mixing mobile and direct dial into one score, changing call windows between runs, letting reps use different dispositions, and testing only easy segments. Those mistakes don’t just skew results; they hide where your costs will show up after rollout.

How to interpret results without lying to yourself: if connect rate improves but right-party outcomes don’t, you may be hitting shared lines or reassigned numbers. If right-party outcomes improve but connect rate doesn’t, your list quality or segmentation may be the real constraint. If both drift down on the repeat test, that’s recency and refresh cadence, not a mysterious “accuracy drop.”

If you want a structured template for running this experiment, use contact data accuracy test. If you want the broader framework for evaluating data quality beyond a single test, use data quality.

Checklist: Feature Gap Table

Decision Tree: Weighted Checklist

This checklist is weighted by standard failure points that drive cost: wasted rep time from dead/wrong numbers, and data decay caused by under-refresh or broken integrations. Weighting is relative (High/Medium/Low) because outcomes vary with seat count, API usage, list quality, and industry.

• High: Outcome reporting by segment tied to connect rate and answer/right-party outcomes. This is the only way to evaluate “how accurate is swordfish” without getting misled by coverage.
• High: Recency and refresh workflow (how often you can refresh without rationing). Data freshness is a leading indicator of reachability.
• High: Ranking and verification signals that prioritize likely-to-work numbers first. Treat verification as a confidence signal, then validate it with outcomes.
• Medium: Integration reliability (CRM + dialer + API) with monitoring. Integration failures create silent staleness even if the provider’s underlying data is strong.
• Medium: Clear fair use boundaries for “unlimited” so you can forecast usage without surprise throttling.
• Medium: Field governance (overwrite rules, conflict handling). Bad overwrite rules can replace good numbers with worse ones and you won’t notice until connects drop.
• Low: UI convenience features. They don’t fix wrong numbers or stale records.

Troubleshooting Table: Conditional Decision Tree

• If your buying goal is “more records returned,” then you’re optimizing for the wrong metric; switch to connect/answer outcomes before evaluating any vendor.
• If your outbound motion depends on mobile reachability, then test mobile separately and require ranked candidates; then choose the provider that improves connect rate on mobile for your ICP sample.
• If your team can’t refresh frequently because of credit rationing, then your effective accuracy will decay between refresh cycles; then prioritize a plan that supports frequent refresh under fair use.
• If your integration is partial (manual exports, inconsistent enrichment triggers), then your results will look worse than the provider’s capability; then fix workflow before blaming data.
• If your test shows higher connects but lower right-party outcomes, then you may be reaching shared lines or reassigned numbers; then tighten validation and segment by seniority/region.
• Stop condition: If you cannot run a controlled test (same list, same dialer, same call windows) and report connect + right-party outcomes by segment, stop. Any purchase decision made on blended “accuracy %” claims will leak budget.

Limitations and edge cases

No contact provider is uniformly accurate across every segment. If someone claims otherwise, they’re selling a blended metric that hides where you’ll bleed time.

• Recency limits: Even good data goes stale. If your workflow doesn’t refresh, your effective accuracy drops. This is why refresh frequency matters as much as the provider.
• Right-party ambiguity: A connected call can still be the wrong person (reassigned numbers, shared lines, assistants). That’s why answer/right-party outcomes matter alongside connect rate.
• ICP variance: Some industries churn numbers faster; some regions have different mobile availability. Your benchmark must match your ICP, not a generic dataset.
• Integration drift: Field mapping mistakes, overwrite rules, and failed jobs can quietly degrade your CRM. That’s an integration headache that looks like “bad data.”
• Compliance and dialing rules: Your ability to call mobile numbers depends on your compliance posture and dialing practices. A tool can’t fix policy violations or poor call hygiene.

Data decay economics (the part procurement forgets): under-refresh happens when credits are rationed, when only one admin can run enrichment, or when the integration fails silently. The fix is boring: set a refresh policy for active accounts, monitor enrichment failures, and don’t let overwrite rules destroy known-good fields.

If your use case is specifically finding a cell number for an individual, compare the workflow to cell phone number lookup and measure whether it reduces time-to-number for your reps.

Evidence and trust notes

Here’s what I’d trust, and what I wouldn’t, when someone asks about Swordfish, data accuracy, and connect rate outcomes.

• Trust: Your own controlled test that reports connect and right-party outcomes by segment, with documented methodology and a repeat run after a few weeks to observe recency drift.
• Trust: A workflow audit that confirms refresh frequency, integration triggers, and overwrite rules. This is where “accuracy” usually dies in production.
• Don’t trust: A single blended accuracy percentage without a variance explainer (seat count, API usage, list quality, industry/geography, recency). That number is designed to look stable.
• Don’t trust: “Returned record rate” presented as accuracy. Returning a number is not the same as reaching the right person.

Methodology you can audit without guessing: ask for an export (or API response sample) that includes number type (mobile vs direct dial), any verification flags, and recency indicators. Then confirm your integration is actually writing those fields to the CRM, refreshing on the schedule you think it is, and logging failures.

Artifacts to request (so you can audit later):

• Number type: a field that labels mobile vs direct dial so you can measure outcomes separately.
• Verification flag + definition: a plain-language description of what the flag means operationally (a confidence signal), so your team doesn’t treat it as a guarantee.
• Recency indicator: a “last refreshed” timestamp (or equivalent) so you can correlate drift with refresh cadence.
• Enrichment observability: job status or logs that show whether refreshes succeeded or failed, so staleness doesn’t hide behind a green UI.
• Overwrite rules: a written summary of what fields get overwritten and when, so you don’t accidentally replace known-good numbers.

If you can’t trace “this number was refreshed on this workflow” through your stack, you don’t have an accuracy problem; you have an observability problem.

If you want a repeatable experiment template, use contact data accuracy test and keep the scoring rules identical across tools.

FAQs

• How accurate is Swordfish? The only buyer-grade answer is outcome-based: measure connect rate and right-party answer outcomes on a controlled sample, split by mobile vs direct dial and by ICP segment. “Records returned” is not accuracy.
• What does “accurate” mean for contact data? For outbound, it should mean the number connects to a working line and reaches the intended person or their business line. A “valid” number can still be wrong for your rep’s purpose.
• Why do vendors avoid connect/answer metrics? Because outcomes vary with list quality, industry, region, and calling practices. That variance makes marketing claims harder, but it’s the variance you pay for.
• How accurate is Swordfish in my industry? It varies. Segment your test by industry and seniority, then repeat after a few weeks to see how recency affects outcomes. If you don’t segment, you’ll average away the problem areas.
• Does verification guarantee the number will work? No. Verification can reduce obvious bad data, but reassignment and churn still happen. Treat verification as a signal, then confirm with connect and right-party outcomes.
• What’s the fastest way to sanity-check Swordfish? Use reverse search on a small set of contacts you can independently confirm. It’s not a full benchmark, but it catches obvious mismatches quickly.
• Why does my accuracy drop after rollout? Usually workflow: infrequent refresh, partial integration, bad overwrite rules, or reps dialing outside the tested segments. Fix the operational causes before blaming the provider.

Next steps

Timeline (operator-friendly):

• Day 0–1: Define success metrics (connect + right-party outcomes), segments, and sample size. Decide how you’ll separate mobile vs direct dial.
• Day 2–4: Run the first controlled test and document methodology (dialer, call windows, dispositions).
• Day 5–7: Audit integration and refresh workflow (field mapping, overwrite rules, triggers, monitoring). Confirm fair use expectations if you plan to refresh frequently.
• Week 2–4: Re-run the same test set to measure recency drift and validate that refresh frequency maintains outcomes.

If you want the broader evaluation framework, start with data quality. If you want a quick proof point before you invest in a full test, use reverse search.

About the Author

Ben Argeband is the Founder and CEO of Swordfish.ai and Heartbeat.ai. With deep expertise in data and SaaS, he has built two successful platforms trusted by over 50,000 sales and recruitment professionals. Ben’s mission is to help teams find direct contact information for hard-to-reach professionals and decision-makers, providing the shortest route to their next win. Connect with Ben on LinkedIn.