Posted in Digital Commerce
June 8, 2026
Portal Scope
What does a manufacturer's B2B customer portal need to include
A B2B customer portal for a manufacturer carries eight workflows that decide whether dealers and direct buyers stay on the portal or route around it. Reorder against history, quote-to-order, contract-aware pricing, account hierarchy with approvals, stock visibility by location, order status and tracking, AR self-service, and CSR order-on-behalf. Each is a commitment to the buyer the portal has to keep.
Key takeaway
A manufacturer portal needs eight working workflows, not a long feature list. If any of them is missing, buyers route around the portal and back to the rep.
The eight workflows that decide adoption
Manufacturer portal projects come with long feature lists. Most of them are decorations. The eight workflows below are the ones buyers actually use, ranked by frequency in the rep channel they're meant to replace. Build any seven and miss one, and buyers will route around the portal for that one task and stay there for the others.
The thing they share is that none of them are storefront features. They are interfaces over the operational truth in the ERP. Reorder reads from order history. Stock visibility reads from warehouse balances. Approvals read from the account structure. The portal's role is to make the truth findable and the work fast. That posture, the portal as a faster path to existing operational truth, is what Acro Commerce treats as the operating thesis for B2B portals.
Reorder against history
The highest-frequency interaction in any manufacturer portal is the reorder. A dealer who buys the same 12 SKUs every month wants to see those 12 SKUs, see what they paid last time, see what's in stock now, and submit. Saved carts, requisition lists, and scheduled reorders are the three patterns that cover it. Pillar 4's saved-carts comparison piece breaks down when to use each.
What buyers don't want is to rebuild the list every visit. The portal has to read history from the ERP and surface it as a working starting point. If the buyer's last order was three months ago, the portal shows it. If they have an open requisition list shared with their team, the portal shows it. If they have a scheduled reorder pattern, the portal shows the next instance. Everything else is friction.
Quote-to-order with CPQ for configured products
Most manufacturer portals need a quote path alongside the cart. Some buyers can't transact without finance sign-off. Some products are configured and priced by the configuration. Some accounts negotiate on every order. The portal has to support buyer-initiated quotes (build a cart, save as quote, route for approval), rep-initiated quotes (rep prepares a quote, sends to buyer to accept), and configure-price-quote logic for the products that need it.
Where teams trip up is in the quote-to-order handoff. The buyer accepts the quote, and the portal has to convert it to an order without re-keying. The conversion rule should read from the same quote engine that wrote the original price, so the order matches the quote line-for-line and the buyer never sees a price they didn't agree to. Pillar 4 has a dedicated piece on the workflow at quote-to-order workflows buyers actually use.
Contract-aware pricing
A buyer who signs a contract expects the contract price to apply, automatically, every time they sign in. The portal's job is to recognise the buyer, identify the contract, apply the pricing terms (line-level overrides, tiered volumes, effective dates), and show the contract price as the price the buyer pays. The calculation belongs in the ERP. The portal renders it.
When pricing is computed in the portal and the ERP separately, the two drift, and the buyer ends up disputing prices on invoices. The pattern that holds up is to call the ERP at cart time with the buyer's account and the line items, take back the pricing decision with the contract reference, and render it to the buyer with a clear indication that contract pricing has been applied. Pillar 4's contract pricing piece details the integration shape.
Account hierarchy and approvals
Most manufacturer buyers don't buy as individuals. They buy as a role inside an account, often with a parent-child relationship to a corporate account, with multiple ship-tos, and with approval thresholds for orders above a value. The portal has to model the hierarchy faithfully so the right ship-tos show, the right approvers get notified, and the right tax and freight rules apply by destination.
The cleanest pattern is to anchor the portal's account view on the same hierarchy the ERP encodes. If the buyer's parent account approves orders above $5,000, the portal surfaces that requirement before checkout, routes the approval through the ERP's workflow, and shows status to both parties. The same hierarchy is what's described from the ERP side in Pillar 1's approval chains piece.
Stock visibility, status, AR, and CSR order-on-behalf
The remaining four workflows are operational. Stock visibility means available-to-promise by location with partial shipment options and realistic ship dates, not a green dot the warehouse can't honour. Order status means tracking, exception flags, and delivery dates pulled from the ERP so the portal and the customer service desk tell the same story.
AR self-service means open invoices, payment history, dispute paths, and statement downloads, sourced from finance's truth. It's the workflow that quietly takes the most call volume off the AR team's desk once it lands. CSR order-on-behalf is the rep view. It lets customer service place an order for a dealer with full audit, so phone orders join the same record the portal writes. Without it, the phone channel runs in parallel and reporting fragments.
Where the four operational workflows succeed is when they're treated as integrations with the ERP, not features in the portal. The ERP carries truth. The portal carries the interface. The customer service team and the buyer see the same record. The work is the integration, and it's the work ERP integration and expansion is built around.
What to leave out of v1
Manufacturer portal v1s fail when they try to ship all eight workflows on day one. The honest sequencing is to ship the rep-facing CSR view, the reorder flow, and the order-status flow first, get adoption, then add quote-to-order, contract pricing, and approvals once the rep team has confidence in the portal. The harder configured-product and CPQ work follows in a second wave.
Things that don't belong in v1 (and often don't belong in the portal at all): a public marketing catalogue (that's the website's job), a content management system for blog posts, a loyalty program, and a notification engine that competes with the ERP's own alerts. Each of them is a project that pulls focus from the eight workflows that decide whether buyers come back. Pillar 4's piece on the pre-built versus custom decision walks through the scoping conversation in detail.
Related Articles
Manufacturer digital self-service: the complete guide to B2B buyer portals
- What B2B buyers actually want online: the manufacturer self-service report
- Pre-built B2B portal vs custom portal: how manufacturers should choose
- How to roll out customer self-service without disrupting sales reps
- What does a manufacturer's B2B customer portal need to include
- Acumatica spotlight: a mid-market manufacturer dealer portal built on Acumatica
- Acumatica spotlight: distributor self-service at scale
Frequently Asked Questions
What does a manufacturer's B2B customer portal need to include?
Eight workflows: reorder against history, quote-to-order with configure-price-quote support, contract-aware pricing, account hierarchy with approval thresholds, stock visibility by warehouse location, order status and tracking, AR self-service for invoices and payments, and CSR order-on-behalf. Each is built as an interface over the ERP's operational truth, not as a standalone feature in the portal.
What's the minimum viable scope for a manufacturer portal v1?
Three workflows usually carry a v1: CSR order-on-behalf (so the rep team gets value first), reorder against history (the highest-frequency buyer task), and order status (the most common call-deflection win). Add quote-to-order, contract pricing, and approvals in waves two and three once the rep team trusts the portal.
Do we need configure-price-quote in v1?
Only if the configured product is the highest-frequency order shape. For most manufacturers, CPQ is a wave-two or wave-three feature, because it's the workflow that pulls the most ERP and product-data work behind it. Pillar 4 has a dedicated piece on designing the quote-to-order workflow so it converts cleanly.
Should the portal have its own catalogue or read from the PIM?
Read from the PIM. The portal is a thin interface over the merchandising truth, not a copy of it. If the catalogue lives in two places, descriptions drift, attributes drift, and the buyer sees mismatched data between the marketing site and the portal. One source per domain is the rule that survives staff turnover.
What's the difference between a B2B portal and a B2B ecommerce site?
An ecommerce site is built around acquisition: anonymous browsing, marketing-driven discovery, a public catalogue. A portal is built around the post-login workflows of identified buyers: contract pricing, accounts, approvals, AR, and rep collaboration. Many manufacturers run both, with the public site as the lead-generation surface and the portal as the daily-use tool.
How do we know which workflows the rep channel uses most?
Ask the customer service team for the call categorization for one month. The top five categories are almost always: order status, stock check, reorder, invoice question, and quote request. Those five become the v1 scope, and the call deflection is the launch metric.
Where does the AR self-service workflow get its data?
From the finance system of record, which is usually the ERP. The portal calls the ERP for open invoices, payment history, and statement detail, and displays them to the authenticated buyer. Anything routed through a separate AR tool drifts from the source of truth within weeks and ends up generating disputes.
Next Step
Get the foundation right before you build.
For readers scoping a platform decision or wanting a full architecture recommendation.