Distance-rate shipping plugins do something powerful: they ask a maps API for the distance between the store and the customer, then look up a cost from a list of distance bands. The configuration is also where they get hard to audit. Bands per method live either in a custom rules table (often woocommerce_distance_rate_rules or similar) or inside the method's instance settings in wp_options. Cross-method audits are not part of the default admin.

SleekView reads the rules source directly and joins it to wp_woocommerce_shipping_zone_methods. Every rule shows zone, method, distance band, cost, and origin address in one table. Filter to rules that have not been updated since the last courier rate review. Sort by cost-per-kilometre to find rules priced out of margin. Compare every 0 to 10 km band across multi-store setups to keep delivery pricing consistent.

Inline edits route through the plugin's own save logic where exposed, with a fallback to direct table writes plus the same cache-clear hooks. Update twenty distance bands after a courier renegotiation in one pass instead of touring every method page.

Distance-rate shipping is a natural fit for stores with local delivery, multi-hub fulfilment, or zone-based courier contracts. The plugin's storage choice (a rules table with one row per band) is right. The UI's choice (one rule list per method page, edited in isolation) is what creates the operational debt.

Auditing every hub's bands before a driver rate change is a multi-screen tour. Missing upper bounds quietly give free delivery to long-haul orders. Misaligned bands between two hubs produce inconsistent pricing for customers right on the boundary.

SleekView turns the same rule data into a real table: every rule a row, joined to its zone, method, and origin, sortable by any column. Bulk updates after a courier renegotiation become an action instead of a script, and multi-hub audits become a filter instead of a spreadsheet.