OvaBooking stores every booking as a row in ovabooking_history with a status column whose values are pending, approved, paid, cancelled, or rejected. The default Booking History screen lists those rows in a long table sorted by booking ID with the status as a small column per row, which works for occasional bookings and breaks down once your tour or rental catalogue is selling weekly.

SleekView Kanban reads the same ovabooking_history table and treats the status column as the natural axis to group by. Each card surfaces the customer name, the booked item, the start date, the duration, and the total. Columns mirror your real OvaBooking statuses, so the pending stack and the paid stack each read as a single number rather than as labels scattered across rows.

Drag a card from Pending to Approved and SleekView calls the same OvaBooking update path the admin uses, which fires the approval email and triggers any payment hook you have configured. Drag to Cancelled and the refund and notification flows run through OvaBooking so any payment gateway integration handles the money side consistently. Per-item boards keep each tour or rental manager focused on their own rows.

Tour and rental bookings are not just rows in a table, they are a sequence of commitments: enquiry, deposit, balance, departure or pickup, return. OvaBooking captures all of that already in ovabooking_history. The default admin presents the result as a list sorted by booking ID, which is the order they came in, not the order they need attention.

The board view fixes this by making the only state that matters, the booking status, the primary axis of the screen. You can see at a glance how many bookings are awaiting approval, how many are confirmed for next week, and how many cancellations still owe a refund. Cards make individual bookings legible at the level of customer, item, dates, duration, and money, which is what a tour or rental operator actually needs.

Drag is the natural verb for moving a booking from one stage to the next, and because SleekView writes through OvaBooking's own functions, every drag still triggers the approval emails, the availability changes, and the deposit captures you already configured. List view and board view become two reading surfaces over the same data instead of a tradeoff between them.