Payment is where the order's work begins

Find the handover point

Trace one order after payment is confirmed. Who checks availability and configuration? Who assigns the work? Who may change the deadline, address or contents? When does the customer receive a revised promise? Map what people and systems do rather than drawing only the integrations between them.

Every stage needs an owner. “Passed to fulfilment” means little if no one is responsible for the work starting. Set a time after which an order counts as stalled and a way to raise an exception to the person who can resolve it.

Keep payment and fulfilment separate

Money and delivery can move on different timelines. Payment has arrived but one item is missing; the order is assembled but shipping is delayed; some items have gone out while others await production. A single “done” field cannot tell the truth to the team or the customer.

Agree on a small set of states for the first workflow: received, checking, awaiting a decision, in progress, partially fulfilled, completed and cancelled. For each, define the event that enters the state, its owner and permitted next steps. Do not copy another company's status list wholesale. The model must reflect the work your team actually does.

Test the exception before the perfect purchase

Run an order with one unavailable item. The system should show which item is missing, who offers a substitute and whether the customer may agree to partial fulfilment. Two more useful tests are a changed address after payment and a partial refund. If people resolve these cases in chat, the order record must catch up with the decision rather than remain a separate story.

Create a morning exception list: stalled orders, promised deadlines at risk, refunds without a completed action and customers awaiting a response. It is more useful than a large display of total order counts because it shows where someone must act today.

Show customers only a confirmed promise

The internal team needs more detail than the buyer. The buyer still needs to know that an order was accepted, what has changed and whether a decision is required from them. Do not send “Your order has shipped” when someone has merely created a packing task. A public status should follow a verified event in fulfilment.

For each notification, define the trigger, the wording and the owner of a failed delivery. If a message fails, the order must remain visible to the team. Keep an order history so a manager can explain why a date moved and who agreed to the change.

Try a small, varied set of orders

Use an ordinary order, one with partial fulfilment, one with a substitution, a cancellation and a refund. Compare the actual work, the system record and the customer message in each case. Then make one team member unavailable and see who receives their tasks. This reveals hidden dependence on an individual.

Test repeated events too. A payment confirmation or order update may arrive more than once. A repeat must not create another order or duplicate the next action. Technical protection matters, but acceptance depends on the visible result: one task for the team and one understandable promise for the customer.

Automate one exception first

Begin with a route people most often rescue manually, such as a paid order with one unavailable item. Document the states, owners and customer message; expand only after testing. The article about building an online store covers the sale, while the article about 1C integration covers data exchange. This is the work after an order is accepted. In designing a website or internal tool, I would connect those layers after each has a testable rule.

Start with the website's purpose

If you are planning a website or rethinking one, we can begin with its role in your business, its structure and the visitor's path to an enquiry.

Discuss a website