WooCommerce Advanced Shipment Tracking attaches a serialized array of shipments to each order through the _wc_shipment_tracking_items meta key. Each entry stores provider slug, tracking number, ship date and an optional tracking URL. The default surface shows that array as a tracking pill on the single order edit screen, which is right for confirming one shipment and wrong for asking how many DHL labels went out today or which orders shipped without a tracking number.

SleekView reads the tracking meta, normalises the serialized array into one row per shipment and joins back to wc_orders for status, customer and date_paid. Filter to today's DHL shipments to confirm a courier pickup happened. Filter to shipments with a derived hours_to_ship over 48 to triage slow fulfilment. Sort by ship date to assemble a daily dispatch log. The same data the chart view aggregates becomes a row-level surface for ops, customer service and finance.

The plugin keeps owning courier integrations and customer notification emails. The table view owns the audit surface, so the tracking records the plugin already writes stop hiding inside individual orders.

Shipment data is the most operational dataset a Woo store produces, and Advanced Shipment Tracking writes it consistently on every shipped order. The plugin's surface for that data is the tracking pill on the single order edit screen, which is right for one order and wrong for almost everything fulfilment, customer service and finance actually do with shipment data. SleekView reads the same _wc_shipment_tracking_items meta and normalises it into one row per shipment with provider, tracking number, ship date and hours-to-ship.

Filters stack into a single query so the daily dispatch log, the SLA-breach triage and the courier-invoice reconciliation become one-click views. The plugin keeps owning courier integrations and notification emails, while the team gets the per-row surface the dataset always deserved.