Going live
Going live is the end of a road, and the road has a right order. It is not the order the menus suggest. This page is that order: a first week of foundations on a small, real slice of your business, then the areas that follow, each when it has something real underneath it. The week does not end with a live shop. It ends with one product group, its prices and one customer working end to end, which is the thing a live shop is made of.
Testartikel 1. Real
data is the only thing that exposes real modelling problems.The shape of the week
| Day | What you do | Why now |
|---|---|---|
| 1 | Orientation, access, markets and tax | Nothing else is correct until currency and tax are |
| 2 | Design the data model on paper | The one decision that is expensive to change |
| 3 | Build the model, create one product by hand | Proves the model before you multiply it |
| 4 | Import the 200–500 real articles | Real data breaks the model, not test data |
| 5 | Prices | Needs products to exist |
| Later | Customers, then the storefront | Both depend on everything above |
Day 1 — Orient, then configure the frame
Read What the Revenue Cloud is and How the pieces fit together, take the Cockpit tour, and invite your team. If you have not yet run the six First setup walkthroughs, days 3 to 5 below are where they fit.
Then do the one piece of configuration that everything else assumes: your markets, their currencies and locales, and your tax classes, under Commerce Studio › Configuration. See Currencies and tax and Languages and markets.
Day 2 — Design the data model before you touch a screen
Spend this day in a room with a whiteboard and your product colleague, not in the Cockpit. Work out which kinds of product you sell, which facts each kind must carry, which of those facts a buyer would filter by, and which are prose.
Plan your data model is the article for this day. While you are there, settle which system owns which field — usually the ERP owns the article number, the weight and the tax class, and the platform owns everything a buyer reads.
Day 3 — Build the model, then one product by hand
Now create it: attributes and their groups, families, measurements for anything with a unit, and a first category tree.
Then create a single product manually. Doing one by hand shows you exactly what the family forces, what is missing, and what feels wrong — while changing it is still free.
Day 4 — Import the real slice
Take your 200–500 articles and put them through the real path: prepare the import file, then import them.
Expect the first attempt to fail. That is the point of doing it in week one rather than week nine. Then look at completeness — it will tell you honestly how much of your data is publishable, and the number is usually lower than anyone expects.
Day 5 — Prices
Products exist, so prices can now be modelled. Create your price lists, set a list price, then add one scale price and one contract price so you have seen all three layers behave.
Finish by using Check a price to see which layer actually won. That screen is how you will answer every "why does this customer see that number" question for the rest of the project.
After the week — customers, then the storefront
Customers next. Create one real organisation, its contacts and roles, and one segment — then assign a price list to the segment and confirm the right price appears for the right buyer. That loop is the heart of B2B, and it is worth building it once by hand before automating anything.
Storefront last. Create a storefront only once there is data behind it. A storefront over an empty catalog teaches you nothing, and a storefront built before the data model settles gets rebuilt.
Do not start the ERP integration this week. Book the conversation with your IT colleague or your integration partner now, because lead times are long, but connecting systems before your model is stable means mapping fields twice. See Connect a system.
What to check at the end of the week
- A real product from your own catalog is visible in the Cockpit with its technical attributes as structured fields, not as text in a description.
- An import ran, and you know what its errors meant.
- One article shows a different price to two different buyers, and you can explain why.
- Nobody on your team is still asking where a thing lives.
Month two and beyond
Week one gets one product group, its prices and one customer working end to end. What follows is the order in which the remaining areas pay off. Each of them needs real data or real traffic underneath it, so the sequence matters as much here as it did in week one.
- Tune search first. Nothing downstream matters if the buyer cannot find the article. Once a few thousand real articles are live, read what people actually typed — search analytics and the zero-results report — then fix it with synonyms and rules and facets that match how your buyers narrow down. Budget an hour a week for this permanently, not a project.
- Then promotions. With prices modelled and search working, a promotion is a lever rather than a liability. Start with one volume offer or one bundle, and settle the stacking question — may a promotion apply on top of a contract price? — before anything goes live. See Promotions vs. contract prices.
- Then quotes. This is the sales-led half of your revenue and usually the fastest win with the Innendienst, because it removes retyping. Agree your quote settings, run ten real requests through the quote lifecycle, and only then model the framework agreements and call-offs behind them.
- Then procurement. Your larger customers ask for this the moment they take the shop seriously: cost centres, budgets and approval chains that mirror their own purchasing policy. Start with the one account that is asking — see Approval models and Approval rules — and hand the ongoing maintenance to their administrator rather than yours.
- Then configurable products and spare parts. Both are catalog projects with a storefront on the end, and both run to months rather than weeks. Decide which one your business actually lives on: a configurator if you build to order, or spare-part identification and bills of material if you have an installed base out in the field.
- Then localization and classification. These are trigger-driven — a new country, or a customer who will not load a catalog without eCl@ss. Neither is urgent until it is blocking, and both take longer than anyone estimates. See How catalog translation works and Classification standards.
- Then recurring orders. Last, because it needs order history to be worth anything: smart reordering predicts from consumption you do not have yet in month one. Begin with standing orders for the handful of customers whose monthly basket you could already write down from memory.
Running alongside all of it is the ERP integration, and the keys and sandbox your integrator will ask for on day one of that project. Provision those early — see Create an API key.
Next
- Go-live checklist: six questions to answer before the domain goes on.
- Launch a B2B shop: the full project, beyond week one.