HBook stores reservations in wp_hbook_reservations with columns for arrival, departure, room reference, status, customer details, and balance, plus rate and availability data in companion tables like wp_hbook_seasons and wp_hbook_bookable_units. Rooms themselves are configured through the plugin's settings, while every reservation lifecycle event lives in one row of the reservations table.

The default HBook admin offers a reservations list and a calendar view, but cross-room filtering, balance-due queues, and bulk status changes for arrivals all require row-by-row clicks. Columns like balance, status, and the linked unit ID stay hidden until you open each reservation.

SleekView reads wp_hbook_reservations directly, pivots the schedule fields into named columns, and joins to wp_hbook_bookable_units for the room name. Front-desk users get a daily arrivals view, finance gets a balance-due queue, and bulk check-ins route through the plugin's status update so confirmation emails still fire.

A small hotel or villa rental runs on the next twenty-four hours, not on a global list of every reservation. The shape of that work is a flat table by arrival date, room, and status, with balance visible on the same row. HBook stores all the pieces (wp_hbook_reservations for the reservation itself, wp_hbook_bookable_units for rooms, wp_hbook_seasons for pricing), so the data model already supports the question.

The default admin still asks staff to open each reservation to see status, balance, and assigned room together. Multiply that by a dozen arrivals on a Friday and the workflow becomes click-heavy and error-prone. SleekView lays the same data out as a single grid: filter to today, sort by room, check guests in inline, mark deposits paid, and route every change through HBook's own status update so the rest of the plugin keeps working.

The result is fewer tabs open at the front desk and a finance team that can pull a balance-due queue without writing SQL.