B2B Ecommerce Portal Development: Why Trade Accounts Still Order By Phone | Digital Heroes

Why trade customers still call, and what that costs you per order

A branch manager at a distributor picks up the phone at 7:40am. The caller is a plumbing contractor standing on a job site who wants forty of a fitting, in the size he calls by the old part number, at the price he negotiated last March, delivered to a site address that is not his billing address, before eleven. The branch manager knows the answer to all four of those questions and nobody else in the building does. That call takes six minutes and it happens two hundred times a day across the branch network.

The usual attempt at fixing this is a webstore. The webstore gets built on a consumer commerce platform, someone exports a price list from the ERP into it overnight, and within six weeks the sales team has told every account not to use it because the prices are wrong. That is not a failure of the team or the platform. It is a failure of the data model. A trade price is not a number sitting on a product. It is the output of a calculation involving the customer, the contract, the quantity break, the branch, the currency, the promotion in effect this week and sometimes a rebate agreement, and that calculation lives in the ERP and only in the ERP.

The tools in this space know this. Sana Commerce is built specifically around live ERP integration and is genuinely good if you run a mainstream ERP it supports. Adobe Commerce B2B and OroCommerce both model company accounts, price lists and approval workflows properly. BigCommerce B2B Edition covers a real subset for smaller operations. The question is not whether they are good products. The question is whether your pricing and ordering rules fit inside the shape those products expect, and for a lot of distributors and manufacturers they do not.

Problem 1: your price is a calculation, not a field

Ask a commercial director to explain how a specific customer's price for a specific item is derived and you will get five minutes of nested conditions. There is a base list. There is a customer contract that overrides some items by percentage off list and others by fixed price. There are quantity breaks that may be per line or per order or per rolling annual volume. There is a branch adjustment. There may be a customer specific part number that maps to your SKU but not one to one, because they buy a kit you assemble. There is a promotion that beats the contract this month but must not beat it next month. There is a currency and an incoterm.

What a custom build does: never store the price. Call the ERP pricing engine at the point of display and again at the point of order, with the full context of customer, ship to, item, quantity and cart. Cache aggressively at the session level for performance, never at the catalogue level for correctness, and show the customer the same number their rep would quote. If your ERP pricing call is too slow to do this at catalogue browse scale, and in older systems it often is, the answer is a read replica of the pricing inputs plus a reimplementation of the rules with an automated nightly reconciliation that compares your engine against the ERP on a sample of every customer and item combination. That reconciliation job is the unglamorous piece that makes the whole thing trustworthy.

Problem 2: the buyer is an organisation, and consumer platforms model a person

A trade account is a hierarchy. There is a parent group, member companies, branches or sites, and users with different rights at each level. A site supervisor can raise a requisition but not approve it. A purchasing manager approves up to a value and above that it goes to finance. Orders must carry a purchase order number or the customer's accounts payable will reject the invoice. Some users can see pricing and others must not. A ship to address list is controlled by the customer, not entered freely, because a rogue delivery address is a fraud vector.

Adobe Commerce B2B and OroCommerce both handle company structures and approval flows, and they handle them well enough for a lot of businesses. Where they strain is when the approval rules are not a value threshold but something specific to your trade: approval by product category because certain items are controlled, approval by project code because the customer bills by job, or a credit hold that must block ordering for one member company and not its siblings.

What a custom build does: model the customer organisation as its own tree, mirror it from the ERP so it does not drift, and attach permissions, budgets, approval rules and credit position to nodes rather than to users. Credit is the part people forget. If the account is on hold in the ERP, the portal must refuse the order at submit with a message the customer can act on, and it must know whether the hold applies to the group or to one branch. Nothing destroys trade confidence faster than a portal that accepts an order finance will cancel.

Problem 3: your largest accounts will not use your portal at all

The uncomfortable truth about B2B ecommerce is that the accounts you most want to lock in are the ones that will never log into your site. They buy through Ariba, Coupa or Jaggaer, and their mandate is that you appear inside their procurement system. That means punchout, using cXML or OCI, where their buyer clicks through into a session on your platform, builds a cart, and returns the cart into their own requisition and approval flow. Then the order arrives as an EDI 850, you acknowledge with an 855, ship with an 856 and invoice with an 810.

What a custom build does: treat punchout and EDI as first class order intake paths into the same order object as the web portal, not as a bolt on. The commercial case is simple. A single national account that mandates punchout is often worth more than every self service customer combined, and if you cannot support it you are not on the vendor list. Budget for it explicitly, per partner, and do not let anyone tell you it is included.

Problem 4: availability and the delivery promise decide whether they come back

A contractor does not want to know that you have stock. He wants to know whether he can collect it from the branch two miles away in an hour, or whether it ships tonight from the regional warehouse for tomorrow morning, or whether it is a four week special order he needs to know about now rather than on Thursday. That is available to promise across a branch network with transfer times, carrier cut offs per location, and item level handling rules for things that ship freight rather than parcel.

What a custom build does: a promise engine that answers the question the buyer actually asked. Show collect from named branch with a time, delivery with a date, and backorder with a realistic estimate drawn from the open purchase order, not a guess. Let the customer choose whether to split or hold. Then, and this is the part that pays, record the promise and compare it against what actually happened, so you find out which branches and which carriers are quietly damaging your reputation.

Problem 5: the rep thinks the portal is a threat, so the portal fails

Adoption stalls when reps believe the portal competes with their own number, so what a custom build does is give the rep the console. Let them place orders on behalf of a customer inside the customer's own context, so they see the same prices and the same availability. Let them build a quote in the portal that converts to an order with one customer click. Show them their accounts' portal activity, including carts abandoned above a value threshold, which is a better call list than anything their CRM (Customer Relationship Management) gives them. Then make sure the commission plan credits portal orders from their accounts to them, because if it does not, no interface design will save the project. Reorder from history and saved lists per job site are the two features trade buyers actually use, and they are the features that increase basket size, so build them early and let the rep take the credit.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, the honest shape is this. A first release with live ERP pricing, the account hierarchy with credit and approval rules, catalogue and search, reorder from history and saved lists runs 70,000 to 150,000 dollars over 14 to 20 weeks. A full portal adding punchout for named partners, EDI order and invoice flows, multi branch availability and delivery promise, quote to order, rep console and customer specific catalogues runs 200,000 to 500,000 dollars phased over 8 to 14 months.

What drives the number up in trade commerce specifically: the age and openness of your ERP, because a modern API surface and a green screen system with a nightly extract are different projects entirely. The number of punchout and EDI trading partners, priced per partner. Product data quality, which is usually the hidden monster, because a trade catalogue with 60,000 SKUs and no attributes or images cannot be browsed and no amount of search technology fixes missing data. Multi currency and multi country tax. And customer specific part numbers, which sound trivial and are not, because the mapping is many to many and lives in spreadsheets your reps maintain.

Build versus buy, and when buying is clearly right

Buy if your trade pricing is a small number of published tiers or a simple percentage off list, your accounts are single site, and you have no punchout mandates. Sana Commerce in particular is designed around live ERP pricing and if you run an ERP it natively supports, it removes most of problem one for a subscription instead of a build. BigCommerce B2B Edition is a fair answer for a smaller operation that wants to be trading this quarter. OroCommerce is worth a serious look if you want an open platform and have the internal capability to extend it.

Build when two or more of these are true. First, your pricing engine cannot be expressed as a price list without being wrong. Second, your customers' organisational and approval structures are specific enough that configuring them in a platform means fighting it. Third, you have punchout or EDI mandates from accounts that matter, and the platform's connector does not cover the trading partner in question. Fourth, availability across branches with a real delivery promise is a competitive weapon in your category. Fifth, you have tried a platform already and abandoned it, which is more common than vendors admit and usually means your rules genuinely did not fit.

How to choose a developer for a B2B ecommerce portal

Ask them how they will get a price. If the answer is a nightly sync, ask what happens when a break condition depends on cart contents, and watch. The developers who have done this will start talking about ERP call latency, session caching and a reconciliation job before you finish the question.

Ask what they have integrated by name. Your ERP, specifically, and specifically which version and which interface. Business Central, NetSuite, Epicor, Infor and an older AS400 estate are five different projects, and a firm that has only ever integrated one of them will learn on your budget.

Ask who owns the code and get it in writing before kickoff, including the repository, the cloud accounts and the right to hire anyone else to continue the work. Your order intake channel is not something to rent from a supplier. At Digital Heroes the client owns everything from the first commit.