Most distributors and wholesalers I talk to take orders the same way: a shop owner sends a WhatsApp voice note, a sales rep writes the order in a notebook or a spreadsheet, someone in the office retypes it into the accounting system, and a day later the warehouse finds out an item was out of stock. Each step is a chance to get the quantity, price or customer wrong.
A B2B ordering portal (also called a dealer portal, trade portal or wholesale ordering portal) puts that flow in one place. Your trade customers log in, see their own prices and what is available, place or repeat an order, and check what they owe. Your team gets a clean order queue instead of a pile of messages.
Who this kind of portal is for
The pattern fits any business that sells repeatedly to other businesses:
- Importers and distributors supplying shops, supermarkets, pharmacies or restaurants
- Wholesalers with a few hundred active trade accounts
- Manufacturers selling to dealers, resellers or franchise branches
- Suppliers whose customers reorder the same items every week or month
If your customers are consumers paying by card, you need an online store. If they are businesses with accounts, credit terms and their own prices, a store will fight you at every step.
Why a regular online store is the wrong shape
A consumer store assumes one public price, anonymous checkout and payment up front. Trade ordering works differently:
- Prices are per customer. A supermarket chain, a corner shop and a reseller rarely pay the same price for the same carton.
- Accounts are approved, not open. You decide who can order, and the catalogue is often hidden until they log in.
- Payment is on account. Many orders are not paid at checkout. They go against a credit limit and are settled later.
- Orders repeat. The most used button is "order the same as last time", not "browse the catalogue".
- Someone else often orders for the customer. Sales reps place orders on behalf of shops during visits.
- Units matter. Pieces, packs, cartons and pallets, with minimum quantities and case multiples.
Those differences are why a B2B portal is usually a custom build or heavily customised, and why it belongs with custom CRM and portal development rather than a quick store setup.
What the first version should include
1. Customer accounts with more than one user
Each trade customer is a company, not a person. The owner, a store manager and a purchasing clerk may all need to order. Give each person their own login under the company account, and let the customer's admin decide who can place orders and who can only view. When someone leaves, their access goes with them. The same thinking applies to your side: admins, order desk staff, sales reps and the warehouse see different things. I covered how to design this without overcomplicating it in roles and permissions in a business app.
2. A catalogue built for ordering, not browsing
Trade buyers know what they want. The catalogue should be fast to search by product name, code or barcode, filter by brand or category, and show the unit and pack size clearly. A dense list with quantity fields usually beats a grid of large photos when someone is ordering forty lines.
Decide early how much stock detail to show. Some businesses show exact quantities. Others prefer "in stock", "low" and "out of stock" so competitors and customers do not see the warehouse numbers. Both are easy to build; switching later is the annoying part.
3. Customer-specific prices
This is the feature that makes or breaks the portal. Common setups:
- Price lists or tiers (wholesale, retail, key account) assigned to each customer
- Customer-specific overrides on certain items
- Quantity breaks (a lower price from a certain number of cartons)
- Time-limited promotions on selected products
The rule is simple: the price the customer sees in the portal must match the invoice they receive. That means prices come from the same place your accounting system takes them, or the portal becomes the source and the accounting system follows. Running two separately maintained price lists is how disputes start.
If you sell across currencies, for example in Lebanon where some customers are priced in dollars and some in local currency, or across several GCC countries, store the currency on the price list and on the order, not as a display setting. Tax handling should follow the rules where you operate; confirm them with your accountant and have the portal apply them consistently rather than recalculating by hand.
4. Fast reordering
Give customers their order history with a one-tap "reorder", plus saved lists ("weekly order", "Ramadan stock") they can edit before submitting. For many trade customers this is the only screen they will use, so make it the first thing they see after login.
5. Orders on account, with clear limits
Show each customer their balance, credit limit and open invoices. When an order would exceed the limit, decide the rule up front: block it, allow it but flag it for approval, or allow it and notify the account manager. Settlement usually happens outside the portal by bank transfer, Whish or OMT, and the portal should show when a payment has been recorded so the customer does not have to call to check.
6. Order status the customer can see
Received, confirmed, preparing, out for delivery, delivered. Keep the list short and use the same words in the office and in the portal. If an item was substituted or short-shipped, show it on the order line rather than leaving it for the driver to explain. A notification when the order is confirmed and when it leaves the warehouse removes most "where is my order" calls. WhatsApp can work for those alerts in markets where customers live in it; WhatsApp notifications for business apps covers when that is worth setting up.
7. Sales rep ordering
Reps should be able to pick a customer, see that customer's prices, history and balance, and place the order in front of them. On a phone this needs to be quick and readable in a shop aisle. A responsive web portal is usually enough at the start. If reps spend whole days in areas with weak coverage and need to work offline, a dedicated mobile app becomes worth it later, which is where mobile app development comes in.
8. An order desk for your team
Behind the customer screens, your staff need a queue of new orders, the ability to edit lines before confirming (stock issues, substitutions), a printable or exportable picking list, and a log of who changed what. This is the part customers never see and the part that saves the most office time.
Connecting to your accounting or ERP system
Most distributors already run an accounting or ERP system that holds products, stock, customers, balances and invoices. The portal should not try to replace it. It should sit in front of it.
The practical questions are:
- Which system is the source of truth for each thing? Usually the accounting system owns products, stock, balances and invoices, while the portal owns logins, saved lists and draft orders.
- How does data move? If your system has an API, the portal can read and write through it. If not, a scheduled export and import (files every few minutes or every hour) works more often than people expect.
- Which direction comes first? Start one way: pull products, prices, stock and balances into the portal, and send confirmed orders back. Two-way sync of everything on day one is where projects stall.
- What happens when the sync fails? Someone should get an alert, and the portal should show "stock updated at 10:40" rather than silently displaying old numbers.
Bring the name and version of your system to the first conversation, and whether you have access to its API or database exports. That single detail affects the plan more than any feature on the list.
Language and layout
In Lebanon and the GCC, customers and staff may prefer Arabic, English or both. If any users will want Arabic, plan for it from the start: right-to-left layout, Arabic product names alongside English ones, and invoices or order confirmations in the customer's language. Retrofitting RTL into a finished portal costs more than building it in, as I explained in building bilingual Arabic and English apps.
How I build it
My usual stack for a portal like this is a Next.js front end, a .NET Core API with a Postgres database, deployed in Docker on a Linux server with a CI/CD pipeline, monitoring and tested backups. That gives you a fast, searchable catalogue, a clean API for the accounting sync and for a sales rep app later, and an audit trail on every order and price change.
The closest public example of this kind of operations product in my work is NeonTask, a field-service platform where the office, technicians and client-facing flows share one set of records instead of parallel spreadsheets. The flow differs, but the principle is the same: one set of records, and everyone sees only what they should.
What can wait for version two
- Online card payment at checkout (most trade orders settle on account anyway)
- Loyalty points and rebate programmes
- Route planning for delivery drivers
- A native mobile app for customers
Launch with a handful of friendly customers and one or two reps, watch what they ask for over the first weeks, then add the next piece. If you want a broader view of how a customer-facing portal is scoped, see a client portal for your business.
What to prepare before contacting a developer
You do not need a full specification. These are enough to scope a first version:
- Your product list with codes, units and pack sizes (an export is fine)
- How your prices work today: tiers, customer overrides, promotions, currencies
- Roughly how many trade customers order regularly, and how many sales reps you have
- The accounting or ERP system you use and whether it has an API
- How customers pay you and how credit limits are handled
- The three most common order problems you want gone
Next step
If your order desk spends its day retyping WhatsApp messages, a B2B ordering portal is usually the right product. Send me the list above, even in rough form, and I will tell you what a sensible first version looks like and how it would connect to your current system.
Email hello@eliechaaban.com or use the contact section, and we can go through it on a call.