EventPrime registers em_event, em_booking, and em_venue as custom post types in wp_posts, with the configuration in wp_postmeta: em_start_date, em_end_date, em_venue, em_price, ticket types, capacity, and so on. The default WP post list shows title and author for each CPT, which makes cross-CPT planning impossible.

SleekView reads the EventPrime CPTs and joins venue and booking fields onto each event row through the linked post IDs. Start, end, venue, price, capacity, sold count, and any custom event meta become configurable columns. Inline edits write to the same EventPrime meta keys that the front-end calendar templates read.

The result is the planning surface a multi-event organization needs: filter to upcoming events with available capacity, group by venue to spot conflicts, sort by sold count to focus marketing on events trending toward sold-out. Saved views split the planning, ticketing, and finance work between roles, each reading the same underlying CPTs.

EventPrime models events the way an event business actually structures them: events, venues, and bookings are separate things, linked by IDs. That model is correct and is exactly why the default admin scales poorly: each CPT has its own list, the joins between them require per-event drilldown, and the planning work that depends on those joins ends up in spreadsheets. Once a team is running more than a handful of events across multiple venues, the missing columns are predictable: venue, capacity utilisation, and booking count are the dimensions that decide the week, and all three live across the CPT boundary.

Treating EventPrime as a real grid that joins venues and bookings onto each event row promotes those dimensions to first-class columns. Saved views become the rituals of the role, almost-full and conflict detection become a sort rather than a per-event drilldown, and inline edits route through the same meta keys the public templates read. The CPT model stays intact; the operational layer that the model needs is what the grid adds.