Dealer portals your channel will actually use.

Manufacturer ecommerce is a trade ordering system rather than a shop. Dealers, distributors, and specifiers log in, see the pricing their contract entitles them to, check real stock, configure or specify a product, and place or repeat an order without emailing a rep. The storefront reads pricing and availability from the ERP that already runs the plant, so what a dealer sees is what your finance and inventory systems agree on.

A B2B website sells to other businesses rather than consumers, which changes the mechanics rather than just the audience. Buyers log in to see pricing their account is entitled to, order against agreed terms rather than a card, reorder from history, and often route the order through an approval step. Public pricing and single-click checkout, the defaults of a consumer store, are usually the wrong answer.

Four things drive nearly all of the variance: catalogue size, whether products are configurable, the state of your product data, and how deep the ERP integration goes. A dealer portal on a clean catalogue with a simple ERP sync is a very different project from a configurable-product build with EDI and punchout. We scope it on a short call and send a fixed proposal before any work starts.

The field splits three ways. Platform vendors such as NetSuite SuiteCommerce and BigCommerce sell the software. Specialist B2B platforms including OroCommerce, Virto Commerce, and Coredna target distribution specifically. Agencies such as OnTap Group and HeadQ, and ourselves, build on top of Shopify Plus, Adobe Commerce, or BigCommerce. The right answer depends on whether your constraint is the platform or the implementation.

Selling through distributors does not remove the ordering problem, it moves it. Distributors still place orders, check stock, chase lead times, and request quotes, and most of that still arrives by email and phone. A dealer portal absorbs that traffic, cuts re-keying errors, and gives you first-party visibility of who orders what. It does not disintermediate your channel unless you choose to sell direct, and most of our manufacturer builds deliberately do not.

A manufacturer typically sells a deep but narrow catalog of its own products to a controlled dealer network, so the hard parts are configuration, spec data, territory rules, and warranty. A distributor resells a broad catalog from many suppliers, so the hard parts are catalog volume, parametric search, supplier data quality, and multi-warehouse inventory accuracy. We build both, but they are different jobs and the platform choice can differ.

Only if you design it to. The common pattern is a dealer-only portal with no public pricing, where a consumer enquiry is routed to the nearest authorised dealer by postcode or territory. Some manufacturers add a direct channel later at list price so dealers are never undercut. We build the rules you want rather than assuming a direct-to-consumer model.

Most run from a few weeks to a few months. The variables that move the timeline are catalog complexity, whether products are configurable, how clean the product data is, and how much ERP integration is in scope. Product data quality is the single most common cause of delay, so we assess it during scoping rather than discovering it mid-build.

Yes. A dealer portal gives each authorised dealer its own login, contract pricing, assigned assortment, order and invoice history, one-click reordering, quote requests, and net terms. Head office accounts can sit above branch accounts so a group sees its own branches while a single branch sees only itself.

Yes. We implement territory restrictions so a dealer only sees products and pricing it is authorised to sell in its region, plus dealer-locator routing that sends public enquiries to the right partner. Where you run tiered dealer programmes, gold and silver tiers can carry different pricing, assortments, and payment terms.

Yes. Bulk order pads let a buyer paste or upload a list of part numbers and quantities and go straight to checkout. Saved lists, reorder from previous order, and CSV upload cover the repeat ordering that makes up most distributor volume. Case, pallet, and box units of measure are enforced at the cart so you do not receive orders in quantities you cannot ship.

Yes. Large distributors and retail buyers frequently will not use a portal at all, and mandating one loses the order. We implement EDI 850 purchase orders, 855 acknowledgements, 856 advance ship notices, and 810 invoices so those accounts trade the way they already do, while their orders land in the same pipeline as portal orders.

Punchout handles that. With cXML or OCI punchout, a buyer inside Coupa, Ariba, Jaggaer, or Oracle procurement clicks through to your catalog, builds a basket at their contracted pricing, and returns an approved requisition to their own system. For enterprise and public-sector buyers this is often the only route their policy allows.

Yes. We build product configurators that enforce real engineering rules: valid option combinations, dependent options, dimensional inputs with tolerances, and derived part numbers or SKUs. The output can be a priced order, or a quote request where the configuration needs engineering sign-off before a price is committed.

Yes, and for technical catalogs this matters more than search. Parametric or faceted search lets a buyer filter by the attributes that actually identify a part: material, dimension, voltage, thread, pressure rating, finish. We also build compatibility and fitment finders where a part must match a machine, model, or year.

Yes. Datasheets, installation guides, CAD and BIM files, safety data sheets, certificates of conformity, and warranty documents attach to the product record and stay downloadable from the product page and the order history. For regulated categories we version them so a buyer can retrieve the document that applied at the time of their order.

Yes, and it is the normal starting point. Most manufacturer catalogs live across an ERP part master, spreadsheets, and PDF price lists. We assess the data during scoping and either clean and structure it into the platform or stand up a PIM such as Akeneo, Salsify, or Plytix as the source of truth. Being honest about the state of the data early is what keeps the build on schedule.

Yes. Inventory syncs per location, so a dealer sees availability at the warehouse that will actually serve it rather than a national total that is misleading. Where you run make-to-order or long lead times, we show expected lead time instead of a stock figure, which is more useful to a buyer than a zero.

NetSuite, SAP S/4HANA and Business One, Microsoft Dynamics 365 Business Central, Epicor Kinetic and Prophet 21, Infor CloudSuite Industrial, Sage X3 and Intacct, Acumatica, IFS, QuickBooks Enterprise, and Odoo. Epicor Prophet 21 and Infor come up most often in distribution specifically. Where no direct connector exists, we build middleware against the ERP API or file interface.

The part master and product attributes, customer and dealer account hierarchies, contract and tiered price lists, credit limits and payment terms, inventory by location, orders, invoices, and shipment tracking. Pricing and stock are read from the ERP rather than copied into the storefront, which is what stops a dealer being quoted a number your finance system disagrees with.

Yes. Prophet 21 is common in distribution and exposes the objects a portal needs: items, customers, contract pricing, availability, orders, and invoices. We scope which objects sync, in which direction, and at what frequency before writing code, because near-real-time inventory and nightly price list updates are very different builds with very different costs.

At checkout the portal reads the account credit limit and open balance from the ERP. Within limit and current, the dealer checks out on account with net terms. Over limit or past due, the order is either held for approval or restricted to card payment, whichever rule you prefer. Nothing relies on a manually maintained copy of the balance.

Yes. Where quotes need engineering or margin approval, we either build the quote workflow into the portal or integrate an existing CPQ so the configured quote, approval chain, and resulting order stay connected. The important part is that an accepted quote becomes an order without anyone re-keying it.

It depends on catalog size and how much configuration you need. Shopify Plus suits a manageable catalog with clean B2B rules and is the fastest to launch. Adobe Commerce suits very large catalogs and deep native B2B. BigCommerce sits well in the mid-market. Commerceflo fits when a unified engine across channels is the goal. We compare them against your part count, configuration complexity, and ERP on a scoping call.

It depends on catalog size, whether products are configurable, the state of your product data, and the depth of ERP integration. Those four things drive most of the variance. We scope on a short call and send a fixed proposal before any work starts, so you are not signing up to an hourly estimate that moves.

Yes. We handle migration of products, dealer accounts, contract pricing, and order history, with 301 redirects and a cutover plan that protects rankings and uptime. Contract pricing and account hierarchies are the parts most often lost in a bad migration, so we reconcile them against the ERP before and after cutover.

Yes. You own the code, the data, and the platform accounts. We are not renting you a tool you lose access to if you stop working with us, and there is no proprietary layer you cannot maintain without us.

Yes, most of the brands we work with are US-based, across manufacturing, distribution, industrial, and MRO, with a decade-plus of commerce builds behind us.