Intercom's messenger and inbox live in its own product, but most WordPress teams sync a copy of conversations and contacts back into WordPress to join with WooCommerce, EDD, or CRM data. Depending on the connector, that synced data sits either in a custom post type (commonly intercom_conversation) with field meta in wp_postmeta, or in dedicated connector tables.

SleekView reads whichever schema your connector uses, joins conversations to WordPress users or WooCommerce customers by email or user ID, and exposes state, assignee, team, tags, and any synced contact attribute as first-class columns. Build a view of open conversations from high-LTV WooCommerce customers, save a per-team queue with state and tag filters, or pivot by assignee to balance workload across the support team.

Edits push through the connector's API where two-way sync is supported. Where the connector is read-only, SleekView marks those columns clearly and links back to Intercom for source of truth, which keeps the WordPress view honest about what it can and can't change.

Intercom's messenger drives a lot of inbound for WordPress-driven products, and the resulting conversations carry context that customer success teams want to read alongside commerce data. The customer database stays in WordPress for most teams: WooCommerce orders, EDD downloads, CRM segments, subscription state. The synced copy of Intercom conversations on the WP side is only half the picture without easy joins to that commerce context.

The default WP connector lists conversations in a fixed table, and pairing them with WooCommerce customers means switching screens and copy-pasting emails. A real pivot view changes that. Conversations and WP customer data sit in the same table joined on email or user ID, with both sides exposed as columns and filters.

VIP queues, churn-risk views, and per-team queues become saved views rather than spreadsheet exercises. Where the connector supports write-back, inline edits push to Intercom. Where it doesn't, SleekView stays transparent about it.

The result is a WP-side support surface that uses WordPress's customer data without dragging Intercom out of where it does its best work.