Benchmark Email Lite is a connector plugin: the real subscriber data lives in Benchmark's hosted account, while the WordPress side keeps API credentials and list mappings in wp_options (typical option keys like bmesp_options and bmesp_list_data) plus per-form metadata on the signup post. There's no custom subscribers table, because the canonical list is in Benchmark.

That setup is fine for sending data out, but auditing it inside WordPress is awkward. The default screens show one form at a time; they don't surface the cross-form question of "which signups failed to push to Benchmark this week and why". Last-sync timestamps and API error logs are scattered across option blobs that aren't designed to be browsed.

SleekView reads the option keys and form postmeta, then renders them as proper tables: every signup with its mapped list, last push status, and most recent API response. Re-pushing a failed signup is an inline action that calls the plugin's own send routine, so it stays consistent with what Benchmark Email Lite would do on its own.

Benchmark Email Lite is designed as a bridge, not a CRM. That is the right architecture: the canonical list lives in Benchmark, and the plugin's job is to push WordPress signups across the API cleanly. The honest tradeoff is that the WordPress side has very little visible state.

A couple of option blobs, some form postmeta, an internal log, and that is it. The default settings screens reflect that minimalism. They show one form at a time and surface very little of the cross-form, cross-list picture that operators actually need when something goes wrong.

SleekView does not invent infrastructure on top of the connector. It reads the option keys and postmeta the plugin already writes, joins them into a real table, and lets retry actions call the plugin's own push code. That turns a near-invisible bridge into an auditable one, which matters when newsletter signups silently stop flowing on a Friday afternoon.