Keep online orders moving from payment to dispatch

A completed checkout starts a new piece of work for your team. Someone still needs to check the order, find the stock, pack the correct items and tell the customer what happens next. When those steps live in separate inboxes and spreadsheets, it becomes difficult to see which orders need attention.

This guide proposes a practical workflow for a small online retailer. Adapt the stages to your products, payment setup and delivery arrangements. The example is illustrative, with no assumed savings or sales improvement.

Separate payment, preparation and delivery

Give the team a clear answer to three questions: is this order ready to process, what work remains in the stockroom, and what has the customer been told?

Your platform may already track these separately. Shopify, for example, distinguishes order, payment, fulfilment and return statuses. An open order can still require action, and payment authorisation differs from payment capture. Its order-status documentation explains those states. Match your working instructions to your actual platform configuration and payment arrangements.

Avoid using one informal “done” label for several events. Packed, handed to the carrier and delivered describe different points in the journey. Agree which event closes the stockroom task and which system supplies delivery information.

Give every order a visible next action

Start with a working queue containing an order reference, preparation state, exception reason, responsible person and next action. Use the order reference when moving information between tools so staff can trace an update back to the original record.

A simple proposed set of working views is:

• Ready to prepare: the checks required by your business are complete and stock is allocated.
• Needs attention: a missing detail, stock discrepancy or other exception has an owner.
• Being packed: someone has started the physical work.
• Ready for collection: the parcel is prepared and waiting for the agreed carrier handover.
• Handed over: dispatch details have been recorded and the appropriate customer update has been checked.

These are suggested team views, not a claim that every platform uses those exact status names. Keep the underlying payment and fulfilment records intact. A custom view should help staff understand the work without creating a competing record of whether a payment succeeded.

Write the exception process before automating it

Choose the situations that currently interrupt packing. Common candidates for a workshop with your team include an unclear address, insufficient stock, a duplicate order, a damaged item and a customer request received after preparation starts.

For each situation, write down who decides, what information they need and what the customer should hear. The packer should be able to pause the order with a specific reason. A manager should be able to see which paused orders need a decision today.

When a customer requests a change, check the live order and parcel state before promising it. Record the agreed change in the order system, then confirm that the packing instructions and customer message reflect it. A note in a separate email thread should not be the only record.

Match messages to what has actually happened

Map each customer message to the event that triggers it. Use a test order to check the confirmation, dispatch update and any delivery messages supplied by your carrier or platform. Read them on a phone and follow the tracking link.

Shopify documents notifications triggered by events such as order placement and fulfilment. It also explains that some delivery notifications depend on carrier or fulfilment-app events, with timing and accuracy varying by source. See its customer-notification guidance.

Before connecting an additional messaging tool, list the messages already being sent. Decide which system owns each type of update. Test repeated events so a retry does not create an extra parcel, a duplicate task or several identical emails.

Explain exceptions in concrete terms. A useful delay message says which part of the order is affected, what the team is doing and when the next update will arrive. Choose that update time based on what someone can realistically check.

A worked example: one order, two stock locations

Suppose a homewares shop receives an order for two cups and a serving bowl. The cups are in the shop, while the bowl is at a small storage unit. This example illustrates the workflow rather than a documented client result.

The order enters a review view because the items need coordination. A named staff member checks availability and the delivery promise. They decide whether to bring the stock together or arrange separate parcels, following the shop’s terms and the customer’s agreement where needed.

The packing task lists only the items assigned to that parcel. A second task remains open for the bowl if it will travel separately. Each dispatch update identifies what has left, and the original order remains traceable throughout.

If the bowl is damaged, the remaining task moves to an exception with an owner. The cups being dispatched should not automatically mark the whole customer request as resolved.

Pilot the workflow before adding connections

Run a normal order, a stock exception, a partial dispatch and a cancellation through the proposed process using test data. Check who sees each change and whether the next action is obvious. Repeat an update to test duplicate handling, then simulate a failed connection and follow the recovery procedure.

For the first live pilot, record orders needing manual investigation, packing corrections, unanswered exceptions and customer questions about dispatch. Compare similar periods and take account of order volume and product mix. The aim is to learn which handover needs attention.

Explore our online-retail solutions and eCommerce services when planning the wider journey. Add system integrations where a clear, tested handover justifies them; start by making the current work visible.