A dealer order rarely ends with choosing products. Which price list applies, who gives approval, which address it ships to and how current the stock figure is are all part of the order. When those details circulate in separate emails, the sales team can spend more time reconciling records than taking orders.
A B2B dealer portal gathers these decisions into one flow that the customer and the operations team can follow together. The aim is not simply to offer an online basket. It is to make clear where an order came from, on what terms it is being assessed and where it is currently waiting.
The examples below are told through a hypothetical wholesaler. They contain no claims about price, savings or success rates; they exist to make the portal's scope concrete.
Treat company, location and user as separate things
A company can have several delivery points, and each point several purchasing users. Designing the user and the company as a single record makes order history and access rights hard to manage when an employee changes.
For example, head office may set the purchasing terms while a regional warehouse can only create its own orders. Keeping the company account, the delivery location and the person placing the order separate in the portal lets you apply that rule more clearly.
This distinction has an equivalent in products too: in Shopify's B2B documentation, company, company location and customer are different concepts, and locations can differ in pricing and payment terms. That is one example of a data-model approach; it does not mean every business should use the same product. Shopify: companies and customers.
Do not let the visible menu be your permission model
One dealer must not be able to open another dealer's order number by editing the link. The company relationship and the permission for the action have to be checked on the server with every request. That approach aligns with OWASP's recommendation to perform authorisation checks on each request. OWASP: authorization.
You can start by defining three roles for your own business: the person who prepares orders, the person who approves them and the person who monitors them. Confirm with the operations team which actions users genuinely need to do their jobs.
Decide at which moment the catalogue and price become binding
In wholesale, product visibility, minimum order quantity, units per case and the pricing unit all matter. Does “12 units” mean twelve items or twelve cases? If the unit is not explicit in the basket, even a correctly calculated price can turn into the wrong order.
Show the sales unit and the increment step on the product card. For a product sold in cases of six, for instance, it may be a business rule that quantity moves in multiples of six. But if customer service permits splitting a case, there has to be an authorised exception flow for it.
Write down at which stage the price is fixed, too. If the price seen in the basket has changed by the time the order is submitted, explain the change to the user and take fresh approval where needed. Do not later reconstruct an old order's total by looking at the current product price; preserve the price the order was accepted at.
Match order states to real operations
A single “pending” state is not enough. It has to be clear whether a dealer order is waiting on a manager's approval, on stock allocation or on a payment check.
An example flow can be set up like this:
- The dealer adds products to a draft order.
- The portal checks quantity, delivery address and pricing terms.
- If required, the dealer's manager approves the order.
- The order is transferred to the business's operational system.
- Once stock and commercial terms are verified, the order is accepted.
- Picking and shipping information is shown to the dealer.
That sequence is an example. Payment or stock checks do not happen at the same stage in every business. Before moving to design, follow the current process and assess whether any approvals can be removed.
Do not forget amendments and cancellations
Will products be addable to an approved order afterwards? If so, does the original approval still stand? Whose authority is needed to cancel an order that has already started picking? The answers affect both the interface and the record history.
For example, a change that increases the total may require fresh approval while correcting a delivery note does not. Test the rule with examples. Tell the dealer what changed and which step they can take, rather than “operation failed”.
In the ERP connection, separate transfer from acceptance
The portal saying “order sent” may not mean the ERP has accepted the order. The request may have arrived and failed validation, or the response may have been lost on the network. Keep transfer status and commercial order status separate in the portal.
Use a reference for each order that can be traced across systems. If there is any chance of resending the same record, establish an agreement that prevents a retry from creating a new order. Where the ERP does not support this natively, matching and duplicate checking may be needed in a middle layer.
Name the source system and the error owner
If stock comes from the ERP, product descriptions from the content system and shipping from the carrier, document the source of each field. Make it clear which information the portal can change and which it only displays.
Orders that fail to transfer should land on a visible work list. The operations colleague should see the reason for the failure, the time of the last attempt and a safe retry option. Present understandable status information without pushing technical error details onto the dealer's screen.
Where currency of data matters, show the timestamp. Rather than presenting old stock figures as a firm delivery promise, separate estimated availability, cases requiring confirmation and alternatives.
Test the first release on a single ordering scenario
For an example pilot, you might choose a dealer group on standard pricing, with one delivery point and a simple approval flow. Rather than covering every complex exception from day one, show that the chosen flow works end to end.
Write your measurement definitions at the start of the pilot: when does order preparation begin, at which moment does it end, how is a correction counted? Record the transactions resolved by phone as well. A drop in clicks inside the portal alone does not prove that total operational load has fallen.
Observe which steps need help on a first order. Does the dealer understand the price, notice the case selection, see the stock change when copying an earlier order? Separate whether the problem is a training gap or an unclear interface.
Implementation checklist
- Define the company, location and user relationships.
- Test dealer-specific catalogue and pricing rules with sample data.
- Show the sales unit and minimum quantity during product selection.
- Separate approval, stock, payment and shipping states.
- Test the scenario of the same order being transferred twice.
- Assign an owner and a tracking screen for failed ERP operations.
- Document amendment, cancellation and return flows.
- Measure the same indicators before and after the pilot.
When planning a dealer portal with WebWizz, you can share an example order and your current systems through our contact page. Running the conversation through the steps a real order passes makes the boundaries of the first release much clearer.
Frequently asked questions
Does a dealer portal require replacing the existing ERP?
Not always. First examine the ERP's access methods, order rules and data currency. The portal can complement the existing system; unsupported connections, however, may require additional development.
Is adding a dealer login to a normal e-commerce site enough?
For simple requirements it can be. Where there are branch-level permissions, price lists, approvals, credit terms and multiple shipments, how those work together has to be designed separately.
Should stock appear in real time in the portal?
It depends on the need. What matters is that the expectation of currency is explicit. Without defining the last-updated time and the order acceptance check, “live stock” is not a useful assurance.
Can a dealer reorder a past order in one click?
That option can be designed, but old prices, discontinued products and changed case quantities have to be revalidated. The copy action must not skip the step of assessing the past order under current terms.