State the decision the data will support and name the buyer responsible for approving the request. Then choose what one record represents: a company, an operating location or a professional contact associated with an organization.
B2B data requirements checklist
Before asking for a list, write down what would make a record useful for your intended task. “US manufacturing contacts” leaves several decisions open: which businesses count as manufacturers, whose location matters and which roles belong in the audience.
Define the audience and the unit of a record
Use this checklist to turn those decisions into a procurement brief. Start with your requirements, discuss feasibility with a provider and record what both sides agree before sourcing begins. A requested field is not confirmation that it can be supplied.
Keep the record unit separate from the matching rule. An organization domain may help discuss organization matching, but it does not identify an individual contact or distinguish every location. Record how missing domains, shared domains and multiple locations should be handled before agreeing a rule.
Describe inclusion in terms someone else can interpret. If you request operations roles at manufacturers, explain which functions qualify and how ambiguous business classifications should be resolved. A title alone may leave the intended function unclear.
Complete your requirements worksheet
Planning requests only. Confirm feasibility, coverage and permitted use before procurement.
Copy the worksheet into your own planning document and fill in each buyer-input space. For every row, choose a status: requested, discussed or agreed. Leave the status blank until you have recorded the request. “Discussed” means a question has been considered; mark “agreed” only when the scope and limitations are documented with the provider.
| Requirement | Your buyer input | Decision needed before sourcing | Status: requested / discussed / agreed |
|---|---|---|---|
| Purpose and owner | Intended use: ____; responsible buyer: ____; decision supported: ____ | Who approves scope and permitted use? | ____ |
| Record unit | Company, location or professional contact: ____; proposed unique key: ____ | What counts as one requested record, and how are repeat entities handled? | ____ |
| Included audience | Organization types: ____; role/function: ____; inclusion rule: ____ | How will ambiguous classifications be resolved? | ____ |
| Exclusions | Existing customers: ____; named organizations: ____; excluded roles or locations: ____ | Which buyer-controlled suppression input applies, and how will it be handled? | ____ |
| Geography | Countries/regions: ____; eligibility based on headquarters, operating location or contact location: ____ | Which location determines eligibility? | ____ |
| Requested fields | Field names and definitions: ____; reason needed: ____; required/optional: ____ | What can be supplied, in what form and with what limitations? | ____ |
| Missing values | Field-specific treatment: blank, flag or exception discussion: ____ | Which missing values prevent buyer acceptance? | ____ |
| Delivery request | Column labels: ____; requested file format: ____; identifiers: ____ | Is the requested format feasible? | ____ |
| Acceptance criteria | Criterion: ____; scope: ____; proposed evidence: ____; buyer decision owner: ____ | What rules and exception process must be agreed before procurement? | ____ |
| Open questions | Unresolved definition: ____; owner: ____; next decision: ____ | Which requests remain outside the agreed scope? | ____ |
Give each requested field a definition
Add a row for each field you want to discuss. Explain the meaning you need, rather than relying on a column label. For example, “country” needs a location definition before it can guide selection. Required means necessary for your use case; it does not establish availability.
| Requested field | Definition and reason needed | Required / optional | Missing-value treatment | Feasibility status |
|---|---|---|---|---|
| ____ | ____ | ____ | ____ | ____ |
| ____ | ____ | ____ | ____ | ____ |
| ____ | ____ | ____ | ____ | ____ |
Resolve exclusions and geography together
A US headquarters requirement and a US operating-location requirement can describe different audiences. Choose the location that governs eligibility, then state whether any other location is merely context. Decide what happens when the qualifying location is unknown.
Write exclusions with the same care as inclusions. “Exclude customers” needs a definition of customer organization and an agreed way to match the buyer's suppression input. Decide how subsidiaries, multiple locations and uncertain matches will be treated. Agree an appropriate handling method before transferring any suppression material.
Worked example: a request for discussion
Fictional buyer planning example — not an AvalenData dataset, customer or offer. Every field and rule below is a buyer request awaiting confirmation. No personal records are used.
A fictional buyer is preparing a software campaign and wants to discuss a US business audience. The following brief records the buyer's starting position; it is not an accepted order.
| Requirement | Fictional buyer input | Status |
|---|---|---|
| Purpose and owner | Discuss an audience for a software campaign. The buyer's campaign owner approves the scope and intended use. | Requested; unconfirmed |
| Record unit | One professional contact associated with an organization. Discuss contact identification separately from organization matching. | Requested; unconfirmed |
| Included audience | Purchasing or operations functions at organizations the buyer defines as manufacturers. Agree classification rules for mixed or unclear business activities. | Requested; unconfirmed |
| Exclusions | Existing-customer organizations defined by the buyer; roles outside purchasing or operations. Agree suppression handling before any transfer. | Requested; unconfirmed |
| Geography | Organization operating location in the US determines eligibility. Headquarters is separate context only if feasible; it cannot substitute for an unknown operating location. | Requested; unconfirmed |
| Requested fields | Organization name, organization domain, role/function and operating country are requested as required. Job title is requested as optional. | Requested; unconfirmed |
| Missing values | Missing requested required information is an exception for buyer decision before agreement. Discuss missing domains and organizations with multiple locations. | Requested; unconfirmed |
| Delivery request | Discuss a CSV with the field labels defined below. No connector or automatic import is assumed. | Requested; unconfirmed |
| Acceptance criteria | Agree written audience, geography, required-field and exclusion rules, including who resolves exceptions. | Requested; unconfirmed |
| Open questions | Resolve manufacturing classification, missing domains, field feasibility and permitted use before agreeing the request. | Requested; unconfirmed |
Fictional requested field dictionary
All entries are requested and unconfirmed; this is not a catalogue of available fields.
| Requested field | Definition and reason needed | Required / optional | Missing-value treatment | Feasibility status |
|---|---|---|---|---|
| Organization name | Name of the organization associated with the contact, for buyer review of audience fit | Required by buyer | Flag for a buyer decision before agreement | Requested; unconfirmed |
| Organization domain | Organization website domain, proposed for discussion of organization matching; not a unique contact or location key | Required by buyer | Discuss missing or shared domains and an alternative matching rule | Requested; unconfirmed |
| Role/function | Purchasing or operations classification under a definition the buyer and provider would agree | Required by buyer | Flag unclear or missing classifications for buyer decision | Requested; unconfirmed |
| Operating country | Country of the organization's qualifying operating location, used for geographic eligibility | Required by buyer | Flag unknown qualifying location; do not substitute headquarters | Requested; unconfirmed |
| Job title | Title associated with the professional contact, for additional role context | Optional | Buyer proposes leaving blank if unavailable; discuss before agreement | Requested; unconfirmed |
Agree acceptance criteria before sourcing
Specify the rule, the evidence needed to agree it and the person who can decide an exception. Avoid leaving “good quality” as an undefined acceptance condition. At this stage, the task is to agree what will be requested and how exceptions will be handled.
Use this blank acceptance table alongside the worksheet:
| Criterion | Requested rule | Evidence to agree | Buyer decision owner | Unresolved exception |
|---|---|---|---|---|
| ____ | ____ | ____ | ____ | ____ |
| ____ | ____ | ____ | ____ | ____ |
For the fictional buyer, the starting criteria would be:
| Criterion | Requested rule | Evidence to agree | Buyer decision owner | Unresolved exception |
|---|---|---|---|---|
| Audience | Document manufacturing inclusion and purchasing/operations functions | Review the written selection definitions together | Buyer campaign owner | Mixed business activities or ambiguous roles |
| Geography | Use US operating location for eligibility | Confirm which operating-location meaning applies | Buyer campaign owner | Multiple locations or unknown operating country |
| Required fields | Agree each definition and missing-value treatment | Review the requested field dictionary and feasibility limits | Buyer campaign owner | Missing domains or other required information |
| Exclusions | Document excluded customer organizations and out-of-scope roles | Confirm the suppression approach and handling responsibilities | Buyer campaign owner | Uncertain organization matches |
These are proposed criteria, all awaiting agreement. No records have been tested or scored, and no match count is implied.
Review open questions before making a request
Check that every unresolved item has an owner and a next decision. For the fictional example, the buyer still needs to discuss:
Which manufacturing activities qualify, and who decides ambiguous cases?
Describe inclusion in terms someone else can interpret.
How will organizations with missing or shared domains be matched for exclusions?
Agree an appropriate handling method before transferring any suppression material.
Which requested fields and geographic definitions are feasible, and what limitations apply?
A requested field is not confirmation that it can be supplied.
What intended use is permitted, and what handling process applies to suppression material?
Confirm fields, coverage, feasibility and permitted use for your project before procurement.
Keep unresolved requests visible alongside the agreed scope. If a requirement changes, update the brief and revisit the affected agreement before proceeding.
Discuss your data requirements
Use your completed worksheet to explain the audience, requested fields, exclusions and decisions you need to resolve. Explore custom audience builds for the related service context, or discuss your data requirements through the existing contact path. Confirm fields, coverage, feasibility and permitted use for your project before procurement.