RestroPress stores every restaurant order as a rpress_payment custom post type with line items in postmeta. Each order carries a post_status like publish for received, processing for in kitchen, completed for delivered, plus custom plugin statuses including preparing, out-for-delivery, and cancelled. Order metadata in wp_postmeta covers the order type (delivery, pickup, dine-in), the requested time, the customer phone, and the address. The plugin's order admin shows everything as a flat list, which is fine for archive but useless for a busy kitchen at peak time.

SleekView Kanban reads the same rpress_payment rows you would query with rpress_get_payments. Pick the order status as the group column and every ticket becomes a card slotted under Received, In Kitchen, Out for Delivery, or Delivered. Card fronts show the customer name, the order type (delivery, pickup, dine-in), the requested time, the total, and the address for delivery orders, so the kitchen sees everything they need on the ticket card directly.

Dragging a card from Received to In Kitchen runs the same status helper RestroPress uses internally, which fires the order status update hooks. SMS and email notifications go out through the notification module, kitchen printers fire if the print module is enabled, and any delivery driver integration listening for the out-for-delivery status reacts, exactly as it would after a manual update from the order admin.

Restaurants running RestroPress hit a wall the moment Friday night dinner service starts. The default order list mixes delivery, pickup, and dine-in tickets in one long table, sorted by date, with status as a small label on the right. Line cooks miss orders because the screen does not show them in a clear queue.

Drivers get dispatched late because nobody updated the status when the meal was ready. Customers call to complain about missing orders and the manager has to scroll through fifty rows to find the right one. The disconnect between what the kitchen needs to see and what the screen offers shows up in the worst places.

Delivery orders get delayed because dispatch did not notice they were ready. Dine-in orders go cold because the floor manager did not see the kitchen finish them. Customer complaints pile up the next morning.

A kanban view that reads and writes the same rpress_payment posts the kitchen system reads keeps the team and the tickets honest. Every drag is a real status change, every column count reflects the real queue depth, and the cards themselves carry enough context for a new line cook to work the queue on their first Friday night.