# Turn supplied domains into reviewable CRM company records

[← All data workflows](https://proxylane.dev/use-cases)  

COMPANY ENRICHMENT · WORKFLOW GUIDE

  

ProxyLane can scope a pilot to enrich company records from domains you supply, with a source URL and observation time attached to each proposed record. A human reviews feasibility, scope, price and acceptance criteria before any work or purchase terms are agreed.

 

**Founder, ProxyLane**Sample data and implementation guide

 

On this page  [Workflow at a glance](https://proxylane.dev/use-cases/company-enrichment#workflow)   [Sample data](https://proxylane.dev/use-cases/company-enrichment#sample)   [Who this fits](https://proxylane.dev/use-cases/company-enrichment#who-this-fits)   [What the pilot proposes](https://proxylane.dev/use-cases/company-enrichment#what-the-pilot-proposes)   [Try the sample locally](https://proxylane.dev/use-cases/company-enrichment#try-the-sample-locally)   [Data requirements and economics](https://proxylane.dev/use-cases/company-enrichment#data-requirements-and-economics)   [Questions buyers usually ask](https://proxylane.dev/use-cases/company-enrichment#questions-buyers-usually-ask)   [Request access](https://proxylane.dev/use-cases/company-enrichment#request)

 

**Get the data you need**

Share your sources and required fields to discuss access for this workflow.

 [Request access ↗](https://proxylane.dev/use-cases/company-enrichment#request)

  

## Workflow at a glance

 

1. ### Supply the source list

Share the domains, geography, required fields, refresh interval, expected volume and output format you want assessed
 
1. ### Review evidence and ambiguity

Check record sources, parent or subsidiary relationships, and records that should remain null or enter a review queue
 
1. ### Accept the output

Agree the acceptance worksheet; if the pilot is feasible, the scoped output format and exception list can then be defined for CRM review

 

SYNTHETIC SCHEMA EXAMPLE

## Sample data

 

The downloadable synthetic sample shows one accepted domain record and one record held for review because the organization relationship is ambiguous. These fictional records demonstrate the format, not measured service output.

 

```json
{
    "input_domain": "example.com",
    "company_name": "Example Harbor Labs",
    "source_url": "https://example.com/company",
    "observed_at": "2026-09-17T00:00:00Z",
    "field_status": "accepted"
}
```

 

[Download JSON](https://proxylane.dev/use-cases/company-enrichment/sample.json)   [Download CSV](https://proxylane.dev/use-cases/company-enrichment/sample.csv)   [Requirements worksheet](https://proxylane.dev/use-cases/company-enrichment/pilot-brief.md)

 

## Who this fits

 

This is for a RevOps team that already has company domains and needs a reviewable enrichment file before CRM updates, or for a builder testing a domain-to-record workflow. It fits teams that care about record-level provenance and want uncertain parent, subsidiary or trading-name relationships kept visible.

 

It does not fit a request for a ready-made customer dataset, a guaranteed coverage percentage, guessed headcounts, contact emails, or a bulk CRM overwrite without review. It is also not a replacement for your CRM's matching policy. Unobserved fields stay null; a plausible value is not evidence.

 

## What the pilot proposes

 

The current public offer is a pilot scoping conversation and illustrative downloads. No managed service or delivery result is being claimed. Select **Request access** to open a draft addressed to  [hello@proxylane.dev](mailto:hello@proxylane.dev) , then review it with your vertical, source list, required fields, geography, refresh interval, output format, expected volume and acceptance rules. Opening the button sends nothing; ProxyLane confirms feasibility, scope, price and acceptance criteria before work begins.

 

| Field | Proposed rule | Acceptance check |
| --- | --- | --- |
| `input_domain` | Preserve the supplied domain exactly | Every output row maps to one supplied domain |
| `company_name` | Include only a name supported by the cited source | Name is readable at `source_url` and ambiguity is flagged |
| `source_url` | Keep the public page supporting the proposed record | URL is present for each non-null record |
| `observed_at` | Record when the observation was made | Timestamp is present and explained as an observation time |
| `field_status` | Use `accepted`, `review`, or `unknown` | Only `accepted` rows may be proposed for CRM overwrite |

 

The sample uses `example.com` and `example.org` with fictional names. It is a synthetic schema example, not measured output or a source verification. The `example.org` row remains in review because its name could describe a subsidiary or parent relationship; it does not assert either one.

 

## Try the sample locally

 

Download  [/use-cases/company-enrichment/sample.json](https://proxylane.dev/use-cases/company-enrichment/sample.json) , save it beside this short script as `sample.json`, and run it with Python. The script checks completeness, timestamps and the synthetic example hosts, then routes incomplete records to review.

 

```python
import json
from datetime import datetime
from pathlib import Path
from urllib.parse import urlparse

data = json.loads(Path("sample.json").read_text(encoding="utf8"))
assert data.get("sample_type") == "synthetic"
records = data.get("records", [])
assert records, "sample must contain records"

required = {"input_domain", "company_name", "source_url", "observed_at", "field_status"}
accepted = []
for record in records:
    issues = [f"missing {field}" for field in required if not record.get(field)]
    try:
        timestamp = datetime.fromisoformat(str(record.get("observed_at", "")).replace("Z", "+00:00"))
        if timestamp.tzinfo is None:
            issues.append("observed_at needs a timezone")
    except ValueError:
        issues.append("observed_at is not an ISO timestamp")
    parsed = urlparse(str(record.get("source_url", "")))
    if parsed.scheme != "https" or parsed.hostname not in {"example.com", "example.org"}:
        issues.append("source_url is outside the synthetic example hosts")
    if record.get("field_status") not in {"accepted", "review", "unknown"}:
        issues.append("field_status is invalid")
    if issues or record.get("field_status") != "accepted":
        print("review required:", record.get("input_domain", "(missing domain)"), issues)
    else:
        accepted.append(record)

print(f"{len(accepted)} record(s) eligible for proposed review, {len(records) - len(accepted)} held back")
```

 

This validates the local synthetic schema only. It does not establish that a company exists, verify a source page, or call a ProxyLane API.

 

## Data requirements and economics

 

Before delivery, agree the exact domain list, required fields, geography, refresh interval, expected volume, output format, source rules and acceptance worksheet. A useful pilot output is a file containing the proposed fields above, record-level source URLs and observation times, plus a review queue for ambiguous relationships and unknown values. CRM overwrite remains your team's decision.

 

The economic case can be stated without inventing a result: `pilot value = (records accepted for review × value of one reviewed record) − pilot cost`. Supply your own record value and acceptance threshold; ProxyLane should not fill them with a benchmark it has not verified.

 

## Questions buyers usually ask

 

### Can you guarantee every domain?

 

The pilot does not guarantee every domain. It can define what counts as an accepted record and how unknown or ambiguous records are returned.

 

### Will this guess missing company details?

 

A field without supporting evidence stays null or enters review. Headcount and contact emails are outside this proposed field set.

 

### Can it write directly into our CRM?

 

The proposed output supports review before overwrite. Direct write access, permissions and any integration behavior must be scoped separately and agreed before work.

 

### What happens next?

 

Select **Request access** to open a reviewable email draft. Include the source list plus the fields, geography, refresh interval, output format, expected volume and acceptance rules.

 

## Request access

 

Tell us which sources and fields you need, and how often the data should refresh. We’ll confirm feasibility, scope, pricing and acceptance criteria with you.

  [Request access ↗](mailto:hello@proxylane.dev?subject=Company%20enrichment%20access%20request&body=I%27d%20like%20to%20request%20access%20for%20Company%20enrichment.%0A%0ASource%20URLs%20or%20domains%3A%0ARequired%20fields%3A%0AGeography%3A%0ARefresh%20interval%3A%0AOutput%20format%3A%0AExpected%20volume%3A%0AAcceptance%20rules%20and%20review%20budget%3A%0APermitted%20use%20and%20retention%3A%0A%0APlease%20confirm%20feasibility%2C%20scope%20and%20pricing%20before%20any%20work.)  

Opens an email draft to hello@proxylane.dev for you to review and send.

 

## Keep reading

[AI retrieval · Workflow guide

### Give your research agent source-linked records it can check

Scope source-linked retrieval records for research and RAG agents with explicit fields, review rules, and a synthetic local sample

 Read guide →](https://proxylane.dev/use-cases/ai-retrieval)   [E-commerce data · Workflow guide

### Compare competitor prices and stock with the fields your repricing review needs

Define a careful e-commerce monitoring pilot for competitor prices and stock, with variant matching, region-aware fields, acceptance rules and a synthetic local sample.

 Read guide →](https://proxylane.dev/use-cases/ecommerce)   [People sourcing · Workflow guide

### Find reviewable professional profiles from defined public evidence

Scope a people sourcing pilot that returns public professional evidence with dates and an explicit identity review queue

 Read guide →](https://proxylane.dev/use-cases/people-sourcing)

Canonical source: https://proxylane.dev/use-cases/company-enrichment

Documentation index: https://proxylane.dev/llms.txt