Tickera keeps tickets in its own wp_tc_tickets_instances table, with events as a custom post type and ticket types as related records. The default admin splits operational concerns across submenus that slow both door staff and finance down.

Charts reads wp_tc_tickets_instances directly and aggregates the data into cards. Total tickets sold, check-in distribution, tickets per event, and sales over time become four cards on one screen. The door team reads check-in pace in real time, finance reconciles revenue per event, and marketing reads the sales curve before each campaign close.

The dashboard preserves Tickera's structure end to end. Custom fields registered through the Tickera Custom Fields add-on promote into the dataset as filter dimensions, so a per-ticket-type pie or a per-session breakdown comes from existing data without manual transforms.

Events live and die by the door, and the door runs on aggregate numbers: how many tickets are scanned, what percentage of the room is checked in, which ticket types are still pending. The default Tickera admin makes door staff log into wp-admin, navigate three menus, and count manually. The cost is operational: a slow check-in line because the team cannot read pace in real time, a refund processed at the wrong event because the support agent cannot search across events, a finance close that takes hours because the revenue-per-event numbers come from a spreadsheet.

Charts reads wp_tc_tickets_instances directly and aggregates the data into cards on one screen. Total tickets, check-in distribution, per-event bars, and a sales trend let each role read the day from the same dashboard. The check-in modal stays the right tool for scanning; Charts is the operational dashboard that surrounds it.