Transform sales

Build recurring revenue

Consumables, wear parts and service contracts: make the reorder a list first, a suggestion second, and automatic only once it is trusted.

Gloves, filter cartridges, cutting fluid, drive belts, the seal kit that gets changed every 500 operating hours. A large share of B2B revenue is the same articles again, at roughly the same interval, ordered by the same person. In most Mittelstand companies every one of those repeats is handled as if it were the first time. The customer notices they are low, calls, someone takes the order and types it. The demand was predictable; the process was not.

Why this is harder than it sounds

Start by separating four things that get filed under one word. They differ in who controls the schedule, what happens to the price, and what a cancellation means. A project that treats them alike will get at least three of them wrong.

Replenishment is customer-driven and irregular: they order when they notice, from a list they keep. A standing order is a fixed basket on a fixed interval that you execute on their behalf. A subscription is a plan with a term and a billing cycle, usually for something that is not a physical good: software, a service level, a maintenance package. A service contract is an obligation with dates in it, which happens to generate orders. Making a wear part a subscription, or a maintenance contract a standing order, produces arrangements nobody can cancel cleanly.

The hard part is the transfer of control, not the schedule.

An automatic order that arrives unwanted damages more than one order. In B2B the customer will not send it back. Returning goods costs them more effort than keeping them, so they keep them, resent it, and end the whole arrangement. One badly timed run costs you the recurring revenue, not the run. Give the customer a visible next run date, a skip, a pause and a quantity change, and remind them before it fires.

Then the price question, which most projects postpone and should not. Does a standing order carry the price agreed when it was set up, or the price valid on the run day? Both are defensible; not deciding is not. Fixed prices become margin leakage the first time your input costs move. Current prices produce a run at a raised price that nobody warned the customer about, which is the same conversation as a wrong invoice. Whichever you choose, it belongs in writing in the arrangement itself, and the customer has to be told before a change takes effect.

Prediction is thinner than it looks. Order history is not consumption. Your customer may buy the same filter from a second supplier, may have bought a year's worth in one project order, may run a plant that stops in August. A naive average over the last four orders will suggest a reorder in the middle of a shutdown. Seasonality and project quantities are the two effects that make a suggestion engine look foolish in its first month, and both are visible in the data before you switch it on.

Run day is an event that can fail without anyone noticing. Stock is short. A price list expired at midnight. A payment term changed. The contact who owns the arrangement left the company six weeks ago and the confirmation email bounces. None of these announce themselves, which is why a recurring programme needs an owner watching runs, on top of a configuration.

Finally, an internal objection you should expect from sales: that an automatic reorder locks in a price and removes the contact. It removes the call. What it locks in is the demand, and the customer who has a standing arrangement with you is the one your competitor cannot reach with a lower quote on a Tuesday.

Where the platform stands today. Order lists exist and belong to the organisation. Standing orders, subscriptions and reorder suggestions are planned apps. Phase 1 below runs entirely on what ships now; Phases 2 and 3 describe the planned screens at their planned state.

The levers

Find what repeats before you automate anything

What good looks like: you have a list of articles and customers where the same thing is ordered on a rhythm, with the interval and the quantity for each. It comes from order history rather than from an assumption about which products are consumables.

What it depends on: order history being complete across channels, including phoned and emailed orders. If only shop orders are in the data, the analysis describes the customers you have already converted.

Turn the repeat order into a list, then into a schedule

What good looks like: the customer's recurring basket exists as a named list they can see and edit, and turning it into a standing order is a decision they make, with the next run date visible from that moment.

What it depends on: lists that belong to the organisation rather than to one person's login, so the arrangement survives a change of contact.

Suggest before you automate

What good looks like: the customer is told "you usually order this about now" and confirms in one action. Nothing ships without a human decision until the suggestion has been right often enough to be trusted.

What it depends on: enough order history per customer and article to make the interval meaningful, and a threshold for when a suggestion is worth sending at all. A suggestion that is wrong twice is ignored forever.

Put the non-physical revenue on a proper plan

What good looks like: service levels, maintenance packages and software are sold as plans with a term, a billing cycle, a renewal date and a defined notice period, instead of an annual invoice somebody remembers to raise.

What it depends on: payment terms and payment methods that work for a repeated charge, and a renewal that is visible before it happens rather than after.

A sensible order

Phase 1: lists, for the customers who already repeat. Before any schedule exists, give your regular buyers their recurring basket as a saved list and make reordering it two clicks. This is the phase with no risk: nothing fires by itself, and the lists are the raw material for everything after. Depends on complete order history. Do it for the twenty accounts with the clearest rhythm rather than for everyone.

Phase 2: suggestions, then standing orders for the ones who ask. Turn on reorder suggestions for those accounts and watch how often the timing is right. Where a customer says "you might as well send it", convert the list into a standing order with the price rule written down, a visible next run date and a skip. Depends on Phase 1 having produced real lists, and on somebody owning the run monitoring from the first run rather than from the first complaint.

Phase 3: subscriptions, contracts and prediction at scale. Service and software plans with terms and renewals; consumption-based suggestions across the whole customer base; the connection between a service contract's due dates and the parts it consumes. This is also where you start managing the portfolio (active, paused, churned) instead of individual arrangements. Depends on Phase 2 having a run-failure rate you can state.

Common mistakes

Making it automatic before it is trusted. Suggest first. The order you send unasked is the one that ends the arrangement.
Hiding the next run date. If the customer cannot see what is coming and change it, they will cancel instead of adjusting.
Leaving the price rule unstated. Fixed or current at run time. Decide, write it in the arrangement, and tell the customer before a change takes effect.
Predicting from order history alone. A project order or a factory shutdown poisons the average. Check both before you switch suggestions on.
Tying the arrangement to one person's login. They change job and the standing order becomes an orphan nobody at either company can explain.
Nobody watching the runs. A run that fails for stock or an expired price list makes no noise, and the customer finds out by not receiving anything.

How you know it is working

Share of revenue arriving from a standing arrangement or an accepted suggestion. The headline metric here, reported per customer segment as well as company-wide.
Run success rate. Runs that fired, against runs that failed for stock, price or contact. Any figure other than near-100% is an operational problem, not a reporting one.
Skip and pause rate. Healthy at a low level; it means customers are steering. Rising sharply means your interval is wrong.
Cancellations of standing arrangements, with the reason. The most valuable number on this page. Cancellations after a run the customer did not want are a different problem from cancellations after a price change.
Suggestion acceptance rate, per article family. Below a useful threshold, the prediction is guessing and should be narrowed to the articles where it works.
Order frequency per customer before and after. The point of the exercise is a shorter, steadier interval rather than a larger single order.

Move existing customers online: the prerequisite. The repeat order has to be digital before it can be automatic.
Cut manual work: where the internal payback lands.
Run a customer portal: where the customer sees and steers their arrangements.

What you're building

Each regular customer's recurring basket exists as an order list that belongs to their organisation, and reordering it is two clicks on the storefront. Where the rhythm is clear, the platform proposes the reorder at the right time; where the customer asks, the list becomes a standing order with a visible next run and a written price rule. Every run produces a normal order that reaches your ERP like any other. Order lists and the order path ship today; suggestions, standing orders and subscriptions are planned.

flowchart LR
  ERP["Your ERP"]
  subgraph IS["Integration Studio"]
    WF["Workflows"]
    SCH["Schedules"]
  end
  subgraph CS["Commerce Studio"]
    C["Customers"]
    OL["Order lists"]
    PR["Prices"]
    ST["Inventories"]
    O["Orders"]
  end
  subgraph XS["Experience Studio"]
    SF["Storefront"]
    MSG["Messaging"]
  end
  RS["Reorder suggestions (planned)"]:::planned
  SO["Standing orders (planned)"]:::planned
  SUBS["Subscriptions (planned)"]:::planned
  ERP -- "order history, stock" --> WF
  WF --> O
  WF --> ST
  C -- "organisation owns the list" --> OL
  OL -- "reorder in two clicks" --> SF
  O -. "history, interval" .-> RS
  RS -. "you usually order this now" .-> MSG
  OL -. "converted" .-> SO
  SO -. "run day" .-> O
  SCH -. "interval" .-> SO
  SUBS -. "term, billing cycle" .-> O
  PR -- "price rule" --> O
  ST -- "availability on run day" --> O
  SF -- "order" --> O
  O -- "order" --> WF
  WF -- "order" --> ERP
  classDef planned stroke-dasharray: 5 5

What you need

Complete order history per organisation, including phone and email orders — Connect a system
An analysis of which articles and customers repeat, with interval and quantity — Recurring revenue in B2B
Order lists enabled, owned by the organisation rather than a contact — Order lists and reordering
A written price rule for arrangements: fixed for the term or current at run day — Standing orders
A stock feed reliable enough that a run does not fail on a stale figure — Stock accuracy
Payment terms and methods that work for a repeated charge — Payment terms
A named owner who reads the run and error list every working day — Monitor your syncs

Build it

Pull twelve months of orders across all channels and find the twenty accounts with the clearest rhythm — Reports
Check each candidate for project quantities and seasonal gaps before trusting the interval — How smart reordering works
Create a list kind for recurring baskets — List kinds
Create the recurring basket as an order list for each of the twenty accounts — Order lists and reordering
Show the list on the storefront after login and make reorder two clicks — Edit pages and blocks
Confirm the order path into the ERP works for a list reorder — Process an order
Write the price rule and the skip, pause and quantity-change rules into the arrangement template — Standing orders
Switch on reorder suggestions for the twenty accounts and track acceptance per family — Configure reorder suggestions
Convert the lists of customers who ask into standing orders with a visible next run — Manage standing orders
Send the reminder before each run and watch the first ten runs by hand — Forms and transactional email
Put the service and software plans on subscriptions with term, cycle and notice period — Subscriptions
Review the portfolio monthly: run failures, skips, cancellations with reasons — Recurring revenue health

Decisions you'll need to make

Decision	The trade-off	Where most customers land
Fixed price or price at run day? The arrangement carries the price agreed at setup, or the price valid when the run fires.	Fixed is what the customer signed up for and leaks margin when input costs move. Run-day is fair to you and surprises the customer with a raised invoice.	Fixed for the term of the arrangement, with the term short (six to twelve months) and a written notice before any change. The customer accepted a price, and an unannounced change is the fastest way to a cancellation.
Suggest or execute? Send a suggestion the customer confirms, or ship automatically on the interval.	Suggestions cost the customer one click each time and are never unwanted. Automatic runs remove the click and put the arrangement at risk on the first badly timed delivery.	Suggestions first, automatic only for accounts that ask for it and only after the suggestions have been right for several cycles. Nobody regrets the slower route.
Who owns the arrangement: contact or organisation? Tie the list and the schedule to the person who set it up, or to the organisation.	Contact-owned is simple and dies when the contact leaves. Organisation-owned survives staff changes and needs a named role to steer it.	Organisation-owned, with one contact named as the steering role and a second as backup. Order lists already belong to the organisation, which makes this the default rather than a decision.
What happens when a run cannot fire? Ship partial, hold the whole run, or skip and notify.	Partial delivers something and produces a backorder the customer did not ask for. Hold keeps the order clean and the customer waiting. Skip and notify is honest and moves the decision back to the customer.	Hold and notify for stock, skip and notify for an expired price or a bounced contact. Both need a person who reads the run list the same day.
Where does the analysis live until the planned apps ship? Build the repeat analysis from order reports now, or wait for the suggestion engine.	Now means a spreadsheet from an order export and twenty lists you maintain by hand. Waiting means the customers keep phoning in the meantime.	Now, for the twenty accounts. The lists and the price rule are the same work either way, and they are what the planned apps will run on.

Commerce Studio — Order lists · List kinds · Organizations · Orders · Price lists · Stock levels · Payment methods · Payment terms
Experience Studio — Sites · Messaging
Integration Studio — Schedules · Workflows · Runs

Edit this page

Automate quote-to-order

Requests, negotiation, framework agreements, call-offs: the sales-led half of B2B revenue, out of Outlook and into one place.

Sell complex products

Spare parts, configured products and punchout: the three journeys where the buyer knows the machine, the specification or the procurement system, but not your article number.