Sell through marketplaces

Somebody has been told to "do Amazon Business". Meanwhile Mercateo has called twice, a large customer's purchasing platform wants a supplier catalogue, and your dealers have had a login to something for years that nobody maintains. These look like four initiatives. They are one question asked four times: which cut of your assortment, at which price, with which content, for whom. The answer is the same mechanism every time.

Why this is harder than it sounds

The mechanical part is a feed. The difficult part is that every new channel is a commercial decision about your existing ones, and most companies make it by accident.

Start with channel conflict, because it is the risk that costs money. If your marketplace listing undercuts the dealer who has sold your product for eleven years, you have opened a dispute, and you will spend a year managing it. If it undercuts your own shop, you have taught your direct customers to buy from you through an intermediary who takes a fee. Neither happens deliberately. Both happen because the price on the new channel was set by whoever built the feed.

Second: on some channels you acquire a customer, on others you rent demand. The distinction is who holds the relationship and the data. Where the platform invoices the buyer, owns the account and mediates the contact, you get volume without a customer; end the listing and the revenue ends with it. A procurement platform or your own dealer portal, where you keep the account and the conditions, builds something that stays yours. Both can be worth doing. Confusing the two is how a company ends up with a third of its revenue on a channel it does not control.

The German B2B reality is roughly four kinds of channel, and they behave differently:

Then the arithmetic nobody does in advance. A marketplace fee is a margin line, and so are the shipping rules, the return handling and the higher share of small orders. Listing your normal net price can mean selling at a loss after fees; listing your list price can mean never winning an order. A channel needs its own price basis, derived from what it costs to sell there.

Finally, order intake. Channel orders arrive with their own numbers, address rules and delivery promises, and on the open marketplaces with penalties for missing them. If they reach your ERP without a marker for where they came from, you lose the one thing that would let you judge whether the channel is worth keeping.

The platform treats a channel as an object of its own rather than as an export script. A channel has a type (storefront, punchout, marketplace, API, point of sale) and can be scoped to a market. Assortment is controlled per channel, including what happens to a product nobody assigned to it. Price lists carry a channel, so a channel price basis is a price list instead of a spreadsheet. Orders carry the channel they came from, and order numbers can run in their own range per channel. That is the mechanism; the rest of this page is how to use it.

The levers

Decide what each channel is for, and what it costs you

What good looks like: each channel has a written purpose (reach, defence, dealer service, a named customer), a stated relationship to your other channels, and a margin calculation after fees and fulfilment. A channel nobody can justify in one sentence gets closed rather than optimised.

What it depends on: settling the dealer question first. Deciding a channel's price after your dealers have seen it is a negotiation.

1. The storefront model
2. Channels, locales and completeness
3. Price models in B2B
4. Metrics that matter

Cut the assortment and the price per channel

What good looks like: each channel shows the articles you intended and no others, at a price basis built for that channel. A new product appears there because somebody assigned it, not because it inherited a default nobody reviewed.

What it depends on: a catalogue where assortment is a property of the relationship rather than a copy of the product. If serving a channel means duplicating articles, the model is wrong and the maintenance will not survive a year.

1. Price lists
2. Categories
3. Scale prices
4. Time-limited prices
5. Check which price a buyer sees
6. Why a product is not visible

Meet the channel's data standard before you list

What good looks like: for every channel you can name its required fields (identifiers, units, classification, image rules, text limits) and run a check that says which articles fail before the channel does.

What it depends on: treating each channel as having its own completeness rules, and an export route per channel you can re-run rather than rebuild.

1. Catalog exchange formats
2. Catalog export profiles
3. Export a catalog for a customer
4. Classification standards
5. Measurements and units
6. Completeness and readiness

Take the orders back, and keep the channel visible in your numbers

What good looks like: a channel order arrives as a normal order, carries its origin and the channel's own reference, runs through the same fulfilment path, and appears in reporting as its own line: revenue, margin after fees and delivery performance.

What it depends on: the channel marker surviving the journey into your ERP, and an agreement on what counts as an order before anyone compares channels.

1. The order lifecycle
2. Number ranges
3. Process an order
4. Build a workflow
5. What counts as an order
6. Reports

A sensible order

Phase 1: make "channel" real, starting with the one you own. Model your existing routes as channels (your shop, and the dealer portal) and get assortment, price basis and reporting working per channel while the stakes are low and no external party is judging your data. The dealer portal is the right first target: the customers exist, there is no fee, there is no conflict, and it is usually the most neglected revenue you have. Depends on nothing except the decision to stop treating channels as exports.

Phase 2: one procurement platform, where the work is data. Add a single procurement-side channel, a Mercateo-style platform or a large customer's catalogue, and let its requirements drive the catalogue work: identifiers, units, classification, images, text limits. Do this second because that data work is the entry ticket for every further channel, including punchout, and doing it once for a demanding partner is cheaper than doing it five times badly. Depends on Phase 1 having assortment and price separable per channel.

Phase 3: the open marketplace, with fee-aware pricing and a channel P&L. Amazon Business or a comparable marketplace, priced from what it costs to sell there, with delivery performance monitored because the channel measures it whether you do or not. Alongside it, start reviewing channels as a portfolio: contribution after fees, customers gained against demand rented, and an annual decision about which to keep. Depends on Phase 2, because a marketplace amplifies a data problem faster than any other channel.

Common mistakes

• Setting the channel price by copying the shop price. After fees it may be a loss; against local competition it may be unsellable. Price the channel from its cost to serve.
• Launching before the data is checked. Suppressed listings look exactly like no demand, and you will draw the wrong conclusion for a quarter.
• Bypassing dealers quietly. They will find the listing in a week, and the relationship costs more than the channel earns.
• Losing the channel marker on the way to the ERP. Without it you cannot compare channels, and you will keep the wrong one.
• Treating a marketplace account as a customer relationship. If the platform owns the buyer, plan for that instead of discovering it.

How you know it is working

• Revenue and margin after fees, per channel. Gross revenue per channel is the number that flatters; contribution is the number that decides.
• Listing coverage: articles you intended to publish against articles live, per channel. The gap is usually data, and usually larger than anyone expects.
• Rejected or suppressed articles, by reason. A working queue for the catalogue team, and the fastest route to coverage.
• Share of dealer orders placed through the portal. The measure of whether your own channel is being used or tolerated.
• Delivery performance per channel: on-time dispatch and cancellation rate. On open marketplaces this is scored, and a bad score removes you from view.
• Customers gained against demand rented. Per channel, the buyers you can identify and contact. This is the number that says what you are building.

Related goals

• Connect customer procurement, the channel that lives inside your largest customers' own systems.
• Publish a digital catalog, the data work every channel above depends on.
• Reach more customers, what channels are for, and the yardstick for whether one is working.

What you're building

One catalog, cut per channel. Each channel (your shop, the dealer portal, a procurement platform, a marketplace) gets its own assortment, its own price list and its own completeness rule, and every order that comes back carries the channel it came from into your ERP. The catalog work is done once; the channels are configuration and export profiles on top of it.

flowchart LR
  subgraph CS["Commerce Studio"]
    P["Products"]
    CH["Channels"]
    PR["Prices: one list per channel"]
    O["Orders: with channel and number range"]
  end
  subgraph XS["Experience Studio"]
    SHOP["Storefront: shop"]
    DLR["Storefront: dealer portal"]
  end
  subgraph IS["Integration Studio"]
    EXP["Export profiles"]
    WF["Workflows"]
  end
  MKT["Marketplace: Amazon Business"]
  PROC["Procurement platform: Mercateo, Unite"]
  ERP["Your ERP"]
  P --> CH
  CH -- "assortment per channel" --> SHOP
  CH -- "assortment per channel" --> DLR
  CH -- "completeness per channel" --> EXP
  PR --> SHOP
  PR --> DLR
  PR --> EXP
  EXP -- "BMEcat, CSV, classification" --> PROC
  EXP -- "listing feed" --> MKT
  MKT -- "orders" --> WF
  PROC -- "orders" --> WF
  SHOP --> O
  DLR --> O
  WF --> O
  O -- "order with channel marker" --> WF
  WF --> ERP
  classDef planned stroke-dasharray: 5 5

What you need

• A written purpose and a margin calculation after fees for each channel — Metrics that matter
• The dealer question settled: which prices your dealers may see, and what a direct listing means for them — Price models in B2B
• A catalog where assortment can be assigned per channel without duplicating products — Channels, locales and completeness
• A price list per channel, derived from the cost to serve that channel — Price lists
• The channel's data requirements written down: identifiers, units, classification, images, text limits — Catalog exchange formats
• An export profile per channel you can rerun — Catalog export profiles
• An order path that keeps the channel marker into the ERP — Number ranges

Build it

1. List your channels, current and wanted, each with a one-sentence purpose and a margin after fees — Metrics that matter
2. Decide the dealer rule before anything is public — Price models in B2B
3. Create your shop and your dealer portal as channels with their types — Channels
4. Assign the assortment per channel and decide what an unassigned product does — Why a product is not visible
5. Create one price list per channel, starting with the dealer conditions — Price lists
6. Give each channel its own order number range — Number ranges
7. Launch the dealer portal as a storefront on the dealer channel — Create a storefront
8. Write the procurement platform's data requirements into a completeness rule for that channel — Completeness and readiness
9. Add units and classification where the check fails — Map attributes to a classification
10. Build the export profile and deliver the first catalog — Export a catalog for a customer
11. Route the platform's orders back into the platform with the channel marker — Build a workflow
12. Price the marketplace channel from its cost to serve and list the checked assortment — Time-limited prices
13. Report revenue, contribution and delivery performance per channel monthly — Reports

Decisions you'll need to make

Related product areas

• Commerce Studio — Channels · Channel types · Prices · Price entries · Products · Channel values · Measurements · Orders · Number ranges · Segments
• Experience Studio — Sites · Domains · Themes
• Integration Studio — Import/export · SFTP server · Workflows · Inbound webhooks · Runs