Trade customers reorder the same things constantly, and most of that ordering arrives as email that somebody then types into an invoice.
A portal turns it around. They place the order themselves, against their own account and their own agreed prices, and what lands on your side is already a document.
What you can do
- Run one store or several, each with its own name, address, language and currency.
- Sell from the catalog you already keep, with no second product list to maintain.
- Let customers order against their account, using their billing and delivery addresses.
- Have each order generate the documents you nominate: an invoice, a packing note, or both.
- Build the navigation and the front page - menu, carousel, images, text blocks.
- Run a promotion with its own image, text and end date.
- Publish your shipping, refund, privacy and subscription policies.
- Post a message of the day when there’s something everyone needs to see.
- Read the orders with their lines, addresses and totals, and edit one before it goes further.
How it works in practice
Create the store (Shop → Stores). Name, title, logo, contact details, language, currency and a slug. The slug is what separates one store from another, which is how you can run a trade store and a retail one off the same catalog without them sharing a front page.
Choose what appears. A product is published to the store by a setting on the product itself, so your catalog stays one catalog. The same record that prices your invoices prices the store, and a price change happens once.
Lay out the front. A menu you build yourself, a carousel, images, text blocks and a template variant. There’s a message of the day for delivery notices and holiday closures - the things a trade customer needs to see before ordering rather than after.
Set the delivery expectations. Default delivery days, plus the blocks of text that go with an order: delivery terms, corrections, anything else you want on the page.
Then customers order. Each order records who placed it, the billing and delivery addresses, the lines with their quantities and prices, the tax breakdown and the totals. Because each line carries a snapshot of the product as it was ordered, an order stays readable long after the catalog has moved on.
Orders become documents automatically. Nominate which document types a completed order should raise, and they’re created through the ordinary document path. That means they post to your accounts and move your stock exactly like anything else.
Check an order before it goes. The list shows customer, city, total and date, and opening one shows the lines and both addresses. You can edit it when something needs adjusting before the documents are raised.
Good to know
- This is a trade portal first. Ordering against an account with agreed prices and known addresses is what it does well. If you’re selling to the general public at scale, weigh it against a dedicated retail platform connected through the WooCommerce connector - see connecting other systems.
- Store customers sign in separately from your staff. Someone with portal access isn’t a user of your company’s system and can’t see anything beyond their own orders.
- One catalog, one price list. The store shows what your product records say. That’s the point, and it means store-only pricing is a matter of the price list attached to the customer rather than a separate store price.
- Decide deliberately which documents get raised. Raising an invoice on every order suits a trade counter. It suits a business that picks and ships before invoicing rather less.
- Nothing here takes the payment by itself. Payment happens the way it does for any other invoice: a payment link, a bank transfer, or an account they settle monthly. See payments and getting paid.