How to Build an ICP With Data for Better Account Targeting

An ideal customer profile is useful only when it changes what your team does next. This guide on how to build an ICP with data focuses on turning a broad description of a good customer into rules for account selection, contact selection, and exclusions.

Define an ICP as a decision system for how to build an ICP with data

An ICP should tell your team which accounts to pursue, how to prioritize them, and which people to engage.

Many teams start with a descriptive profile: a company type, a rough size band, a few industries, and a list of buyer titles. That is a useful input, but it is not yet an operating model. A descriptive document cannot reliably determine whether an account belongs in a campaign, should be routed to a rep, or should be excluded from a territory.

A decision-oriented ideal customer profile has clear inputs and outcomes:

• Inputs: company, contact, and contextual data.
• Rules: inclusion criteria, exclusion rules, and edge-case handling.
• Outcomes: segment assignment, priority, owner, audience eligibility, or review status.

Start with the GTM decision you need to improve. The decision shapes the data you collect and the precision you need.

For example:

• Prospecting: Decide which net-new accounts enter an account list.
• Routing: Decide which accounts go to a particular team, territory, or motion.
• Campaign audience creation: Decide which accounts and buying roles should receive a message.
• Expansion: Decide which existing customers resemble accounts that may support another product, team, or use case.
• Account review: Decide which accounts need manual research before they are assigned.

Do not try to use a single rule set for every decision. A broad campaign audience may tolerate an account that needs review. A high-priority outbound list may not.

You also need to separate the company-level profile from the people you intend to engage. A matching company is not the same thing as a ready-to-contact buyer committee.

Your company profile might include:

• Industry or operating model.
• Location and country.
• Employee count or employee range.
• Founding year.
• Published company description.
• Domain.
• Revenue, funding, or web-traffic context when those fields are relevant to your decision.

Your people profile might include:

• Department.
• Seniority.
• Current title.
• Location.
• Current employer.
• LinkedIn URL.
• Work email when an email lookup is justified.

This separation matters because company qualification and contact selection fail differently. You may have a strong target account with no suitable contact identified yet. You may also find a senior contact at a company that does not meet your firmographic segmentation rules. Treat those as distinct states.

Choose data signals that match the decision

A useful data signal changes an operational decision; an available signal does not automatically belong in your ICP.

Start with company signals because they define the account universe. Industry, location, headcount, description, domain, and founding context can all support account selection when they map to a real buying condition.

For example, an industry field can be useful when your product serves a known set of operating environments. It is less useful when teams use a broad industry label as a shortcut for “companies we like.” In that case, the company description may be a better signal because it reflects what the business says it does.

Use company data with a stated purpose:

Signal	Useful when it changes a decision	Common misuse
Industry	Your motion is designed for defined sectors	Treating broad classifications as proof of fit
Location or country	Coverage, language, legal, or territory rules apply	Assuming headquarters reflects every operating market
Employee count	The product, sales motion, or account owner changes by size	Treating a size estimate as an exact headcount
Company description	You need to identify a business model or use case	Using generic marketing language as a hard qualification rule
Domain	You need entity resolution, deduplication, or company enrichment	Assuming similar domains belong to the same account
Founded year	Company maturity affects the motion	Treating age as evidence of current budget or intent

Contact signals should answer a different question: who is relevant within an account that already qualifies?

Department, seniority, title, and location are usually the core fields. Department and seniority are especially useful because they turn title variation into controlled categories. A title can vary widely between companies. A normalized department such as engineering, sales, finance, or operations gives you a more stable input for buyer committee rules. A normalized seniority band such as manager, director, vp, or c_level does the same for decision authority.

Titles still matter. Use them when the role itself is meaningful to your motion. For example, you may want a specific functional owner while also including a wider department and seniority band for related stakeholders.

Keep contact location separate from company location. A company may fit your target geography while the relevant team operates elsewhere. That may affect routing, message language, or whether a person belongs in an audience.

A practical test for each field is simple:

If this field changed, would the account’s segment, priority, owner, eligibility, or contact list change?

If the answer is no, do not put the field in the matching logic. You can still retain it for research or reporting. Just do not let it create the appearance of precision.

Write inclusion criteria and exclusion rules

Write ICP criteria as observable conditions that can be searched, enriched, or reviewed consistently.

Broad statements create inconsistent account selection. “Modern technology companies,” “high-growth businesses,” or “companies with complex operations” may be useful strategy language, but they are not rules. Different people will interpret them differently, and the resulting list will drift.

Convert them into conditions that a workflow can evaluate.

Instead of:

• “Target larger software companies.”
• “Focus on operational leaders.”
• “Avoid companies that are too early.”

Write conditions such as:

• Include companies whose published description indicates a software business model.
• Include companies within the employee ranges assigned to your sales motion.
• Select contacts in operations, finance, it, or another defined department.
• Prioritize contacts with director, vp, c_level, or founder seniority when the motion requires an executive buyer.
• Route accounts with incomplete company context to review instead of treating them as qualified.
• Exclude categories of company that your product does not serve.

The exact criteria depend on your business. The important part is that another person can apply them and reach the same result.

Exclusion rules deserve as much attention as inclusion rules. They prevent a target account list from accumulating accounts that look superficially similar but belong to a different motion.

Common exclusion categories include:

• Business models your product does not support.
• Countries or regions outside the intended market.
• Existing customers, partners, competitors, or internal accounts.
• Account types assigned to a different segment.
• Companies below or above the scope of a particular motion.
• Departments or functions that should not receive a given message.
• Contacts whose role does not participate in the buyer committee.

Be explicit about edge cases. This is where many ICP documents stop being useful.

For example, define how you will handle:

• A parent company and a subsidiary with different domains.
• A company that operates in multiple industries.
• A company whose location is published at headquarters but whose relevant team is elsewhere.
• An account with a matching title but an unrelated department.
• A founder at a small company versus a founder at a larger, established organization.
• A company with missing employee data but a clear published description.

You do not need to force every edge case into automatic qualification. A review state is often more honest than a false pass or false rejection. The rule should specify when human review is required and what evidence resolves it.

Use enrichment to complete the ICP inputs

Enrichment helps you fill the inputs required by your ICP; it should not silently invent a qualification decision.

Start with the identifiers you already have. A domain, company name, LinkedIn URL, work email, or a person’s name plus employer can anchor an enrichment request.

Company enrichment can resolve a company identifier into usable account context. Depending on the available company record, that may include company name, company domain, LinkedIn URL, location, country, headline, industry, employee count, employee range, founded year, annual revenue, total funding, latest funding round, and monthly visits.

That context helps you apply firmographic segmentation to an account list that started with only domains or company names. It can also support deduplication and account review. A domain is generally a stronger operational key than a display name, but it still needs review when you are dealing with corporate families, brand domains, or regional entities.

People enrichment works differently. It resolves identifiers you already hold into current person context, including current employer, title, normalized seniority, normalized department, location, country, and LinkedIn URL. You can request a work email by naming the email field. Email addresses are returned with an email status: verified, probable, unverified, risky, undeliverable, or unknown.

Search serves a different use case. Use people or company search when the ICP criteria are specific enough to identify net-new accounts or people you do not already know. A company search can start from firmographic and natural-language criteria. A people search can identify people based on an ideal-customer-profile description, titles, seniority, department, location, and employer context.

Enrichments supports both patterns through its API, CSV workflow, chat agent, and MCP server. The right surface is the one that fits where your account-selection process starts. The rule set should remain the same.

Treat missing data as an explicit state. Missing employee count does not mean a company is small. Missing title does not mean a person lacks influence. Missing email does not mean the person is not a relevant contact.

Use states such as:

• Matched: the account meets the defined inclusion criteria.
• Excluded: the account meets a documented exclusion rule.
• Needs review: a required field is missing, ambiguous, or conflicting.
• Not found: the identifier could not be resolved.
• Contact gap: the company matches, but no suitable person has been identified.

This prevents an empty field from becoming an undocumented negative signal.

Translate the ICP into repeatable operating rules

Your ICP becomes operational when every account follows the same matching sequence.

A practical sequence looks like this:

• Normalize the identifier you have, such as a company domain, company name, LinkedIn URL, work email, or name plus employer.
• Resolve company data where the required ICP inputs are missing.
• Check exclusion rules before assigning a target segment.
• Apply company inclusion rules and assign the account to a defined segment or review state.
• Select relevant departments, seniority bands, titles, and locations for the buyer committee.
• Resolve or search for people only after the account qualifies for the intended motion.
• Apply contact exclusions and message-specific audience rules.
• Send the result to the next system only after the match decision is recorded.

Keep matching logic separate from enrichment rules and CRM writeback rules.

Matching logic answers: does this account qualify, and why?

Enrichment logic answers: which fields do we need to resolve before we can decide?

Writeback logic answers: which fields should be stored, updated, or left untouched in your CRM or warehouse?

Combining these layers makes auditing difficult. If an account changes segment, you need to know whether the cause was a new company record, a revised ICP rule, a changed mapping, or a writeback process. Separate logic gives you that answer.

Normalized fields reduce dependence on title wording. For example, an account rule can select contacts in marketing at director, vp, or c_level seniority without maintaining a long and fragile title list. Then you can use titles as a narrower refinement for the specific message or workflow.

Do not treat normalization as perfect classification. A department and seniority value are useful rule inputs, but ambiguous roles still exist. Record exceptions rather than repeatedly adding one-off title conditions that make the system impossible to maintain.

For implementation detail, use the API documentation as the source of truth for request schemas and response handling. Requests can return results inline or as a job, depending on request size, requested fields, and asynchronous preferences. Your workflow should read job.status and handle returned result wrappers rather than assuming every request follows the same path.

Maintain an ICP as market and data change

An ICP needs review because your market, motion, and live data can change.

Do not treat the planning document as the final artifact. Treat the operating rules as a versioned decision system. When an account is disputed, when a rep finds a recurring mismatch, or when a required field is often absent, that is evidence about the rule set.

Capture workflow feedback in a structured way:

• Accounts marked as wrongly included.
• Accounts marked as wrongly excluded.
• Recurring exceptions that require manual review.
• Missing fields that block a decision.
• Company descriptions that do not fit existing categories.
• Buyer committee roles that repeatedly appear in successful workflows.
• Titles that normalize poorly for your intended use.
• Changes in territory, product, or campaign rules.

Review these inputs against the original decision. Do not add a criterion simply because it appears in an isolated account. Add it when it improves consistency for the GTM decision you are trying to make.

Live enrichment also changes how you should manage target account data. The same identifier can legitimately return different information later because enrichment is not a licensed static database. Refresh company or person inputs when timing matters, especially before a new campaign, account assignment, or contact-selection pass.

Preserve the rule set that produced each decision even when the source data changes. Store the criteria version, the fields used, the result state, and the date of the decision in your own system. That gives you a way to explain why an account entered a segment at the time, compare later outcomes, and revise the rules without losing the earlier record.

A maintained ICP is not a larger list of attributes. It is a smaller set of explicit rules that your team can apply, inspect, and improve.