WooCommerce Points and Rewards stores every transaction in the wp_wc_points_rewards_user_points_log table. Each row carries a user_id, the points delta, an event_type like order-redeem, order-placed, admin-adjust, or points-expired, plus an order_id link back to the order that triggered it. The plugin's own ledger screen shows the data as one long sortable list, which makes it hard to see how many adjustments are still pending audit versus how many have already been applied.

SleekView Kanban reads the same wp_wc_points_rewards_user_points_log rows you already query with the plugin's helper functions. Pick event_type as the group column and every entry becomes a card slotted under Earned, Redeemed, Adjusted, or Expired. Card fronts can show the customer name from wp_users, the points delta with a sign, the order number from order_id, and the date, so a support agent answering a missing points ticket has everything in front of them at once.

Dragging a card from Adjusted to Earned runs the same plugin helper the admin edit screen uses, which fires the wc_points_rewards_user_points hooks. The customer's running balance updates on the user profile, any earn-on-purchase rule recomputes, and the order timeline gets a note about the adjustment, exactly as it would after a manual entry from the points admin.

Stores running Points and Rewards typically have thousands of ledger entries every quarter. Some are earn events on orders, some are redemptions at checkout, and a steady stream are admin adjustments the support team enters every day. The default ledger screen treats all of them the same, which means support agents end up exporting CSVs to track adjustments and finance keeps a parallel spreadsheet to reconcile outstanding liability.

The disconnect between what the cart sees and what the team can find shows up in the worst places. A customer disputes a missing points balance and support cannot tell whether it expired, was redeemed, or was clawed back as an adjustment. A finance reviewer flags a liability spike and nobody can confirm which campaign earned the points.

A kanban view that reads and writes the same wp_wc_points_rewards_user_points_log rows the storefront reads keeps the team and the ledger honest. Every drag is a real event reclassification, every column count reflects the real loyalty health, and the cards themselves carry enough context for a new support agent to resolve a points dispute on day one.