- Set the Compiler Boundary for ICP Targeting
- Compile Each Fit Statement into a Field, Operator, and Value
- Return Eligible, Ineligible, or Unknown Without Silent Promotion
- Version the Predicate Set When Fit Logic Changes
- Debug the Eligibility Contract Before It Becomes a List
- Frequently asked questions
ICP targeting requires explicit inclusion and exclusion rules rather than prose alone. Translate each company-fit statement into a record rule that can return eligible, ineligible, or unknown, and reject any criterion that cannot be evaluated against an account record.
Set the Compiler Boundary for ICP Targeting
"We already wrote a detailed persona. Why turn it into rules?" The objection is fair when the work is choosing a message, exploring a market, or understanding a buyer. It is not fair when your database must decide what one company record means. ICP targeting starts at that narrower point. It does not create a full targeting strategy, allocate attention, or produce a final account list. Its job is to make a company-fit statement evaluable for one account.
The skeptic is right that a persona can be rich and useful. Salesforce's buyer-persona guidance, checked September 2026, frames personas around an individual's motivations, goals, pain points, and behavior. You can use those inputs for human judgment. But they do not by themselves answer whether a particular company record belongs inside your eligibility boundary. A record cannot reliably test a motivation that has not been observed for that company.
Company-fit attributes are not buyer-persona motivations
That distinction gives the compiler its boundary. HubSpot's ICP material, checked September 2026, describes an ideal customer profile at the company level through attributes including industry, size, budget, and buying process. These are not a complete definition of fit for every team. When you translate your ICP, treat them as examples of company-level statements that can be carried by fields on an account record. Keep buyer motivations nearby as context, but do not confuse them with a predicate that the record can resolve.
One account record must return one eligibility state
The observable result is modest but decisive: the same record receives the same declared state when the same rule version evaluates it. Can you rerun your rule and expect that result? That is what makes a fit statement targeting logic rather than a note for a future meeting. If two reasonable operators can read the prose and reach different outcomes, the statement has not yet crossed the boundary. The next step is not to debate the account. It is to make the statement testable.
Compile Each Fit Statement into a Field, Operator, and Value
"Rules will make our ICP too rigid," says the skeptic. They can, if you pretend that an unobserved judgment is a fact. So what should you do instead? Do not preserve vague prose. Separate what the record can test from what remains a research question. A fit statement becomes an eligibility predicate only when it names a field, an operator, and an approved value or value set. Without all three, a tool has nothing deterministic to evaluate.
- Field: identify the company attribute you expect the account record to hold.
- Operator: choose the comparison your rule permits, such as equals, is one of, or is absent.
- Value: state the approved value set or named condition against which you test that field.
Choose the account field that can carry the stated criterion
Start by asking yourself the hostile but useful question: where, exactly, does this statement live on your account record? A phrase such as "companies like our best customers" has no field yet. You can translate it into a company attribute only after your team specifies the attribute it means. If no record field can carry the criterion, keep it as a hypothesis for research rather than silently treating it as an inclusion rule.
Pair a testable operator with an approved value set
The field alone does not decide anything. The operator says how you read the field, and the value set says what your team will accept for this version of the rule. Are you asking a system to infer a business judgment from a paragraph? If so, pause there. A system such as OKKI Go should receive a clear contract instead. The contract can be revised later, but its current form must let the same observed value produce a stated result. This article does not choose the market values for you or rank tools that might hold them.
Return Eligible, Ineligible, or Unknown Without Silent Promotion
The skeptic now has the stronger point: a rule can be explicit and still mislead you if missing data gets treated as a pass. That objection wins. You should not use a two-way pass or fail design when the required field is blank, stale, or contradictory, because it invites silent promotion. ICP targeting needs a third return, unknown, so that your record can remain unresolved without being turned into an apparently positive fit decision.
Salesforce's ICP guidance, checked September 2026, asks teams to document company characteristics, buying signals, and barriers that prevent movement. Before you decide a result, that supports recording what can advance or block your company-level fit judgment. It does not prescribe a universal threshold or state model. The three states here are therefore a bounded operating contract: they make the result of your own predicate visible, rather than claiming that every company should be judged by the same market rule.
Eligible requires a predicate that resolves true
Eligible is not a feeling that your record looks promising. It means every required inclusion predicate for the stated scope resolves true and no declared exclusion predicate resolves true. You do not need to make that judgment intuitive. The wording matters because a positive signal that is merely present is not automatically sufficient. The rule specifies which observations are required, and the record earns eligibility only by satisfying that rule as written.
Ineligible requires a stated exclusion condition
Ineligible also needs more than disappointment. You need a stated exclusion condition that resolves true. That protects your team from treating a missing positive signal as proof of a negative condition. It also gives you a useful audit question: can another person point to the condition that excluded this record? If not, you should not present the result as a confident rejection.
Unknown remains unresolved when the required field is absent or conflicts
Unknown is not an error bucket and it is not an invitation to guess. Return it when you lack a required field, when observed values conflict under the current contract, or when the predicate cannot resolve. In a company-research workflow such as OKKI Go, that boundary lets you preserve the unresolved state instead of converting uncertainty into an apparent match. What happens after that is outside this article: no account scoring, sourcing, deduplication, or list export follows from the state itself.
Version the Predicate Set When Fit Logic Changes
A skeptic asks, "Is versioning too formal for a simple ICP?" It is unnecessary only while your predicates never change. The moment you change a field, operator, or approved value set, your team is using a different eligibility contract. Treating that as an invisible edit makes it impossible to explain why the same company may receive a different state over time. Versioning is not a claim about better performance. It is a definition of which rule was in force.
Consider a bounded scenario that you can use to test traceability. The operating constraint is that the team may evaluate only the fields named in its current contract. Scenario assumption: one company record contains the required company attribute and a documented value, while a second required field is absent. Under revision R1, the input parameters make that absent field required, so the second record returns unknown. The mechanism change is a proposed R2 that changes the predicate set. The observable result is not a promised lift, but a changed eligibility reading for the same record. The decision consequence is to record R2 with its effective date before you use it. This example tests rule traceability, not market thresholds or a final list.
Give every predicate a revision identifier and effective date
A practical test is simple. Can you read a past eligibility state and identify the record, the predicate revision, and the effective date? If one is missing, you cannot interpret the state reliably. A revision identifier does not make your rule correct. It makes the rule inspectable, which is the prerequisite for challenging it honestly when fit logic changes.
Keep the fit statement and its supporting evidence traceable across revisions
Keep your original fit statement beside the field, operator, value set, and the evidence or decision note that justified that version. You are not turning every predicate into a research project. You are preventing a later reader from mistaking a changed rule for an unchanged ICP. Where the support is only an internal judgment, label it as such rather than borrowing authority from a general ICP definition.
Debug the Eligibility Contract Before It Becomes a List
The final objection is practical: "Why not start building the list and fix the rules as we go?" Because list work can conceal an ambiguous predicate behind apparently useful records. Before you hand off the contract, test it against representative records only to expose whether each required condition can resolve true, false, or unknown. The point is not to prove coverage, measure outcomes, or manufacture a target list. It is to find language that your record cannot evaluate.
For each representative record, ask the same questions: Which field do you read? Which operator applies? Which value or condition is approved? Which state follows, and why? A result that depends on an unwritten exception is a debugging finding, not a reason for you to improvise. Revise the predicate set, give the revision an effective date, and repeat the reading. This is the limitation the skeptic wanted preserved: a well-formed rule does not prove the underlying ICP is wise. It only makes the eligibility decision challengeable.
Use representative records only to expose ambiguous predicates
A representative record is a diagnostic surface, not an approval sample. Choose records that make your wording work hard: a clear match, a clear exclusion, an absent required field, and a conflicting observation. If you cannot state the return for one of them without adding a new rule aloud, the contract is still descriptive prose. Do not solve that gap by silently promoting the account.
Hand the frozen predicate contract to strategy and list-production owners
Once your predicates, states, revision, and trace notes are frozen, hand that eligibility contract to the owners of strategy and list production. Their work begins only once you freeze this eligibility decision. Allocating attention, resolving entities, managing exceptions, deduplicating, and producing a list are separate decisions. You can now agree with the skeptic on one conclusion. An ICP earns its place in targeting only when an account record can evaluate it, show uncertainty, and preserve the rule that produced the result.
Make the fit statement testable before it reaches a record. If a database cannot evaluate the criterion, retain it as context or a research hypothesis, not as an eligibility decision.
Frequently asked questions
What does ICP targeting describe for a company record?
It describes whether the declared company-level eligibility predicates resolve to eligible, ineligible, or unknown. It does not describe an individual buyer's motivations or choose a contact.
What evidence should remain attached to an ICP eligibility predicate?
Keep the fit statement, field, operator, approved value set, revision identifier, effective date, and the evidence or decision note that supported that version. This preserves traceability without claiming an outcome metric.
What boundary limits the use of ICP targeting rules?
The rules stop at the account-level eligibility decision. They do not allocate strategy resources, source or deduplicate accounts, score them, export a list, or prescribe outreach.
When should ICP targeting change the next action?
It should change the next action when a representative record exposes an ambiguous predicate, a required field is absent or conflicts, or the fit logic itself changes. Revise and freeze the contract before downstream owners act on it.
