To keep accepted, preparing and completed orders from getting mixed up, give each status one operational meaning, one person responsible for changing it, and one next action. Write those meanings next to the actual labels in your ordering system. Then make sure the kitchen and front counter use the same map.
The distinction matters: an accepted order may still be waiting for a cook, while a completed order should not leave staff guessing whether the food is ready or already handed off. Decide those boundaries before a busy shift, not while a guest is waiting.
Start with the statuses your system actually uses
Ask your ordering provider for the full list of statuses available in your setup. Include normal progress, cancellations, failed acceptance and any delivery-related states. Ask which labels staff can change, which change automatically, and whether the same words appear on every screen.
Do not assume that two systems use the same word in the same way. A provider may use “completed” when food is marked ready, when it is collected, or when another event occurs. Ask the provider to define the event behind each label and show where staff see it.
Collect input from the people who work at each handoff:
- Owner or manager: Sets the operating rule and decides who resolves exceptions.
- Order receiver: Explains when an incoming order is checked and accepted.
- Kitchen lead: Identifies when preparation truly starts and when food is ready.
- Front counter or delivery coordinator: Describes how staff confirm pickup or handoff.
- Provider: Explains available labels, automatic changes, permissions and connected-system behavior.
Record the exact provider label alongside your house definition. If a label cannot be renamed, staff can still use a shared explanation in training. If it can be renamed, check whether the change affects other screens or connected services before using a new term.
Review every place staff look for orders, including the ordering screen and any connected kitchen or POS display. The online ordering buying guide can help you frame broader system questions; for this decision, focus on what each screen tells the next person to do.
Map each status to an action and an owner
The following is a hypothetical pickup-order map, not a list of statuses offered by a particular provider. It assumes the restaurant can record these four stages. The manager should adapt it to the actual system and shift roles.
| House meaning | Change happens when | Owner | Next action |
|---|---|---|---|
| Accepted | The order receiver confirms the restaurant will make the order | Order receiver | Kitchen reviews the ticket and queues the work |
| Preparing | A cook starts work on the order | Kitchen lead or assigned cook | Prepare, check and pack the items |
| Ready for pickup | The packed order has passed the restaurant's handoff check | Kitchen lead | Front counter holds it for the correct guest |
| Completed | The order is handed to the guest | Front counter | Close the handoff; route any later issue to the manager |
The table separates a kitchen milestone from a handoff milestone. Under this rule, “ready” means the food is available; “completed” means the guest has it. If your system only offers one of those labels, agree on which event it represents and use a separate, visible handoff procedure for the other. Do not train staff to infer a handoff from a label that only means the food is ready.
Accepted also needs a boundary. It means the restaurant has agreed to fulfill the order, not that a cook has started it. The order receiver should check that the ticket is workable under the restaurant's normal process before accepting it. The kitchen should still know how to find accepted orders waiting for preparation.
Choose a primary owner for each change, then name a backup for breaks and shift changes. The owner can be a role rather than a specific employee. If the system changes a status automatically, assign someone to monitor the resulting queue rather than pretending a person made the change.
For delivery, make a separate map. Decide whether your final internal milestone is food handed to a courier or delivery confirmed by another party. Ask what evidence the system actually provides. A kitchen employee should not mark an order as delivered merely because it left the counter.
Find ambiguous labels and missing states
Walk through the map looking for a point where the next person cannot tell what happened. “In progress,” for example, could mean accepted, cooking or packed. Ask the provider what triggers it and which team should act on it. If the answer covers several events, add a local instruction that tells staff where to look for the next reliable signal.
Pay particular attention to these gaps:
- Waiting after acceptance: Can the kitchen distinguish an accepted order that has not started from one already being prepared?
- Ready versus handed off: Can the counter identify food still waiting for pickup without treating it as already collected?
- Changes and cancellations: Who checks the current ticket and tells the kitchen when an order needs attention?
- Failed or delayed acceptance: Where does the order appear, and who is responsible for noticing it?
- Connected screens: Do labels or updates differ between the order screen and any connected kitchen or POS display?
Use a concrete rule for exceptions: the employee who spots a mismatch alerts the shift manager, and the manager establishes the current order state before anyone advances it. The manager then tells the affected team what to do. A shared rule prevents two employees from independently changing the same ticket based on different assumptions.
Ask what happens when someone selects the wrong status. Can an authorized person correct it, and is the correction visible to the next team? Also ask which changes trigger messages or other external actions. These answers affect both training and recovery; a label that looks internal may have consequences beyond the screen.
For a restaurant website that receives orders, include the channel in the review. Staff need to know where those orders appear and whether their status journey differs from orders entered elsewhere. Keep the internal meaning of each state separate from the wording a guest sees.
Practice the journey, then observe a live pilot
Use a hypothetical pickup order with two menu items for a dry run. First, confirm with the provider how to simulate it safely. The practice must not create a real card payment, send a guest message or dispatch a courier. If the setup cannot prevent those actions, rehearse on paper or with screenshots instead of using a live order.
- Receive: The order receiver reads the ticket and identifies what must be checked before acceptance.
- Accept: The receiver marks the order accepted in the simulation, or points to that step on paper. The kitchen identifies where it would find the waiting ticket.
- Prepare: The assigned cook identifies the moment work starts and the action that would move the order to preparing.
- Check and hold: The kitchen lead checks the packed order and identifies how the counter would know it is ready.
- Hand off: The counter describes how it would match the order to the guest and record completion.
At each step, ask the next person what the current status means and what they should do. Note any answer that depends on guessing. Then rehearse an exception: the cook notices an item problem after acceptance. The cook alerts the shift manager, who determines the next action and communicates it to the counter. Do not advance the order simply to make the screen look tidy.
A simulation checks whether people understand the process; it does not prove every connected system will behave the same way during service. If you choose a live service pilot, use an actual order through the normal approved process, with the staff involved aware that the workflow is being observed. The shift manager should watch the handoffs and record where the labels or responsibilities caused hesitation. Do not manufacture a payment, message or dispatch as a training exercise.
After the pilot, update the map and review it at a shift meeting. Keep a short version where staff can consult it, and revisit it when roles, screens or provider settings change. A status map is useful only if the team can apply it consistently when orders arrive at once.
Start by comparing your current labels with the four-column map above. Then ask Fleksa about restaurant online ordering, including which status controls fit your workflow and verified availability in your US location.
Frequently asked questions
Does accepted mean the kitchen has started cooking?
Not under the sample map. Accepted means the restaurant has agreed to fulfill the order; preparing begins when a cook starts work. Confirm how your own system uses both labels.
Should completed mean ready for pickup?
Choose a meaning that matches the event your system records. If completed means ready rather than handed off, give the counter a separate way to track the handoff and train staff on the distinction.
Who should update an order status?
Assign the role closest to the event: the receiver for acceptance, the kitchen for preparation and the counter for pickup handoff. Name a backup and identify any changes the system makes automatically.
