Scale your business

Reduce manual work

From order intake to ERP without anyone retyping anything.

The point of efficiency here is capacity. The same team handles several times the volume, and the errors introduced by retyping (wrong quantity, wrong article, wrong delivery address) stop happening. The capacity you free is what lets you say yes to the next growth step without hiring first.

Why this is harder than it sounds

Automation is unforgiving in a way that people are not. When an order arrives as an email saying "10 Stk. der üblichen Dichtung", somebody in your Innendienst resolves three ambiguities without noticing: which seal, what "Stk." means for that article, and whether ten is plausible for that customer. A workflow does not. It either rejects the order or, worse, processes it literally.

That produces the first rule of this goal: automating a broken process gives you broken results faster. Every automation project turns into a data-quality project somewhere around week three. The teams that plan for that finish; the teams that treat it as a surprise stall.

The second obstacle is that the exceptions are the work. A large share of your orders are trivially automatable: known customer, known article, in stock, within credit limit, standard delivery. The remainder (partial availability, a blocked customer, an article discontinued last month, a delivery address that does not exist yet, a quantity that is not a multiple of the packaging unit) carries most of the handling effort. Automating the straightforward majority is a real win, but only if you design what happens to the rest. Left undesigned, exceptions turn into an order stuck somewhere with nobody's name on it.

Third, and most dangerous: after automation, nobody sees failures any more. While a person retyped every order, that person noticed when something looked wrong. Once the pipeline runs by itself, a failure is a line in a log. Without monitoring and someone accountable for it, failures accumulate for weeks until a customer calls to ask where their delivery is.

Finally, the constraint is usually the ERP. If it exposes stock through a nightly batch, no amount of configuration on this side makes it real-time. Design what you promise customers around what the source system can deliver; see Integration patterns.

This changes jobs, and the change needs to be said out loud. The Innendienst role shifts from data entry to exception handling and advice, which is more skilled work. If the team hears about it first from a project plan, you will get resistance that looks technical and is not.

The levers

Stop retyping orders

What good looks like: an order placed in the shop at 22:30 exists in the ERP with the correct customer, articles, quantities, prices and delivery address before anyone arrives in the morning, and the customer has a confirmation.

What it depends on: the article numbers and customer numbers matching on both sides. Mapping mismatches are the single most common cause of failed order transfers, and they surface only when you try.

Stop maintaining product data by hand

What good looks like: a supplier price and data update is a prepared file and an import run instead of a week of copy-paste. Changing a specification across 800 articles is one bulk operation. Category membership follows rules rather than being clicked in one product at a time.

What it depends on: a data model that is regular enough to be addressed in bulk. Bulk editing is only powerful over structured attributes: you cannot mass-edit a free-text description into a filterable value.

Design the exception path deliberately

What good looks like: every way an order can fail to go straight through has a named destination, a person responsible, and a customer-facing consequence you chose. A partially available order becomes a partial delivery with a clear confirmation instead of a phone call three days later.

What it depends on: knowing your exception categories. Take a week of orders, sort every non-standard one into a category, and count. That list is your automation backlog for the next year, in priority order.

Make failures visible before a customer sees them

Most manual work is rework. Monitoring converts a customer complaint into an internal alert that nobody outside the company ever hears about.

What good looks like: a failed sync raises an alert with a named owner within minutes. Product data that is incomplete for a channel does not reach that channel. Somebody looks at the error list every working day, and it is usually empty.

A sensible order

Phase 1: one direction, one document type, happy path only. Shop order out to the ERP. Everything that does not match the happy path is routed to a person with a clear reason attached. This removes the largest single block of retyping in the company and it depends on almost nothing beyond the connection itself and matching article numbers. Ship it before you attempt anything cleverer.

Phase 2: the return path and the master data. Stock, prices, order and delivery status flowing back so the customer can see them; product and price maintenance moving to bulk operations. This phase depends on having settled the system of record, because two systems both writing the same field is the failure mode that costs the most to unwind afterwards.

Phase 3: work through the exception list. Take your categorised exceptions and automate them in order of frequency, one at a time, each with its own monitoring. There is no end state here and there should not be. The last few percent of exceptions almost always cost more to automate than they save. Stop when the arithmetic stops working, on purpose, rather than drifting into a permanent project.

Common mistakes

Automating before cleaning. The pipeline will happily deliver your existing data problems into the ERP at speed.
Aiming for 100% straight-through processing. The irregular orders are irregular for business reasons. A designed manual path for them is a feature.
No alerting. An automated process with no monitoring is not automation, it is an unattended process. The first person to notice will be a customer.
Treating the ERP connection as a project that ends. It needs an owner, a test after every ERP change, and someone who reads the error list. Interfaces rot without anyone noticing.
Not planning the role change. The people whose work you are automating are the people who know every exception. They are the best source of requirements you will ever have and the most effective opposition if you leave them out.

How you know it is working

Straight-through rate: the share of orders that go from placement to ERP with no human touch. Measure it weekly and per channel; shop, punchout and manually captured orders behave differently.
Order lines retyped per week. On the automated path this should be zero, and any non-zero week is a defect to investigate, not a statistic to average.
Median and worst-case time from order placed to order in the ERP. The worst case matters more than the median. It is what the complaining customer experienced.
Open sync errors older than one working day. The target is zero. This one number tells you whether monitoring is real or decorative.
Exceptions per 100 orders, by cause. The total is a health measure; the breakdown is your backlog.
Hours per week spent on product data maintenance. Sample it for a week before you start (the estimate people give from memory is always low) and repeat the sample each quarter.

Move existing customers online: the source of the order volume this goal automates.
Consolidate systems: fewer interfaces is the structural version of this goal.
Decide on real numbers: the same integration work makes the reporting possible.

What you're building

An order path where the routine order never touches a person: placed in the storefront or by punchout, validated at checkout, written to the ERP by a workflow within minutes, confirmed to the buyer by transactional mail. Orders that fail a rule land in the order list with a status and a reason for the Innendienst to work. Supplier data arrives as scheduled import profiles rather than as copy-paste, and every automated flow has a run history with a named person who is alerted when it fails.

flowchart LR
  ERP["Your ERP"]
  SUP["Supplier files"]
  subgraph XS["Experience Studio"]
    SF["Storefront checkout"]
    MSG["Messaging: confirmations"]
  end
  subgraph CS["Commerce Studio"]
    CART["Carts: validation, units"]
    O["Orders: status, pending, exceptions"]
    P["Products"]
    INV["Inventories"]
  end
  subgraph IS["Integration Studio"]
    EV["Order events"]
    WF["Workflows: orders out, stock in"]
    IMP["Import profiles on a schedule"]
    RUN["Runs and alerts"]
  end
  IND["Innendienst: exception list"]
  SF --> CART --> O
  O --> MSG
  O -- "order placed" --> EV --> WF
  WF -- "order, immediate with retry" --> ERP
  ERP -- "stock, status" --> WF --> INV
  O -- "failed rule, reason attached" --> IND
  WF --> RUN --> IND
  SUP --> IMP --> P

What you need

A week of orders sampled and every exception sorted into a named category — The order lifecycle
The system of record settled per entity, written down — Deciding your system of record
Article numbers and customer numbers that match between shop and ERP — Field mapping
A working ERP connection for orders out — Connect your ERP
A product model regular enough for bulk operations — Plan your data model
Checkout rules for packaging units, addresses and credit limits — Checkout configuration
A named owner for the error list and the exception queue, told before the project plan is published — Monitor your syncs
A baseline: hours per week on order entry and product maintenance, sampled — The metrics that matter in B2B

Build it

Sample a week of orders and count the exceptions by category; this is the backlog — The order lifecycle
Settle which system owns orders, stock, prices and customers — Deciding your system of record
Connect the ERP and map article and customer numbers — Connect a system
Build the orders-out workflow for the happy path only, with retry and alert — Build a workflow
Route every order that fails a rule to a person, with the reason on the order — Orders that get stuck
Move validation to checkout: packaging multiples, delivery addresses, credit limit — Checkout configuration
Bring stock and order status back so the customer stops asking — Manage stock
Bring prices in as a scheduled import or as price entries — Import prices in bulk
Turn each supplier's file into an import profile on a schedule — Import/export
Move specification changes to bulk edits over structured attributes — Edit many products at once
Gate each channel on completeness so incomplete products never reach it — Completeness and readiness
Alert the named owner on every failed run and review the list daily — Runs
Automate the exception categories in order of frequency, one at a time — Partial deliveries and backorders
Re-sample the hours and the straight-through rate every quarter — Reconcile with your ERP

Decisions you'll need to make

Decision	The trade-off	Where most customers land
How much straight-through do you aim for? Everything automated, the routine majority automated with a designed manual path, or automation only for one channel.	Chasing the last exceptions costs more than they save and produces literal processing of orders that needed a person. Automating one channel only leaves the phone orders where they were.	The routine majority automated for every digital channel, and a written manual path with a reason code for the rest. The exception list is worked by frequency and stopped when the arithmetic stops working.
Where do exceptions live? As orders with a status in the platform, in the ERP, or in a mailbox.	The platform holds order statuses and the `pending` hold for orders above a contact's approval limit, but there is no routing and no notification out of the box; a person has to open the order list. A mailbox is invisible to reporting.	Exceptions stay as orders in the platform with a status and a reason, the Innendienst works the order list at fixed times, and an outbound webhook or workflow sends the notification. Releasing a held order is a manual step and is planned as one.
Validate at checkout or fix downstream? Reject a quantity that is not a packaging multiple at checkout, or accept it and let a person correct it.	Checkout rules mean an occasional buyer is stopped for a reason they may not understand. Downstream correction means the exception exists every time.	Validate at checkout with a clear message, for units, multiples and addresses. An exception prevented is cheaper than one handled.
Supplier data: scheduled import profile or manual? One profile per supplier on a schedule, or a colleague preparing each file.	A profile costs mapping work per supplier once and then runs. Manual preparation is quick for the first supplier and never stops.	A profile per supplier, starting with the three that send updates most often. A supplier whose format changes every time stays manual and is listed as such.
Who reads the error list? The integrator, IT, or the Innendienst.	The integrator is not there after go-live. IT does not know whether "customer 4711 unknown" is a data defect or a new account. The Innendienst does, and has a day job.	One Innendienst colleague, daily, at a fixed time, with the expectation that the list is usually empty. That person also owns the exception categories.

Commerce Studio: Orders · Carts · Cart import/export · Bulk actions · Import · Stock levels · Payment terms
Experience Studio: Messaging · Forms
Integration Studio: Workflows · Runs · Schedules · Event catalog · Outbound webhooks · Import/export · SFTP server

Edit this page

Connect your ERP

Products, prices, stock, customers, orders: in the right direction, at the right cadence, with one owner per field.

Decide on real numbers

One version of the truth, instead of five spreadsheets that disagree.