WooCommerce Blocks ships the Cart and Checkout Blocks as block editor versions of the standard WooCommerce cart and checkout pages. The orders they produce live in wp_posts or in the HPOS wp_wc_orders table with statuses prefixed with wc- like every other WooCommerce order, plus standard postmeta for the billing details, the line items, the payment method, and the order total. The native orders screen lists them mixed with shortcode-based checkout orders.

SleekView Kanban reads the same WooCommerce orders you would query with WC_Order. Pick post_status as the group column and every order becomes a card slotted under Processing, On Hold, Completed, or Refunded. Filters can scope the board to Blocks-based checkout orders only based on a source meta key, or simply show all orders if the merchant wants to see the whole funnel together. Card fronts show the customer name, the order total, the payment method, and the date placed.

Dragging a card between columns calls the standard WooCommerce status transition the admin uses, which fires woocommerce_order_status_changed. WooCommerce hooks fire normally, the customer notification email goes out through the WooCommerce email module, and stock reductions and refunds fire as expected, exactly as they would after a manual update from the order admin screen by a shop manager during fulfillment work in the daily queue.

Stores migrating from the shortcode-based WooCommerce cart and checkout to the new Cart and Checkout Blocks need a way to see how the new funnel is performing without losing visibility into the legacy orders that still come through shortcode pages. The default WooCommerce orders screen mixes them all together, which means the conversion team cannot easily compare the two funnels and the support team cannot tell which checkout flow a customer used when they call about an issue. The disconnect between the migration the team is leading and the screen the team has shows up in the worst places.

A Blocks checkout bug quietly drops conversion on a single product and nobody notices until weekly revenue review. A Blocks-specific edge case causes refunds to spike on a single payment method and the pattern stays hidden until finance notices in the monthly reconciliation. A kanban view that reads and writes the same WooCommerce orders the team already uses, filtered by source, keeps the team and the funnel honest during the migration period.

Every drag is a real status change, every column count reflects the real Blocks health, and the cards themselves carry enough context for a marketing analyst to spot a Blocks funnel issue on day one of the migration window.