Key points
- Every commercial decision has two consequences: it changes what your sales rep does daily, and it determines what has to be configured in the system. Skip the decision and the default setting of your chosen tool makes it for you.
- Price and stock visibility is really a decision about how much work stays with your sales reps. Price on request across the whole catalog hands them back exactly the orders the platform was meant to take away.
- Trade credit without an agreed blocking variant, a named person who can lift the block, and a response time will stop a regular customer at the worst possible moment.
- Not every price fits a price list. Decide explicitly which situations follow the quoting path, so the platform never pretends to know a price it does not know.
The scope of your first release is settled: you know which processes go into the platform and which stay outside it for now. That scope now needs commercial substance, and it needs it before anyone starts building.
This chapter is not about price list mechanics. We covered rule layers, the order in which they resolve, and versioning separately, in the piece on B2B contract pricing. What matters here are the decisions an owner has to make earlier, because each one has two consequences: it changes the daily work of a sales rep, and it sets what has to be configured in the system.
Who sees a price, and at what point
The first decision is about price visibility. It has three variants, all of them common in wholesale:
- A public price list: the same figures for every visitor. It effectively rules out differentiated terms.
- Prices after login: the catalog is open to everyone, the figures only to verified trade customers. In wholesale this is the default.
- Price on request: nobody sees a figure until a sales rep gets in touch.
You can mix these: part of the assortment with public prices, the rest behind login. The consequences run both ways. Prices after login mean somebody has to verify and approve new accounts, and that task usually lands with a sales rep, along with the question of how fast it has to be done.
On the system side you need registration with approval, a link between the account and the customer record, and a catalog that works properly without prices. That is how a prospect sees it before logging in, and how search engines see it too.
Price on request applied to the entire assortment hands back to your sales team exactly the work the platform was supposed to remove: processing small, repetitive orders. Keep it where it is genuinely needed instead of making it the default.
Does everyone see availability
Stock visibility is a separate decision from price, so make it separately. There are four levels to choose from:
- An exact unit count: it shortens the conversation about whether goods are there, but it also reveals the size of your warehouse to anyone who will use that in a negotiation, competitors and dealers included.
- A general status: "in stock", "low stock", "made to order". Commercially safer, though on larger orders it still ends in a phone call.
- Availability after login: only verified trade customers see it.
- No stock information at all: every question goes back to a sales rep.
The system consequence matters more than it looks: the more precise the number you display, the more often you have to refresh it, and the more an error costs. The decision you make here comes back to you as an invoice in the next chapter.
Payment terms and credit limits
In wholesale, payment is rarely up front, so the platform has to handle deferred terms. Three things need settling:
- Who gets deferred payment: every verified trade customer, only those with purchase history, or case by case.
- Where the limit and the balance come from: it has to be the same ledger your finance team uses, not a separate table inside the store. Two independent versions of a balance will diverge within the first month.
- What happens once the limit is exceeded: the decision most often left unspoken until the day it blocks a regular customer.
Blocking variants and who lifts them
There are several kinds of block and they differ in commercial impact:
- A hard block: the order cannot be placed at all.
- A warning: the customer is informed but can continue.
- Accept and hold: the order is recorded and stopped before the goods are released.
- Restricted payment methods: ordering continues, but on prepayment only.
The last variant is usually the most sensible starting point, because it does not stop the sale, it changes its terms. Whichever you pick, you need an answer to who can lift the block and how quickly. Without that, the procedure collapses into a phone call to the owner.
Blocking on an exceeded credit limit is a finance decision with an immediate sales effect. Before you switch it on, settle three things: what exactly is blocked (placing the order, releasing the goods, or only the deferred payment option), who can lift it and within what time, and what the customer sees. A message saying "this order cannot be placed" with no reason and no named contact guarantees a call to the sales rep and a bad day on both sides.
Order minimums, units and case packs
A minimum order value or quantity is a logistics tool in B2B, not a marketing one: the point is that picking and shipping make cost sense. The decision is whether the minimum is one figure for everyone or varies by customer group and channel.
For a sales rep it means the end of manually merging micro-orders, but also conversations with customers who fall short of the threshold. For the system it means the minimum has to be a parameter of the customer terms rather than a constant in the configuration: the first contract with an exception to the rule will appear within a month.
Free shipping thresholds
This mechanism travels from retail to wholesale worse than expected. A single value rarely works, because transport cost depends on weight, dimensions, pallet count and region, and two orders of the same value can be a parcel and a half pallet.
A sensible first release keeps one value threshold for typical orders plus individual freight pricing for the unusual ones, flagged clearly in the cart.
The selling unit
The third decision in this group: if the product ships in cases of twelve, you have to settle whether a customer can buy seven. Answering "no" is easier in the warehouse, but it asks three things of the system:
- A unit conversion: single units, packs, cartons and pallets all have to convert into each other.
- Rounding up: to a full case, automatically and visibly to the customer.
- A message in the cart: explaining why seven became twelve.
The unit shown on the platform must be the unit that appears on the invoice. Otherwise your first complaint will be about exactly that.
Currencies and selling abroad
Multi-currency starts with a binary decision: does the first release handle export sales, or do they stay in email and quotes for now.
If they are in, you are adding a separate currency price list or a conversion rule, and with it the immediate question of which rate, from which day, applies to an order. Then come the consequences that are easy to forget at the planning stage:
- Tax: EU VAT number validation and different rates.
- Documents and the language of support: the invoice, the correspondence and after sales help.
- Logistics: different delivery terms and the cost of taking goods back from another country.
For a sales rep it means a second price grid to watch. For the system it means the currency is an attribute of the customer agreement and of the document, not a switch in the footer. If exports are a few percent of turnover today, an honest "not in the first release" is defensible, but it has to be a decision rather than an oversight.
The table below collects the decisions from this chapter. Read it row by row: if a column is blank for you, the decision has not been made yet, only postponed.
| Decision | What it means for the sales rep | What it means for the system |
|---|---|---|
| Prices visible only after login | Verifies and approves new accounts within an agreed response time | Registration with approval, account linked to the customer record, catalog that works without prices |
| Exact stock levels for logged-in customers | Fewer "is it in stock" questions, more complaints when the number drifts | More frequent stock refresh and a choice between physical stock and available to sell |
| Deferred payment with a credit limit | Needs to know who lifts a block and how quickly | Access to balances and overdue invoices, not just the limit amount |
| Logistics minimum per order | Fewer micro-orders to merge by hand, more conversations about the threshold | Minimum as a customer terms parameter plus a clear message in the cart |
| Selling in case packs only | Stops correcting quantities after the customer | Unit conversion, rounding up, consistency with the unit on the invoice |
| Selling in a second currency | A second price grid to maintain and different delivery terms | Currency as a customer and document attribute, a rate rule, EU VAT handling |
The pattern across the whole table: a commercial decision always has a counterpart in human work and in system configuration.
When you need a quote instead of a list price
Not every transaction fits a price list, and the platform should not pretend otherwise. The typical cases that need quoting:
- A configurable or non-standard product: the price only exists once the specification is agreed.
- Volume beyond your thresholds: the order runs past the agreed quantity breaks.
- Non-standard freight: size, deadline or delivery location outside the routine.
- A project or tender with a deadline: the quote is valid until a specific date.
- A new customer: no agreed terms exist yet.
The decision is which of these follow the quoting path and which can be handled by a rule in the price list. For the customer it means sending an enquiry instead of filling a cart. For the sales rep it means a task with a response deadline instead of another email in the inbox. For the system it means a quote status and an expiry date, so nobody orders at a price agreed six months ago.
The second, less obvious decision is what happens after acceptance. An accepted quote can apply once, to that order only, or it can create a time-limited customer term that also applies to subsequent purchases.
The first variant is simpler; the second reflects how wholesale actually works and is the one that removes the repetitive re-keying of the same arrangements from your sales team. How we set this process up in practice is described under B2B pricing and quotes.
Write the decisions down before you pick a tool
None of the decisions in this chapter belongs to IT or to your platform vendor. Collect them in one document and record the reasoning next to each, because a year from now nobody will reconstruct it from memory.
Some of them will trigger an internal conflict: finance will want prepayment and hard blocks, sales will want flexibility and exceptions, logistics will want high minimums. That conflict is better resolved on paper than in a system configuration a week before launch.
Nearly every one of these decisions also assumes the platform knows the current customer price, the stock level and the outstanding balance, and it holds none of that data itself. Where it gets that data, how often, and what happens when the source goes quiet is the subject of the next chapter.
Questions
Will hiding prices behind a login hurt your store visibility in search?
Category and product pages can still be indexed when figures are shown only to logged-in trade customers, provided the catalog works without prices and is not entirely locked behind a login. The real cost is different: a prospect cannot compare your offer before registering, and some enquiries land with a sales rep instead of in a cart. A middle path is a public list price or a price range on part of the assortment, with individual terms available after login. Neither variant guarantees rankings or traffic.
Does a B2B platform have to support trade credit from day one?
It does not. A first release can run on prepayment and proforma invoices for new customers and offer deferred terms only to those who already have an approved limit in your finance system. There is one condition: the platform must know the current balance and any overdue invoices. Without that, the block is calculated late, which is worse than no block at all because it creates the illusion of control.
What if some customers buy single units and others only full case packs?
Treat the selling unit as part of the customer trading terms rather than a global catalog setting. Set a default variant (usually the case pack) and name the groups allowed to order single units. The critical part is that the unit shown in the cart is the unit that reaches the sales document, together with its conversion factor. A mismatch between them ends in credit notes and disputes on delivery.
