An order processing flowchart shows how an order becomes eligible for fulfillment, which team handles each handoff, and what happens when an order cannot continue. It should make exceptions visible before a customer has to ask where their package is.
The useful output is a release decision backed by evidence: the right items are allocated, the payment condition is satisfied, the address and shipping method are usable, and any required review is complete. A diagram that simply says “pay → pick → ship” hides most of that work.
Define the boundary and the states
Start with one concrete scope: for example, domestic stocked goods sold through one online store. Begin when the order record is created and end when each shipment has reached the support handoff or completion condition your team uses. Returns can be a linked subprocess instead of making the main diagram unreadable.
Keep four state tracks separate. An order can be open while payment is pending. Payment can be authorized without being captured. Stock may be available but not allocated to this customer. A package can be fulfilled in the commerce platform but still in transit with the carrier. These combinations are normal; they are not all errors.
Write a small glossary next to the diagram. “Ready to release” should be an internal gate with explicit conditions, not an invented replacement for the platform's payment or fulfillment statuses. When platform labels differ, record their exact names in the operating notes.
Build the main order processing flow
1. Receive and validate the order. Record the order identifier, line items, quantities, address, requested delivery service and customer contact. Rejecting an invalid address is different from rejecting an unavailable product. Give each a labeled exception path.
2. Evaluate payment status. Read the provider's actual status. Pending, failed, authorized and captured are different outcomes. A retry branch needs an expiry and a customer communication step. An authorization may expire; do not describe it as settled cash.
3. Allocate inventory. Check sellable quantity at the intended location, including existing reservations. Two customers can see the last item before either checkout finishes. The inventory system must control allocation; the drawing only describes the policy. If allocation fails, offer the options your store actually supports: wait, substitute, split or cancel.
4. Check the release gate. Confirm the required payment condition, allocation, shipping details and any applicable review. Assign a named role to resolve an unclear result. The chart must not allow warehouse work to proceed merely because one of the checks passed.
5. Create the pick and pack task. Pass order and shipment identifiers, allocated quantities, location and packing instructions. During packing, a discrepancy should return to allocation review or an exception owner. Do not silently substitute a different item because the box is already open.
6. Confirm shipment handoff. Record the carrier, service, package contents and tracking reference. Distinguish creating a label from handing the package to the carrier. If your platform uses a fulfillment event at this point, preserve that meaning rather than renaming it “delivered.”
7. Track delivery exceptions. A delayed scan does not automatically prove loss. Route missing tracking, failed delivery and returned-to-sender events to the support policy for that service. The owner checks the evidence and communicates the next action.
8. Close the defined work. Decide what closes a warehouse task, a shipment and the parent order. They may close at different times. Keep a return or dispute route available after normal fulfillment has ended.
Worked example: one order, two shipments
Consider a hypothetical order containing one desk lamp and two notebooks. The lamp is allocated at Warehouse A, while the notebooks are at Warehouse B. The customer's selected service allows split shipping, and the store's policy requires captured payment before warehouse release.
The payment provider initially returns pending. The order exists, but neither warehouse receives a release task. Customer support owns the pending-payment queue, and the stock reservation follows the store's documented expiry. If payment never reaches the required state, the expiry branch releases reservations and sends the appropriate notice.
Payment then becomes captured. Both allocations are still valid, so the release gate creates Shipment A for the lamp and Shipment B for the notebooks. Their fulfillment tasks share the parent order identifier but have separate quantities and tracking references. This prevents the first shipment from falsely completing the second.
Warehouse B finds that one allocated notebook is damaged. That shipment stops at a discrepancy branch. An authorized owner checks replacement stock and the customer's available options. The diagram does not let the picker invent a refund, change the item or mark the full order shipped.
Meanwhile the lamp has been handed to its carrier. Its shipment can advance according to the platform's fulfillment rules while the notebook issue remains open. Customer communication should describe the split accurately. A single generic “your order is complete” message would conceal unfinished work.
This example tests the chart's most important property: every quantity has a current state and an owner. A flowchart is useful when it helps someone answer “which part is blocked, why, and who can move it?” without reading a thread of informal messages.
Make exception paths finite
| Trigger | Route | Evidence before leaving the route |
|---|---|---|
| Payment pending | Wait or contact customer under the payment policy | Required provider status, or recorded expiry |
| Allocation failed | Availability review | Confirmed allocation or approved customer option |
| Packing mismatch | Warehouse exception owner | Correct item and quantity, or approved alternative |
| Cancellation requested | Check current shipment stage | Whether interception is possible and who approves the outcome |
| Tracking problem | Shipping support | Carrier evidence and the next customer update |
A loop labeled “try again” needs a stopping condition. For payment this may be the configured retry or reservation expiry. For stock it may be the customer's accepted wait period. Use real policy values instead of borrowing arbitrary hours from an example.
Cancellation and refund are also different actions. Cancelling unshipped work does not necessarily undo a captured payment, and issuing a refund does not prove a parcel was intercepted. Draw the checks separately and let the relevant system record their outcomes.
Choose shapes and ownership lanes
Use rectangles for actions and diamonds for questions with explicit exits. “Check payment” is an action; “required payment state reached?” is a decision. Label branches with conditions rather than leaving readers to infer which arrow means yes.
When more than one team is involved, use lanes for customer support, the commerce or inventory system, warehouse and shipping support. At each lane crossing, name the task or record being handed over. “Tell warehouse” is weaker than “release shipment task with allocation and order identifier.”
Avoid drawing every field as a node. Keep the main path readable and put the required inputs in a nearby checklist. Link complex returns handling to a separate flow rather than placing a second full process inside the delivery decision.
Test the chart before adopting it
Walk through a successful single shipment, a pending payment, a stock race, a packing discrepancy, a split shipment and a cancellation after label creation. Use hypothetical identifiers rather than exposing customer details in a public diagram.
Ask the person receiving each handoff to explain what they would do next. If two people interpret “complete” differently, refine the glossary and gate. A layout can look neat while its instructions are still ambiguous.
Check the diagram against the actual platform configuration. A flowchart cannot create inventory locking, automatic retries, refunds or customer notifications. If an action is manual, label it manual; if software performs it, identify the system and the condition that triggers it.
Draw and maintain your version
Open the flowchart template, replace the generic actions with your store's release conditions, and add exception owners before polishing colors. Use the flowchart symbols guide if you need a consistent visual vocabulary.
CodePic provides an editable canvas for documenting this process. It does not operate the order-management system. Export a PNG for a handbook, keep editable JSON for later changes, or use a read-only share link for reviewers.
Add a process owner, revision date and link to the current operating procedure. Review the chart when payment capture rules, warehouse allocation or shipping services change. A useful review checks whether the old routes still match the work; changing the date alone does not make an obsolete process current.
Frequently asked questions
Should a failed payment immediately cancel the order?
Only if that matches the store's policy and platform configuration. Otherwise show the retry or pending state, its owner, its expiry and what happens to reserved stock.
Can one order have several fulfillment branches?
Yes. Track each shipment's quantities and status separately, then apply the parent order's completion rule. Do not let the first tracking number stand in for the whole order.
Which template should I start with?
Use a basic flowchart for a single team's path. Use a swimlane diagram when the main problem is responsibility across teams.
