WP Hotel Booking stores each reservation as an hb_booking post with its own post_status values: hb-pending, hb-processing, hb-completed, and hb-cancelled. The default admin lists those bookings in a flat WordPress posts table sorted by ID, which is the order they happened to be created. You cannot see at a glance how many reservations are still awaiting payment, how many are confirmed for tonight, and how many checked out today and need their housekeeping ticket closed.

SleekView Kanban reads the same hb_booking posts and their meta, treats the booking status as the natural axis to group by, and renders one column per status. Cards show the guest name, the room or accommodation, the check-in and check-out dates, the number of guests, and the total. Filters let you scope a board to a single property, a single room type, or a single arrival date so the front-desk view and the housekeeping view each stay focused.

Drag a card from Pending Payment to Processing and SleekView updates the underlying hb_booking post, fires the WordPress hooks WP Hotel Booking listens for, and sends the confirmation email you already configured. Drag to Cancelled and the cancellation flow runs end to end. Inventory and availability stay accurate because writes go through the same APIs the plugin's own admin uses.

Running a small hotel or guesthouse is mostly about moving each reservation through a small number of stages: a guest enquires, they pay, they arrive, they stay, they leave. The default WP Hotel Booking admin treats those bookings as a list of WordPress posts. That works for browsing but it does not give your front desk a single screen that says: nine deposits to chase, twenty-three guests arriving today, fourteen rooms still occupied, six checkouts done.

A kanban view does. It turns the booking status into the primary axis of the screen and surfaces today's actual workload as four numbers at the top of four columns. Drag becomes the verb that moves the work forward: confirmed when payment lands, processing when the guest checks in, completed when they check out, cancelled when the booking falls through.

Because the writes go through the same WordPress endpoints the plugin's own admin uses, the confirmation emails, the inventory updates, and the third-party hooks all keep firing. The team gets a clearer day, the property runs cleaner, and reporting reflects what actually happened.