Bookly's base schema is wp_bookly_appointments, wp_bookly_customer_appointments, wp_bookly_customers, wp_bookly_staff, wp_bookly_services, and wp_bookly_payments. The Pro addons add more: custom fields land in wp_bookly_appointment_extras, waiting lists, recurring appointments, packages, and group bookings each touch additional rows or columns.

The default admin presents these through fixed-column lists, and most addon features have their own settings screen. Reception staff confirming tomorrow's bookings, support staff looking up a customer's history, and finance reconciling a month of Stripe charges all swap between tabs and modules because the schema is split across them.

SleekView reads the wp_bookly_* tables directly, joins by customer ID, staff ID, service ID, and payment ID, and surfaces custom fields and waiting-list entries as optional columns. Edits route through Bookly's API so notification, recurring, and waiting-list logic still fire. Saved views give each role (front desk, staff, finance, support) the slice they need without leaving the workspace.

Bookly's Pro addons each add value (custom fields, recurring, packages, waiting lists, group bookings) and each adds a screen or settings page. The base schema is already well-modelled across wp_bookly_appointments, wp_bookly_customer_appointments, wp_bookly_payments, and wp_bookly_appointment_extras, but every Pro feature widens the surface that operations staff have to navigate. Confirming a day of bookings ends up touching multiple admin pages, and a single customer-support call can mean opening the customer panel, the payments addon report, and the custom-field setting in succession.

SleekView treats Bookly's data the way the schema actually stores it: joined relations, exposed as one editable grid. Front desk staff confirm pending bookings, support staff browse a customer's history in chronological order, finance reconciles a month of gateway charges, and managers spot under-utilised staff slots, all from the same workspace. Bookly's API still handles the writes so the addon-specific logic continues to fire, and the indexes the plugin already maintains keep the grid fast as data grows.