WooCommerce Table Rate Shipping stores zones in woocommerce_shipping_zones, methods in woocommerce_shipping_zone_methods and the rules within each method's settings rows. At checkout the engine resolves a rate for the cart and writes the chosen method instance to the order. The plugin's UI is built for configuring rules, not auditing outcomes, so questions like which rule fired most often or which zone produced the most shipping revenue require zone-by-zone clicking.

SleekView reads the order_items table for the shipping line, joins to woocommerce_shipping_zone_methods for method title and to woocommerce_shipping_zones for zone name, and renders one row per order shipping line. Filter to Europe zone shipments to triage a rate complaint by region. Sort by shipping_total descending to surface the highest-margin rules. Group rows by method instance to rank rule popularity. The data the chart view aggregates becomes a row-level surface for shipping ops, finance and merchandising.

The plugin keeps owning the rate engine and configuration UI. The table view owns the audit surface so rule outcomes become something a team can review row by row instead of inferring from zone settings.

Table rate shipping is one of the most expensive corners of a Woo configuration to get wrong, and yet the management surface still treats it as a configuration screen rather than an outcomes screen. Rules accumulate over years; nobody on the team can confidently say which are firing and which are dead. SleekView reads the order_items shipping lines joined with the zone and method tables and renders one row per order.

The plugin's configuration UI stays the configuration UI. The audit table answers the operational questions (which rule fired here, what did we charge, which zone is doing the work) without anyone having to memorise zone IDs or open orders one at a time.