Shipping classes are a clean WooCommerce idea: tag products as heavy, fragile, or oversized, then charge differently per class. The execution is split across two screens that never share a table. Classes are managed as taxonomy terms under product_shipping_class; per-class costs live inside each flat-rate method's instance settings in wp_options. There is no single list that shows class, method, and cost together.

SleekView joins them. The product_shipping_class taxonomy gives you the term list (slug, name, description, count). Each shipping zone method's instance settings carries the per-class cost as a setting key. Joining the two produces a real audit table: zone, method, class, cost, last-updated. Filter to find every method missing a fragile-class rate. Sort to find the class that costs the most internationally.

Inline edits write back through the same path the WooCommerce method settings UI uses so cache invalidation and shipping-recalc hooks still fire. Update a class cost across a dozen zones in one pass instead of editing twelve method pages.

Shipping classes solve a real problem: products are not uniform, and a freight-class catalog needs class-aware costs. The execution splits the data: classes live as taxonomy terms, costs live inside each method's serialized settings, and the relationship between them only exists at calculation time. That means missing rates are invisible until a customer hits them, renaming a class can break references silently, and auditing a catalog before a market launch is a tour of every flat-rate method page.

SleekView treats the class-rate matrix as a real table. Each row joins a class to a method instance and surfaces the cost. Filters find the missing rates before they become refund requests.

Bulk edits update many methods after a single courier renegotiation. The data has always been there; it just needed a list view to be useful to ops, finance, and support.