A match is a start, not a priority
A territory list can be full of companies that match your ideal customer profile and still leave the central sales question unanswered: which account deserves attention first? An ICP is designed to narrow a market. It is not designed to prove that a particular buyer has a workable business case, a feasible deployment, or a reason to move now.
That distinction matters when a team is deciding where to spend its limited campaign and discovery time. A profile match may tell you that an account belongs in the conversation. It does not tell you whether the conversation is likely to lead anywhere useful.
The better question is not simply, “Does this company look like our customer?” It is, “Can this specific buyer create enough value with this specific product to justify the change?” That question turns a broad account list into a reasoned opportunity order.
Use ICP as the baseline
Begin with the facts that establish basic relevance: industry and vertical, revenue and company size, business model, and the channels through which the company sells. These dimensions help identify where a product may belong. They also keep a sales team from treating every company in a large territory as equally plausible.
But baseline fit is only one layer. Two businesses can share an industry, revenue range, size, and e-commerce channel while having sharply different customer behavior, operating realities, and potential return. The work after ICP is to find those differences rather than smooth them away.
For B2B software sellers, this is especially important when recurring contract value and implementation effort are meaningful. A profile can support a hypothesis. It cannot carry the full burden of qualification.
ICP match
Industry · Vertical · Revenue · Channels · Business model
Full cost ↔ realized value
Deployment, operation and assumptions. Buyer ROI—not the seller’s lead-purchase return.
Technical fit + intent + BANT
Compatible systems. Product-specific evidence. Budget, authority, need and timing.
Evidence-backed account report
Sources, unknowns and a supported next move—not an automatic pass.
Every added layer may reveal a reason to hold or reject. Qualification is an investigation, not a procession of green checkmarks.
The ROI belongs to the buyer
The economic model should measure the buyer’s return from deploying the software, not the seller’s return from purchasing a lead and not the seller’s projected contract revenue. Seller economics matter to a commercial plan, but they do not establish whether the buyer should make a change.
Start with the product-specific formula: what does the software actually change, and which buyer metrics does that change affect? Then use the buyer’s starting numbers and a reasonable improvement range. For a loyalty product, the relevant inputs could include average purchase value, purchase frequency, reachable revenue, margins, participation, and the full set of costs.
Those costs are not an afterthought. Subscription fees, implementation and integration, staffing, rewards, campaigns, and ongoing operating costs all belong in the picture. Assumptions should be labeled, unknowns should remain visible, and the buyer should validate the business case. A model is a disciplined starting point for a conversation, not a substitute for the buyer’s own facts.
Same profile, different economics
Consider two fictional e-commerce apparel companies, each generating $500 million annually. On an account list, they can look almost interchangeable. One sells bridal dresses with an average order value of $5,000 and roughly one purchase per customer in the measurement year. The other sells everyday apparel with an average order value of $200 and customers purchasing about six times a year.
For software intended to increase repeat purchases, those patterns create very different opportunity. A bridal purchase is often tied to one event. It would be unsound to assume a customer returns for another wedding dress every year. Everyday apparel has a repeat-purchase pattern that may provide a different basis for a loyalty business case.
That does not make the bridal company a bad business. It may be better suited to a different product outcome, such as reviews or referrals that support new-buyer acquisition. The point is precision: assess whether this buyer fits this particular product, rather than assuming one general category of company fits every promise.
Bridal dresses
- Annual company revenue
- $500 million
- Average purchase value
- $5,000
- Purchases per customer / measurement year
- About 1
Everyday apparel
- Annual company revenue
- $500 million
- Average purchase value
- $200
- Purchases per customer / measurement year
- About 6
Fictional inputs quoted from the supplied film. Neither revenue nor purchase frequency confirms a budget or an intention to buy.
Model the full arc, not the first invoice
A credible model looks beyond the first year. Implementation costs are often concentrated at the beginning, adoption takes time, and the ongoing cost structure continues after launch. A negative first year can be compatible with a strong long-term business case; it can also be a signal to investigate more closely. The model should show annual results, cumulative net gain, and the anticipated payback point.
In the narration’s illustrative loyalty model, the fictional everyday-apparel company is modeled at about negative $157,000 in year one, turns cumulative positive by the end of year two, and reaches about $5.18 million in cumulative net gain by year five. The fictional bridal company, using the same offering, is modeled at a five-year loss of about $2.19 million.
These figures are example assumptions, not client outcomes or a promise of results. The full input schedule is not provided in the narration, so the intervening model years cannot be reproduced from it. Realized time is not automatic cash savings, either; value depends on adoption, execution, and the buyer’s actual inputs.
Modeled annual result after the initial deployment costs.
Exact intervening values are not supplied in the narration.
Modeled cumulative net gain—not gross revenue.
The fictional bridal example is modeled at a five-year loss of about $2.19M. These are quoted illustrative milestones, not a scale chart, independently reproducible input schedule, client result or guaranteed return.
A paper return must be deployable
Economic potential has to survive operational reality. Ask whether the software can work with the buyer’s existing systems, data, and required integrations. A strong return on paper is only useful when the product can actually deliver the mechanism behind that return.
Then map channel coverage. Does the product support how the company actually sells: e-commerce, physical stores, distributors, business customers, direct-to-consumer, or a combination? If a material channel is unsupported, its proposed value should come out of the model and the return should be recalculated.
This is not a reason to force every account into a pass/fail decision immediately. It is a reason to name the gaps before a sales narrative is built around an impossible deployment. Known material failures justify rejection. Important unknowns justify a hold while they are validated.
Intent and timing are evidence questions
Buying intent should come from credible evidence, not profile inference. Relevant research activity, evaluations, business initiatives, and other available evidence can identify where to investigate. A signal is a reason to look closer; it is not a confirmed decision to buy.
Timing needs the same discipline. An announcement is not automatically a date. The useful question is whether a dated event creates a plausible decision window: a contract expiration, acquisition, scheduled rollout, expansion, or another event tied to the software need and a likely decision date. A strong-fit account with later timing may remain in the pipeline. A strong-fit account with a credible near-term event can move toward the top.
This evidence-led view also clarifies BANT. Budget is not the same as buyer revenue or modeled ROI. Authority, need, and timing are separate questions as well. A buyer may have strong modeled economics without confirmed budget, the right buying role, an active need, or a date for action. Keeping those distinctions visible produces a more honest qualification conversation.
Actual funding—not company revenue and not modeled ROI.
ILLUSTRATIVE: BUDGET UNKNOWNThe decision roles, approval route and people who can authorize change.
A demonstrated product-specific problem, not assumed pain.
A dated buying window, not a generic announcement.
Unknown → hold and validate. Known material failure → reject. No named people, confirmed budget or buying commitment is fabricated in this illustration.
Make the next step tangible
The output should be more useful than a score. A tangible account report can bring together the five-year economics, findings from each assessment layer, channel and technology maps, supporting evidence, open questions, and the relevant buying roles. It should explain why an account advanced, why another account was excluded, and what would need to be true to move a held account forward.
That gives a seller a practical foundation for a better conversation: who to approach, what to validate, and how to position the product without overstating certainty. It also preserves room for the buyer to correct assumptions before the business case becomes a pitch.
Alma Hunter publishes this perspective from Ogden, Utah, for B2B sellers nationwide; this is not a Utah customer case. If your team wants to assess the gap between an ICP match and a real opportunity, define the product’s buyer economics and use the existing inquiry channel to start a conversation. An inquiry does not start research automatically.
“A matching profile gets you a list. The rep still has to decide where the real opportunity is.”
From the supplied Alma Hunter company explainer.
Based solely on the supplied Alma Hunter video narration, using its corrected segment-level transcript. The fictional apparel economics are illustrative assumptions from that narration, not verified client outcomes; the complete input schedule is not supplied and all real-account assumptions require validation. Watch the source film.
