SupportCandy keeps each ticket in the wp_wpsc_ticket table with status, priority, and category stored as ID references into wp_wpsc_ft_status, wp_wpsc_ft_priority, and wp_wpsc_ft_category. Custom fields land in wp_wpsc_ticketmeta, agents in wp_wpsc_agent. The plugin's All Tickets screen is a list with a status filter dropdown that forces a reload every time the lead wants Pending instead of Open.

SleekView joins those tables and renders one card per ticket grouped by the status field, the natural choice because every SupportCandy team already names statuses to match their flow. Card fronts show subject, requester email, priority pill, agent name, and last activity date so a triage lead reads the queue without clicking.

Dragging a card from Open to Pending writes the new status ID through SupportCandy's REST endpoint, fires wpsc_after_change_status, and triggers the configured email notifications and webhooks. Bulk status changes work the same way, so closing five resolved tickets after a customer confirmation only takes one drag from Resolved to Closed.

SupportCandy already thinks in terms of status, priority, and category, but the default admin screen flattens that structure into a single sortable table with one status filter at the top. Every time the lead wants to look at Pending instead of Open, the page reloads. Every time an agent finishes a reply, they click into the ticket to flip the status.

The information the team needs to coordinate a shift, how many tickets sit in each bucket and who owns them, is technically available but spread across pagers and dropdowns. A kanban view rebuilds the screen around the queue. Open on the left, Pending in the middle, Resolved and Closed on the right, each column counting its tickets so the lead sees backlog shape at a glance.

Drag means status change, which SupportCandy already handles cleanly through its REST endpoint, so the hooks, the email templates, and the audit trail all keep working without a parallel automation layer.