The recommendation is the starting point.
Imagine a customer asking AI to choose running shoes. The brand appears in the answer. Now the agent needs to check the model and size and add it to the cart. This is a fictional example, but it explains why a mention and a usable buying journey require separate checks.
In the historical adidas test, the barrier came before the product. The tested access routes encountered an Akamai 403 block at entry; no cart was reached [S1]. That documents access in that test, not how every agent can use the website today.
At Zalando, the reference run with a prepared session reached the cart. The four fresh-session access types discussed separately in the report failed; all three standard-browser repetitions were unsuccessful [S2]. Looking only at the successful reference result would hide the condition that made it possible.
Record the session state and the step the agent actually reached.
Reading product data is a task of its own.
Once access works, the agent needs dependable information about the offer. AI Visibility describes whether the brand appears in answers. AI Usability asks whether an agent can complete the defined task on its website. Both checks belong to the customer journey [S5].
In the BMW 318i test, encapsulated web components restricted access to the configurator. The plain reader and coding agent did not reach the goal; the standard browser succeeded in one of three runs. The tested goal was a completed configuration, not a vehicle purchase [S3].
In the published Mercedes-Benz test, the browser could read the C 180 configuration and its price. Simpler access routes were restricted, and test-drive booking remained a separate subsequent step [S4]. Your team therefore needs to specify whether its test requires information, a configuration, an enquiry or a binding transaction.
Reaching a vehicle price does not establish a booked test drive.
Three barriers, three checks.
The cases help narrow the first investigation. The following three barriers may occur on the same website. They are neither an exhaustive list of failures nor a ranking of the brands.
01 · Access
adidas
The tested routes were blocked before reaching the product [S1].
Can the agent reach the page?
02 · Product data
BMW
The configuration was readable through some access routes, but not others [S3].
Can it verify the offer?
For access, your team checks which intended agents may reach a public page and why a request is rejected. For data, it compares visible product information with what the agent can actually read. For the next step, it records the required session, login or approval [S6].
A required login or identity check is not a defect to remove. The question is whether the permitted route works for the customer's agent and where the customer must take over. Dealers and portals may also be intended sales routes [S5] [S6].
Start with one customer journey.
Choose an important offer and a real customer question. Before testing, write down what success means: placing the right item in a cart, for example, or preparing an enquiry for final review. Define the actions the agent may take. A test need not place an order or submit an enquiry.
Record the model, date, starting page, session state and first unresolved step. Address one specific barrier, then repeat the same task under comparable conditions. This shows whether the change improves the tested journey. The linked self-test supplies seven prompts to start with [S7].
Hyperize calls potential revenue loss through these dead ends or detours an Agent Revenue Leak. These tests alone cannot establish how much revenue is actually lost. That requires additional business and completion data. We discuss the customer journey with you and agree which pages, data or permitted actions to improve [S5] [S6].
The next step is a customer journey you can test on your website.
