Event Tickets writes every attendee as a row. Tickets Commerce attendees live as tec_tc_attendee posts with post_status values like tec-tc-completed, tec-tc-pending, tec-tc-refunded, and tec-tc-denied, plus a check-in meta key _tribe_qr_ticket_checkedin and a timestamp. The default Attendees report shows those rows as a list filtered per event, with status visible only as a column label.

SleekView Kanban reads the same tec_tc_attendee posts and groups them into columns by status. The combined order plus check-in state is the natural grouping, so the board shows Pending, Completed, Checked in, and Refunded as distinct stacks. Each card carries the attendee name, the ticket name, the event title, and the order total from the linked Tickets Commerce order, ready to read at the door without opening the full record.

Dragging a card writes the new state back to the source row. Moving a card from Completed to Checked in writes the check-in meta and stamps the time, moving a card to Refunded refunds the matching Tickets Commerce order, and moving a card to Denied flips post_status to tec-tc-denied so the attendee email and the reports reflect the change. Edge cases like partial refunds and reissued tickets are surfaced as flags on the card so the organiser sees them without drilling in.

Tickets Commerce moves an attendee through several states: a checkout creates the attendee as Pending, the payment capture flips it to Completed, the door scan writes the check-in flag, and a refund either reverses the order or moves the row to Refunded. The plugin already records each transition with the right status and the right hook. The default reading surface is still a per-event Attendees list sorted by purchase date with status as a label, and the check-in tally lives on a different screen.

SleekView Kanban reads the same tec_tc_attendee posts and lays them out as columns by state with door-ready cards on each one. Dragging a card writes back to post_status, the check-in meta, or the linked Tickets Commerce order through the standard hook the orders screen uses. The organiser stops switching between the Attendees report, the scanner screen, and the orders list because all three reflect the same source row the board edits.

Refunds, denials, partial captures, and last-minute completions all show up as movements between columns instead of as new entries on a list that has to be re-sorted.