What buyers see before they log in

In a B2C shop every visitor sees the same page. In a B2B shop the same URL is a different shop for an anonymous visitor, a logged-in buyer at Kunde A, and a logged-in buyer at Kunde B. This article explains what varies, why, and how to decide what an anonymous visitor gets.

The three audiences on one URL

Everything in that table is a decision somebody at your company has to make. The default is not obvious and it is not the same for every business.

Why prices are hidden at all

Three reasons, in the order they come up in a Mittelstand company:

The list price is not the price. If most of your revenue runs on customer-specific conditions, a public list price is at best noise and at worst a negotiating position you handed your customer's purchasing department for free.

Your competitors read your shop. A public price list is a competitor briefing that updates itself. Technischer Großhandel in particular treats the price file as commercially sensitive, and putting it behind a login is the normal industry posture rather than paranoia.

Sales does not want it public. This is usually the real reason and it is worth naming. Your Außendienst will resist a public shop that undercuts their own quotes. A login gate is often the compromise that gets the project approved.

Against that, one hard argument for showing something:

The middle grounds worth knowing

You are not choosing between "everything public" and "nothing at all". The patterns that work:

• List price public, real price after login. The most common B2B compromise. The buyer gets an order of magnitude and a reason to register.
• Catalog public, prices after login. Full product data, no numbers. Works when the technical data is what buyers search for: spare parts, norms, dimensions.
• Everything behind the login. A pure customer portal. Correct when the assortment itself is confidential, or when the shop exists only to serve existing contract customers.
• Public shop plus a closed portal, as two storefronts on two domains sharing one catalog. The cleanest split when the two audiences have nothing in common.

Customer-specific assortments

Hiding prices is the straightforward half. Hiding products is the half that quietly breaks things.

A closed assortment means a buyer at Kunde A sees 1,200 articles out of your 80,000, the ones their framework contract covers. This is a normal request in B2B: a punchout contract usually describes exactly this, and procurement departments ask for it so that their staff cannot order off-contract.

The mechanism is the channel. Each channel decides what happens to a product that nobody has explicitly assigned to it:

• Visible (open): the whole catalog shows in this channel. The platform default, and right for a public shop.
• Hidden until assigned (closed): only explicitly assigned products show. This is the negotiated assortment.
• Inherit from the tenant setting: follow the tenant-wide default.

Login-gated price lists

A price list carries a Logged-in buyers only flag. When it is set, anonymous price requests skip that list entirely. The list does not take part in resolution at all for a visitor who is not signed in.

That has a consequence people trip over: if the only list covering a product is logged-in-only, an anonymous visitor sees no price, not a fallback price. If you want a public list price plus private conditions, you need two lists: a public one at low priority and the customer's one at higher priority. Among equally specific lists, the higher priority wins.

Price lists can also be narrowed to a single organization, to a contact, to a channel, and to a validity window, which is how "this price, for this customer, for this quarter" is expressed. The full resolution order is in How pricing works.

There is also a price type of on request, which is a real answer rather than a missing one: the product is orderable, the number comes from a person. Use it instead of leaving a price blank, because a blank price and a deliberate "price on request" look identical to a buyer and completely different to you.

What decides who somebody is

The buyer's identity comes from the customer model, not from the storefront: a contact signs in, the contact belongs to an organization, and the organization is what price lists, assortments, payment terms and approval rules attach to. A contact's role then decides what they may do inside that organization: order, request a quote, approve. See The B2B customer model.

This is why "log in as the customer to check what they see" is the only reliable test. Reading the configuration and reasoning about it gets it wrong often enough to be worth the two minutes.

How this works in the Revenue Cloud

• Assortment: Commerce Studio › Configuration › Channels, the field Products with no assignment to this channel are.
• Login-gated prices: the Logged-in buyers only flag on a price list, under Order Management › Price lists. See Price lists.
• Who the buyer is: CRM › Organizations, Contacts and Roles. See Organizations.
• Whole-storefront protection: a domain can sit behind HTTP Basic Auth while you build it, with public paths and allowed IP ranges. That is a staging control, not a customer-facing login. See Domains and going live.

What to check

Before a launch, open the storefront three ways and write down what you see:

1. In a private browser window, signed out.
2. Signed in as a standard customer contact.
3. Signed in as a contract customer with a restricted assortment.

If any of the three surprises you, the configuration is wrong, not the shop.

Next

• Price lists: where the login gate is set.
• Search and product discovery: what happens after they are in.