Skip to content
platform

Portals · by profile

Governed Marketplace

Almost every distributor loses sales to a thin assortment, and almost none of them fixes it, because the alternative would be buying stock or letting a third party configure price, freight and availability inside the house. Without a layer that allows the second option while keeping control, the company chooses not to act, and the stockout becomes a fact of life. The Governed Marketplace is that layer: own and third-party stock in the same cart, with the rules for who appears, who delivers, who gets paid and how much stays at each end written by whoever owns the portal.

Governed Marketplace hero: the store order set by the portal owner decides which offers, own and third-party, enter the buyer's cart.
Illustration of a B2B portal with a single cart mixing own-stock and partner-store items, and the order automatically split by origin.
One cart, two stock origins. The buyer sees a single cart. Behind it, each item carries the store that made the offer, and the order is born already split by origin.

A marketplace is an output, not an objective

No project that began with the sentence "we want to launch a marketplace" ever comes close to liquidity. What works is the opposite route: digitise the operation that already exists, with the branches, sellers, suppliers and customers the company already has, and let the marketplace emerge as a consequence of an operation that became legible. That is why this profile is not sold as a new product. It is a state a B2B Digital Selling operation reaches when the assortment has to grow faster than the stock.

The difference from a general marketplace is not in the catalogue, it is in who keeps the customer. On a general marketplace demand is rented, and what comes back is less margin and no data from the end of the chain. On your own portal, every transaction records origin, and that is the raw material for the sell-out nobody can see today.

The question that stalls the project: who controls the buy box

In a marketplace, the most expensive decision is which offer appears first. When that decision is outsourced to the lowest price, the portal becomes an auction against its own owner, and the invited supplier stops being backup and becomes a competitor inside the house. CWS Platform treats this as configuration: the buy box criteria are yours, the order between combined stores is yours, and there is an explicit rule for not showing third-party prices on items you hold in your own stock.

The same logic holds on the other side. The seller keeps price, terms and availability under their own control, and the portal governs the frame: region, exposure, commission and order rules. Governing the frame is not running someone else's commercial policy, and confusing the two is what makes most networks decline the invitation.

Comparison between a buy box that becomes a lowest-price auction and a governed buy box, where the portal owner's rule orders offers by own stock and region.
Who controls the buy box. Without a rule, the day's lowest price decides and the partner becomes a competitor inside the house. With the owner's rule, offers come out in the order the network chose.

The portal layer: what the owner defines

A CWS Platform portal is configured in layers, and the first one belongs to the portal owner. That is where governance lives. The owner designs the ecosystem, and that configuration flows straight into every seller's Seller Center:

Below it comes the store layer: the invited stocks, from the company itself or from third parties. Each store receives orders, takes part in promotions and configures its own logistics, freight, payment methods and campaigns, within the freedom the owner granted. When a store has several stock points, its warehouses form the warehouse layer. How many layers come in is a project decision, and the recommendation is for the invitee to join as a store, because that is where it gets the most functionality and flexibility.

That is why the levers on this page are not loose capabilities. The order between stores, the buy box criteria, each store's region, the split, pickup and the origin trail are what the portal layer configures. The buy box rule has an owner too: the option of not showing third-party prices for items the house holds in its own stock is the preference for own stock, parameterised by the portal owner.

Three-layer diagram of the governed marketplace: the owner's portal layer on top, own and partner stores in the middle and warehouses at the base, with rules flowing down to each seller's Seller Center.
Portal, store and warehouse. Governance lives in the portal layer. From there, rules flow down to each invited store and to each store's warehouses.

The four viability conditions

A B2B marketplace lives or dies on four conditions, and none of them is technology. The platform replaces none of the four; it is the place where the fourth stops being a verbal understanding and becomes a parameter that holds equally across portal, app and seller module.

  1. 1

    Participation

    Participants must see value before they feel the platform as a competitor. Participation is not decreed in a contract, it is designed into governance: what each one keeps under control is what decides whether they join.

  2. 2

    Data quality

    Product, application, stock, price and lead time must be right at the moment of the offer. A marketplace on poor data is not a portal with a defect, it is a promise broken once per transaction.

  3. 3

    Liquidity

    Enough supply and enough service for the buyer to come back. Without mass on both sides, the portal becomes a shop window nobody visits twice.

  4. 4

    Governance

    Explicit rules for exposure, order distribution, pricing, commission, service, logistics and returns. It is the condition that sustains the other three, and the only one that cannot be bought ready-made.

What the platform does, in practice

Combined stores with priority order

Stores enter the portal in a defined order, and the platform honours that order when assembling the offer. Turnover goes where the operation decided.

Buy box by configurable criteria

Who wins the offer comes from a criterion set by the portal owner, who parameterises the preference for own stock, third-party stock or both, including the option of hiding third-party prices for items the house holds in its own stock.

Store selection by category and brand

A seller can take part only in the categories and brands where it makes sense, rather than entering the whole catalogue.

Region restriction per store and per seller

Each store and each seller serves the area it can actually cover. The restriction is there to avoid two houses in the same network competing for the same address.

Payment split and commission

Payment is split among participating stores at transaction time, with commission by origin. The customer closes one cart and each part reaches whoever sold it.

Seller governance on pickup

Store pickup can be restricted to your own stores or extended to partners, even when the partner holds the item. It is a commercial lever, and it is yours.

Identification of the offering store

The store or branch that offered the price appears in search and on the product card, and stays identified on the order. Without it there is no auditable ecosystem.

Sellers operating their own orders

The seller handles what is theirs, cancellation included, and receives transactional emails for the orders they serve. Operation is distributed, the rules stay central.

All of it comes from the Marketplace Management Platform (Marketplace Center) on the same core that supports the other profiles: Commerce Rules Engine (CDL Workspace) for the rules, Contextual Pricing (Pricing Engine) for the price, Distributed Inventory (Inventory Hub) for stock across origins, Shipping & Fulfillment (Logistics Engine) for delivery and pickup, and the Order Management System (OMS) for the order split by origin.

Illustrative screen of the portal owner's console showing store priority order, the option to hide third-party prices for items in own stock, and each store's service region.
The buy box as configuration. Store order, third-party pricing and service region stop being verbal agreements and become parameters set by the portal owner.

By decision-maker angle

Distributor owner or director

The pain: The customer asks, the company does not have it, and they buy from a competitor. The item exists at the supplier, but widening the assortment would mean buying stock.

What changes: Assortment grows without tied-up capital. The third party covers the stockout inside the house's rules, and the sale that was walking away stays, with the customer still served by the distributor's portal.

Invited supplier or seller

The pain: Joining someone else's portal looks like handing over price, customers and autonomy. And it looks like a long integration project before any result.

What changes: They keep price, terms and availability under control, and start by registering the sales that already exist. If they already operate on another CWS Platform portal, they use the same login and receive in the same OMS. What they gain is qualified demand without building a channel of their own.

Anchor manufacturer

The pain: Has scale and reach, and still does not know how much the channel sold at the end. Without sell-out there is no forecast, no intelligent replenishment and no measurable campaign.

What changes: Every transaction becomes traceable by origin. The network's power gains a readout, and the anchor can activate the channel by rule rather than by phone.

CFO

The pain: Volume grows and margin does not follow. Commission settled afterwards in a spreadsheet, and returns nobody can attribute to the right origin.

What changes: Payment and commission split at transaction time, with origin recorded on the order, the transactional email and the cancellation. Settlement stops being a month-end job.

Flow from cart to split: one payment is divided among the participating stores, the portal commission is separated in the transaction and each order reaches the OMS of the seller who sold it.
Split and commission at transaction time. The customer pays once. The split between stores and the commission happen at purchase time, with the origin recorded on the order.

The three designs this profile covers3

All three run on the same engine and differ on a single question: whose stock appears in the buy box. Moving between designs is a reconfiguration, not a new project, and an operation commonly starts at the first and arrives at the third.

Own network as sellers
The distributor's own branches and stores enter the portal as stores, each with its own catalogue, price, region, campaign and logistics, or as warehouses of an internal store, when the network prefers simpler service and a single campaign. All stock is the company's, and governance exists so units do not compete with each other.
Hybrid: own and third-party stock
The portal still belongs to the distributor, and the assortment starts to include invited suppliers. The same customer is served from own or third-party stock, and the rule of who appears first belongs to the portal owner, not to the deepest discount.
Ecosystem orchestrated by an anchor
An industry player or an association organises purchasing for an entire network from selected distributors. Whoever publishes the frame is not whoever sells, and governance must protect each link's commercial autonomy for the network to join.

The governance levers, from buy box to payout6

Governing a marketplace is not choosing who joins, it is deciding what each participant may do once in. Every lever below is a configuration of the portal layer, the owner's, and flows from it into each store's Seller Center. They are not loose capabilities: they are the decisions the owner makes when designing the ecosystem.

Stock priority between stores
Stores are combined in a defined order, and the platform honours that order when assembling the offer. It is how turnover goes where the operation decided, rather than to whoever has the lowest price at that moment.
Buy box by criteria, not by auction
The criteria for who wins the offer are configurable: the portal owner flags and favours own stock, third-party stock or both, and can hide third-party prices for items the portal holds in its own stock. Without that rule, the marketplace becomes an auction against its own owner.
Service region per store and per seller
Each store and each seller has the area it can genuinely serve, and the restriction is there to avoid overlap. Two houses in the same network fighting over one customer is the most common reason a network refuses the portal.
Payment split and commission
Payment is split among participating stores at transaction time, with commission recorded by origin. The customer closes one cart, and each part reaches whoever sold it, with no later spreadsheet settlement.
Store pickup as the owner's decision
There is a choice to offer pickup only at own stores or also at partner stores, even when the partner has the item. Favouring your own house at pickup is a commercial lever, not a side effect.
Origin trail on every order
The store that offered the price is identified in search and on the product card, and stays identified on the order, the transactional email and the cancellation. An ecosystem can only be governed if every transaction says where it came from.

The rails, in the operator's vocabulary

Portal, store and warehouse layersPreference for own or third-party stockOne login, many portalsPartner stores and combined storesStock prioritisation between storesStore selection by category and brandPayment split between storesCommission by originRegion restriction per store and per sellerStore pickup with seller governanceIdentification of the store offering the priceOrder cancellation by the sellerTransactional email per serving store

A use case already live

Dealer marketplace

The profile applied to a network of light and heavy vehicle dealers: the vehicle owner enters the car, sees only the parts that fit, buys from the dealer covering their region, and whatever is missing comes from another house or from the factory in the order the network administers.

See the use case →

In operation

On the industry side, Pirelli, through Pirelli Conecta, orchestrates on CWS Platform the buying of its authorised resellers from selected distributors, and MTE-Thomson built its own digital sales channel that strengthens its distribution. Those are the two shapes of anchor-orchestrated ecosystem running on the same engine.

Frequently asked questions

If I open my portal to third-party stock, am I not teaching my customer to buy from someone else?

Only if the buy box is an auction. Here the criteria for who wins the offer are your configuration, and they include the option of not showing third-party prices for items you hold in your own stock. The third party enters where you had a stockout, not where you had a sale.

How do I convince a supplier to join without them feeling they lose control of their pricing?

Because they don't. The seller sets their price, terms and availability, and the portal's governance sets the frame: region, exposure, commission and order rules. Governing the frame is not running someone else's commercial policy, and that distinction is what makes a network join.

My branches compete with each other. Won't the portal create internal conflict?

That is precisely what region restriction and the priority order between combined stores exist to avoid. Each store serves the area it can actually cover, and the order in which the others come in as backup is the network's decision, not the lowest price of the day.

How much will a seller have to change before seeing results?

Entry is through what they already do. If they already operate on another CWS Platform portal, they join with the same login, and orders from this portal land in the same OMS where they already receive the others: one login, many portals, and the only thing that changes is the rules they accept when offering here. If it is their first time, the first step is registering the sales that already exist on the platform, with the catalogue and stock they already have, and portal owner, store and warehouse staff all sign in to the same system, in the same place. Prioritisation, campaigns and the AI agent come on top afterwards, once the operational data is trustworthy. It is also why the more CWS Platform portals there are around a sector, the cheaper it gets to build an ecosystem in it.

Isn't this the same as listing my products on a general marketplace?

No, and the difference is who keeps the customer. On a general marketplace you rent demand and give back margin and data. In a governed marketplace the portal is yours, the rules are yours, and every transaction stays traceable by origin, which is the raw material for the sell-out you cannot see today.

Talk to CWS Platform

Want to see your buy box with your rules?

Tell us how many stores or branches take part, whether third-party stock is involved and who decides the order of the offer. We come back with a demo in your scenario: priority between stores, service regions per store, split, and the order arriving divided by origin.