B2B wholesale portals: sell according to each account’s terms

A procurement employee may arrive with SKUs and quantities already listed, not to browse lifestyle photography. They need fast entry, reorder, contract pricing, and a believable delivery date. Their manager may log in only to approve an order, while finance downloads invoices and statements. Design the signed-in homepage around these tasks rather than a public promotion repeated on every visit. Interview several existing customers and watch how they order today before writing requirements.

One customer may deliver to several branches while another consolidates invoices monthly. “Company account” does not mean one person and one address. Model users, roles, destinations, and constraints. Decide whether prices and terms belong to the whole organisation, one branch, or a specific contract. Postponing that choice leads to costly workarounds in orders and reporting.

Price may vary by tier, contract, quantity, or temporary agreement. Write the precedence when rules overlap. Does the contract price override a public discount? Is a minimum quantity per item or per order? Buyers need to see the final price or a clear notice that a quote is required. Showing one price and manually revising it after submission damages confidence. Sales staff need to see why a rate was applied instead of guessing from a separate spreadsheet.

Test awkward scenarios: an alternative product, partial availability, a price change while a saved basket is waiting, or an expired agreement. Do not turn low stock into a misleading delivery promise. Depending on your policy, show available quantity and a separate estimate for the balance or route the order for review. Explicit rules reduce later calls and shorten approval time.

Not every wholesale order ends in instant online payment. A purchaser may create a draft, submit it to a manager, or request a quote valid for a defined period. Your team may need to check a credit limit before acceptance. Give the order clear states: draft, awaiting buyer approval, awaiting your team, accepted, in preparation, or rejected with a reason. An order must not enter the warehouse twice if someone clicks approval again or an event is delivered twice.

If credit is involved, let finance define limits and exceptions. The portal may show an outstanding balance or place an order on hold, but software should not invent your collection policy. Record exception approver, reason, and date so management can review risk. A digital journey should not become an unmonitored shortcut around established controls.

Decide whether ERP or another system owns product, stock, pricing, and customer records. The portal submits an order and receives fulfilment and invoice states. Any manual adjustment should flow back into what the buyer sees. If integration is down for an hour, are orders queued and can staff identify which have not reached finance? Test outages, retries, and duplicate messages. An attractive interface must not hide lost orders between systems.

Use stable company, branch, product, and order identifiers rather than matching free-text names. Some buyers order using their own internal codes; a map between their codes and yours can make repeat ordering substantially easier. These details matter more as the number of accounts grows.

A corporate buyer orders one hundred units. Sixty are in a nearby warehouse, twenty are elsewhere, and the remainder will arrive in two weeks. The portal might offer split delivery, one later delivery for the whole quantity, or an alternative product that needs procurement approval. It should not silently select an option that violates the customer’s contract or changes delivery cost. Test what the buyer, account manager, warehouse, and finance team each see; they need different views of the same order.

If the customer accepts a partial shipment, connect each fulfilment event to the appropriate invoice or document according to your operating process and keep the remaining quantity visible. Do not mark an order complete merely because the first parcel left. One case like this reveals data-model quality, order states, and permissions better than a gallery of attractive screen designs.

When requesting a development quotation, send this scenario and ask what belongs in the first release, what requires ERP integration, and what will remain a controlled manual step. This produces testable scope and prevents management and supplier from discovering different expectations after launch. It also helps your own team agree whether customer promise, stock accuracy, or speed is the primary constraint to solve first.