Sell digitally

Launch a B2B shop

The full first build: catalog, prices, customers, checkout, go-live.

This is the everything-at-once project, and the order you do it in decides whether it takes one attempt or two. Data model before data, prices before customers, storefront last. A B2B shop sells to organisations rather than to people, and almost every difference from a consumer shop follows from that one fact.

Why this is harder than it sounds

The most expensive misconception in this whole area is that a B2B shop is a B2C shop with customer groups added. It looks true for a while. It stops being true the first time a key account logs in and does not see the conditions they negotiated, the first time a purchasing department asks who can approve a 12,000 € basket, or the first time a corporate customer asks for punchout. At that point you are building around the system instead of in it, and each addition makes the next one harder.

The second thing to accept early: the timeline is set by your ERP, not by the shop. Prices, stock, credit limits and order confirmation all live there. How quickly you can launch depends on what interfaces exist, how clean the article master is, and how customer conditions are structured. None of that is under the shop project's control. Companies that discover this in month three lose the time twice, because they have also built a storefront against assumptions that turn out to be wrong.

Third, the visible part is the small part. Everyone can have an opinion about the design, so the design attracts all the attention, while the attributes, the condition logic and the organisational model attract none. Those three decide whether the thing works at all. Resist this. The storefront is the last thing to build, and building it first is the most common reason a project has to redo work.

Scope is where these projects drown. The wish list on day one usually contains a configurator, punchout, a customer portal, three languages and a mobile app. Launch narrow: one country, one currency, one storefront, a defined assortment, a defined set of pilot customers. Everything on the list is still possible afterwards, and it will be cheaper once real orders exist.

Go-live is a ramp rather than a date. A B2B shop with no customers on it is not live in any meaningful sense, and a B2B shop that all your customers were told about on the same Monday will show every defect to everyone at once.

The levers

A data model that survives contact with reality

Everything downstream depends on this, and it is the expensive thing to change later, because by then products have order history attached.

What good looks like: the attributes buyers filter by exist as structured, typed values with units. Families group what behaves alike. Variants keep the article count manageable. Categories match how buyers think rather than how your ERP is organised.

What it depends on: deciding the model before loading data. Loading first and modelling afterwards means migrating products that are already referenced by orders.

  1. How product information management works
  2. Plan your data model
  3. Attributes and attribute groups
  4. Families
  5. Variants and family variants
  6. Create a product, once by hand, to prove the model
  7. Prepare your import file and Import products in bulk

Prices that are the buyer's prices

This is what makes it a B2B shop rather than a catalogue with a basket.

What good looks like: a logged-in buyer sees their negotiated net price with their scale breaks. An anonymous visitor sees a defensible list price, or nothing at all, by your choice. You can answer "why does this customer see this price" in under a minute.

What it depends on: where conditions are maintained and how they reach the shop. Settle this in week one. It is the item most likely to move your launch date.

  1. How pricing works
  2. Price models in B2B
  3. Price lists
  4. Currencies and tax
  5. Set a list price
  6. Contract prices for a customer
  7. Check which price a buyer sees

Customers modelled as organisations

What good looks like: the customer is an organisation with addresses, conditions and payment terms. The people are contacts with roles. A purchasing department with four buyers has four accounts, not one shared password.

What it depends on: knowing your customers' internal structures well enough to model them. The Innendienst knows them; the project team usually does not. Ask them.

  1. The B2B customer model
  2. How procurement governance works
  3. Organizations
  4. Contacts and roles
  5. Segments
  6. Payment terms and credit limits

A checkout and storefront built for how B2B orders

What good looks like: the buyer can enter their own order reference and their cost centre on the line, choose a delivery date, and split the delivery. Invoice is a payment method. The confirmation is immediate, and the order reaches the ERP without anyone retyping it.

Know where the boundary sits. The cost centre is free text captured on the order line. It travels with the order, but it is not master data, and there is no budget to draw it down against. Each contact has an order approval limit; an order above it is held as pending instead of being released. There is no approval queue, no routing and no notification, so releasing that order is a manual step your team performs. Design the checkout and the launch communication around that, rather than around a workflow that does not exist yet.

What it depends on: the order path and its numbering being agreed with whoever runs the ERP, before launch rather than during it.

  1. The order lifecycle
  2. Checkout configuration
  3. Payment methods · Shipping methods and zones · Stock and locations
  4. Number ranges
  5. How storefronts work
  6. Create a storefront and Themes and branding
  7. Domains and going live · Pre-launch checks

A sensible order

Phase 1: the invisible half. Model the catalogue, load the products, connect the ERP for prices and stock, and model your customer organisations. Nothing is customer-facing yet. This is most of the project by effort and all of it by risk. Its exit criterion is concrete: for ten real customers and fifty real articles, the platform shows the same net price and the same availability as the ERP, checked line by line.

Phase 2: a real pilot with named customers. Real domain, real prices, real orders, a limited assortment and a limited group of customers who know they are first. Everything after this point is easier to fix while the audience is small. Phase 2 depends entirely on Phase 1's exit criterion. Going live with prices that are 95 % right means every customer meets the other 5 % personally.

Phase 3: widen and add. Open the assortment, migrate accounts in waves through the Innendienst, then add what the wish list contained: punchout for the accounts that need it, a second language, quotes handled in the platform, portal features. Each of these is a small project once the foundation is real, and an enormous one before.

Common mistakes

  • Starting with the design. It is the only part everyone can judge, which is exactly why it absorbs attention it has not earned.
  • Deferring the ERP connection to "phase 2". It is the critical path. Anything built before it is built on assumptions.
  • Treating a customer as a login. A shared account makes per-contact spend limits meaningless, hides who ordered what, breaks reporting, and is painful to unwind after go-live.
  • Announcing the launch to everyone at once. Every defect surfaces simultaneously, in front of your whole customer base, and you get one first impression.
  • No definition of "the data is ready". Without a written completeness standard per channel, the catalogue is never finished and the launch date moves by feel.
  • Building the wish list into the first release. Configurators and punchout are legitimate requirements. They are not first-release requirements.

How you know it is working

  • Time to the first order placed by a real customer with no assistance. The single most informative number in this project, and the reason to run a pilot instead of a demo.
  • Second orders. Of your pilot customers, how many ordered again within their normal reorder cycle? One order proves the shop works. The second proves it was better than phoning.
  • Price defects reported per week. Near zero by the end of Phase 2 and exactly zero before you widen.
  • Straight-through rate, meaning orders that reach the ERP without a human touch. See Reduce manual work.
  • Checkout drop-off by step, plus orders sitting in pending. In B2B the interesting step is not payment. Count the orders held because they exceeded a contact's approval limit, and how long each waited before somebody released it. That queue is manual today, so it is a service-level number.
  • Products failing the completeness standard for the live channel. Target zero for the launched assortment; the count for the rest is your Phase 3 plan.

Related goals

What you're building

A storefront where a logged-in buyer sees their own articles at their own net prices, with the stock figure from your warehouse, and places an order that lands in your ERP before anyone arrives in the morning. The ERP stays in charge of conditions, stock and invoicing. The platform holds the catalog, the customer model and the checkout, and Integration Studio moves data between the two.

flowchart LR
  ERP["Your ERP"]
  subgraph IS["Integration Studio"]
    WF["Workflows"]
  end
  subgraph CS["Commerce Studio"]
    P["Products"]
    PR["Prices"]
    INV["Inventories"]
    C["Customers"]
    CART["Carts"]
    O["Orders"]
    PAY["Payments"]
    SH["Shipping"]
  end
  subgraph XS["Experience Studio"]
    SF["Storefront"]
  end
  ERP -- "article master" --> WF
  ERP -- "conditions, list prices" --> WF
  ERP -- "stock" --> WF
  WF --> P
  WF --> PR
  WF --> INV
  ERP -- "customer numbers" --> C
  SF -- "login, basket" --> CART
  CART --> O
  PAY --> O
  SH --> O
  O -- "order" --> WF
  WF -- "order" --> ERP
  WF -- "order status, documents" --> SF
  classDef planned stroke-dasharray: 5 5

What you need

Build it

  1. Write the data model on one page and get product management to sign it — Plan your data model
  2. Create attributes, attribute groups and families in the Cockpit — Attributes and attribute groups
  3. Create one product by hand and take it to 100 % for the web channel — Create a product
  4. Prepare the import file from the ERP export and load the launch assortment — Import products in bulk
  5. Set up markets, currencies and tax classes — Currencies and tax
  6. Create the list price list and the customer-specific price lists — Price lists
  7. Connect the ERP: stock in, orders out, prices per the decision you made — Connect a system
  8. Load organisations, contacts, roles and payment terms — Organizations
  9. Check ten customers and fifty articles line by line against the ERP — Check which price a buyer sees
  10. Configure checkout, payment methods, shipping and number ranges — Checkout configuration
  11. Create the storefront, apply the theme, connect the domain — Create a storefront
  12. Run the pre-launch checks — Pre-launch checks
  13. Onboard the pilot customers one conversation at a time — Move existing customers online
  14. Watch order transfer and price defects weekly, then widen — Monitor your syncs

Decisions you'll need to make

DecisionThe trade-offWhere most customers land
Where do customer conditions live? The ERP stays the owner and the platform reads them, or you maintain price lists in the platform and export to the ERP.ERP-owned means the shop is right whenever the ERP is, but every condition type the ERP has must be readable, and the connection is on the critical path. Platform-owned is faster to launch and wrong the first time the Innendienst changes a condition in the ERP by habit.ERP-owned, read live for customer conditions and nightly for list prices. Fifteen years of conditions do not move, and nobody wants two places to maintain a discount.
What does an anonymous visitor see? Prices, list prices only, or a catalog with no prices.Public prices bring search traffic and new accounts, and your dealers and competitors read them. No prices protects the conditions and closes the door on new demand.Catalog public, list prices public where dealers are not involved, everything else after login. Companies with a dealer network keep prices behind login and accept the lost reach.
One organisation per company, or one per site? A customer with three plants is one organisation with three delivery addresses, or three organisations.One organisation keeps history together and makes company-wide reporting trivial, but every contact sees every site. Three keep sites apart for permissions, and the customer's headquarters loses the overview. Organizations have no parent-child hierarchy, so you cannot have both today.One organisation with addresses, unless the sites buy on separate conditions or must not see each other's orders. Segments group what belongs together for reporting.
Invoice as a payment method for whom? Everyone who registers, known customers only, or nobody until vetted.Open invoice terms remove all friction and put credit risk on every new registration. Prepayment for unknown accounts is safe and costs some first orders.Invoice for existing customers, taken from the ERP's payment terms; card or prepayment for self-registered accounts until somebody moves them.
How do you handle orders above a contact's approval limit? Set the limit and hold the order, or leave limits off and let everything through.A held order is honest to the customer's purchasing rules, and releasing it is a manual step on your side today. No limits means the shop cannot be used by buyers whose company requires sign-off.Limits on for the larger accounts that ask, with a named person releasing held orders daily. Everyone else: no limit, order goes straight through.
Launch to whom? A pilot group of five to ten, or all customers with a mailing.A pilot finds defects in front of people who forgive them, and it costs a few weeks. A mailing is faster and shows every defect to everyone at once.A pilot. Nobody who has done the mailing does it twice.

Related product areas

Sell digitally

The first digital channel: catalog, portal, shop, marketplaces, and the customers you cannot reach today.

Launch a customer portal

One place for documents, orders and self-service, instead of five email threads.