Move existing customers online

The largest opportunity is almost never new customers. It is the regulars who already buy from you and still call to do it. Look at your own order intake: most of it arrives by phone, fax or email, and every one of those orders is your Innendienst retyping something the customer already knew.

Why this is harder than it sounds

Start by accepting that the phone is a good channel. The customer says "the usual, but forty this time", and a person who knows the account understands that, notices forty is unusual, mentions last month's price change and confirms Thursday. To move that customer online, the shop has to be better than a competent human who already knows the answer. Available is not enough.

So this goal has one hard dependency, and everything else is secondary.

Getting that right is rarely a shop problem. Conditions live in the ERP as layers: a customer/material condition, a customer-group discount, a scale starting at 250 pieces, a promotional condition dated 2019. Reproducing that faithfully, for every customer, as the page renders, is the project. Estimates go wrong here, not at the storefront.

Two more obstacles reliably surprise people. Availability that is a day old is worse than none. A buyer who orders against "in stock" and gets a backorder confirmation learns permanently that your shop lies, and phones to check from then on.

And the buyer is often not free to buy. In most of your customers, the person choosing the article is not the person who may commit the money. If the shop cannot capture their cost centre and respect what each person may commit, using it means going around their own purchasing rules. Competent buyers do not do that.

Then a people problem. The Innendienst does the migration, account by account, and from where they sit it can read as an argument that they are unnecessary. They are not (the same team handles several times the volume), but unless that is said out loud and reflected in how they are measured, the calls keep coming.

The levers

Show the customer their own price, without a phone call

What good looks like: a logged-in buyer sees exactly the net price their last invoice showed, including scale breaks, with no "price on request" in their assortment.

What it depends on: deciding where prices are owned and how they reach the shop. Read conditions from the system that maintains them rather than exporting once. An export is correct for about six weeks.

1. How pricing works
2. Price models in B2B
3. Price lists
4. Contract prices for a customer
5. Check which price a buyer sees

Make reordering faster than making the call

What good looks like: the buyer's last twelve orders are on the landing page after login, and reordering one is two clicks. A buyer who already has the article numbers, from a parts list, a maintenance plan or a spreadsheet, can paste them straight into a basket.

What it depends on: order history being complete, including phoned orders. A history showing only online orders is useless to exactly the customers you are converting.

1. The order lifecycle
2. Order lists and reordering
3. Quick order by article number
4. Checkout configuration
5. Quotes and negotiation

Work with their internal approval process

The outcome the customer wants: the buyer builds the basket, the spend is checked against what that person may commit, the release is recorded, and the cost centre travels with the line.

What the platform does today: every contact carries an order approval limit and an approve permission. An order above that limit is created and held as pending rather than going straight through. The limit is real and enforced at the moment of ordering. The cost centre is captured as free text on the order line and travels with the order.

What still happens outside the platform today: the release itself. There is no approval queue, no routing, no notification and no multi-step chain. A held order is released by your team once the customer confirms sign-off. There is also no budget entity and no consumption tracking, so "€40,000 this quarter for cost centre 4711" is counted in the customer's system, not in yours.

What it depends on: individual contacts rather than one login shared by the whole purchasing department. With one shared account, a per-contact spend limit means nothing.

1. How procurement governance works
2. Organizations
3. Contacts and roles
4. Approval rules
5. Cost centres and budgets

Make availability and order status trustworthy

What good looks like: the stock figure on the page is the one in the warehouse system, and the order placed at 22:30 is in the ERP before anyone arrives in the morning.

What it depends on: settling which system owns stock, and monitoring the sync so you find out it stopped before a customer does.

1. Integration patterns
2. Deciding your system of record
3. Connect a system
4. Stock accuracy
5. Monitor your syncs
6. Orders that get stuck

A sensible order

Phase 1: one segment, prices correct. Pick five to ten friendly regulars with different condition structures between them. Get their prices right, load their full order history, enable reorder, and let them use it. This phase proves the pricing mechanism against real conditions on real accounts, the only test that counts, while the number of affected customers is still small enough to fix things by hand. Depends on pricing and the ERP connection. Nothing else.

Phase 2: roll out account by account. The Innendienst migrates their own accounts, one conversation at a time: "your prices are in there, your last orders are in there, here is your login." Switch on per-contact spend limits and cost-centre capture for the accounts that need them, usually the larger ones. Be honest internally that releasing a held order is manual today, so this phase adds a task for your team before it removes one. Depends on Phase 1 holding up under load, and on the Innendienst having a reason to push. A per-account migration is slower to plan and far faster to succeed than a mass email.

Phase 3: remove the remaining reasons to call. Recurring baskets for demand that repeats, quotes handled in the platform instead of by email, self-service documents, and punchout where purchasing systems require it. Each targets a specific remaining call type. Pick them from what your team is still answering.

Common mistakes

• Announcing the shop to all customers at once. The first week produces every price defect simultaneously, in front of everyone, and you get one first impression.
• Copying prices in as a one-off export. It works until the first condition change, then it is wrong without anyone noticing. The most expensive defect in this area.
• Leaving the Innendienst out of the plan. They are the migration channel. If the project reads to them as a headcount argument, the calls continue and nobody can explain why.
• Making the buyer re-enter what you already know. Delivery addresses, their usual order units, their last basket. They have been your customer for eleven years; behaving as if you have never met is the fastest way back to the phone.
• Reporting one company-wide "online share". The number only becomes actionable per customer.
• Switching off the phone to force adoption. It converts a migration into a churn event.

How you know it is working

• Share of orders arriving through the shop, per customer, per month. The core metric here. Watch the distribution, not the average: fifteen customers fully converted is a different situation from every customer at 20%.
• The step change after enabling contract prices for an account. If it does not move their online share within a couple of order cycles, the prices are wrong or the reorder path is too slow.
• Calls and emails that are pure lookup. "What is my price for 4711-A", "where is my order", "can you resend the invoice". Categorise a week of them before you start, then repeat each quarter.
• Time from order placed to order confirmed, shop orders against phone orders. If the shop is not faster, buyers notice before your reports do.
• Orders held above a contact's limit, and how long each waited before your team released it. That wait is your customers' experience of the manual release step.
• Price mismatches reported by customers. Any at all after Phase 2 means the pricing source is not settled. See Common pricing problems.

Related goals

• Raise order value: the next lever once orders arrive digitally.
• Cut manual work: where the internal payback lands.
• Run a customer portal: the lower-risk first step if a shop is too much at once.

What you're building

A storefront where each regular logs in as a named contact of their organisation, sees the net price their ERP conditions say they should see, sees the stock your warehouse system reports, and reorders from their complete history in two clicks. The order lands in your ERP without anyone retyping it. The ERP stays in charge of conditions and stock; the platform reads them and hands orders back.

flowchart LR
  ERP["Your ERP"]
  subgraph IS["Integration Studio"]
    WF["Workflows"]
  end
  subgraph CS["Commerce Studio"]
    PR["Prices"]
    C["Customers"]
    ST["Inventories"]
    OL["Order lists"]
    O["Orders"]
  end
  subgraph XS["Experience Studio"]
    SF["Storefront"]
  end
  ERP -- "conditions, scales" --> WF
  ERP -- "stock" --> WF
  ERP -- "order history" --> WF
  WF --> PR
  WF --> ST
  WF --> O
  C -- "contact, approval limit" --> SF
  PR -- "net price" --> SF
  ST -- "availability" --> SF
  OL -- "reorder" --> SF
  SF -- "order, cost centre" --> O
  O -- "order" --> WF
  WF -- "order" --> ERP
  SUB["Standing orders (planned)"]:::planned
  SUB -.-> O
  classDef planned stroke-dasharray: 5 5

What you need

• A decision on where conditions are owned and how they reach the platform — Prices and your ERP
• Contract prices and scales per customer, readable at page-render time — Contract prices for a customer
• Customers modelled as organisations with named contacts, not shared logins — Organizations
• Complete order history per organisation, including phoned and emailed orders — Connect a system
• A stock feed with a cadence you can defend — Stock accuracy
• Order lists and quick order enabled on the storefront — Order lists and reordering
• An owner on your side for held orders and for the sync error list — Monitor your syncs

Build it

1. Write down which system owns prices, stock, customers and orders — Deciding your system of record
2. Set up the ERP connection for conditions, stock and history — Connect a system
3. Create the price lists and load contract prices for five to ten pilot accounts — Price lists
4. Check the price each pilot contact sees against their last invoice, line by line — Check which price a buyer sees
5. Create the pilot organisations and one contact per buyer, with approval limits — Contacts and roles
6. Load their full order history and switch on order lists and quick order — Quick order by article number
7. Configure checkout so order reference and cost centre are captured on the line — Checkout configuration
8. Route shop orders into the ERP and test one order end to end — Build a workflow
9. Agree with each pilot customer who releases a held order and how — Approval rules
10. Hand the pilot accounts their logins, one conversation each, and watch the online share per account — Customer activity
11. Migrate the remaining accounts through the Innendienst, in waves — Payment terms and credit limits
12. Put sync monitoring and a weekly reconciliation in place before you widen — Reconcile with your ERP

Decisions you'll need to make

Related product areas

• Commerce Studio — Price lists · Price entries · Organizations · Contacts · Order lists · Cart import/export · Orders · Stock levels
• Experience Studio — Sites · Messaging
• Integration Studio — Credentials · Workflows · Runs · Field mapping