If three or more of these are true, the backorder management process is consuming operations and customer service time that should be directed at fulfilment, not at answering queries the system should already be answering.
B2B PO manager, shoe manufacturer and distributor
Root cause: Backorder status is not surfaced in a format accessible to customer service or to the customer themselves without manual investigation. The order management system records that an order is open and partially fulfilled. It does not connect the outstanding lines to the purchase orders expected to fulfil them. It does not calculate expected dates. It does not expose the current order state or next delivery date to a customer-facing report.
Every query requires someone to manually assemble the answer from multiple sources.
Stok.ly surfaces backorder status, expected receipt dates and outstanding quantities from the live operational record.
Customer service answers queries from the system without investigation.
B2B trade customers with reporting access see their outstanding orders, the quantities still to arrive and the expected dates — without contacting the team.
The Stok.ly B2B reporting platform gives trade customers a self-service view of their account. Reports are published to a URL that you provide your customer with – they simply log into a browser, open the URL and see their refreshed report.
They can see placed orders with line-by-line status: despatched (with tracking), awaiting despatch (stock committed and in the warehouse queue), and backordered (outstanding with expected date where available from confirmed purchase order data). Â
The report view is drawn from the live operational record.
It reflects the current operational state — not a manually updated status field.
When an order moves from backordered to despatched, as the reports are refreshed periodically, the data updates automatically.
This could run every morning after orders are processed in your Stok.ly system or every evening at close of business.
The customer does not need to call to find out.
For customer service teams fielding backorder queries, the operational requirement is simple: when a customer asks “what am I still waiting for?”, the answer should be available in the system in seconds, not after a manual investigation. Â
In Stok.ly, customer service teams see each customer’s outstanding orders, the backordered lines, the expected fulfilment dates from confirmed PO data, and the despatch status of everything already shipped.
The answer to any backorder query is in the system. No manual compilation. No holding the customer while checking three different records.
Sales orders are linked to pre-allocated purchase orders on the sales order, purchase order and in the pre-allocation table.
The question B2B customers most frequently ask about backordered items is when the stock will arrive.
Most operations teams answer this question from memory, from a manually maintained spreadsheet, or by checking the open purchase order and estimating delivery.
None of these methods is reliable or scalable. Â
In Stok.ly, expected dates for backordered order lines are calculated from the confirmed delivery dates on open purchase orders.
When a supplier confirms a PO delivery date, every backorder line waiting for stock from that PO receives an updated expected date. The calculation is automatic and updates whenever the PO delivery date changes. Customers and customer service always see the current best estimate, not a manually entered date that was set three weeks ago.
| Capability | What it controls | Why it matters |
|---|---|---|
| Backorder status visibility | Outstanding quantities, expected dates and fulfilment status per order line | Customer service answers queries from the system; no manual investigation required |
| B2B trade portal | Account portal showing open orders, despatched items and outstanding backorders per customer | B2B customers see their own backorder status without contacting the team |
| Expected dates from PO data | Backorder expected dates calculated and updated from confirmed PO delivery dates | Expected dates are accurate and current; not manually maintained estimates set weeks ago |
| Backorder allocation on receipt | Stock arriving against a PO allocated to backorders in priority order | Oldest backorders or highest-priority accounts fulfilled first on stock arrival; systematic not manual |
| Partial despatch tracking | Order line-level status showing despatched and outstanding quantities separately | Customers and customer service see exactly what has shipped and what remains outstanding |
| Per-customer outstanding summary | Complete view of all outstanding quantities across all orders per trade account | Account managers have a complete picture for every customer; customer meetings are data-led |
| Current approach | What tends to break | Stok.ly |
|---|---|---|
| Backorder status requires manual investigation to answer | Customer service time consumed by queries the system should answer instantly | Backorder status, expected dates and despatch status visible from the operational record in seconds |
| No customer self-service visibility | Every backorder query generates a phone call or email to the team | B2B customer portal shows open orders, despatch status and outstanding backorders |
| Expected dates communicated by phone after manual calculation | Dates inaccurate or delayed; customers lose confidence in information quality | Expected dates calculated from confirmed PO delivery data; updated automatically when PO dates change |
| Stock allocated to new orders rather than outstanding backorders first | Customers who ordered first receive stock later than customers who ordered after | Backorder allocation in arrival order; oldest backorders fulfilled first on stock receipt |
| Partial despatches not clearly communicated to customers | Customers chase the outstanding balance without knowing what has already shipped | Partial despatch visible per order line; customer and customer service see exactly what has shipped |
| No per-customer outstanding order summary | Account manager cannot prepare for customer review without manual compilation | Per-customer outstanding view; data-led account conversations without pre-meeting export work |
“The platform is versatile and caters for all our ecommerce needs. Working alongside our Shopify store, it is our backbone for supporting inventory management and order management.”
COO, London urban fashion brand — Verified G2 review, 5 stars — Read on G2
Pure B2C businesses with no B2B trade accounts or backorder management requirements. Businesses where all orders are fulfilled immediately from stock with no backorder scenarios. The B2B portal and backorder visibility features add the most value where trade account management, backorder frequency and customer communication overhead are a material operational cost.
What do you like best about Stok.ly – Inventory-Centric Cloud ERP?
“we have been a user for the last 4 years and we cannot think of life without it for our retail business. it makes listing to shopify and other marketplaces easy, keeps inventory accurate online and the POS is easy to use. accurate inventory across all sales channels is the big win for us.”
B2B backorder visibility fails when the order management system does not expose outstanding order status, partial despatch information and expected dates in a format accessible to the customer or to customer service without manual investigation. Trade customers have no self-service view. Customer service cannot answer backorder queries without looking through the order record manually. Every query generates a phone call and a delay.
A B2B customer portal is a self-service account view where trade customers see their placed orders, what has been despatched, what is outstanding and when outstanding items are expected. In Stok.ly, the B2B trade portal is connected to the live operational record. Expected dates are calculated from confirmed purchase order data. Despatch status updates when the warehouse confirms despatch. The customer sees the current operational truth without contacting the team.
Stok.ly calculates expected fulfilment dates for backordered order lines from the confirmed delivery dates on open purchase orders linked to the outstanding stock. When a supplier confirms a PO delivery date, every backorder line waiting for stock from that PO receives an updated expected date. The calculation is automatic and updates whenever a PO delivery date changes.
When goods-in is confirmed for a purchase order, Stok.ly allocates the received stock to outstanding backorders in priority order. The default is by order placement date — oldest backorders first. Customer priority tiers can be configured to ensure high-value accounts receive stock ahead of lower-priority backorders. Manual overrides are available for specific situations without losing the overall allocation structure.
In the Stok.ly B2B trade portal, customers see their placed orders with line-by-line status: despatched (with tracking), awaiting despatch (stock committed and in the warehouse queue), and backordered (outstanding with expected date from PO data where available). They see what has been partially fulfilled and what remains outstanding. The view reflects the current operational state, not a manually updated status field.
Stok.ly tracks fulfilment status at order line level. When a partial despatch is made — some lines fulfilled, others backordered — the despatched lines show with tracking information and outstanding lines show with backorder status and expected date. The customer sees exactly what has shipped and what is outstanding. Customer service sees the same line-level view without any manual investigation.
Stok.ly generates order status updates and despatch notifications as part of its order management and fulfilment workflow. When an order moves from backordered to allocated, or from allocated to despatched, status updates are generated. The specific notification configuration depends on the business’s customer communication setup. The underlying status data driving any notification is always current in the operational record.
Cin7 has limited native B2B trade workflow depth, particularly around trade portals, backorder visibility and account-level management. Brightpearl has reasonable B2B capability but its backorder management and customer portal functionality is less developed than its core retail ERP features. Stok.ly is built for businesses running both B2C and B2B from one system, with trade portal, backorder management, account pricing and fulfilment visibility in the same operational layer.
All our sales, support and development team are located in Hereford and Cheltenham in the U.K. Please submit the contact form and we will contact you within the same business day.