Configurable Ideal Customer Profile Fields for B2B Industries

Good to see you again. In the previous lesson, you mapped the tenant lifecycle: provisioning creates a governed tenant boundary, onboarding gathers the configuration needed for useful automation, active tenants run status-gated growth workflows, and export/offboarding remain controlled processes.

One of the first onboarding artifacts is an ideal customer profile, or ICP. For this command center, the ICP cannot be a static paragraph such as “mid-sized B2B companies.” It must become configurable data that different tenants can use to guide lead research, qualification, outreach, CRM routing, and later analytics—without your product assuming every client sells to the same industry.

Today you will define the field system behind that configuration: the portable core fields every B2B tenant can use, the rules attached to them, and the extension points that preserve flexibility without turning the product into an unsearchable collection of custom notes.

---

An ICP is an account-level decision policy

An ICP describes the organizations most likely to achieve success with a client’s offer and to be commercially viable customers. It is not exactly the same thing as:

• a buyer persona, which describes an individual stakeholder such as a VP of Sales or Operations Manager;
• a lead score, which is a later operational output calculated from evidence;
• a total addressable market, which may be much broader than the segment a client should pursue now.

For your product, an ICP should answer three distinct questions:

1. Fit: Does this company resemble the kinds of organizations this tenant can serve well?
2. Readiness: Is there evidence that the company has a timely reason to consider a solution?
3. Eligibility: Is there any reason this company must not be pursued?

The distinction matters because it prevents a common automation failure: treating a company that looks superficially attractive as automatically ready for outreach. A 300-person manufacturer may match a client’s target size and industry, for example, but have no observable transformation trigger, lack a required integration, or fall in a region the client cannot support.

The useful output is therefore a policy, not merely a list of attributes. It classifies accounts into intentional categories:

Tier	Meaning in the command center	Typical permitted action
Green	Strong, intended ICP fit with no confirmed exclusion	Research, qualify, and prioritize according to tenant workflow policy
Yellow	Plausible adjacent fit or incomplete evidence	Route for review, nurture, or include only in a controlled experiment
Red	Confirmed disqualification or prohibited segment	Suppress from active targeting and record the reason
Unknown	Insufficient information to determine fit	Enrich or request review; do not silently treat as a match

The unknown state is important. Missing revenue, technology, or location data is not evidence that a company is small, technology-incompatible, or outside the target region.

A client’s current inbound leads should inform the ICP, but should not define it by themselves. A durable ICP aims at customers who can obtain the promised outcome, sustain the commercial relationship, and be served within the tenant’s actual delivery constraints.

---

Use a universal field model, then configure it per tenant

The diagram below presents six useful ICP component families. Treat these as a common vocabulary for the product, not as six mandatory questions every client must answer on day one.

A cross-industry product should supply a small canonical field catalog. Each tenant chooses which fields matter, the accepted values or ranges, and whether a rule is required, preferred, experimental, or disqualifying.

1. Firmographic and geographic fit

These fields describe what the company is and where it operates. They are the most reusable fields across B2B industries.

Field group	Portable fields	Configuration examples
Industry	Industry, subindustry, business model, customer type	Include industrial services and B2B SaaS; exclude consumer retail
Company scale	Employee count, revenue range, locations, growth stage	Prefer 50–500 employees; require at least two operating locations
Geography	Headquarters country, operating regions, service region, preferred language	Target US and Canada; allow UK as yellow; exclude unsupported regions
Operating structure	Sales team present, operations function present, distributed teams, parent/subsidiary status	Require a revenue operations or sales operations function

Keep an industry’s raw source label separate from your normalized category. A website may call itself “industrial automation,” a data provider may label it “manufacturing,” and the tenant may want both mapped to industrial_manufacturing. Preserving the raw label makes future review possible; using a normalized category makes filtering and reporting reliable.

For numerical fields, configure structured ranges rather than vague text:

• Employee count: lower and upper bounds.
• Revenue: currency, period, lower and upper bounds.
• Company age: a range in years or incorporation-date rule.
• Locations: a count or named regions.

A phrase such as “mid-market” can remain a user-friendly label, but the system should associate it with explicit ranges that the tenant can edit.

2. Technographic fit

Technographics describe a company’s systems and technical environment. They are especially valuable when a tenant integrates with, replaces, or complements a specific tool.

Useful configurable fields include:

• CRM or customer-data platform;
• marketing automation or email platform;
• sales engagement platform;
• ERP, accounting, or operations system;
• e-commerce, support, or content-management system;
• cloud, on-premises, or hybrid deployment posture;
• technology maturity indicators, such as “uses a CRM” or “has no automated lead routing.”

A technology rule must support more than a simple “uses tool X” checkbox. For each technology category, let the tenant express whether a tool is:

• required for integration fit;
• preferred because it strengthens the use case;
• disqualifying because it conflicts with the offer;
• unknown, requiring enrichment or review.

For example, a consultancy selling GoHighLevel implementation could prefer companies using disconnected spreadsheets and inboxes, while a data-enrichment product might require a CRM with an accessible integration path. The same field category supports both cases; only the tenant’s policy changes.

3. Pain, use-case, and desired-outcome fit

These fields capture why the account may benefit. They should be represented as controlled concepts, not only as a free-text “notes” field.

A tenant might configure:

• target use cases, such as pipeline generation, proposal automation, CRM cleanup, or account expansion;
• pain indicators, such as manual lead routing, low follow-up consistency, or poor conversion visibility;
• desired business outcomes, such as reduce response time, increase qualified pipeline, or improve campaign attribution;
• delivery constraints, such as minimum project scope or a required implementation owner.

This group must distinguish between two things:

• The tenant’s hypothesis: “Companies with manual lead routing are a good fit.”
• The prospect evidence: “The company’s careers page describes hiring its first RevOps manager.”

The ICP stores the first. A prospect record later stores the second, with source evidence and confidence. Do not put unverified prospect claims into the tenant’s ICP configuration.

4. Purchase readiness signals

Fit and readiness are related, but they should never be merged into a single field. Readiness changes quickly; company size and industry usually do not.

Common readiness signals include:

• hiring for relevant roles;
• funding, acquisition, expansion, or new-location announcements;
• a newly announced transformation initiative;
• migration, modernization, or replacement of relevant systems;
• a requested demo, inbound form submission, event attendance, or content engagement;
• a newly created budget, procurement initiative, or executive mandate.

Each signal needs a freshness window. A job posting from two years ago is not the same as one posted last week. A tenant should be able to say, for example, that “hiring a sales operations manager within 90 days” is a strong signal, while an older signal is informational only.

5. Behavioral and stakeholder traits

Behavioral data is often the most powerful and the most context-sensitive category. It should be limited to data the tenant is entitled to use, such as activity from its own CRM, website, campaigns, product, or authorized integrations.

Possible behavioral fields include:

• key website pages viewed;
• form completion;
• event registration or attendance;
• email engagement, unsubscribe, or reply state;
• prior customer or opportunity history;
• content topics consumed;
• product usage, for tenants that sell software.

Stakeholder and buying-group conditions belong nearby because B2B purchases rarely involve one person. Configurable fields can include:

• target job functions;
• seniority bands;
• likely economic-buyer, champion, user, or technical-reviewer roles;
• required internal capability, such as a sales operations owner;
• purchasing style or procurement complexity.

These should be used cautiously. The system can represent a tenant’s desired buying environment, but it should not pretend to know a company’s culture or purchasing process without evidence.

---

Negative ICP criteria are first-class configuration

A robust system makes it easy to define who not to target. An exclusion is not merely a low score; it is a reason to stop a workflow, suppress a segment, or require an exception approved by a human.

Your default negative-ICP catalog should allow tenants to configure exclusions for:

Exclusion category	Example
Serviceability	The tenant does not operate in the prospect’s market or language
Commercial viability	Below the minimum contract, revenue, or maturity threshold
Technology incompatibility	A required integration is unavailable or a conflicting platform is in use
Regulatory or delivery constraint	The tenant cannot support the prospect’s compliance or security needs
Sales-motion mismatch	The account requires procurement complexity the tenant cannot support
Use-case mismatch	The prospect has a broad problem category but not the problem the tenant solves
Strategic exclusion	Competitors, existing customers, agencies, channel partners, or explicitly named accounts
Data and consent restriction	The record is suppressed or cannot be used in the intended workflow

Keep business fit exclusions separate from contact and outreach suppression. “Outside our supported geography” is an ICP decision. “This person unsubscribed from email” is a contact-level compliance restriction. Both can block outreach, but they must remain separately explainable and auditable.

---

Define fields with matching behavior, not just labels

A database column called industry is not yet an ICP field. It becomes one only when the system knows how to interpret it for a given tenant.

Every configurable ICP criterion should have the following properties:

Property	Why it is needed	Example
Stable field key	Keeps APIs and automation independent of display labels	employee_count
Display label	Makes the configuration understandable to tenant users	“Company size”
Scope	States whether it describes an account, stakeholder, buying group, or engagement	account
Data type	Enables consistent validation and filtering	Enum, range, boolean, date, multi-select
Allowed or normalized values	Prevents incompatible labels from fragmenting data	b2b_saas, professional_services
Operator	States how to evaluate the condition	in, between, contains_any, exists
Policy role	Defines whether it is required, preferred, experimental, or disqualifying	required
Unknown-data policy	Determines what happens when evidence is absent	route_for_enrichment
Evidence expectation	States what level of support is needed for a later decision	Public source, CRM data, tenant confirmation
Freshness rule	Prevents time-sensitive signals from remaining active forever	90 days for a job posting

The data types should be deliberately limited at first:

• Enumerations for industry, country, CRM category, use case, and role type.
• Numeric ranges for employee counts, revenue, site count, and contract size.
• Booleans with unknown support for “has a dedicated sales function” or “uses a CRM.”
• Dates and durations for signal recency.
• Multi-select values for technologies, regions, target roles, and use cases.
• Short controlled text only when no reliable taxonomy exists.

Avoid allowing arbitrary logic expressions in a tenant-facing form during v1. A carefully designed set of operators is easier to validate, explain, test, and later translate into deterministic qualification rules.

Rule precedence

When multiple criteria apply, establish precedence now:

1. A confirmed exclusion takes priority over a positive match.
2. A missing required field results in unknown or review, not an automatic match.
3. A green profile requires the tenant’s required conditions to be satisfied.
4. Yellow profiles represent explicitly configured adjacent segments or controlled tests.
5. Preferences can improve prioritization later, but should not override exclusions.

This policy is much safer than a single opaque numeric score. Later, you will build an explainable qualification rubric and scoring model; for now, make sure the ICP configuration contains the structured rules that such a model will need.

---

A practical v1 configuration shape

The following is a blueprint representation, not a final database schema. It demonstrates the separation between profile metadata, rules, and exclusions.

{
  "profile_name": "US Growth Services Core ICP",
  "purpose": "Outbound prospecting and inbound prioritization",
  "green_rule": "all_required_conditions",
  "yellow_policy": "human_review_or_inbound_only",
  "criteria": [
    {
      "field_key": "industry",
      "scope": "account",
      "operator": "in",
      "values": ["professional_services", "b2b_saas"],
      "policy_role": "required",
      "unknown_policy": "route_for_enrichment"
    },
    {
      "field_key": "employee_count",
      "scope": "account",
      "operator": "between",
      "min": 25,
      "max": 500,
      "policy_role": "required",
      "unknown_policy": "human_review"
    },
    {
      "field_key": "sales_operations_function_present",
      "scope": "account",
      "operator": "equals",
      "value": true,
      "policy_role": "preferred",
      "unknown_policy": "continue_with_caution"
    },
    {
      "field_key": "recent_relevant_hiring",
      "scope": "account",
      "operator": "exists_within_days",
      "value": 90,
      "policy_role": "readiness_signal",
      "unknown_policy": "not_a_disqualifier"
    }
  ],
  "exclusions": [
    {
      "field_key": "operating_region",
      "operator": "outside",
      "values": ["US", "Canada"],
      "reason_code": "unsupported_market"
    },
    {
      "field_key": "industry",
      "operator": "in",
      "values": ["consumer_retail", "gambling"],
      "reason_code": "strategic_exclusion"
    }
  ]
}

Notice several design choices:

• The tenant controls values and policies, while your product controls valid field keys, types, and operators.
• recent_relevant_hiring is a readiness signal, not a requirement for the company to be a fit.
• unknown_policy makes missing data visible instead of silently converting it into a negative result.
• Exclusions carry a reason_code, so a reviewer can later understand why an account was blocked.
• This profile does not store a prospect’s actual industry, employee count, or job posting. It only defines the tenant’s target conditions.

For cross-industry flexibility, use a core-plus-extension model:

1. Provide the canonical field catalog described in this lesson.
2. Let tenants enable only the fields relevant to their motion.
3. Permit tenant-defined fields only through a controlled registry with a label, scope, type, allowed values, and matching behavior.
4. Require custom fields to follow the same unknown-data and evidence policies as standard fields.
5. Preserve the tenant’s original configuration language alongside normalized values where helpful.

A manufacturing client might add erp_modernization_status. A professional-services client might add minimum_project_value. Both can be custom fields, but both must behave like structured rules—not unbounded notes that later automation cannot evaluate.

---

Build the blueprint artifact for your SaaS

Create docs/product/icp-field-model.md. This is a product-design artifact, not yet a migration or API contract.

Include these sections:

1. Definitions: ICP, buyer persona, fit, readiness, exclusion, green/yellow/red/unknown.
2. Canonical field catalog: the core groups and fields your product supports.
3. Field contract: key, scope, data type, operators, allowed values, unknown-data policy, and evidence expectation.
4. Tier policy: how green, yellow, red, and unknown classifications are intended to behave.
5. Negative ICP catalog: the exclusion categories and reason codes.
6. Extension policy: when a tenant can add a custom field and which data types are allowed.
7. Open decisions: industry taxonomy, revenue normalization, default signal freshness windows, and which engagement data sources are permitted.

Keep unresolved decisions explicit. For example:

“Industry taxonomy source: TBD. The product must preserve raw source labels and map them to a normalized tenant-configurable category.”

That is much stronger than prematurely hard-coding an industry list into frontend forms or a database enum.

---

The key result of this lesson is a configurable ICP model that works across B2B industries: firmographics and geography describe stable fit; technographics, pain points, and stakeholder conditions explain compatibility; readiness and behavior capture timing; success metrics anchor the intended outcome; and explicit exclusions protect the workflow from poor-fit accounts.

Most importantly, an ICP is a transparent tenant policy with structured fields, operators, unknown-data behavior, and exclusion reasons—not a generic marketing description or a black-box score.

Next, you will turn the lifecycle and ICP blueprint into testable MVP acceptance criteria for each stage of the growth workflow.