Tickera Pro already tracks every ticket as a row. Sold ticket instances live in tc_tickets_instances with a check-in flag and a parent reference to tc_orders, which carries the order status (Pending payment, Order received which is Tickera's paid state, On hold, Cancelled, or Refunded). The default Tickera admin lists tickets and orders on separate screens, each as a long table sorted by ID.

SleekView Kanban reads both tc_tickets_instances and tc_orders and groups them into columns by the combined status. The board shows Pending payment, Paid, Checked in, and Refunded as separate stacks. Each card surfaces the attendee name, the event title, the ticket type, the order total, and a check-in indicator, ready to scan at the door or reconcile in the back office without opening the record.

Dragging a card writes the new state back to the source row. Moving a card from Paid into Checked in flips the check-in flag on tc_tickets_instances the same way the door scanner does. Moving a card from Pending payment to Paid (Order received) calls Tickera's own order status update path, which fires the confirmation email, releases the ticket as valid, and triggers any payment integration you have configured.

Tickera Pro splits ticket data across two related tables: tc_tickets_instances for issued tickets and tc_orders for the parent transactions. The default admin shows them on separate screens, which is fine for accounting and confusing for the team at the door. A registrar trying to confirm tonight's check-ins has to read the orders list, the tickets list, and the scanner report, all of which read the same underlying data.

The board view fixes this by making the only state that matters, the combined ticket and order status, the primary axis of one screen. You can see at a glance how many tickets are awaiting payment, how many are paid and ready to scan, how many have been checked in, and how many have been refunded. Cards make individual tickets legible at the level of attendee, event, ticket type, total, and check-in flag.

Drag is the natural verb for scanning a ticket in, confirming a payment, or moving a refund through to closure, and because SleekView writes through Tickera's own update paths, every drag still triggers the confirmation emails, the ticket validity changes, and the payment integrations you already configured.