It is easy to describe an order as a status: accepted, preparing, ready, served, paid. But in a restaurant, a status is never only a label. It marks a handoff between people with different responsibilities, different permissions and different information needs.
A waiter acknowledges an order. The kitchen owns the next task. The counter may need the bill. The manager may step in only when something goes wrong. When one generic screen tries to serve everyone, it creates noise and makes the next action harder to see.
The interface should mirror responsibility
The useful design question is not “what statuses should appear in a dropdown?” It is “who needs to act now, what can they safely change, and what information helps them do it?” The answer shapes both the order flow and the permission system around it.
- Accept when the order is acknowledged
- Prepare when the kitchen owns the next task
- Mark ready when service can collect it
- Serve when the table team completes the handoff
- Bill and pay only when the service flow is complete
A sequence is more useful than a dashboard
People working during service should not need to interpret a broad dashboard before they can act. The current state, the next legitimate action and the exception path should be clear in the local context of the order.
That approach changes small details too: table state updates after payment, kitchen staff do not see billing controls, and an owner can override a flow without making the everyday path more complicated for everyone else.