The Klaviyo for WooCommerce plugin owns three things in WordPress: the public key, email and SMS consent strings, and the sync state with the Klaviyo cloud. They live as a serialized array in wp_options under klaviyo_settings, with sync timestamps and webhook health flags written alongside on each round trip with the cloud.

The default Klaviyo settings page renders those across separate Settings, SMS and Sync tabs, sized for configuring one store at a time. On a multisite network with regional stores, an agency with twelve client sites or any site running through a staging-then-production flow, that per-store layout becomes the bottleneck. A question like "which stores still have SMS consent off" requires opening every settings page individually.

SleekView reads klaviyo_settings on every blog and pivots the array into columns. Public key prefix (which encodes the data center), email and SMS consent flags, last sync age and webhook health sit as real columns. Sort by sync age to find broken integrations, filter to mismatched data centers to catch a staging-key-in-prod mistake, bulk-flip a consent flag across multiple stores in one pass.

Klaviyo's WordPress plugin is correctly architected as a thin bridge. The trade-off is that the few things it does store, consent strings, public key, sync timestamps, webhook health, are exactly the things audits care about, and the per-store settings page never aggregates them. On a multisite network with regional stores, an agency portfolio or a staging-to-production flow, that per-store layout becomes the bottleneck.

SleekView treats klaviyo_settings as a dataset and renders the network-wide state as one table, so privacy ops sees consent coverage, marketing sees sync health and support sees broken integrations as the top rows. Same data the plugin already writes, organised as a list instead of a tab tour.