Dealer portal development means building a logged-in system where your dealers place orders, see their own net prices and check their account balance without calling your sales desk. It tends to pay off when you have dozens of dealers or more, orders repeat, and your inside sales team spends its day taking calls and retyping them. It is the wrong next step when your dealer terms exist only in people's heads, your stock figures can't be trusted, or a module in your existing ERP would do the job.
This guide is for manufacturers and distributors who still take dealer orders by phone, email or WhatsApp and are trying to decide what a portal should cover and whether to fund one. We start from the work your team does today, because that is what determines the scope, and because the honest answer is sometimes "not yet".
A phone order is a longer process than it looks
When a dealer calls and says "same as last month, but add two cases of the 40-millimetre", it sounds like a thirty-second transaction. Trace what actually happens next. Someone finds last month's order, remembers which item the dealer means, checks stock in another screen, applies a discount from memory or from a spreadsheet, types the order into the ERP, and then sends a confirmation, if they remember. A credit check may wait until the warehouse asks. Any mistake surfaces days later as a wrong delivery.
That walk-through matters for two reasons. It shows where errors enter, which is usually retyping and memory rather than carelessness. It also exposes what your salesperson does that nobody ever documented: suggesting a substitute when an item is out, warning that a truck leaves at 3 pm, spotting that an order is unusually small. A portal removes the retyping, but it will also remove those quiet favours unless you design replacements for the ones that matter.
Log one week of contact before you write a brief
Before you talk to any developer, ask whoever handles dealers to tag every call, email and message for one week: place order, change order, price question, stock question, balance question, where's my shipment, return or warranty. Note roughly how long each one took. It costs almost nothing and gives you a better requirements document than a workshop will.
Results often contradict management's assumptions. You may be planning an ordering portal when a large share of contact is really "has my order shipped?", in which case order status and tracking deserve a place in the first release ahead of an elaborate promotions engine. Or you may find balance questions are rare because reps already handle them, so the statement screen can wait.
Now do a simple sum with your own numbers. As an illustration: 40 order calls a day at 6 minutes each, including entering the order, is 240 minutes, or 4 hours of team time daily. A portal will only absorb part of it, because some dealers won't switch and complicated orders will stay on the phone. So apply a cautious share rather than the whole figure, and treat any vendor who promises a specific saving as guessing. Reduced mis-shipments and out-of-hours ordering may add to the case, but you should estimate them from your own returns data.
Your real price list is the list of exceptions
Few established dealer networks run on one price list. Over the years you gain tier discounts, a legacy rate for one long-standing account, freight-included terms for one region, a free-goods deal on ten cases, year-end rebates and project pricing agreed for a single job. None of that is wrong, but a screen can't say "let me see what I can do". Every arrangement has to become a rule or be retired.
A useful exercise: pick three dissimilar dealers, namely a large one, a small one and the one with the messiest agreement. Work out by hand the net price of the same five products for each. You will see how many exceptions you really have, and you will have test cases to give your developer. When the system goes live, its answers must match yours to the cent. It is also worth checking the order of operations, because whether discounts stack or compound changes the result, and only one of those can be the rule.
International networks add more variables. If you sell across borders, each price list needs a currency, and you must decide whether exchange-rate moves update prices automatically or on a schedule. Agree on how long a displayed price stays valid, and whether it locks at order or at shipment. Delivery terms change the landed cost a dealer compares against, so showing them next to the price prevents arguments later. A dealer who sees a Euro price with undefined freight will still pick up the phone.
Treat the project as a chance to simplify. Consolidating dozens of one-off discount rates into a handful of tiers makes the software cheaper and your commercial policy clearer. Sales will push back, so hold that conversation before development begins. We cover the fundamentals of tiers, credit and minimums in our wholesale sales management guide.
Credit and statements: show one version of the truth
A statement screen sounds like the easy part. It isn't, because the moment a dealer sees a balance that differs from your accounting records, you have created a dispute the phone would never have caused. Settle three matters first. Decide which system owns the ledger; almost always that is your ERP or accounting package, and the portal only displays it. Decide how fresh the figure must be and show a "last updated" time, since overnight sync is often acceptable if dealers know that's what it is. Finally, decide what counts: do unpaid invoices that are not yet due reduce available credit, and how do open orders count?
Credit-limit behaviour is a commercial decision disguised as a software setting. Blocking outright can lock out a twenty-year account at the worst moment, while warning only may make the limit meaningless. Many businesses begin with a hold-for-approval queue, then tighten it once they trust the data. Whoever runs credit control should write this rule, not the developer.
A dealer is not one user, and a portal is not only an order form
Dealer businesses have people. The owner wants statements and purchase history. A counter employee should be able to place orders but might need buying prices hidden, because the screen could be open in front of an end customer. A bookkeeper only wants invoices. A dealer with several branches might order locally but be billed centrally. On your side, a territory rep should see only their accounts, be able to order on behalf of a dealer, and leave a clear record of having done so.
Here is what separates a dealer portal from a wholesale web shop: the relationship continues after the sale. Depending on your products, the most valuable screens may not concern ordering at all. Equipment manufacturers may need warranty registration by serial number, return authorisations and spare-part lookups by model. Brands with co-op marketing may want a place for approved images, price sheets, product documents and promotion claims. If you run a training or certification programme, dealer staff status may affect what they are allowed to sell or service.
Don't put all that in release one. List it, rank it using your contact log, and ask your developer to make sure the data model doesn't rule it out later. A good first release handles the most repeated work well. If what you actually need is a catalogue with customer pricing and little else, read our guide to B2B ecommerce website development, since that is a different and often smaller project.
Manufacturers and distributors should also expect different priorities. A manufacturer's dealers often care most about lead times and production status, because orders go into a schedule and dates can move. Configurable products may need a guided selection tool that grows the project considerably. A distributor usually lives on availability, warehouse choice, large catalogues and frequent supplier price files, with slim margins that make any error in a discount rule expensive. If you are both, choose which flow leads the first release.
Connect to the ERP, or become a second ERP by accident
The most expensive mistake in this category is letting the portal quietly grow its own version of stock, price and balance. Give each piece of data one owner. Item master and stock normally stay in the ERP. Price rules may live in the ERP or in the portal, but in one place only. Orders are captured in the portal and written back to the ERP, where they become the official record.
Ask your current ERP vendor these questions before requesting quotes: Is there a documented API on your version? Does access need another licence or module? Is there a native dealer or B2B module you should try first? What happens to integrations when you upgrade? And what should happen when the ERP is unreachable: should orders queue, or should the portal stop? Writing an order back with proper error handling is a much bigger job than reading a price. If the concept is new to you, our explainer on what API integration is will prepare you for that conversation.
Four routes, and the first may be enough
Custom development is not the default answer. A disciplined shared sheet and an order form can serve a small network ordering rarely. A dealer module from your ERP vendor is a natural candidate since the data is already there, although the interface and flexibility may not satisfy every dealer. A B2B platform or ecommerce plugin is a strong choice when your rules are fairly standard. Custom building earns its cost when the rules don't fit and those rules are part of why dealers choose you.
Equally, there are times to wait. Hold off if the same product exists under two codes, if counted stock regularly differs from the system, if terms with dealers aren't written anywhere, or if nobody on your side can own decisions during the project. Software cannot fix any of those, and fixing them first makes every later option more valuable.
Why quotes vary so much, and how to compare them
Dealer portal quotes can differ widely because each firm fills your unanswered questions with its own assumptions. The cost depends less on the number of screens than on the number of rules and connections, which is why a meaningful price only emerges once scope is clear; we'd rather discuss yours in a free call than quote a figure that doesn't apply to you. These items move the budget most:
- Pricing logic: flat tier discounts are one job; rules combining dealer, product, region, currency and terms are quite another.
- Integration direction: reading data is simpler than writing orders back and recovering from failures.
- Catalogue quality: missing images, inconsistent units and duplicate codes need cleaning, and that is often excluded from quotes.
- Roles and approvals: each extra level multiplies what has to be tested.
- Languages and countries: translated catalogues, tax handling and local documents add ongoing work too.
- Native mobile apps: a good responsive site is enough for many dealers, while an app store app brings its own maintenance.
To compare fairly, give every vendor the same three sample dealers and the same five scenarios: reorder, over-limit order, partial shipment, return and promotional price. Ask for a written yes or no on each. Then look for costs that arrive after launch, such as hosting, backups, security patches, integration updates after ERP upgrades, training for newly signed dealers, and the hours your own staff will spend. Also confirm who owns the source code and documentation, because this system will sit between you and your partners for years.
Tax, privacy and competition rules vary by market
A portal usually doesn't issue tax documents itself. Orders flow to your ERP, which issues invoices, and the portal displays copies. That separation helps, because the requirements differ by jurisdiction and keep changing. A growing number of countries require structured e-invoices between businesses, and our e-invoicing guide for SMBs explains the general concepts. Cross-border sales can raise further questions: VAT number checks and reverse charge inside the EU, resale or exemption certificates for US sales tax, and more. Confirm the details with your accountant in each market.
Portal users are individuals, so names, work email addresses, phone numbers and activity logs are likely personal data under the GDPR, UK GDPR or similar laws. Think about where data is hosted, who can access it, how accounts of departed staff are closed, and whether a processing agreement is needed with your developer. If your provider works from another country, as Welda does from Istanbul, international transfers should be reviewed with your privacy adviser as part of the project, rather than after it.
Competition law rarely appears in software proposals, but it should be considered. Using a portal to enforce dealers' resale prices or to block sales outside a territory may look like sensible channel management and yet be legally sensitive in several markets. A suggested retail price field is a very different thing from a mandatory one. Take advice before encoding such rules.
Dealers will not migrate because you sent an email
Dealers have often bought from the same person for years, and that relationship is an asset. Plan the rollout around it. Your phone line stays open: unusual orders, delivery problems and new product conversations still need a human. The goal is to take repetitive work off the phone, not to end the phone.
Choose five to ten pilot dealers, including your most complicated agreement and your least digital owner. Sit with them on the first login and have them check opening prices and balances. Fix any discrepancy before the wider launch, since one wrong balance spreads quickly across a dealer network.
Your reps deserve attention here. If they believe self-service orders threaten their commission, they will quietly steer dealers away from the portal. A common fix is to credit the territory regardless of order channel, while shifting the rep's time from taking orders to opening accounts and collecting overdue balances. Operational incentives work better than discounts: a later order cut-off or priority picking for portal orders won't erode your margin. Report rep-entered and dealer-entered orders separately so you can see true adoption, and give reps the list of dealers who haven't logged in.
Questions that expose a weak proposal
Every demo looks polished, so put your hard cases on the table instead of watching a tour of screens. Note the answers from each vendor side by side.
Come prepared as well: your contact log, three worked pricing examples, your ERP version and access details, a permissions chart, and the name of the person who will make decisions. A brief like that earns a far more accurate proposal than "we need a dealer system".
Where Welda can help, and where it can't
If you're planning dealer portal development, Welda's custom software service covers the building blocks: tailored web apps and portals, REST and GraphQL integrations with accounting, payment and ecommerce systems, approval and notification automations, WhatsApp Business API order and notification flows, and live dashboards. Our process starts with discovery. The data model, integration points and interface flows come to you for approval before code is written, and development ships in releases. You own the source code and documentation, and maintenance is arranged under agreed service levels after launch.
The limits are just as important. We don't sell a ready-made dealer portal. Our own products, Welda Stock for retail inventory and sales and Welda CRM for clinic and patient management, are not substitutes for one. Running them in production teaches us what software demands day to day, but it doesn't mean we have a ready connector for your ERP; we can only say that after reviewing your system. We work from Istanbul, so if you need on-site workshops in your country or local-language dealer support, raise that early. And if your log shows a shared sheet or your ERP's module is enough, we'll tell you.
When you're ready, book a free call through our custom dealer portal development page. Bring your contact log and three sample dealers, and scope and price will become clear much faster.
Frequently asked questions
What is the difference between a dealer portal and a B2B web shop?
They overlap. A B2B shop centres on catalogue and ordering. A dealer portal usually adds statements, shipment tracking, rep roles, multi-level dealer structures and, for some sectors, warranty, returns and marketing resources. Compare the listed functions rather than the label.
How many dealers do we need to justify a portal?
Dealer count alone misleads. A few dealers ordering daily can justify one, while many dealers ordering once a month may be fine with a form. Look at contact volume, how often orders repeat and what errors cost you.
Will a dealer portal replace our ERP?
Normally not. The ERP remains the record for accounting and stock, and the portal is what dealers see. How they connect depends on your version and the access it offers, so verify this before development starts.
What should a first release include?
Whatever your log shows repeating most. For many firms that's quick reorder, correct net prices and order status. Promotions engines, native apps and advanced reports can follow once dealers are using the basics.
What if some dealers refuse to use it?
Some may hold out for a long time, so keep the phone line and let reps enter orders for them. Base your investment case on a realistic share of dealers switching, not all of them.
How do we find out what it would cost?
Any number given before pricing rules, integration direction, roles and maintenance are known won't be dependable. Once sample dealers and scenarios are on the table, a tailored quote can be discussed in a free call.