Define state transitions
Write down when an order can move from review to allocation, fulfillment, and completion. Include who can reverse or cancel each stage. Keep order state separate from payment and delivery state; one label cannot accurately represent all three. In production, validate every transition on the server rather than trusting a client-side button.
Model the line items
An order can be partially fulfilled or returned. Track quantities at line level and preserve the original request. Decide how substitutions, backorders, and split shipments affect the customer promise. Display remaining quantity and relevant dates so an operator does not need to calculate them manually from separate shipment records.
Coordinate external systems
Inventory, carriers, and payment providers may respond at different times. Use stable identifiers and retry-safe operations when passing events between them. Do not mark an order paid because a browser reports success; verify payment through the provider. Define which system owns each piece of state and how conflicts are reconciled.
Rehearse difficult cases
Test cancellation after allocation, return after partial delivery, and a retry after an uncertain network response. Record a reason for manual overrides. A useful first release may cover a single fulfillment model well before adding every sales channel. Monitor aging orders and exceptions so stalled work has an owner and a deadline.
A planning guide. The right implementation depends on your system and requirements.
Talk through your next step