Dealer portal development

What a dealer portal actually coordinates

A dealer portal is a controlled ordering environment for companies you have approved to buy from you. It coordinates four things a retail store never touches: who is allowed in and on whose authority, what each account may see and at what price, how an order is committed when payment is not immediate, and what record each side keeps.

The people using it are at work. They are not browsing, they are placing the order their branch needs by Thursday, and they will judge the portal on whether it beats the message they send you today. Platform choice, gateway fees and the order chain every store shares belong to e-commerce website development. This page is the trade layer on top, built custom rather than bought.

Is it a dealer portal, or a shop with accounts?

The fit test is short. If everybody pays the same published price, pays when they order, and one person decides alone, a normal store with customer accounts will do, and accounts and portals covers the login side. It becomes a portal when price depends on the account, when goods go out on credit terms, when somebody must approve an order before it is real, or when what a dealer may buy is restricted.

Many businesses sit in the middle, selling to the public and to the trade from one catalogue. Decide early whether the trade side is a mode of the same store, where signing in changes prices and payment options, or a separate surface. Deciding late is what produces a retail checkout with trade rules stapled to it.

The buyer is doing a work task, not shopping

Most dealer orders are reorders: the same twenty or thirty lines every few weeks. That makes speed and accuracy the job rather than discovery, which points at a different interface. Order from a previous order or an invoice, saved lists per branch, a quick entry pad taking pasted part numbers and quantities, and units of measure that match how you sell, so a carton of twelve is never mistaken for twelve pieces.

Search has to match how the trade talks. A buyer types your part number, their own code, the manufacturer's reference or an industry nickname and expects one correct row, which is catalogue and search work. Photographs matter far less than a correct price, a current stock position and a clear pack size. Assume a phone in a van, and keep a reorder within very few clicks.

Companies, buyers and the staff behind them

The account is the company, and people hang off it. One dealer may have a manager who orders, a director who approves and an administrator who only wants statements. Your side has actors too: the account manager, the credit controller who releases held orders, and the warehouse team who see what was committed. Those roles decide every permission in the system, so write them down before anything is designed.

Then write the lifecycle around them: how a company applies, who approves it, what it sees before approval, and how access is removed. One documented portal product treats access as an explicit grant tied to a company's contacts, which can be revoked later. Revocation is the forgotten half. A buyer who has left the dealer and still has a working login can commit that company's credit.

Price and catalogue are properties of the account

In a trade system the price is not a number on a product, it is the answer to a question about who is asking: price lists by tier, negotiated lines, quantity breaks, and a decision on whether recommended retail appears at all. The catalogue moves the same way, since some ranges are reserved, and an item a dealer may not buy should not be a disappointment discovered at checkout. One platform's B2B documentation models this with companies, contacts, locations and catalogues carrying negotiated prices, which illustrates the shape rather than the choice.

The harder question is where those prices live. If the authoritative list sits in your accounting or ERP system, the portal has to show what will actually be invoiced, because a mismatch between the two destroys trust faster than any amount of slow loading. Decide the source of truth for prices, stock and the account itself, then which way data flows and how often.

Credit, approvals and the order nobody simply pays for

Retail checkout ends in a payment. A dealer order often ends in a commitment against agreed terms, which is a different thing to build. The portal needs the credit limit, what is already outstanding, and what the account may do when the next order crosses that line. Block it, hold it for release, or allow part of it: each is defensible, but the rule is yours to set rather than improvised on a Friday afternoon.

Approvals run on the buyer's side too. A manager builds an order, a director approves it above a threshold, and only then is it an order you are expected to fulfil. Documented platform workflows include that pattern, an order drafted for review before the buyer completes it. Our recommendation, a design choice to confirm rather than a universal rule, is that a blocked order routes to a named person with its context rather than failing quietly.

Stock across branches, and what you promise about it

Trade buyers ask one question: can I have it, from where, and by when. Answering it means deciding which branch serves a dealer, whether stock elsewhere is visible, and whether a transfer is something the portal offers or your team arranges. Then decide what a number on screen means, because committed stock, stock allocated to somebody else and stock arriving next week are three different things. Many wholesalers are better showing a band, such as available, low or call us, than a precise count they cannot stand behind, and your team needs one screen of held orders, approvals and commitments, which is admin dashboard work.

Where the portal meets the systems you already run

Most dealer portals are an interface onto systems that already exist. Accounts, price lists, credit balances and stock usually live in an ERP or accounting package, and the portal exposes them safely to the right company. Whether that can be done depends on what the system exposes, the permissions you can obtain, how clean the data is and what the supplier's terms allow, all checked before anyone promises a connection. That is integration work. Decide too what happens when that system is unavailable: queue orders and say so, or refuse them. And sometimes the honest answer is a smaller integration rather than a new portal, which we would rather say early.

A dealer network we built

Sentrix Auto is client work, live on the client's own domain: a brand site with a dealer platform behind it, where authorised installers sign in to register customer installations against a vehicle, keep warranty records and maintain the storefront details feeding the public installer map. That network surface is about records and accuracy rather than ordering, which is the point: a dealer portal is defined by what the network has to do, not by a template.

Scope, ownership and acceptance

Write the scope with names against it: the account model and its roles, onboarding and revocation, catalogue and price rules per account, credit terms and limits, approval thresholds and routes, stock visibility, reordering behaviour, the systems being integrated and in which direction, and the acceptance evidence above. Agree who accepts each part and what ownership looks like after launch, because a portal holding trade accounts is a system rather than a website.

Bring what you know: how many dealers you have and how many order regularly, how your price lists are structured, your credit rules, who approves what, the systems holding the truth today, and the twenty lines that make up most of your volume. Tell us how your accounts buy and we will say what we would build first, what belongs in a second phase, and where fixing the existing process would serve you better.