Event Espresso already tracks every registration as a row in esp_registration with a STS_ID column whose values are codes like RAP for Approved, RPP for Pending payment, RWL for Wait list, RNA for Not approved, RCN for Cancelled, and RIC for Incomplete. The default Registrations report lists those rows as a long table sorted by registration ID with the status visible only as a small code per row.

SleekView Kanban reads the same esp_registration rows and groups them into columns by status. The board shows Approved, Pending payment, Wait list, and Cancelled as the most common four columns, with the not-approved and incomplete states available as additional columns when needed. Each card surfaces the attendee name, the event title, the ticket name, the line item total, and the payment status, ready to read at the door or in the back office without opening the record.

Dragging a card writes the new state back to the source row. Moving a Pending payment registration into Approved calls Event Espresso's own status update, which fires the approval email, decrements ticket inventory through the EE messages system, and triggers any payment integration you have configured. Moving a card into Cancelled handles the refund flow through the same hooks the admin uses, so payment gateways behave identically to the default screen.

Event Espresso captures every registration cleanly in esp_registration with a clear status model. The cost is that the default Registrations report shows status as a three-letter code in a long table sorted by registration ID, which is the order they came in, not the order they need attention. That order makes sense for accounting and useless for the registrar trying to confirm tonight's workshop.

The board view fixes this by making the only state that matters, the registration status, the primary axis of the screen, with readable labels instead of codes. You can see at a glance how many registrations are waiting on payment, how many wait list slots are queued behind a sold-out workshop, and how many cancellations still owe a refund. Cards make individual registrations legible at the level of attendee, event, ticket, line item total, and payment status.

Drag is the natural verb for moving a registration through its lifecycle, and because SleekView writes through Event Espresso's own update path, every drag still triggers the EE messages, the payment captures, and the wait list promotion you already configured.