A B2B dealer portal is a single login where a sales rep places an order on behalf of their customer and sees that customer’s price list, credit limit and complete purchase history. It differs from an ordinary store in one respect: the buyer is not anonymous. Every partner has assigned terms, an account manager and a balance, and the system has to know all of it at the moment that partner drops goods into the cart. That is what makes the call to the office - “what does this cost for me and can I take it on invoice?” - unnecessary.
How a dealer portal differs from an ordinary store
An ordinary store shows everyone one price and takes payment up front. A dealer portal shows a price calculated for one specific business partner and accepts an order settled later, within an approved trade credit.
| Element | Retail store | B2B partner portal |
|---|---|---|
| Access | open to anyone | after registration and approval, prices hidden from guests |
| Price | one for everyone | discount group, individual price list, quantity tiers |
| Payment | up front | deferred, credit limit, balance and overdue invoices |
| Who orders | the customer themselves | the customer or a rep on their behalf |
| Volume | single units | cases, pallets, multiples |
The basic version - partners simply placing their own orders, with no dealer layer on top - I described in the piece on the B2B ordering portal.
Three roles that have to fit into one portal
In a well-designed dealer system there are three types of user, and each of them sees something different after logging in.
- The business partner (a shop, a workshop, a farm) - their own price list, availability, their orders and invoices. They see neither other partners’ prices nor your margin.
- The sales rep - a list of the customers assigned to them, the ability to place an order for any of those customers, their own turnover and the commission accrued.
- The office and logistics - everything: approving registrations, setting limits, releasing orders held back by a balance.
That split is the single most important design decision. The systems that land on my desk for repair usually have one panel with field-hiding bolted on afterwards. The outcome is predictable: sooner or later somebody sees another partner’s discount.
Features that genuinely shorten the working day
| Feature | Who benefits | What stops happening |
|---|---|---|
| Ordering on behalf of a customer | the rep | dictating an order to the office over the phone |
| Individual pricing in the cart | the partner | questions like “what is my price on this item code?” |
| Live stock levels | both sides | orders for goods that are not there |
| Credit limit and balance | the office | manually checking whether goods can be released |
| Ordering by code or from a file | the partner | clicking through a hundred items in a catalogue |
| Reorder and shopping lists | the partner | rebuilding the same cart every month |
| History and downloadable invoices | accounting | email requests for duplicates |
| Commission report | the rep | a spreadsheet kept by hand |
Quick ordering tends to be underrated. In industries with long catalogues, where the partner knows the item codes by heart (tyres, parts, electrical, agri), a “type a code and a quantity” field plus a CSV upload replaces clicking through the entire catalogue line by line. How much it actually saves depends on the size of the cart and on whether the item codes are in order.
Price lists, discounts and limits - the heart of the system
The pricing layer decides whether the portal survives the first change in commercial policy. A layered setup works: base price, the partner’s discount group, an individual discount on selected product groups, and quantity tiers at the end. All of it calculated in one explicitly documented order, with the result visible in the cart together with an explanation of where it came from.
The credit limit works just as simply: the system knows the approved amount and the total of unsettled invoices. An order above the limit does not vanish - it moves into a “held, awaiting a decision from the office” state. A hard block always ends in a phone call, and phone calls were exactly what we set out to remove. Settlement data usually comes from the ERP system - how that works with the popular ones, I laid out in the piece on a B2B platform wired into Subiekt, Comarch and enova.
Ordering on behalf of a customer without the risk
A rep stepping into a partner’s account can do real damage if it is built carelessly. The rules I stick to:
- The rep sees only the customers assigned to them, never the whole database.
- Every entry into a customer account is logged: who, when, what they ordered.
- A bar stays on screen at all times: “you are working as: Company X”.
- The rep cannot change invoicing details or the partner’s password.
- The partner receives an email noting who placed the order on their behalf.
Point five gets skipped often, and it is the one that builds trust in the system. The partner has to know what was ordered on their account before the goods arrive.
Integration with the warehouse and the ERP system
A B2B portal is only as good as the data it shows. When stock levels refresh once a day, sooner or later somebody orders the last two pallets twice. A sensible flow: products, item codes and base prices travel from the ERP system into the portal, stock levels sync frequently and - on critical items - are reserved the moment an order is placed, while orders travel back the other way along with a note on who placed them. I went through the detail of that in the piece on syncing stock levels across the store, the warehouse and marketplaces.
KSeF, Poland’s mandatory e-invoicing system, now applies to every business, so the assumption is that the document for a B2B order is created in the accounting system, that system sends it to KSeF, and the portal merely shows the invoice to the partner.
Rolling it out in stages, not all at once
The biggest mistake in projects like this is trying to launch everything in one go. A dealer portal splits into stages, each of which can go live on its own and each of which takes a slice of manual work off the office.
| Stage | What gets built | Effect |
|---|---|---|
| 1 | login, registration with approval, individual pricing | partners see their prices without calling |
| 2 | cart, quick ordering, history | orders come in overnight and at weekends |
| 3 | rep accounts, ordering for a customer | the rep serves the customer on site |
| 4 | limits, balances, invoices in the portal | the office stops chasing receivables by hand |
| 5 | commissions, reports, two-way integration | settlements calculate themselves |
Stages one and two are worth launching quickly, with a handful of friendly partners - their comments are worth more than a month of planning. Taking on new partners, with tax ID and VAT status checks, I described in the piece on registering B2B accounts.
What it costs and where the budget leaks
The cost depends mainly on the number of integrations and on how unusual the pricing policy is. A simple portal with one group price list and an order export is a different job from a system with commissions and multiple warehouses.
I bill fixed-bid, usually in the range of 5,000-10,000 PLN net per stage with a closed scope (Polish market rates), and I quote every stage separately in writing before we start. On top of that comes maintenance, because a portal wired into an ERP system needs looking after: Basic from 1,000 PLN, Pro from 2,000 PLN, Premium from 3,500 PLN net per month. Third-party tools (hosting, plugins, connectors) are counted separately and worth checking as you go, because vendors change their price lists.
The budget usually leaks in three ways: messy product data, a discount policy nobody can state in a single sentence, and integration left to the end instead of done at the start. The first two you can sort out without a developer.
How I work
I start with a free diagnosis: I look at what you have today (a store, spreadsheets, an ERP system), ask about the pricing policy and about how many partners and reps are meant to use the portal. Out of that comes a map of stages, and on a larger job a fixed bid in writing before we start, with the scope of each stage. I usually build this on WooCommerce with a B2B layer, and where the logic gets complex, in a hybrid with Laravel. If you already run a retail store, adding a B2B layer to it usually comes out cheaper than building a second system alongside - I wrote that up in the piece on B2B and retail in one store.
Frequently asked questions
Can a B2B portal be built on WooCommerce, or does it need a custom system? It can, and in most cases that is the sensible choice, because WooCommerce already handles products, orders and taxes, and the B2B layer goes on top. A custom system makes sense with unusual logic - product configurators, say, or settlements across several legal entities. I make that call after looking at the pricing policy, not upfront.
Can a rep order on behalf of a customer from a phone? Yes, and it is one of the main reasons portals like this get built. There is one condition: the interface has to be designed for a phone from day one, because the rep places the order standing in the customer’s warehouse. A search by item code and a list of recent orders matter more there than pretty photography.
How long does a distributor portal take to implement? The first stage - login plus individual pricing - is usually a few weeks, provided the product data is in order. A full system with commissions and two-way integration is a project measured in months, which is why I split it into stages. The brake is almost never the programming, it is waiting for decisions and for access to the ERP system.
Will partners actually use it? That comes down to two things: whether the portal is faster than a phone call and whether the data in it is true. If a partner sees an out-of-date stock level twice, they go back to calling and it is hard to win them back afterwards. So I get data quality and speed right first, and only then add features.
Running a store where something does not work the way it should? I build and rebuild WooCommerce stores - from a single fix to reworking the whole sales flow. Tell me what you are dealing with and I will send back a scope and a price.