Drift's WordPress plugin is a thin embed: it injects the Drift JavaScript snippet using a Drift Org ID stored in wp_options under the drift_settings key, plus a small set of page-targeting rules. The actual conversations, contacts, and playbooks live in Drift's SaaS app. That keeps the WordPress footprint small, but it also means the only UI on the WP side is a single settings screen with no history of which pages have the widget enabled, no log of when the Org ID was last rotated, and no inline edit for path-based show/hide rules.

SleekView reads wp_options directly, expands serialized Drift configuration arrays into one row per rule, and treats each show/hide pattern as a first-class record. Saved views like Pages where Drift is hidden or Recently changed targeting rules give marketing and revenue ops a real audit surface, and inline edits flip a rule on or off without round-tripping through the plugin's tabbed settings panel.

Edits go through update_option() so the standard WordPress settings hooks fire and any caching layer flushes the embed footprint as expected. Because Drift's real data (conversations, leads, deal stages) lives outside WordPress, SleekView focuses on what WP actually stores: the embed configuration, the targeting ruleset, and the option-change audit trail.

Drift's WordPress plugin is intentionally thin: a snippet loader, a settings screen, and a serialized option holding the targeting ruleset. That keeps the footprint small, but it also means that as soon as more than two people start editing the configuration, nobody can answer simple questions like which pages currently hide the widget or who paused the pricing-page rule last quarter. The settings screen is built for the first-time setup, not for ongoing operations.

Most teams paper over this with documentation in a separate wiki, which immediately falls out of sync. SleekView solves the structural problem by treating the serialized option as a real table. Each targeting rule becomes a row, each setting becomes a column, and every change goes through standard WordPress option hooks so the existing audit-log plugin (if there is one) captures the history.

The result is the same Drift snippet on the frontend, the same SaaS conversations in Drift's app, but a WordPress admin surface that can actually be reviewed and operated by a team rather than reverse-engineered every time someone asks why the widget vanished from the checkout page.