Weight-based shipping plugins encode their logic as a list of rules: if cart weight is between X and Y kg, charge Z. The plugin stores those rules either as a serialized array under a key like wbs_method__rules in wp_options, or in a dedicated rules table. Either way, the default admin shows one rule list per method instance, which means auditing rules across zones requires opening every method page in turn.

SleekView reads the rule source directly and joins it to wp_woocommerce_shipping_zone_methods so every rule shows zone, method name, weight band, condition, and cost in one table. Filter rules with overlapping bands. Sort by cost-per-kilo to find the rule that prices freight customers out. Compare every 0 to 1 kg band across zones to see where domestic shipping has drifted out of line with international.

Inline edits write back through whatever path the plugin exposes, falling back to a direct update_option with the same cache invalidation hooks. Bulk-update weight bands after a courier weight-tier change in one pass instead of editing each method's rule list by hand.

Weight-based shipping is one of those features that quietly scales into a problem. A store starts with three weight bands per zone and ends up with twelve bands across nine zones after a year of courier renegotiations. The plugin's storage choice (serialized rules per method) is reasonable.

The UI's choice (one rule list per method page) means nobody can audit the matrix without opening every method in turn. Overlapping bands stay hidden until a customer hits the cheaper one. Missing bands at the heavy end stay invisible until a freight customer gets accidental free shipping.

Cost-per-kilo drift between zones is impossible to see without a spreadsheet export. SleekView turns the same rule data into a real table: every rule a row, joined to its zone and method, sortable by any column. Audits become sorts, gap analysis becomes a filter, courier renegotiations become a bulk action.