By industry

The Mittelstand without an IT team

Everything above, done by three people who also have day jobs.

Forty people, a product that sells itself, customers who have bought from you for two decades, and every order arrives by phone, by fax or as an email that somebody retypes. There is no IT department. There is a colleague who is good with computers, a managing director who signs everything, and an Innendienst that is already at capacity. The digitalisation does not fail on willingness. It fails because nobody in the building has a spare year to run a shop project, and because the last enterprise software project produced a large invoice and a system nobody uses.

That history matters, because it usually leads to the wrong conclusion: that you need a smaller version of a big project. What you need is a different order of work. Everything on this site can be done by a team of three, if it is sequenced so that each phase is useful on its own and none of them requires a developer. The pattern that works in a company your size: get the product data right first, open the shop to the customers you already know, and only then automate. The pattern that fails is starting with the feature that demonstrates well.

What is different about your business

Nobody has this as their whole job. Plan in hours per week, not in full-time roles. Two people at four hours a week, sustained for six months, achieve more than a three-week sprint by everyone followed by silence. If a phase cannot be run at that pace, it is scoped too large.

Your ERP is grown, and it is the truth. It has twenty years of conditions, customer numbers and habits in it. Do not re-model it in the shop, and do not let anyone propose replacing it as step one of a shop project. The shop reads from it and writes to it; the ERP stays in charge.

You cannot absorb a failed launch. A large distributor can quietly retire a bad storefront. Your customers all know each other and your sales team by name. One week of wrong prices in front of your regulars costs trust you will spend a year rebuilding, which is why the rollout is account by account rather than by announcement.

Your scepticism about software projects is earned, and it is useful. Use it as a rule: every phase has to produce something a customer or a colleague can use within weeks. If a proposal's first visible result is six months out, it is the wrong proposal for your company.

Your advantage is that you know every customer by name. The large competitor has to run campaigns to move customers online. You can phone eight regulars, walk them through it personally, and fix what breaks the same afternoon. That is a faster and far more reliable migration channel than anything a marketing budget buys.

What you buy in matters more than what you build. Integration, hosting, updates and search are the parts that need specialists permanently. Configuration, product data and customer relationships are the parts only you can do. Keep that line in mind whenever the scope grows.

Your path

Phase 1: The catalog, not the shop

The first phase produces a usable digital catalog and no checkout. It is the phase your team can do alone, and it removes the largest cause of shop projects overrunning: the discovery, three months in, that the product data does not exist in a usable form.

  1. What the Revenue Cloud is and How the pieces fit together: one hour, everyone involved.
  2. B2B commerce basics and the B2B commerce glossary, so the vocabulary in the meetings is shared.
  3. Tour the CockpitInvite your teamFirst setup
  4. Publish a digital product catalog: the goal page for this phase.
  5. Plan your data model. Keep it small. Model the company you are, not the one you might become.
  6. Create a product, then Import products in bulk when the shape is settled.

Phase 2: A shop for the customers you already have

No campaign, no launch event. Eight regulars first, then the rest of the Innendienst's accounts one conversation at a time.

  1. Launch a B2B shop and Move existing customers online: the two goal pages for this phase.
  2. How pricing worksWhere your prices come fromContract prices for a customerCheck which price a buyer sees
  3. Connect your ERPDeciding your system of recordConnect a system. Buy this connection as a product. A colleague who can code is not a reason to build it; whoever writes it owns it at three in the morning for the next ten years.
  4. Organizations and hierarchies and Contacts and roles
  5. Order lists and recurring carts and Quick order and cart import: the two features regulars adopt.
  6. Pre-launch checks before the first customer logs in.

Phase 3: Take work off the team, then keep it running

  1. Cut manual work: the phase where the project pays for itself.
  2. Build a workflow and Monitor your syncs: you need to learn about a broken sync before a customer tells you.
  3. Build recurring revenueStanding orders for anything that repeats on a rhythm.
  4. Consolidate systems: the licence and tool count is a maintenance burden your team feels directly.
  5. Agree what counts as an orderDashboards and KPIs. Three numbers, reviewed monthly, is a complete analytics programme at your size.
  6. Users, roles and permissions and Security and data protection: an afternoon, once, and then annually.

The mistakes we see most in your industry

  • Starting with the feature that impresses. The configurator and the AI assistant demonstrate beautifully and depend on catalog and pricing work that has not happened. Start with the thing that removes a task from someone's desk this quarter.
  • Building the ERP connection in-house. It is the single most common source of long-term pain in companies your size. The person who wrote it leaves, the ERP gets an update, and nobody left in the building understands the mapping.
  • Modelling for the company you might be in ten years. Every attribute, family and price list you create has to be maintained by two people with other jobs. A small model you keep clean beats a complete one that rots within a year.
  • Announcing it to all customers at once. Every price defect appears simultaneously, in front of everyone, and you have one first impression with people who have bought from you since the nineties.
  • Not naming an owner for after go-live. A shop is a channel, not a project. Without one named person and a recurring hour in the calendar, the catalog goes stale, the zero-result list grows and within a year the phone orders are back.

What to measure

  • Hours per week the team spends on the platform. The number that decides whether this is sustainable. If it climbs above what two people can carry, something needs to be bought in rather than absorbed.
  • Orders arriving without anyone retyping them, as a count and as a share of all orders. This is the payback, in the plainest form available.
  • Online share per customer, for the accounts you have migrated. Never one company-wide average. With a customer list your size, the per-account view is both readable and actionable.
  • Lookup calls and emails: "what is my price for 4711-A", "where is my order", "can you resend the invoice". Count a typical week before you start, then repeat each quarter. It is the clearest before-and-after you will get.
  • Time to publish a product change, from the decision to it being live and correct. If it is measured in days, the model or the ownership needs attention.
  • Number of systems and licences in use. It creeps up, and it is a cost your team pays in attention as well as in money.
  • Price complaints from customers. Any at all, after Phase 2, means the price source is not settled. Stop the rollout and fix that before adding accounts.

Where to start reading

  1. First setup: a concrete plan for the first days, at your scale.
  2. Publish a digital product catalog: the right first project for almost every company your size.
  3. Where your prices come from: the decision that determines whether Phase 2 is weeks or months.

What you're building

The smallest stack that removes retyping: one catalog, one price list per customer group with contract prices for the regulars, your customers as organizations with named contacts, and one storefront. The ERP stays in charge. It sends articles, conditions and stock through a bought connection, and receives orders back the same way. Nothing here needs a developer, and nothing here is optional.

flowchart LR
  ERP["Your ERP: the truth"]
  subgraph IS["Integration Studio"]
    WF["Workflows: nightly file or connector"]
  end
  subgraph CS["Commerce Studio"]
    P["Products: a small, clean model"]
    PR["Price lists and contract prices"]
    C["Organizations and contacts"]
    OL["Order lists and quick order"]
    O["Orders"]
  end
  subgraph XS["Experience Studio"]
    SF["One storefront"]
  end
  ERP -- "articles, conditions, stock" --> WF
  WF --> P
  WF --> PR
  WF --> C
  SF --> OL
  OL --> O
  O -- "order, untouched" --> WF
  WF --> ERP
  SO["Standing orders (planned)"]:::planned
  SO -.-> OL
  classDef planned stroke-dasharray: 5 5

What you need

  • Two named people with four hours a week each, and a managing director who has agreed to that — First setup
  • A data model small enough to maintain: the families you sell today, the attributes buyers ask for — Plan your data model
  • A clear answer to where prices are owned (the ERP) and how they reach the shop — Where your prices come from
  • The ERP connection bought as a product, with the ERP partner booked before the go-live date is set — Connect a system
  • Your regulars as organizations, each buyer as a contact with their own login — Contacts and roles
  • Eight pilot customers who know they are first and have your mobile number — Move existing customers online
  • One person who owns the shop after go-live, with a recurring hour in the calendar — Data quality in practice

Build it

  1. Sit everyone involved down for one hour on what the platform is and how the pieces fit — How the pieces fit together
  2. Invite the team and walk through the Cockpit once — Invite your team
  3. Model the families and attributes you sell today, and stop there — Plan your data model
  4. Create ten products by hand, then import the rest from the ERP export — Import products in bulk
  5. Publish the catalog without prices, so it is useful before the shop exists — Publish a digital product catalog
  6. Book the ERP partner and get orders flowing out of the shop into the ERP, in a sandbox first — Connect your ERP
  7. Load conditions for the eight pilot customers and check what each of them sees — Check which price a buyer sees
  8. Set up order lists and quick order, because those are what regulars use — Order lists and recurring carts
  9. Run the pre-launch checklist, then phone the eight and walk them through it — Pre-launch checks
  10. Migrate the rest of the accounts one conversation at a time, through the Innendienst — Move existing customers online
  11. Switch on sync monitoring and name the person who reads the error list — Monitor your syncs
  12. Agree three numbers and review them monthly — Dashboards and KPIs

Decisions you'll need to make

DecisionThe trade-offWhere most customers land
Build or buy the ERP connection? The colleague who can code writes it, or the ERP partner and the platform's connectors deliver it.In-house is cheaper this quarter and depends on one person for ten years. Bought costs a day rate now and someone else owns it after every ERP update.Buy it. The one exception is a flat file the ERP already exports nightly, which an import profile can read without code.
How much do you model? The families and attributes you sell today, or the full range you might sell.A small model is maintainable by two people and needs extending later. A complete model is right on paper and rots within a year because nobody has time to fill it.Today's families, the attributes buyers ask for, nothing speculative. Extend when a real customer needs it.
Public catalog or login only? Product data visible to anyone with prices after login, or everything behind a login.Public data brings new enquiries and needs the catalog to be presentable. Login-only is safer and invisible to everyone who is not already a customer.Product data public, prices after login. Prices are confidential; thread sizes are not.
Where do prices live? The ERP owns conditions and the shop reads them, or the shop holds its own price lists.ERP-owned means one truth and a connection that has to work. Shop-owned means a copy that is correct for six weeks.ERP-owned, read through the connection. Contract prices for pilot customers may be loaded by file until the connection is live, and never after.
Rollout by announcement or by account? One email to all customers, or eight regulars first and then one conversation at a time.Announcement is fast and shows every defect to everyone at once. Account by account is slower and lets you fix things by hand while the audience is small.Eight regulars, personally. Then the Innendienst migrates their own accounts. No newsletter until the price defects are at zero.
Who owns the shop after go-live? A named person with hours in the calendar, or "the team".A named owner costs a few hours a week. No owner costs you the shop within a year, and nobody notices until it is gone.One named person, one recurring hour per week, and a second person who can cover.