Discover: What an AI Commerce Readiness Assessment Needs to Understand First

An AI Commerce Readiness Assessment should not begin by assigning scores. It should begin by understanding the business.

That distinction matters because readiness is contextual.

A retailer with fifty highly technical products does not face the same readiness challenges as a marketplace with two million SKUs. A manufacturer selling primarily through distributors does not have the same control points as a direct-to-consumer brand. A company preparing for AI-assisted product discovery may have very different priorities from one evaluating agentic checkout.

The same technical condition can therefore have very different business significance depending on the organization.

That is why RPE Origin begins with Discover.

Discover is the first step in the assessment process: Discover → Assess → Baseline → Prioritize → Roadmap.

Its purpose is to understand the business model, customer decision patterns, priority categories, major systems, strategic goals, current concerns and practical constraints before the assessment team begins evaluating evidence.

The guiding question is simple: What do we need to understand about this organization before we can judge whether it is ready?

Discovery Prevents the Assessment From Becoming Generic

A weak readiness assessment can easily become a checklist. Does the site use structured data? Does the company have a product feed? Is there a PIM? Can an AI crawler reach the site?

Those questions can be useful, but they do not establish business significance by themselves.

For one retailer, missing compatibility information may be a minor content gap. For another, compatibility may be central to the entire purchase decision and a major source of returns. For one merchant, stale inventory may affect a small subset of products. For another, rapidly changing availability may determine whether AI-assisted recommendations can be trusted at all.

Discover creates the context that allows later findings to be interpreted correctly.

Without that context, an assessment can produce technically accurate observations that are strategically irrelevant.

The point of Discovery is not to delay evaluation. It is to make sure the evaluation is answering the right questions.

Start With the Business Model

The first area to understand is how the organization actually sells.

That may include direct-to-consumer ecommerce, B2B ecommerce, marketplaces, dealers or distributors, subscription commerce, retail locations, franchise models, omnichannel fulfillment, regional storefronts or multi-brand environments.

The business model affects almost every readiness dimension.

A direct-to-consumer retailer may control its product pages, feeds, structured data and checkout. A manufacturer selling through distributors may control product knowledge but not the final transaction. A marketplace may need to govern product truth across thousands of sellers. A B2B organization may depend on account-specific pricing, restricted catalogs or negotiated availability.

Those differences influence where evidence can be gathered, which systems matter and what the roadmap can realistically change.

Discover should therefore establish where the organization controls the commerce experience and where it depends on partners, platforms or downstream sellers.

Understand the Customer and the Purchase Decision

The assessment also needs to understand how customers choose.

Some purchases are straightforward. Others require substantial evaluation.

A customer buying a commodity replacement item may care primarily about compatibility, availability, price and delivery. A customer buying a complex technical product may care about suitability, specifications, use environment, accessories, tradeoffs, warranty and long-term value.

Those decision patterns matter because AI-assisted discovery works from customer intent. The more complex the decision, the more important it becomes that the underlying product evidence supports the reasoning required to reach a useful recommendation.

Discover should therefore ask what customers ask most often, where they become uncertain, which questions reach support or sales, what causes returns, which differences matter most and which categories depend heavily on compatibility or suitability.

Those answers help determine where Product & Catalog Data, Semantic Product Knowledge and Content & Merchandising deserve deeper attention.

Priority Categories Matter More Than Catalog Averages

Most commerce organizations do not need every category assessed with equal depth.

Priority categories should be selected deliberately because they are strategically important, high revenue, high margin, complex, frequently compared, rapidly changing, prone to returns, heavily promoted or particularly relevant to AI-assisted discovery.

This matters because catalog averages can hide the problems that matter most.

A retailer may have excellent data quality across ninety percent of the catalog but serious readiness gaps in its most valuable category. Another organization may have strong flagship products but poor long-tail content. A third may have accurate product pages but only in categories that contribute little strategic value.

Discovery helps define a representative assessment scope rather than assuming that the whole catalog behaves the same way.

The objective is not to make the scope as large as possible. It is to make it representative enough that the findings are useful.

Understand the Commerce Architecture Before Testing It

A readiness assessment needs a working model of how product information moves through the organization.

That does not require a perfect enterprise architecture diagram. It does require enough understanding to answer practical questions: Where are products created? Where are attributes maintained? Which system owns pricing? Where does inventory originate? How are product pages generated? How are feeds produced? Where is structured data created? Which systems expose APIs? How do marketplaces receive product information?

This context is essential because a visible problem may originate far upstream.

A product-page defect may actually be caused by a PIM mapping. A stale feed value may come from a transformation job. A missing variant may originate in the ERP. A crawler issue may come from the CDN rather than the storefront. A measurement gap may stem from inconsistent product identifiers across systems.

Discover creates the system map needed to trace those relationships later.

The goal is to understand the path of product truth well enough that the Assess phase knows where to look for evidence and where a defect might originate.

Identify the Major Systems

The assessment should document the major platforms involved in the commerce lifecycle.

Typical systems may include ERP, PIM, ecommerce platform, CMS, DAM, order-management system, pricing engine, inventory service, feed-management platform, marketplace connectors, analytics platforms, customer-service systems, product-knowledge repositories and custom APIs.

The objective is not to inventory every application in the company.

It is to identify the systems that materially influence the seven readiness dimensions.

That distinction keeps Discovery focused. A system should be included because it creates, transforms, publishes, measures or governs commerce information relevant to the assessment.

Understand Data Ownership Early

Discover should also surface who owns important information.

This does not replace the Governance & Operational Readiness assessment. It gives the assessment team an initial ownership map and identifies the people who need to participate.

Useful questions include who owns product identity, product attributes, pricing, inventory, product content, structured data, feeds, AI-facing integrations and analytics.

The answers help identify evidence sources and stakeholder interviews.

They can also reveal ownership ambiguity before formal governance findings are produced. If two teams both believe they own pricing transformation, or each believes the other team owns structured data, that conflict is useful assessment context.

Strategic Goals Shape the Assessment

Organizations pursue AI Commerce readiness for different reasons.

Some may want to improve product representation in AI-assisted discovery. Others may want to prepare for conversational shopping or agentic commerce. Some may be responding to a specific executive initiative. Others may simply want an independent view of their current exposure.

Discover should make those goals explicit.

Possible objectives may include improving AI product visibility, increasing product-data quality, reducing feed inconsistency, strengthening product comparison, improving machine-readable product knowledge, establishing AI Commerce measurement, improving governance or creating a practical implementation roadmap.

The assessment should not assume every organization has the same destination.

Later prioritization is much more useful when it can distinguish a real business objective from an interesting technical capability.

Current Concerns Are Important Evidence

The organization often already knows where some of the problems may be.

Stakeholders may say that feeds do not always match the site, ownership is unclear, compatibility data is weak, product content varies widely, some automated traffic is blocked, AI referrals cannot be identified or APIs are not externally ready.

Those concerns should be documented during Discover.

They should not yet be treated as confirmed findings.

They are assessment hypotheses.

Discover listens. Assess verifies.

That distinction matters because stakeholder experience is valuable context, but the readiness baseline should ultimately be grounded in evidence.

Define What Success Means Before Measuring Readiness

A readiness assessment should also establish what improvement would look like.

Success might mean more complete product attributes, fewer feed-to-page mismatches, stronger compatibility information, reliable crawler access, improved AI referral tracking, documented ownership or clearer remediation priorities.

Those expectations help frame later recommendations and give the roadmap a business purpose.

They also prevent the project from becoming an abstract maturity exercise.

The objective is not simply to produce a score. It is to establish a baseline that helps the organization make better decisions.

Representative Commerce Scenarios Are Critical

One of the most important outputs of Discover should be a set of realistic shopping scenarios.

Those scenarios allow the assessment team to test the commerce environment through the lens of actual customer intent rather than through isolated technical checks.

A scenario might ask for a lightweight carry-on under $200 that fits domestic overhead bins and includes a laptop compartment. Another might ask which replacement filter fits a specific refrigerator. Another might ask for hiking shoes suitable for wet trails and wide feet. Another might compare three products for a beginner.

Each scenario connects customer intent to multiple readiness dimensions.

A single scenario can expose missing attributes, weak semantic knowledge, poor comparison content, technical discoverability problems, inconsistent data across systems, measurement gaps or ownership ambiguity.

That makes representative scenarios powerful because they test the system as an integrated commerce experience rather than as seven disconnected checklists.

Scenarios Should Be Representative, Not Convenient

The assessment should avoid selecting only easy products.

Representative scenarios should include meaningful complexity: products with several variants, compatibility requirements, promotional pricing, inventory constraints, technical specifications, accessories, replacement relationships or regional differences.

A simple product can prove that the happy path works.

A complex product shows whether the operating model holds under pressure.

Discover should therefore identify both ordinary examples and stress-case examples. The purpose is not to manufacture failure. It is to select products that exercise the parts of the commerce architecture where readiness actually matters.

Scope Has to Be Explicit

A good assessment needs clear boundaries.

Without them, Discovery can expand indefinitely and findings can be generalized beyond the evidence.

The Discover phase should define which business units, sites, markets, product categories, systems and channels are included. It should also define representative scenarios and any important exclusions.

That creates a defensible assessment scope.

If the assessment evaluates three priority categories, the final report should not imply that every product in the enterprise was tested. If agentic checkout is out of scope, the assessment should not quietly convert that omission into a readiness failure.

Scope discipline strengthens the credibility of the baseline.

Discovery Should Identify Evidence Sources

The assessment team also needs to know where evidence can be obtained.

That may include product exports, feed files, PIM data, Merchant Center, analytics, structured-data output, product pages, API documentation, architecture diagrams, governance documents, support FAQs or customer-service records.

Discover should establish which sources exist, which are accessible and which are missing.

Missing evidence can itself be informative.

If no one can provide a current feed specification, a product-ownership map or documented API contract, the absence may point to an operational gap that the Assess phase should examine more closely.

Access Requirements Should Be Planned Early

Some assessment activities require platform or system access. Others can be performed from public evidence.

Discover should identify required access before the assessment begins in earnest so the work does not stall later.

That may include read-only Merchant Center access, GA4 reporting access, Search Console access, product-feed exports, PIM exports, API documentation, test credentials or architecture documentation.

Access should be proportionate to the work.

An assessment usually does not need administrative or write access simply to evaluate readiness. Planning access early improves efficiency while preserving appropriate security boundaries.

Discovery Is Also About Constraints

Every organization operates within constraints.

Those may include limited engineering capacity, vendor dependencies, platform limitations, upcoming replatforming, budget, seasonal change freezes, compliance requirements, contractual restrictions or organizational changes.

Those constraints matter because the assessment is intended to produce a practical roadmap, not an idealized architecture diagram.

A technically elegant remediation that cannot be implemented for eighteen months may deserve a different priority from a smaller improvement that can be completed next month.

Discover makes those realities visible before the assessment team begins recommending work.

What the Discover Phase Produces

Discover should produce a concrete working set of outputs.

At minimum, the assessment team should leave the phase with business context, strategic goals, priority categories, major systems, an initial ownership map, known concerns, representative commerce scenarios, a defined assessment scope, identified evidence sources, access requirements and known constraints.

Those outputs become the working inputs for the next phase.

Discover does not determine the readiness score.

It determines what should be assessed and why it matters.

What Poor Discovery Looks Like

Discovery can fail in several predictable ways.

Common problems include beginning technical testing before understanding the business, assessing random products instead of strategic categories, accepting stakeholder assumptions as findings, ignoring system architecture, failing to identify authoritative sources, testing only simple products, leaving scope undefined, requesting unnecessary system access, ignoring implementation constraints or treating every issue as equally important.

Those mistakes reduce the usefulness of the assessment.

A technically detailed report can still miss the business problem if the discovery work was weak.

Discover Is Where Context Becomes Assessment Design

The purpose of Discover is not to delay the assessment. It is to make the assessment meaningful.

By the end of the phase, RPE Origin should understand what the organization sells, how customers choose, which products matter most, how product information moves, which systems matter, who owns what, what the business wants to improve, what concerns need verification and which scenarios should be tested.

That context defines the assessment design.

The next phase can then move from questions to evidence.

That leads to Assess: How Evidence Is Evaluated Across the Seven Readiness Dimensions.

A meaningful readiness assessment begins with context. Business priorities, product complexity, system architecture, customer decision patterns and current concerns all determine where the strongest risks and opportunities may exist. An AI Commerce Readiness Assessment can help establish that context before moving into evidence-based evaluation across the seven readiness dimensions.