WooCommerce Product Recommendations stores each recommendation rule as a custom post with post_status values like draft, publish, and private, plus meta fields for placement (product page, cart, checkout, thank-you), the source query (related, cross-sell, upsell, frequently bought together, viewed together), and the result limit. The admin list is a long flat table that gives you the rule title and not much else, so the team running merchandising experiments has to click into each engine to find out what it does.

SleekView Kanban reads the same recommendation rules through the WordPress REST endpoints, pulls the placement and source meta with each row, and turns the post status column into the natural grouping axis. Each card shows the rule title, the placement, the source query, the click count, and the revenue attribution if you have analytics linked. Columns mirror the recommendation post statuses, so a glance tells you what is drafted, what is live, and what is paused.

Drag a card from Draft to Published and SleekView writes through the WordPress REST endpoints, firing the publish hooks the recommendations plugin uses to refresh placement caches. Drag to Paused (a custom status the team can register) and the rule stops serving without losing its meta. Merchandising experiments finally have a board that respects the way recommendation engines actually get built and tested.

WooCommerce Product Recommendations is genuinely one of the highest-leverage merchandising tools in a WooCommerce store, because the right cross-sell at the right placement can lift average order value by double digits. Building and testing those rules, though, is editorial work. Drafting, reviewing, publishing, measuring, and pausing or archiving when something stops working.

The default WooCommerce admin treats recommendation rules like any other custom post, so the workflow lives across multiple tabs and clicks: open a rule to see its placement, open the analytics to see its performance, open the admin to publish or unpublish. The board view fixes this by treating recommendations as the editorial pipeline they actually are. Status is the primary axis, click count and attributed revenue live on the card, and a drag is the natural way to move a rule from Draft to Published or from Published to Paused.

Writes go through the WordPress REST endpoints so the recommendations plugin's placement cache refreshes cleanly, and the team finally has a single screen where the whole recommendation pipeline is legible.