Sourcing a Competitor's Customers Into a Ranked Displacement List

This is a sourcing guide, not a messaging guide. The job is narrow and comes before every displacement email ever written: find which companies actually run a named competitor's product, prove it from public evidence, strip the false positives, collapse the duplicates, and rank what remains by how ready each account is to switch and when its window opens. It is for founders selling their own product, account executives, SDR leads, and partnerships teams who are tired of guides that start after the list already exists.

Most published displacement advice spends its ink on switching-cost objections and cold-email templates. It assumes the list. That assumption is the hard part. A displacement list built on single-vector detections and duplicated subsidiaries will send your best reps to the wrong accounts at the wrong time. This guide treats the list as a sourcing problem with real evidence-grading, deduplication, and timing steps, and hands you a ranked, dated artifact at the end.

What public evidence proves that a company runs the incumbent

A company's use of a competitor's product leaks through a consistent set of public vectors, and each one proves something different. Some prove client-side presence outright; others only suggest usage and need corroboration.

The vectors fall into two families. Crawl-based methods read a company's website and detect front-end code, so a script tag or a fingerprint on the marketing site is direct evidence the tool loads in a browser. Job-posting and public-web methods read hiring signals and infer the backend and internal tools a crawler can never see. The two families cover different parts of the stack, which is why a serious list draws from both.

Adoption depth matters as much as presence. A tool that appears only on the marketing site signals light use; a tool that appears across internal subdomains and APIs signals deep integration. The second is a far better displacement target, because deep integration means the incumbent is load-bearing and the switch decision reaches budget holders. When you record a hit, record where it appeared, not just that it appeared.

The important distinction to carry through the whole exercise: HTTP, DNS, and script-tag fingerprints prove client-side presence; job mentions only suggest it. A required skill in a posting can reflect a live deployment, a planned adoption, a migration in progress, client work rather than internal use, or simply an aspirational requirement. Treat the two families accordingly.

Why one detection is never enough

A single fingerprint is a heuristic, not proof. Detection results are point-in-time heuristic detections, not confirmation that a technology is present or absent, and even the best scanners are wrong often enough to matter.

The published precision numbers set the ceiling. In one hand-check of a 100-technology sample, 86% of one scanner's detections were verified genuinely present against 64% of Wappalyzer's. Read that carefully: this is precision, meaning it counts false positives and says nothing about what either tool missed. So even the stronger scanner leaves roughly one in seven detections wrong, and both are silent on coverage. A fingerprint-only list both over-includes and under-includes.

This is why the spine of the whole method is source count, not raw hit count. A detection confirmed by a script tag, a DNS record, and a job posting carries far more weight than one backed by a single crawl, because three independent methods would have to produce the same false positive simultaneously. Grade every account by how many independent vectors agree, and rank on that grade before anything else.

Job mentions are the weakest single vector and deserve the most suspicion. One provider builds detections from five independent sources - job descriptions, script tags, DNS records, IP ranges, and cookies - plus a flag for tools that sit behind a firewall. That five-source design exists precisely because no one source is trustworthy alone.

The install-base signal is real but market-skewed

Skill-listing density is a cheap, public proxy for how widely a tool is deployed, but it varies so sharply by geography that a single evidence threshold will over-target one market. Use it to calibrate your bar, not to build the list.

In Refolk's index of professional profiles, 78,428 US professionals list Salesforce as a skill and 65,878 list HubSpot, while 8,947 UK professionals list Salesforce. The US-to-UK Salesforce gap is 8.77x. That gap is not a claim about market share; it is a warning about your evidence pipeline. If you set the same job-mention or profile-count threshold across both markets, you will surface a deep US list and a thin UK one for the same competitor, and conclude wrongly that the incumbent barely exists in the UK.

Counts come from Refolk's index; the index column is derived. The practical rule: set your evidence threshold per geography. A UK account that clears a two-vector bar is proportionally rarer, and often more qualified, than a US account that clears the same bar in a much denser pool.

Build the list: the procedure

Run these eight stages in order. The estimates assume one analyst with one RevOps handoff, and total roughly a working week for a single competitor. Do not reorder the grading and dedup steps; ranking dirty data produces a confident wrong list.

The one ordering choice worth naming: some teams score dissatisfaction first, then time the window; renewal-window plays time first, then score. Either works. What does not work is skipping grading or dedup because the raw list looks impressive. A raw superset in the thousands is expected and mostly noise.

Deduplicate companies the way companies actually behave

Account deduplication breaks when you match company records the way you match people, because legal entities, subsidiaries, franchises, and firmographic fields behave nothing like a name and a date of birth. This is where inflated lists and inflated addressable markets come from.

The mechanics are specific. Cross-object deduplication identifies records as the same company through domain matching and fuzzy name algorithms, then merges into a single master record, reassigns all child records to the surviving account, and establishes the corporate hierarchy with subsidiaries. Two rules keep it honest. First, an entity should retain every name it has ever traded under as a known alias of itself, so a record matched under an old legal name still resolves to the same account. Second, use firmographic data as weighted, probabilistic supporting evidence in a confidence score, never as a required exact match. Match by domain and fuzzy name; let firmographics adjust confidence, not gate it.

Finding the person behind a deduplicated account - the actual buyer at the surviving parent entity - is its own step, and it is where a plain-English search over the professional graph saves the most time.

Refolk turns the abstract "companies running the incumbent" into named people at named employers, which is exactly the join you need after dedup: an account with a graded detection and a human to reach.

Rank by switch-readiness, then time the window

Two accounts can both run the incumbent and be worlds apart in how ready they are to move. Rank by active evaluation and demonstrated dissatisfaction first, then treat news events as probability-raisers, and finally time each account to its renewal.

Active evaluation is the strongest signal, and the timing data proves it. Comparison views convert far faster than passive research, because a head-to-head view means the shortlist is already forming.

The multiples are derived from the published day counts. A comparison view is worth 2.3 to 2.8 times a passive research hit, so weight it accordingly. Below active evaluation, rank demonstrated dissatisfaction: phrases like "we switched from," "replaced," or "moved away from" indicate a company that has already changed tools once, meaning low switching friction and more openness to doing it again. A dissatisfaction hit from a serial switcher should outrank an equally negative hit from a long-tenured incumbent user.

A comparison view means the shortlist is forming; a category view might just be a student.

News events sit below both. A new VP of Revenue, a funding round, or an office expansion does not confirm a switch is coming, but each one raises the probability that a stale vendor relationship gets a second look. Score them as probability-raisers, not proof.

Then time the account. Renewal windows are a documented lever, not a guess. Contracts encode a notice window, often 30, 60, or 90 days before renewal, and auto-rollover notice windows commonly run 60 to 120 days before expiry - miss that window and the account locks into another 12-month term. Practitioner planning bands scale with deal size:

• Enterprise contracts above $100K: plan around 180 days out.
• Mid-market accounts ($25K to $100K): roughly 90-day lead times.
• SMB and self-serve: 30 to 60 day cycles.

The default construction: take the inferred install or signup date, add twelve months, subtract 90 to 120 days, and set that as the account's work-by date. Corroborate with review clusters - a cluster of negative reviews in a 60-day window often correlates with a pricing change, a deprecation, or a support drop, and reaching out within 90 days catches the frustration while it is fresh.

How this goes wrong

Most displacement lists fail in predictable ways, and every failure has a specific check. Treat this section as the QA pass before you hand anything to a rep.

• Single-vector "confirmed" usage. A marketplace listing or one job mention gets treated as production use. Check: require source count of two or more; remember a job skill can be aspirational or client work.
• Stale fingerprint. A scanner reports a tool the company already migrated off. Check: re-scan and confirm recency, because fingerprints are point-in-time heuristics.
• Agency or consultancy false positive. A firm lists the tool because it implements it for clients, not internally. Check: does the tool appear on internal subdomains, or only on the marketing and services pages?
• Subsidiary double-count. One parent shows up as three companies, inflating the list and the TAM. Check: resolve domain plus fuzzy name plus alias history before ranking.
• Research mistaken for intent. A category or profile view may be an analyst, student, or consultant. Check: treat passive research as a prompt for account research, not proof of a deal.
• Window guessing. An inferred renewal date is wrong and outreach lands after lock-in. Check: corroborate the install date with review clusters or news, and default to the 90 to 120 day band.
• Precision mistaken for coverage. A high precision score counts false positives but says nothing about misses. Check: never treat a precision figure as a completeness score; corroboration is non-optional.
• Displacement math over-trusted. The 3x conversion and 35% win-rate uplift are one vendor's unaudited claims. Check: tag deal type and report displacement separately.

That last point deserves its own numbers. What is well established is the context, not the uplift. New-logo B2B win rates fell to 19% across 655,000 opportunities, enterprise new-business typically runs 15 to 30%, and expansion and renewal motions reach 40 to 60% because of incumbent advantage.

Displacement generally runs lower than greenfield because of switching costs and incumbent relationships, so it behaves like neither pure net-new nor pure expansion. That is the whole reason to forecast it on its own line.

Before you call the list done

Run this checklist before the list leaves your hands. It catches the failures above in the order they usually appear.

Keeping the list current

A displacement list decays the moment you build it, because every input is time-sensitive: fingerprints go stale after migrations, renewal windows pass, and dissatisfaction fades once a vendor fixes the problem. Re-scan fingerprints on a schedule tied to your outreach cadence, and re-check any account you did not reach before its window closed.

The two inputs that move fastest are comparison-view signals and leadership changes, so wire those to alert rather than to a quarterly rebuild. Re-run your seed queries for new job postings and new reviewers monthly, regrade anything that crosses from Suspected to Probable, and push newly two-vector accounts into the ranking. The method does not change; only the rows do. A list you rebuild the grading and timing on every month stays a working document instead of a snapshot that was right once.