The Linnworks WP Connector pushes WooCommerce orders into Linnworks for fulfilment and pulls stock back. Its WP-side surface is a settings page and a log; the per-order routing state it writes to wp_postmeta on each shop_order (or wc_orders_meta under HPOS) is invisible to the standard Orders screen. When a push fails, you check the log and click into the offending order.

SleekView joins wc_orders (HPOS) or wp_posts with post_type=shop_order (legacy) against the Linnworks meta keys, plus the connector's channel and warehouse map cached in wp_options (linnworks_channel_map, linnworks_warehouse_map). Every order row shows its Linnworks order ID, push timestamp, target warehouse, and channel push status side by side.

Inline edits go through standard meta-update paths, and bulk re-push uses the connector's own do_action('linnworks_push_order', $order_id) hook. Mark a hundred stuck orders for re-push in one click; the connector picks them up on the next cron run and fires its existing retry logic.

Linnworks is the operational brain for many UK and EU multi-channel sellers, and the WP connector is the pipe that feeds it. The connector itself scales fine because it writes a few meta keys per order and reads a small options cache. The pain is operational: the WP Orders screen treats every order the same, regardless of routing state, so a failed push to Amazon looks identical to a paid web order until you open it.

Warehouse leads end up keeping a parallel spreadsheet of "orders we pushed but didn't confirm", which drifts within hours. SleekView removes that side-channel by making the routing state a first-class part of the order row: channel, warehouse, Linnworks ID, push timestamp, all in one filterable view. Channel managers spot per-marketplace problems faster, fulfilment teams trust the picking queue, and support can answer "where is my order" without paging through a log.

None of this requires changes to the connector, it reads what's already there.