A company list is only useful when “which companies?” has a precise answer.

1. State the decision the list must support

Begin with the business purpose. A supplier search, competitor landscape, location directory, market-participant review, and account-planning dataset may all involve organizations, but they need different inclusion rules and fields. The intended use determines what belongs in the list and what evidence is strong enough to support it.

A useful purpose statement names the decision or workflow, the people or system using the result, the geographic or market boundary, and the minimum facts needed after delivery. “Find manufacturers” is too broad. “Identify operating manufacturers of a defined product category with a public facility in three named states” is a scope that can be researched, priced, and tested.

Before listing fields, answer:

• What decision will the finished list support?
• What kind of organization could affect that decision?
• What fact proves that an organization qualifies?
• Which facts must be present before a record is usable?
• What is the relevant date or business deadline?

2. Define what one record represents

Decide whether each row represents a legal organization, operating company, brand, branch, facility, franchise location, or another business entity. These are not interchangeable. A parent company may own several brands; one brand may operate many locations; a registered entity may use a different public trade name.

The record identity rule should explain which variations belong together and which remain separate. If the project counts facilities, one organization with four qualifying plants may produce four records. If the project evaluates vendors, those same facilities may need to roll up to one supplier record with separate location fields.

Specify:

• the entity represented by one row;
• the primary name or identifier;
• how parent companies, subsidiaries, brands, and locations are handled;
• whether inactive or historical organizations qualify;
• which fields distinguish legitimate separate records; and
• how uncertain relationships should be flagged instead of assumed.

3. Write inclusion and exclusion rules

Inclusion rules turn a topic into a test. Each organization should qualify because public evidence supports defined conditions—not because its name sounds related. Criteria may involve industry, product or service capability, geography, organization type, operating status, facility type, market role, or another observable business attribute.

Exclusion rules are equally important. A list may omit resellers, individual practitioners, government entities, nonprofits, organizations without an operating location in the target area, or companies whose connection to the category cannot be supported by permitted sources. The right exclusions depend on the intended use.

A good criterion is observable and repeatable. “Established company” is subjective unless the scope defines the supporting fact. “Appears reliable” cannot be tested. Replace subjective labels with specific public evidence or leave them out of the dataset.

4. Set the geographic and market boundary

Geography can refer to headquarters, registered address, operating facility, service territory, customer market, shipping coverage, or another location relationship. State which one matters. A company headquartered outside the target region may still operate a qualifying facility inside it, while a local mailing address may not represent an active business location.

Name the countries, states, provinces, counties, cities, postal areas, or distance rules that define coverage. For global work, identify included countries or regions and the language, transliteration, currency, address, and source constraints that affect consistent delivery. Do not assume that a request for “North America,” “Europe,” or “worldwide” has one universal operational definition.

Market boundaries also need definitions. If an organization must sell into a particular industry, serve a particular customer type, or participate in a specific category, describe the evidence that demonstrates that relationship.

5. Separate required fields from useful extras

Every requested field adds research and quality work. Choose fields because they support the stated purpose, not because they might be interesting. Mark fields as required, optional when publicly available, derived under an agreed rule, or excluded.

Company-list fields may include:

• organization name and public trade name;
• official website;
• headquarters or qualifying operating location;
• industry, category, capability, or market-role evidence;
• parent, subsidiary, brand, or location relationship;
• public business telephone or general business contact channel when appropriate;
• source URL, document reference, and observation date;
• controlled qualification status and exception reason; and
• customer-defined fields supported by permitted sources.

Define the exact meaning and format of every field. A “location” column is ambiguous unless it is identified as headquarters, facility, service area, or another type. An “industry” field needs either a source-preserved label or an approved classification rule. Missing and conflicting values also require a controlled representation.

6. Approve sources and evidence standards

Source policy determines what can support a record. Appropriate projects may use customer-provided files, official organization websites, public directories, public records, public documents, authorized interfaces, and other sources approved during scope review. Different sources have different strengths, dates, geographic coverage, and usage restrictions.

A project should specify whether one source is sufficient, whether selected fields need corroboration, and what provenance must accompany each row. For example, the organization’s own site may support a product capability while a public registry may support legal status. Conflicting sources may require a stated precedence rule or an unresolved status.

Morrow Creek does not bypass authentication, paywalls, technical controls, or source restrictions. Requests focused on private personal information, prohibited outreach data, or unauthorized access are excluded. If a named source cannot be used consistently or lawfully, the scope must be changed before production.

7. Choose a measurable coverage model

No public-web research process can prove that an undefined list contains “every company everywhere.” Coverage needs a stopping rule that matches the intended decision. The project can target a fixed number of accepted records, all qualifying entries within named sources, a defined customer-supplied universe, a geographic/category boundary, or a time-boxed research effort with documented limitations.

Common coverage models include:

• Fixed accepted count: deliver the agreed number of records that pass all required rules.
• Named-source coverage: review all qualifying entries available through specified permitted sources.
• Defined-universe review: assess every organization in a customer-provided list against the criteria.
• Bounded discovery: research within defined regions, categories, dates, and source types until the confirmed stopping rule is met.
• Time-boxed landscape: use an agreed research effort and deliver found records with a transparent limitation statement.

The scope should also state how duplicate organizations, multiple locations, unavailable fields, ambiguous candidates, and organizations discovered after the research date affect the final count.

8. Define acceptance and duplicate controls

Quality must be measurable. Required-field completeness, valid formats, source presence, qualification evidence, record uniqueness, controlled categories, geographic consistency, and record-count reconciliation are all testable. “Looks right” is not.

Duplicate rules should use the record definition. Matching names alone can merge unrelated companies or miss the same organization written differently. Depending on scope, review may use official domains, addresses, registration identifiers, parent relationships, normalized names, or a combination of agreed fields.

Acceptance rules should distinguish defects from permitted-source limitations. If a required fact is not publicly available, the correct result may be exclusion, a controlled unavailable status, or an exception record—whichever rule was confirmed before production. Values should never be invented to make a row appear complete.

9. Set a research date and change policy

Organizations open, close, relocate, change ownership, rename products, and update websites. A company list represents a documented research period. State whether fields must be observed during production, published within a defined freshness window, or checked again immediately before release.

For recurring operational use, a separately scoped refresh may be more appropriate than treating one delivery as permanently current. The original project should still record its observation date, evidence, and relevant limitations so later changes can be identified without rewriting history.

10. Design the output for its destination

Choose CSV, Excel, JSON, or another agreed format based on the system and people that will use the list. Define column order, worksheet names, date format, controlled values, delimiter and encoding requirements, relationship structure, and any summary totals.

If the list will be merged with an existing file, provide the target structure and identifiers during scoping. If the supplied records also need normalization, deduplication, or validation, the data cleaning and verification service can be included as a separately defined stage.

What happens after the request

1. Private request: Describe the desired organizations and the decision the list must support.
2. Scope review: Morrow Creek checks the criteria, source boundaries, coverage model, feasibility, and lawful use.
3. Written confirmation: You receive the deliverable definition, exclusions, acceptance rules, and exact price before commitment.
4. Research and quality control: Approved work proceeds against the confirmed rules, and completed records are checked before release.
5. Payment and delivery: When the finished customer files are ready, payment and download occur through the private workspace.

For a broader framework covering research, collection, and cleaning projects, read How to Plan a Custom Data Project. For service details, review Custom Company List Research and Custom Data Research Services.