Company Data Ops Series · Research schema
What should a company research row actually contain?
A company research row is easy to overbuild. If you ask five teams what they want, you will get fifty fields: funding, founders, headcount, LinkedIn, country, tags, descriptions, scores, notes, competitors, technologies, and more. The trick is deciding which fields actually help someone make the next decision.
Start with the decision, not the database
Before choosing fields, ask: what will this row be used for?
- A sales team may need territory, company size, and industry.
- An investor may need category, location, description, and optional funding context.
- A market researcher may need consistent tags and a short summary.
- A KYB team may need website, location, and a review flag before deeper checks.
The same company can support all of these workflows, but the row should not become a junk drawer.
The baseline fields that usually matter
For most company research workflows, these fields earn their place:
- Input name: the raw company name you started with. This helps audit mistakes.
- Website: the strongest practical anchor for review, dedupe, and matching.
- Description: a short explanation of what the company does.
- Industries/categories: used for segmentation and filtering.
- Location: useful for routing, market maps, and regional analysis.
- Size: useful for prioritization and fit.
- Optional funding: useful in startup/investor workflows, but not always present.
- Review status: your internal signal for whether the row is trusted, sparse, or needs a human.
A row that works in spreadsheets and code
{
"input_name": "Example Robotics",
"website": "https://example.com",
"description": "Robotics software for warehouse automation.",
"industries": ["Robotics", "Software", "Logistics"],
"location": "Boston, Massachusetts, United States",
"size": "51-100",
"funding_usd": 12000000,
"review_status": "ok",
"review_reason": null
}
Notice what is not here: a fake certainty score, a giant paragraph, or a required funding value. The row is designed to be useful even when some fields are missing.
Common schema mistakes
- Mixing source data and internal judgment. Keep returned profile fields separate from analyst notes and internal scoring.
- Requiring optional fields. Funding, size, and some descriptions may be missing for normal companies.
- Using vague tags. “Tech” might be too broad to help anyone.
- Not storing the original input. Without it, debugging a bad match becomes painful.
- Skipping review state. Downstream users need to know whether a row is complete enough to trust.
How this helps different teams
Sales ops: can filter accounts by industry, size, and location before routing or campaigns.
Analysts: can build market maps without reformatting every company manually.
Startup researchers: can compare companies consistently while treating funding as optional.
Internal tools builders: can design a predictable object shape instead of passing around messy free text.
Where company enrichment fits
A company profile lookup endpoint can populate the first version of this row. Then your workflow can add internal notes, review flags, and business-specific scoring. This separation matters: external profile data should inform your process, not secretly become your entire process.
A practical minimum viable schema
If you are starting today, do not create a 40-column monster. Start here:
input_name
website
description
industries
location
size
funding_usd
review_status
review_notes
You can always add more fields later. It is much harder to remove fields after people build reports around them.
If you want to populate these fields automatically
The ShakeChillies company enrichment endpoint can help populate company profile fields such as website, description, industries, location, size, and optional funding. Use the output as a structured first pass, then add your own review and business logic.
Disclosure: maintained by ShakeChillies. The API is not an official Crunchbase product and does not guarantee complete company or funding data.