FooEvents Pro models events as WooCommerce products and tickets as the event_magic_tickets custom post type. Each ticket post stores attendee name, email, event product ID, ticket option, custom attendee meta, and the check-in state. The default admin's per-ticket list is fine for badge printing and unworkable for day-of check-in across multiple events.

SleekView reads event_magic_tickets and joins the WooCommerce product (the event) and order onto each row. Custom attendee fields configured through FooEvents (meal preference, t-shirt size, accessibility note) promote to columns automatically, and the check-in cell is editable. Toggling the cell writes the same FooEvents meta keys the plugin uses internally, so check-in reports stay consistent.

The result is the door workflow FooEvents does not ship: a phone-friendly grid filtered to today's events with one-tap check-in, a per-buyer support view across events, and a finance view that joins each ticket to its WooCommerce order for paid versus refunded reconciliation.

FooEvents Pro is one of the most complete event setups on WooCommerce, with multi-day support, seating, and customizable attendee fields, and it is held back operationally by exactly the same gap every event plugin has: the per-event admin list is the wrong shape for day-of check-in on a multi-event run. Door staff at a conference with parallel tracks need to find an attendee without first knowing which track they are checking into. Customer support needs to see every ticket a buyer holds across events when an email comes in.

Finance needs a paid versus refunded view that joins tickets to WooCommerce orders for reconciliation. All three jobs depend on a cross-event grid, role-based saved views, and inline edits, which is what SleekView adds on top of the FooEvents CPT. The data is already correct in event_magic_tickets; what changes is whether the team has to assemble the right view themselves every day at the door.