Public evidence index / CRM operations

Find risky CRM cleanup decisions before they become writes

This is the evidence and fixed pilot contract for a proposed HubSpot CRM data-hygiene and enrichment-QA app. It is for a RevOps lead or CRM administrator at a B2B company who needs to separate obvious formatting cleanup from duplicate and enrichment decisions that still require evidence and human review.

Request the $249 pilot scope

$249 onceOne read-only founding-team pilot; no automatic renewal.
10,000 recordsUp to 10,000 exported contact and company rows.
10 business daysAfter scope, data-handling terms, and a buyer-controlled export are accepted.
Zero writesThe pilot delivers findings and never applies a merge or field update.

No HubSpot app, OAuth connection, Marketplace listing, checkout, contract, or customer dataset exists for this test. The request form takes no payment and asks for no CRM export.

The fixed pilot deliverable

A RevOps lead at a HubSpot-using B2B company pays $249 one time for a read-only hygiene and enrichment-evidence review of up to 10,000 exported contact and company rows, delivered within ten business days as a CSV issue manifest and an HTML audit receipt. There is no subscription and therefore no renewal to cancel. Scope acceptance happens before payment, and the request form on this page is only an inquiry.

Included

  • Exact- and normalized-match duplicate candidates for contacts and companies, with the two source record IDs beside every candidate pair.
  • Field-format findings for email case, phone shape, country and state codes, whitespace, obvious placeholder values, and inconsistent enumerations.
  • Enrichment QA for fields that already carry a source URL or source identifier: supported, contradicted, stale, or unknown.
  • A proposed canonical value beside the untouched original value, the rule or source used, and a confidence label.
  • A CSV issue manifest plus a human-readable receipt that totals every finding class and names all coverage limits.

Not included

  • No automatic merge, field update, deletion, association change, workflow trigger, or write-back to HubSpot.
  • No purchase of third-party enrichment data, no guessed employer or revenue facts, and no unsupported value converted into a confident answer.
  • No legal, GDPR, deliverability, identity, fraud, compliance, or revenue conclusion.
  • No review of deals, tickets, activities, attachments, custom objects, or more than the accepted 10,000-row scope.
  • No OAuth connection or production app until the product clears the build and marketplace gates described below.

Read-only acceptance rule. The pilot never changes a CRM record: every proposed merge, normalization, or enrichment correction remains a reviewable finding. The buyer chooses what to approve after delivery. A later app would need an independently tested reversal path before any write mode could be considered.

What a finding must prove

A cleanup list without traceability simply moves the uncertainty. This pilot uses a proof-carrying issue manifest. A duplicate candidate must name both CRM record IDs and the compared fields. A normalization finding must retain the original value, show the proposed value, and name the deterministic formatting rule. An enrichment-QA finding must name the stored source URL or source identifier. If the export contains a value but no recoverable source, its evidence status is unknown; the system does not invent a citation or quietly call the value valid.

Confidence is attached to each individual finding rather than to the entire database. An exact normalized email match may be high confidence while a similar company name remains review-only. The receipt separates observation from recommendation, and every row includes write_applied: false. This prevents a summary score from hiding the specific records that create risk.

The public reference receipt exercises that schema on 8 synthetic records. It contains 2 duplicate candidates, 4 normalization findings, and 2 unsupported enrichment values. All five structural checks pass, including zero emitted write operations. That is a real schema receipt, but it is deliberately narrower than product proof: it is not an OAuth run, a packaged HubSpot app, a customer result, or marketplace approval.

Inspect the machine-readable reference receipt.

Observed HubSpot Marketplace evidence

Observation date: 2026-08-09. On , the official HubSpot Data Quality and Backup category page was observed with the title “The 69 Best Data Quality and Backup Apps for HubSpot.” Three direct comparables show that HubSpot administrators install tools for this job. Install counters are lower-bound display values, not paid seats, revenue, retention, active use, or evidence that this particular offer will convert.

Direct comparableDisplayed installsDisplayed ratingObserved position
Koalify - Merge & Deduplicate4K installs5 (111 ratings)HubSpot-embedded duplicate detection and controlled merges
CRM Data Grader by Insycle900+ installs4.3 (6 ratings)Read-only CRM quality analysis and grading
Dedup by Insycle600+ installs4.9 (9 ratings)Previewable bulk deduplication with CSV reports and an audit trail

Koalify shows the strongest direct duplicate-management signal in this sample at 4K installs and 111 ratings. CRM Data Grader shows 900+ installs for a read-only analysis position. Dedup by Insycle shows 600+ installs and advertises preview, CSV reporting, and an audit trail. Those are meaningful incumbents, so “another dedupe button” is not a defensible wedge. The test here is narrower: every proposed merge or normalization keeps record-level evidence, and enrichment quality is explicitly unknown when its supporting source cannot be recovered.

The comparable pages were counted from rendered official HubSpot results. Direct command-line requests returned a shared application shell, so this receipt does not invent page response hashes. The official developer-requirements and legal pages were directly fetchable; their response hashes and extracted requirements are preserved in the market receipt.

Download the dated market-probe receipt and its official source URLs.

The marketplace gate is real—and has not been crossed

HubSpot's current listing requirements say a public app needs at least 3 active, unique production-account installs unaffiliated with the developer organization. Activity must appear through OAuth-authenticated API use, signed webhooks, or extensions during the prior 30 days. The listing also needs accurate pricing, a public setup guide, support resources, terms, a privacy policy, and a review of the Technology Partner Program Agreement. HubSpot says the initial review target is 10 business days and only one app may be submitted at a time.

Those rules mean a marketplace listing cannot honestly be the first artifact. The three external active installs require a functioning public app, and the partner agreement is a contract only the operator can accept. This run did neither. A public offer and synthetic receipt can test whether RevOps teams ask for the evidence-led pilot without pretending the marketplace has approved, distributed, billed, or endorsed anything.

The first product build remains blocked until a real sample clears deterministic field and duplicate checks, the read-only scope is stable, privacy and data-handling terms exist, and three unaffiliated test portals produce qualifying activity. No free page or request authorizes access to a portal or permission to process a CRM export.

Three steps from this test to a listed app

  1. Request and qualify one pilot. Tell us the HubSpot object types, approximate row count, known hygiene problems, and whether enriched values already carry source URLs. Do not upload CRM data, credentials, exports, private links, or portal identifiers.
  2. Prove the read-only receipt. After a human accepts scope and data-handling terms, the pilot runs on an agreed buyer-controlled export. Every reported item must preserve source record IDs, original values, rules or citations, confidence, and the zero-write guarantee.
  3. Build and seek distribution only after evidence. A future OAuth app must pass security, privacy, reliability, reversal, and fixture gates; earn three unaffiliated active installs; and receive an operator-approved partner agreement before any marketplace submission.

Demand-test boundary: this page counts product-specific requests separately from reach. Our own probes, search crawlers, comparable install counters, and page fetches are never buyer demand. A request is contact, not payment, a contract, an accepted dataset, or permission to build.

Request the read-only pilot scope

Questions a RevOps team should ask

Will this merge records in our portal?

No. The proposed pilot does not connect to the portal and does not emit writes. It evaluates an accepted export and returns a review queue. The static marker and reference receipt both make that boundary testable.

Does “enrichment QA” mean you will add third-party facts?

No. It means checking whether an already-enriched value carries recoverable support and whether that support agrees with the stored field. A value without evidence is labeled unknown. Purchasing or scraping new enrichment data is outside the pilot.

Is the $249 price a subscription?

No. It is a proposed one-time price for one accepted export, one issue manifest, and one HTML receipt. There is no automatic renewal or cancellation step. Any future app subscription would be a separate offer and would need fresh, accurate marketplace pricing.

Why request a pilot before an app exists?

The marketplace itself requires active external installs before listing. The pilot tests the narrow evidence contract first, without requesting portal access or silently creating an app-shaped data processor. A serious request supplies a real acceptance case; the public receipt supplies a format to inspect before anyone shares data.