Delivery scheduling in a B2B ordering portal: how NZ wholesalers manage cut-off times and route-based windows

Most wholesale distributors run structured delivery routes. Auckland customers on Tuesday and Friday. Wellington customers on Monday, Wednesday, and Thursday. Regional accounts on a weekly or fortnightly run. A food service operator whose kitchen needs to receive by 7am has a different window than a hospitality account that takes anything before noon. The sales rep who has managed these customers for years holds all of this in their head. When you move ordering to a self-service B2B portal, none of that institutional knowledge transfers automatically.

Delivery scheduling is one of the most underestimated requirements in a B2B portal build. It looks straightforward until you model what actually needs to happen: a customer logging in at 3pm on a Tuesday should not be able to order for Wednesday delivery if Tuesday's cut-off was 2pm and the Wednesday run covers their area. They should be offered Thursday — or Friday if Thursday is also closed. The portal needs to know their route, the cut-off time for that route, what the next available date is, and whether that customer has any individual exceptions that override the standard schedule.

Generic e-commerce platforms don't model this. They offer shipping method selection and estimated dispatch times, which is not the same thing as a structured route calendar with per-customer delivery days. This is one of the meaningful differences between a purpose-built wholesale trade portal and a platform designed for retail order fulfilment — a distinction covered in more detail in our B2B trade portal vs e-commerce guide.

Route-based delivery days: how most NZ distributors are structured

The typical NZ food distributor or wholesaler runs a fixed weekly route schedule. Each route covers a geographic area and runs on specific days — Wellington CBD might be Monday, Wednesday, Friday; Hutt Valley on Tuesday and Thursday; Kapiti Coast weekly on Wednesday. Customers are assigned to a route based on their location, and their delivery days follow from that route.

In a B2B portal, this means the available delivery dates shown to a customer must be filtered to their route's schedule — not a generic list of all available dates. A customer on the Kapiti Coast route should only see Wednesday as an available delivery date, not Monday through Friday. If that Wednesday has been closed (a public holiday, a driver shortage, a warehouse event), the portal should offer the next eligible Wednesday — not the following Tuesday, which runs a different route entirely.

NZ public holidays add a layer of complexity that generic platforms rarely handle well. Auckland Anniversary and Wellington Anniversary fall on different dates. Hawke's Bay Anniversary is a regional holiday that affects deliveries in that area but not elsewhere. A portal that simply flags all public holidays as non-delivery days will incorrectly block deliveries in regions where a provincial anniversary is not observed. The holiday calendar needs to be configured at the route or region level, not applied uniformly across all customers.

Cut-off times and what happens after them

Every delivery run has a cut-off time — the point at which orders stop being accepted for that run so the warehouse can begin picking. For a Tuesday delivery, that might be 2pm Monday. For a Wednesday delivery, cut-off might be midnight Tuesday (for smaller, predictable accounts) or noon Wednesday (for accounts the warehouse can still pick that afternoon).

The portal needs to enforce these cut-offs in real time. When a customer logs in after cut-off for their next scheduled delivery, the portal should advance the earliest available date to the following eligible run — not allow them to select a date that is already closed. This has to happen automatically, not through a warehouse team member manually checking and rejecting orders in the morning.

What happens to orders that arrive just before cut-off is also worth considering. Some distributors allow a short grace window for large or strategic accounts — a key customer who submits at 2:05pm might still make the run. This is not a technical question; it is a business policy decision. The portal can be configured to enforce a strict cut-off for all accounts, or to allow exceptions based on account type. What it should not do is let orders through silently after cut-off without flagging them — that creates warehouse confusion and missed commitments.

Per-customer delivery calendars and negotiated windows

Not every customer fits neatly into a route's standard schedule. Key accounts often have negotiated delivery terms: a hospital kitchen that needs delivery by 6:30am, a hotel that requires Thursday delivery only, a national chain whose distribution centre has a booking system that specifies an arrival window on specific days. These exceptions exist in the rep's relationship history and, if you're lucky, in a note field in the ERP.

A B2B portal stores these at the customer account level. A customer with a negotiated Monday/Thursday schedule sees only those days when selecting a delivery date, regardless of what the general route schedule is. A customer with an early-morning delivery window has that window noted in the order confirmation and the warehouse's run sheet. The per-customer configuration sits in the portal's account record, can be updated by your operations team when schedules change, and propagates immediately to that customer's checkout experience.

Minimum order values for delivery can also be configured per customer or customer group. A regional account with a weekly delivery might need to hit a minimum order value to justify the run; a high-volume Auckland account might have no minimum at all. The portal enforces these at checkout and can show the customer their remaining headroom before they reach the minimum — reducing abandoned carts and unnecessary delivery cost queries.

How delivery data flows to the ERP and warehouse

The portal's delivery schedule configuration determines when orders are transferred downstream and in what form. The integration between the portal, your ERP, and your warehouse operation — whether that's a full WMS or a pick-and-pack process driven from ERP reports — specifies the trigger and format.

A common pattern: orders flow from the portal into the ERP as confirmed sales orders in real time, but the warehouse doesn't see them until cut-off passes and the run is closed. At that point, picking lists or run sheets for that route are generated from the ERP, grouped by delivery address or vehicle route. The warehouse picks against the closed run; the portal shows those orders as confirmed and in progress.

For distributors integrated with Accredo, MYOB Acumatica, or similar ERP systems, the sales order created in the ERP at the portal order point carries the confirmed delivery date as a field — which drives dispatch and invoice timing downstream. The integration between the portal and the ERP handles this mapping as part of the order write-back. For more on how Accredo specifically integrates with a B2B ordering platform, the complete guide for Accredo-integrated portals covers the full order and invoice flow.

What goes wrong when delivery scheduling isn't designed in

A B2B portal that doesn't model delivery scheduling properly creates a predictable set of problems. These are not edge cases — they surface consistently in the first weeks of go-live when a system that wasn't designed for structured routes meets a real route schedule:

• Orders placed after cut-off make it into the pick list for a run that's already being picked. The warehouse has to chase these, either rush-picking or calling the customer to delay — both create friction and damage the efficiency the portal was supposed to deliver.
• Customers select a delivery date that doesn't correspond to their route. The order arrives at the warehouse addressed for a day that route doesn't run. Someone has to manually reassign it. At scale, this becomes a daily triage task.
• Key account exceptions aren't captured. A customer with a negotiated Thursday-only delivery places an order for Wednesday. The portal confirmed it; the warehouse can't fulfil it on that day. A customer service call follows that shouldn't have needed to happen.
• Regional public holidays aren't handled. A Wellington Anniversary delivery closure is applied to Auckland customers who had no reason to be affected, creating unnecessary delays and confused customers who can't work out why the portal won't let them order.

These failure modes share a root cause: delivery scheduling was assumed to be simple configuration that could be added after go-live, rather than a core business logic requirement that shapes how the portal is built. This mirrors the pattern we've described for credit limit management — both are operational requirements that need to be designed in from the start, not retrofitted.

What to configure before go-live

Getting delivery scheduling right requires decisions that come from your operations team, not your IT team. The portal can implement any rule set you define — but the rules have to be defined explicitly. Before go-live, that means documenting:

• Every delivery route, the days it runs, and the cut-off time for each day — including whether cut-off is the day before or same day, and at what time.
• Every customer account's route assignment — and any individual exceptions where a customer's delivery days differ from the standard route.
• Regional holiday closures that affect specific routes, not all customers nationally.
• Minimum order values per route or customer, if applicable.
• What the portal shows a customer when they land after cut-off — which next available date to offer, and whether any account types get a grace window.
• How confirmed orders flow into the ERP and what triggers the warehouse pick list for each run.

This is operational configuration work, not a technical unknown. The complexity is in gathering the current-state rules that live in your reps' heads and your existing run schedules, and translating them into explicit, documented logic the portal can enforce consistently.

If you're scoping a B2B ordering portal for your distribution business and want to understand how delivery scheduling, route configuration, and ERP integration would work for your specific operation, reach out to the Zeabyte team. We build and operate the Provender B2B ordering platform, which handles route-based delivery scheduling, per-customer delivery calendars, and cut-off time enforcement as part of the core platform — integrated with Accredo, MYOB, Xero, and more than 25 accounting and ERP systems.