Build a company brief you can actually use

A useful company brief answers a decision. Before you collect fields, write down what the reader needs to do: prepare for a sales conversation, map a recruiting market, or decide which company deserves deeper research.

This walkthrough uses Forma Labs, a fictional company at forma.example. Every company fact below is illustrative. Vencavo has 299M+ contact records and 25M+ company records; the website demonstration uses fictional records to explain the research method.

What you’ll take away

• A company brief organized around one decision, rather than a collection of disconnected facts.
• An evidence ledger that separates what a source says from what you infer.
• A reusable agent prompt and a CSV worksheet for the next research handoff.

1. Start with one decision

For this exercise, the decision is: Is Forma Labs worth a discovery conversation for a product used by SaaS teams with 50–250 employees?

Write the criteria before opening a search tool:

• Required: a SaaS business and an employee range that overlaps 50–250.
• Useful context: location, the product it sells, and the team that would use your product.
• Still to establish: an actual need, a suitable contact, and whether the company is buying.

The sample record can support an initial fit hypothesis. It cannot establish buying intent. Keeping those questions separate prevents a short company record from becoming an overconfident sales narrative.

2. Resolve the company first

Use a domain or another stable identifier alongside the company name. Names alone can collide; a parent company, subsidiary, and product brand may also be different entities.

Our fictional input is:

{
  "name": "Forma Labs",
  "domain": "forma.example",
  "industry": "SaaS",
  "location": "San Francisco, US",
  "employees": "51–200"
}

For a real brief, record the supplied identifier, the resolved entity, and any ambiguity. If the domain refers to a product rather than the intended company, stop and resolve that mismatch before enriching the record. Do not silently merge two similarly named businesses.

The company-data identity review shows three useful outcomes in the illustrative example:

Input	What the example establishes	Research decision
forma.example	An exact match to the Forma Labs fixture	Use the sample record, still labeled fictional
Forma	A name-fragment search result	Confirm a stable identifier before treating it as the intended company
unknown.example	No matching fixture	Keep the identity unresolved; do not borrow fields from a similar result

In production research, even an exact domain match is only an identity starting point. Check whether the domain belongs to the parent, subsidiary, or product you mean; document the source and the date you checked it.

3. Build an evidence ledger

Keep an observation, its source, and your interpretation in separate fields. A retrieval time tells you when you obtained a value; it does not prove when that value last changed.

The downloadable worksheet starts with these example observations:

• Industry: SaaS. Source: illustrative website example. Interpretation: matches the broad industry criterion.
• Employees: 51–200. Source: illustrative website example. Interpretation: overlaps the target range; the exact count is unknown.
• Location: San Francisco, US. Source: illustrative website example. Interpretation: location context, not proof of operating coverage or a buying team’s location.
• Buying need: unknown. Source: none. Interpretation: a question for discovery, not a value to fill by guessing.

In real research, add the original source reference, retrieval time, source observation time where supplied, and any conflicting values. Preserve an unknown as an unknown. An agent should not manufacture a timestamp or contact just to complete a schema.

4. Ask the agent for a bounded brief

Give an agent only the evidence it needs, then specify the output. This example works as a writing instruction with the fictional record; it does not assume a live Vencavo API or MCP connection.

Use only the supplied company record and evidence ledger.
Decision: assess initial fit for a SaaS product aimed at teams
with 50–250 employees.

Return:
1. Identity: name and domain.
2. Observed facts: include their source and known freshness.
3. Fit hypothesis: explain which criteria the facts support.
4. Unknowns: list information needed before outreach.
5. Next step: recommend one verification action.

Label inference separately. Do not infer contacts, buying intent,
growth, funding, or product usage from industry and employee range.

Review the result against the ledger, not against how convincing the prose sounds. For repeatable workflows, a small structured result with explicit missing values is easier to inspect than a long essay.

5. Make the brief decision-ready

Here is an acceptable result for our example:

Initial fit hypothesis: Forma Labs is a possible account to investigate. Its fictional SaaS classification and 51–200 employee band overlap our broad target criteria. Its actual needs, current tools, appropriate contact, and willingness to buy are unknown. Next step: verify the company’s business and team context against current primary sources before deciding whether to approach it.

Notice what the brief leaves out: no invented growth story, no assumed budget, and no named decision-maker. If a source later provides conflicting information, keep both observations with their dates and resolve the conflict before updating the conclusion.

6. Save a handoff someone can check

Export the brief with the entity identifier, evidence ledger, review owner, and unresolved questions. Recheck time-sensitive facts when they become relevant to a decision; choose that cadence based on the workflow rather than treating all fields as equally fresh.

Before the brief leaves your desk

Check that every factual statement maps to a row in the ledger. A reader should be able to trace “51–200 employees” to the original observation without searching through a chat transcript. If two sources disagree, show the disagreement and the next verification action instead of selecting the value that makes the account look like a better fit.

Then ask three questions: can another person identify the same company, distinguish evidence from inference, and see exactly what to verify next? If any answer is no, the handoff is incomplete. Keep the owner and review decision with the brief so the next person can continue the work without repeating the research.

Use the company research worksheet as a starting point. It includes the fictional Forma Labs observations, blank verification fields, and a row for the missing buying-need evidence. Download it and work locally; this site does not collect your worksheet.

To try the worked example, open the database explorer. For your real target market, discuss company and contact data with our team. The data model and agent workflow guide explain record and tool design; they are not released API or MCP connection instructions.