Restaurant Delivery Status Workflow: No Skipped Steps

Last verified: 2026-08-28

Delivery status is an operational record, not a decorative label. If riders can jump directly from assigned to delivered, nobody knows whether the handoff or journey actually happened.

Use one-way states

A reliable order moves assigned, picked up, on the way, then delivered. Permit only the next state and return a clear error for a skip or reversal.

Define who owns each transition

Dispatch assigns; the rider confirms pickup and travel; delivery is confirmed at handoff. Keep timestamps for later service analysis.

• Assignment owner
• Current state
• Last update time

Handle rejection separately

Rejection is not delivery failure. Capture a reason, return the order to an unassigned queue and let dispatch respond quickly.

One status should answer one operational question

Delivery status should show where the order is in the restaurant-controlled fulfilment flow and who owns the next action. Avoid a label such as completed that could mean kitchen finished, rider collected, customer received, payment settled or support closed. Use separate fields or states for kitchen readiness, delivery movement, payment and refund when those processes can differ.

Write a status dictionary before configuring automation. For every state define its meaning, allowed previous and next states, normal actor, required evidence, customer message where used and exception path. Staff should not need to guess whether ready means ready for pickup or already handed to the rider.

Reference delivery state machine

Products may use different names or combine steps, but the operational meaning must remain clear. If assigned occurs before ready, show both readiness and assignment rather than forcing one timeline to replace the other.

Keep a status event history, not only the latest value. Support needs actor and timestamp to find where a delay or mistaken transition occurred.

Set valid transitions and permissions

Prevent impossible jumps such as delivered before pickup, or returned after a normal close without reopening an authorised exception. Some transitions need prerequisites: assignment requires an eligible rider; pickup requires the correct current assignment; delivered requires the restaurant's chosen proof and any mandatory cash confirmation step.

Restrict actors by responsibility. Kitchen marks preparation/readiness, dispatch manages assignment, the rider updates trip and handover, and an authorised manager resolves a failed or reversed status. An override should capture the original state, new state, actor and reason.

Separate event time from edit time

Store when the event occurred and when it was recorded if offline or delayed entry is possible. A rider may complete handover while connectivity is unavailable and sync later. Using the sync time as the delivery time distorts support and performance review; accepting arbitrary backdating without an audit trail creates a different risk.

Define which events can be queued offline, how conflicts are resolved and how the UI marks a pending update. Never claim a general offline capability unless the exact workflow has been tested.

Restaurant-to-rider handover

Pickup is a custody boundary. The kitchen or dispatcher should not mark pickup merely because food is ready, and a rider should not receive an order assigned to another person without a controlled handover or reassignment. This boundary supports both food quality and cash responsibility.

Customer communication should follow evidence

Map messages only to reliable events. A ready message should not claim the rider is travelling; an assigned message should not promise an arrival time the system has not calculated and verified. If staff can correct a status, decide whether the customer needs a correction message and who approves it.

Use the minimum customer information needed for delivery and support. Do not expose internal rider notes, staff names or blame. Keep opt-in and channel requirements in the restaurant's current communication policy.

Failed, cancelled and returned are different

A cancelled order may stop before dispatch; a failed delivery may occur after pickup; a return describes the physical food or item moving back. Record the delivery outcome, order sales/refund decision, payment state and food disposition separately. One failed label cannot safely decide all four.

Use reason categories such as unreachable customer, unusable address, refusal, payment issue, damage, safety concern or restaurant error, with a factual note. The manager or support owner decides reattempt, return, cancellation, remake, refund or other authorised action.

Payment and COD status boundary

Delivered does not necessarily mean restaurant cash is reconciled. For COD, record expected amount, rider collection, deposit handover, receiving cashier and difference. For a prepaid order, confirm the authorised payment state without exposing gateway credentials or treating a pending settlement as cash received.

A refund or payment correction follows its own approval and evidence. Do not move the delivery timeline backward merely to change financial reporting; link the financial event to the order.

Exception ownership by status

Each exception needs a next action and deadline appropriate to the order, not just a warning colour. Escalation should protect rider safety and food handling as well as customer communication.

• Preparing too long: kitchen or shift manager
• Ready without rider: dispatcher
• Assigned but not accepted: dispatcher
• Pickup mismatch: dispatcher and manager
• Trip delay or safety issue: rider support
• Failed delivery: support/manager decision
• Delivered with COD difference: cashier/finance
• Wrong status update: authorised correction owner

Status workflow audit

Review the audit to fix workflow, training and system rules. Elapsed time needs preparation, route, traffic, weather and assignment context; it is not automatically a rider-performance conclusion.

• Orders stuck in each state
• Skipped or overridden transitions
• Event time vs record/sync time
• Ready-to-pickup handover context
• Failed/return reasons and unresolved owner
• Delivered orders without required proof
• COD delivered but not deposited
• Customer message sent before supporting event

State-machine test cases

• Normal confirmed-to-delivered flow
• Assignment before readiness
• Rider reassignment before pickup
• Attempted pickup by wrong rider
• Offline event synced later
• Failed delivery with return
• Delivered COD with difference
• Manager correction of a wrong status
• Access revoked during an active delivery

A small state machine creates a shared language for kitchen, dispatch, rider and customer support.

Related guides

• Rider Assignment Workflow
• Secure Rider Login
• Food Delivery Management Software
• Compare Restaurant Management Software

See this workflow in Rosuii: Track delivery updates

Start using Rosuii for free