Here is a scene that repeats across distribution and manufacturing: the company builds a customer portal, and separately buys a sales-rep ordering app. The portal shows the customer one price. The rep’s app shows another, because the two systems resolve pricing differently. Now the business has two order-entry systems that disagree, and the rep – who was supposed to be freed up – spends the day reconciling them.
It does not have to work this way. Your reps should not need a separate app; they should use the same B2B portal your customers use, ordering on behalf of their accounts, at those accounts’ real pricing, into the same ERP flow. This guide explains how order-on-behalf-of works and why building it into the portal beats bolting on a rep tool.
The two-system problem
When rep ordering lives in a different system than the customer portal, everything that has to be consistent becomes a synchronization project:
- Pricing disagrees. The portal resolves the customer’s contract and multiplier pricing one way; the rep app resolves it another (or not at all). The customer notices when the rep’s quote and the web price differ.
- Inventory disagrees. Two systems reading stock on different cycles show different availability.
- Orders land differently. Rep-app orders and portal orders take different paths into the ERP, so order history is fragmented and reporting is unreliable.
- Nobody trusts either. The moment a rep and a customer see different numbers, both start calling to confirm – the exact phone traffic the portal was meant to remove.
Order-on-behalf-of, done inside the portal
Order-on-behalf-of (sometimes OOBO) is the clean alternative. A rep logs in, selects one of their assigned customers, and enters that customer’s context: the rep now sees the portal exactly as that customer would – their catalog, their contract and multiplier pricing, their part numbers, their order history, their credit status. The rep places the order, and it flows into the ERP as that customer’s order, indistinguishable from one the customer placed themselves.
Because it is the same portal, there is one pricing engine, one inventory feed, one order path, one order history. The rep becomes a power user of the customer’s own tool rather than the operator of a parallel system.
Guardrails: who can order for whom, and how much
Reps acting as customers need controls, and they map naturally onto the portal’s role model:
- Account scoping. A rep can only enter order-on-behalf mode for accounts assigned to them – mirroring the ERP’s rep-to-customer assignment.
- Discount and price authority. Whether a rep can override a resolved price, and within what bounds, before it needs approval.
- Order limits and approvals. Value thresholds above which a manager signs off, and flags for non-standard terms.
- Audit trail. Every rep-placed order records who placed it for whom, so the order-on-behalf action is fully traceable.
Field sales versus inside sales
The pattern flexes to how your team actually sells:
- Inside sales / telesales – reps take phone orders and enter them in the portal as the customer, so a “phoned-in” order still becomes a clean, correctly priced portal order in the ERP.
- Field sales – reps place orders on a laptop or tablet from the customer’s site. Where connectivity is unreliable, a thin offline layer can queue orders, but it should sync to the same portal backbone, never to a separate pricing system.
- Counter and will-call – counter staff use the same order-on-behalf flow, so in-person, phone, and web orders all resolve pricing identically.
Building it on Magento and Shopware
Both platforms support the account model order-on-behalf needs. Adobe Commerce’s company-account structure and Shopware’s B2B components both let a user act within a company context; the order-on-behalf capability itself is typically custom, built on that foundation and wired to the ERP so the rep sees the customer’s real pricing and the order follows the same integration path as any other. The design principle is the one that runs through every piece of a serious B2B build: one source of truth. Pricing, inventory, and orders resolve the same way no matter who places the order – customer, rep, or counter.
Who we are
Web Solutions NYC builds B2B portals where reps and customers work from the same system – anonymized examples include distributors whose field and inside reps place orders at customer-specific pricing straight into the ERP. We are a Shopware Platinum Partner and official Adobe Commerce partner, integrating rep ordering with NetSuite, SAP, Dynamics, Acumatica, Sage, and Epicor P21.
Frequently asked questions
Yes. Order-on-behalf-of (OOBO) lets a rep log into the portal as one of their assigned customers, see exactly what that customer sees – their contract pricing, their catalog, their order history – and place an order that flows into the same ERP process as a self-served web order. It turns the rep’s ordering into an extension of the portal rather than a separate phone-and-rekey process.
They should, and it is the whole point. When a rep enters order-on-behalf mode for a customer, the portal resolves that customer’s price levels, multipliers, and contracts, so the rep quotes and orders at the customer’s real price. If the rep sees generic list pricing, the feature is only half built and reps will keep their own spreadsheets.
Usually not, and often it is a liability. A standalone rep app that does not share the portal’s pricing and ERP integration creates two systems that disagree – the rep quotes one price, the portal shows another. Building order-on-behalf into the same portal keeps one source of truth for pricing, inventory, and orders. Separate apps make sense mainly for offline field scenarios, and even then they should sync to the same backbone.
Through account assignment and role permissions: a rep is scoped to their book of business, with optional limits on order value, discount authority, or which actions need approval. The controls live in the portal’s user/role model and mirror how the ERP assigns customers to reps, so a rep can only act for their own accounts.
Running a portal and a separate rep app that disagree? Consolidating them onto one pricing-and-ERP backbone is usually a fast, high-relief win for both your reps and your customers. Let’s talk.