Restaurant Table Booking plugins built on WordPress store each reservation as a custom post (commonly something like table_booking) with party size, requested time, assigned table number, status, and customer details in wp_postmeta. The plugin's settings define service times, table count, and capacity rules.

The default admin lists reservations with fixed columns and a calendar tab. Comparing a service's coverage across tables, filtering pending reservations for confirmation calls, and seating walk-ins by reassigning a table all require opening individual reservation records.

SleekView reads the booking CPT directly, pivots postmeta keys for date, time, party size, and assigned table into named columns, and joins to the configured table list for friendly labels. Status, table assignment, and seating notes become inline-editable columns, and the host stand stops needing three tabs to run a service.

Restaurants run on services, not on calendars. The 19:00 sitting is its own world: who's confirmed, who's still pending a callback, which tables are reserved for parties of six. The data lives in the table-booking plugin's postmeta, but the default admin shows reservations as a flat list and a calendar tab.

Neither matches the way a host stand actually works. SleekView lays each service out as a real grid: time, party, table, status, all on one row. The host can confirm the morning's pendings, reassign tables for walk-ins, and mark no-shows in place.

Bulk confirmations route through the plugin's own status methods so customer notifications keep firing. After service, a saved CSV export gives the kitchen tomorrow's covers and finance the night's tally. Front-of-house gets a tool shaped like its workflow, not a generic posts list.