Tickera writes each issued ticket as an instance under the tc_tickets_instances CPT, with attendee fields in wp_tc_tickets_meta and check-in status against the same row. The Tickera scanner app and the WordPress admin both read those fields, but the admin's list view treats each ticket as a post and hides ticket type, event, and check-in behind the edit screen.

SleekView reads tc_tickets_instances and joins wp_tc_tickets_meta for attendee name, email, and check-in flag, plus the event taxonomy or linked event post for event title and start date. Inline edits target the same check-in meta key the Tickera scanner writes, so a tap in the grid lines up with a scan at the door.

The practical outcome is the operational surface Tickera assumes you'll build elsewhere: cross-event check-in, role-based saved views for door staff and finance, and a phone-friendly grid that doesn't require the Tickera scanner app for the staff member already living in WordPress.

Tickera ships a good scanner app for the staff member at the door, but check-in is rarely just a scanner problem. It is a workflow problem that crosses door staff, customer support, finance, and sponsor reporting. Door staff need a phone-friendly grid that works without the scanner app installed.

Support needs to find every ticket a buyer holds across every event the venue runs. Finance needs paid versus refunded versus checked-in counts for the weekly reconciliation. Sponsors paying for attended attendees need a clean checked-in export, not a buyer list.

Treating the Tickera ticket instance CPT and its meta table as a real grid solves all four with the data the plugin already writes. The scanner stays where it works best; the rest of the operation finally has its surface.