Mobile ordering for NZ field sales reps: how a B2B portal needs to work on-site

A sales rep visiting a customer on-site is not using the B2B portal the same way a buyer at an accounts desk in the office is. The rep is working from a phone or tablet, standing in a cool store or cafe kitchen, often with unreliable connectivity, trying to capture an order in under five minutes before the next stop. A portal designed around desktop self-service handles the accounts-desk scenario well. It often fails the on-site rep scenario — and designing for both from the start is a different brief than designing for one and bolting mobile on later.

This guide covers the specific design requirements the field rep scenario adds to a wholesale B2B ordering portal: rep-on-behalf-of ordering, offline mode, quick order from history, barcode scanning, and delivery cut-off visibility on mobile. It also covers four failure modes that recur when the rep workflow is under-specified at the start of the project.

The rep scenario is structurally different from desktop self-service

Two things make the rep-on-site scenario different enough to require explicit design attention.

First, the rep is ordering for the customer, not as the customer. The order should appear in the customer's account, priced at the customer's rates, subject to the customer's credit limit, and visible in the customer's order history. But the order should also record who placed it — the rep's identity, not the customer's — so the distributor can distinguish self-service orders from rep-assisted ones. That distinction matters for understanding which accounts have genuinely adopted self-service and which still depend on rep visits to order.

Second, speed matters more than browse. A desktop customer might spend twenty minutes moving through a catalogue and building a new order from scratch. A rep on-site with a customer is trying to capture the current week's order — which is usually a known pattern with variations — in a few minutes, confirm the delivery date, and move to the next account. The interaction model is fundamentally different: the rep needs to start from what the customer typically orders and adjust from there, not navigate a full catalogue from zero.

Rep-on-behalf-of ordering: how it should work

Rep-on-behalf-of ordering means the rep uses their own login credentials, then selects the customer account they are currently visiting. From that point, the portal operates exactly as it would if the customer had logged in: customer pricing, customer credit limit, customer catalogue visibility, customer delivery schedule. When the order is submitted, it is recorded against the customer's account and triggers the same ERP integration as a self-service order.

What it does not mean: the rep logging in as the customer using shared credentials. Shared credentials break the audit trail — every order appears to have been placed by the same account with no record of which rep was involved. They also break permission controls: a rep with access to multiple customer accounts cannot be managed separately from the customers themselves. And they make it impossible to measure self-service adoption over time, since you cannot tell which orders came from the customer and which were rep-placed.

The permission model behind this — separate rep logins, customer account selection, role-based access scoped to assigned accounts — is covered in detail in the B2B portal user roles and permissions post . The short version: the portal needs to distinguish between the trading account (the ERP debtor record) and the individual users who can act on it, including internal reps who act across multiple accounts.

Offline mode: who needs it, and what it actually means

Most NZ wholesale distributors have reps who cover regional routes alongside metro accounts. A rep calling on customers in rural Waikato, the Hawke's Bay, Marlborough, or Southland is regularly in areas with unreliable or absent 4G and 5G. Visiting a customer inside a cold store, a large warehouse, or a food processing facility often means losing signal even in urban areas.

A standard web portal that requires connectivity does not work in those environments — not "works slowly," but does not work at all. Page loads fail, order submissions time out, and the rep defaults to phoning in an order or writing it down. The portal doesn't save time; it adds friction.

Offline mode that genuinely works means the portal loads and functions without connectivity, and queues submitted orders for sync when the connection returns. There is a meaningful difference between offline-first — designed from the ground up to work offline, typically as a native app or a Progressive Web App with full local data caching — and offline-lite — a web portal that has a cached shell but cannot actually submit or retrieve data without connectivity. Offline-lite works fine in metro areas and looks like it might cover regional reps but fails when tested in the field.

Before specifying offline mode, map your rep routes. If all routes cover accounts with reliable urban connectivity, a mobile-responsive web portal is sufficient. If a material portion of routes include rural stops, cold stores, or large facilities, offline-first architecture is a basic operational requirement — not a feature to add later.

Quick-order from history

Field reps know what their accounts typically order. The on-site visit is rarely a product discovery exercise — it is an opportunity to capture the week's order, which is usually last week's order with adjustments: a seasonal volume increase, a new SKU to introduce, a line that sold out and needs to be skipped. A portal that forces the rep to browse a full catalogue and add items from zero is significantly slower than one that starts from the customer's last order.

Quick-order from history lets the rep select the customer, pull up the previous order or a standing order template, adjust quantities and lines, and submit. The portal is augmenting what the rep already knows about the account rather than replacing it with a browse interface that adds no value for this use case.

This requires ERP order history as part of the integration design — not just orders placed through the portal, but the customer's full order history from the ERP including phone and email orders. Customers with no prior portal history still have ERP history that should be accessible to the rep. Quick-order from history is a standard requirement for rep-facing mobile portal design; it is consistently under-specified at the scoping stage because it is assumed to be a minor UI feature when it is actually an integration requirement.

Barcode scanning

A mobile device's camera can serve as a barcode scanner for adding items to an order by scanning product barcodes, which is useful for reps working in a customer's stockroom during a stocktake-and-order visit. Camera-based scanning on a modern smartphone is accurate enough for this workflow without requiring dedicated hardware.

Barcode scanning is an option, not the primary input method. For the common quick-order scenario — adjusting a known order from history — scanning is slower than starting from the previous order list. It becomes useful when a rep is physically checking stock levels and ordering against what they can see on the shelf. Design it as an additional entry method, not the default.

Delivery cut-off visibility on mobile

Orders placed by reps on-site are subject to the same delivery cut-off rules as customer self-service orders. If Tuesday delivery cut-off is Monday noon and the rep is visiting a customer at 2pm Monday, the next eligible delivery is Wednesday — not Tuesday. The portal's scheduling logic does not make exceptions for orders placed by reps.

Without the next eligible delivery date surfaced clearly on the mobile order screen, reps commit verbally to delivery dates based on habit — "we can get this out Tuesday" — while the portal schedules Wednesday because the cut-off has passed. The customer expects Tuesday. The delivery arrives Wednesday. The rep gets a complaint for a problem that the portal created without surfacing any warning.

The mobile order screen needs to show the next eligible delivery date in context, at the moment the rep is about to submit — not in a separate calendar view the rep has to navigate to separately. This connects to how per-route cut-off times are configured in the portal; the delivery scheduling post covers the underlying configuration in detail.

Four failure modes to design around

1. Web portal used for mobile without offline support. The portal performs well on desktop but fails in the field when connectivity drops or is absent. Reps revert to phoning orders to the desk rather than troubleshoot a portal that does not respond. Self-service adoption from reps stalls at zero.
2. No quick-order from history forces full catalogue browse. Reps find the portal slower than their existing workflow. They continue placing orders by phone even when connectivity is good, because the portal adds time rather than saving it. The portal gets measured as a failure when the actual failure was an incomplete rep-workflow design.
3. Rep ordering uses shared credentials. Reps log in as the customer to place orders on their behalf. The audit trail is lost. The portal cannot report on which orders were self-service and which were rep-placed. Permission management breaks when the same credentials are shared across multiple people. Customer account administrators cannot remove a rep's access without also locking out the actual buyer.
4. Cut-off context missing on mobile. Reps make verbal delivery commitments during on-site visits that the portal's scheduling logic cannot honour. The mismatch creates customer complaints attributed to the rep rather than to the portal's information design. The fix — surfacing the next eligible delivery date in context on the order screen — is simple but needs to be in the spec before the build starts.

Design for both workflows from the start

The rep-on-site ordering scenario adds a set of specific requirements to a wholesale B2B portal that do not arise from the desktop self-service scenario alone. Rep-on-behalf-of authentication, offline capability, quick-order from ERP history, and cut-off time visibility on mobile are all resolvable — but they require explicit decisions before the build starts, not retrofits after a desktop portal is launched and rep adoption fails to materialise.

Zeabyte's platform is built to handle both workflows: customer self-service on desktop and rep-on-behalf-of ordering from mobile, both integrated with the same Accredo or ERP back-end. The user roles post covers the permission model that makes rep-on-behalf-of ordering work correctly. The Accredo integrated ordering platform post covers the ERP integration layer that drives pricing, credit limits, and order history access for both channels. If you are designing a portal with a field rep workflow, get in touch with the team — we build integrated B2B platforms for NZ wholesale and distribution businesses.