3. ICP & Account Architecture

Most teams score fit against one dimension — usually firmographic (size, industry, revenue). That catches theoretical fit but says nothing about whether an account is ready to buy right now, which is the actual question a scarce deployment team needs answered.

Company size, industry, revenue band. The easiest layer to score, and the least predictive on its own — thousands of companies can match a firmographic profile with zero near-term buying intent.

Existing tool stack, technical maturity, cloud vs. on-prem posture. This layer predicts deployability, not just fit — an account with no data infrastructure can be a perfect firmographic match and still be six months of prep work away from a real engagement.

Trigger events — a leadership change, a funding round, a public AI initiative — that indicate active buying intent right now, not just theoretical fit. This is the layer most ICP frameworks skip, and the one that actually predicts timing.

A company can score well on any one layer and still be a poor near-term target. Scoring across all three is what turns a target list from a wish list into something a deployment team can actually act on this quarter.

When a sales lead hands you an account that "matches the ICP," the first question is which layer they mean. A firmographic-only match with no trigger event is a very different priority than an account showing all three signals at once.

An explicit anti-ICP isn't about turning away revenue — it's a filter applied early, before discovery time is spent on an account that was always going to fail on a predictable dimension.

An account that fails the seven-dimension check from Section 2 — no ground truth, no accessible data, ownership disputes — is a disqualifier regardless of how enthusiastic the buyer is. This isn't a "revisit later" flag; it's a hard stop until the underlying data problem is fixed on their side.

Without an executive sponsor willing to spend political capital, a deployment has no one to unblock it when the inevitable internal resistance shows up. This is different from a champion (from Section 2) — a champion advocates, a sponsor has the authority to remove a blocker.

Deep integration debt that would consume the engagement before any value ships, or unit economics where deployment cost exceeds any plausible contract value, are disqualifiers even when every other signal looks strong.

Using this as a filter before discovery time is spent — not as a post-mortem explanation for why an account failed — is what actually protects capacity. If a disqualifier is visible in the first call, that's the moment to apply it.

Most prioritization frameworks ask "how much value could this account create." That question alone is incomplete — it ignores what the value costs to deliver.

A high-value account requiring six months of custom integration work may be a worse use of capacity than three mid-value accounts that each ship in three weeks. Ranking by value alone routinely misallocates a scarce team toward a small number of slow, prestigious accounts.

Prioritize on potential value relative to deployment cost — a ratio, not a raw score. This surfaces accounts that look modest on value alone but are fast, low-risk, and compounding quickly once delivered.

A working rubric weighs: firmographic/technographic/behavioural fit (from ICP layers), estimated deployment cost (from data readiness and integration complexity), and strategic value (does this account's use case generalize to others). Applied consistently, not judged account-by-account from gut feel.

When two accounts compete for the same deployment slot, the rubric — not seniority, urgency of the ask, or who shouted loudest — should decide. That's what makes the prioritization defensible later, including to the account that didn't get picked.

Produce a scoring rubric — weighted criteria across firmographic, technographic, behavioural, and estimated deployment cost — applied consistently across the pipeline. This becomes the standing tool used every time two accounts compete for the same deployment slot.

Section 2 introduced Operator/Buyer/Champion/Blocker as the core four. A real enterprise account has more texture than that — IT, security, legal, and procurement each carry independent power to slow or stop things, often invisibly.

For every stakeholder, the useful question isn't "what's their role" — it's "what makes them look good or bad from this deployment." A security reviewer isn't motivated by your success; they're motivated by not being the person who approved something that later became an incident.

Power to approve, block, or just complain doesn't track cleanly with org chart position. A mid-level security engineer can hold veto power an SVP doesn't have over a specific technical decision.

The most dangerous blocker is the one not in any meeting — a security reviewer who can veto architecture choices weeks in, or an operator (from Section 2) who quietly under-adopts the tool because it threatens their role. Mapping this in advance surfaces it before it becomes a surprise.

Building this map during discovery — alongside the Operator/Buyer/Champion/Blocker work from Section 2, not instead of it — is what turns "the deployment mysteriously stalled" into "we knew security would need six weeks for this, and planned around it."