Let your trade customers place their own orders

Manual wholesale ordering fails quietly. Nothing breaks; it just gets slower and more expensive per order. Every emailed order has to be read, interpreted, priced against the right agreement, checked against stock and retyped into the system that holds the truth. Each of those steps is somewhere a wrong unit, a stale price or a missed minimum quantity enters the business, and wholesale errors are expensive because the quantities are large. It shows up as credit notes, re-shipments and your best people doing data entry. It also shows up as a ceiling: you can take only as many orders a day as your team can type, so growth means hiring order-entry staff rather than serving more accounts. A portal removes the transcription, not the relationship — the rep still handles the negotiation, the new account and the problem delivery.

• The same accounts reordering the same SKUs every month, by hand
• Prices read off a PDF that may not be the current one
• "Is this in stock?" answered by a person instead of a screen
• Re-keying errors that turn into credit notes and re-shipments

Retail pricing has one number. Wholesale has a number per customer, and sometimes per customer per product. A portal is only useful if every buyer sees the price they will actually be invoiced: contract prices for negotiated accounts, tier or group pricing for everyone else, quantity breaks that reward larger orders, and promotions with an end date. Layered on top are the rules that stop bad orders before they become admin — minimum order quantity per line, minimum order value per basket, case packs and pallet quantities that force multiples of six or forty-eight instead of arbitrary numbers. Getting these rules into the storefront matters far more than any visual decision. A portal that shows the wrong price, or lets a buyer order half a case, creates more work than the email thread it replaced, and it damages trust with exactly the customers you least want to annoy.

A trade buyer is not browsing. They arrive with a list, often produced by their own stock system, and they want it in a basket in under a minute. That means a quick-order screen where SKUs and quantities can be typed or pasted in bulk, CSV upload for buyers whose list comes out of an ERP, saved lists for recurring assortments, and reorder from history as the fastest path of all — most wholesale orders are a variation on the last one. Search has to match part numbers and manufacturer codes, not just product titles, because codes are what buyers have written down. Stock belongs on the same screen: quantity available, or at least a band and a lead time, so nobody has to ask. This is where a B2B storefront rebuild earns its keep, since these screens live entirely on the customer-facing side.

• Quick order by SKU, typed or pasted in bulk
• CSV upload for lists exported from the buyer's own system
• Reorder from history, plus saved recurring lists
• Search that matches part numbers, not just product titles

One wholesale customer is rarely one person. There is a buyer who builds the order, a manager who approves spend above a threshold, and an accounts department that never logs in but receives the invoice. A portal that models this — several logins under one company account, shared order history, a spend limit that routes larger orders to an approver — matches how procurement already works. Payment follows the same logic. Many trade accounts do not pay by card at all; they order on credit terms against a purchase order number, so checkout needs a PO field and the option to place the order on account instead of taking payment. Where payment does happen online, keeping the native WooCommerce checkout through a hybrid handoff means existing tax, terms and payment plugins behave exactly as they do today. Quotes sit alongside this: some orders start as a request, get a negotiated price, then convert into an order.

Most businesses can run trade and retail on a single WooCommerce install, and usually should. Products, stock and orders stay in one place, which is the whole point — two sources of truth for inventory is a problem you will pay for weekly. What separates the audiences is a role on the customer account plus pricing and visibility rules, so a logged-in trade buyer sees trade prices and trade-only products while everyone else sees retail. Splitting into two installs is worth considering only when the catalogues genuinely differ, when tax or shipping logic conflicts, or when an approval workflow would complicate retail checkout — and it costs you shared inventory. The boundary is the same either way. WooCommerce keeps products, stock, orders, customers, pricing rules, coupons, tax, shipping and payments. The storefront replaces the pages buyers touch — catalogue, search, quick order, account area, order history — and asks WooCommerce for every decision that has money attached.

A wholesale catalogue leaking into search results is a commercial problem before it is a technical one: retail customers see trade prices, and so do competitors. Login-gated pages have to be genuinely gated rather than merely unlinked — served only to authenticated accounts, marked noindex, kept out of the XML sitemap, and excluded from any product feed going to Google Merchant Center or a comparison site. Caching deserves the same care, because a price rendered for one account must never be served from cache to another; per-account pages should not be publicly cached at all. The public side can still be indexed hard: a trade landing page, product pages without prices, an application form. That split is usually the right one, and our technical SEO work treats the gated area as something to keep out of the index deliberately, not something to hope crawlers ignore.

• Authentication first — noindex alone is not access control
• Gated URLs excluded from the sitemap and from product feeds
• No public caching of any page that renders an account price
• A public trade page that can rank, separate from the portal

Wholesale orders do not end at the confirmation screen. They have to reach whatever system issues the invoice and tells the warehouse to pick — Xero, QuickBooks, Sage or a full ERP. There are three honest options. Export, where someone downloads orders and imports them, which is fine at low volume and miserable at high. Middleware, where a connector syncs orders, customers and stock on a schedule. Or direct integration, which is the most reliable and the most work. Whichever you pick, decide early which system owns each field. If the ERP owns stock and pricing, WooCommerce is a mirror and the portal displays it without arguing; if WooCommerce owns them, the ERP has to accept that. Two systems both convinced they hold the master price is the most common way a wholesale portal starts producing wrong invoices, and it is much cheaper to settle on paper than to debug later.

If you have eight wholesale customers who order twice a year, a portal is the wrong purchase and you will feel it. The build cost is real, the rules take longer to specify than to implement, and software that eight people barely use still needs maintaining. The cheaper fix comes first: one shared, always-current price list instead of emailed PDFs, a simple order form that arrives in a consistent format, and a standard answer for stock questions. That usually buys a year. What changes the arithmetic is volume and repetition — dozens of accounts, orders arriving weekly, the same SKUs coming back, and someone whose real job has quietly become retyping. If you are unsure which side of that line you sit on, count the hours your team spends on order entry in a normal week and weigh them against what a build costs. If you would rather talk it through than guess, describe a typical week and we will say honestly whether this is worth doing yet.