WooCommerce Rewards Points keeps customer balances in wp_wc_rewards_user_points and writes ledger rows into wp_wc_rewards_points_log for earns, redemptions, signup bonuses, and expiry clears. The default admin shows the customer balance list and the event log on separate screens, which makes a simple question like "who is 50 points away from a redemption tier" or "how many points did the recent signup push issue" surprisingly hard to answer.

SleekView reads wp_wc_rewards_user_points, joins it to wp_users and the latest log row from wp_wc_rewards_points_log, and exposes balance, lifetime earned, last event reference, and last activity timestamp as first-class columns. Filter by event_type to audit a single campaign, sort by lifetime_earned to find the top spenders, or save a view called "Near redemption threshold" that the marketing team reuses every week.

Inline edits route through the plugin's points API so balance adjustments still trigger the plugin's hooks and write a ledger row with the right reference. When the plugin does not expose an editor for a column, SleekView falls back to a direct write on the user-points table with optimistic-lock checks against the row's updated_at so two admins can not silently overwrite each other.

A loyalty program only works if the team running it can answer questions about it without filing a developer ticket. Which customers are 50 points away from claiming a reward, so an email nudge converts them. Which long-time spenders have not engaged in 90 days, so retention can intervene.

How many points did the recent signup bonus push actually issue, and to whom. WooCommerce Rewards Points collects the raw data correctly in its own custom tables, but its default admin presents balances and event logs on separate screens, which forces the loyalty team into copy-paste workflows or ad-hoc SQL. SleekView joins the points table with the ledger and the customer record into one grid, where a single sort or filter answers each of those questions.

The plugin keeps doing what it does well, and the operators get a surface that matches how they actually think: per-customer, with current state and recent behavior on one row, segmentable on the spot.