No. Crisp keeps conversations entirely in their cloud — that's a deliberate design choice, and SleekView respects it. SleekView only reads what's actually written to your WordPress database. If your team needs conversation data in WP, you'd need a sync layer using Crisp's API to pull transcripts, and SleekView would then tabulate whatever that layer writes locally. The boundary is clean and predictable.

Plugin configuration as wp_options rows, and on some setups, webhook payloads or captured leads written to custom tables or postmeta by integrations. Schema varies — MagicReply hooks, pre-chat survey integrations, and third-party webhook handlers each write differently. SleekView lets you point at any of them and surface the columns inside, without assuming a single schema.

No. SleekView edits WordPress data only — that's intentional and keeps the data ownership clear. Pushing changes to Crisp's segments, conversation tags, or visitor properties requires their API and a sync layer (Zapier, Make, or custom code). Many teams find they only need WP-side edits for the records SleekView surfaces, since the cloud-side data is already managed in the Crisp app.

No. SleekView is admin-side only. It doesn't enqueue scripts on the public site, doesn't touch the embed code, and doesn't intercept page requests. The chat widget loads from Crisp's CDN exactly as it always does, with no performance impact and no behaviour change. You can install and configure SleekView without anyone outside the WP admin noticing.

Yes. Any saved view exports to CSV directly from the table header with the columns and filters you've configured. Useful for handing data to non-WP stakeholders, monthly reporting, or feeding records into a spreadsheet for analysis. The export is one click and includes the same fields visible in the table — what you see is what you export.

MagicReply automations and Crisp segments are managed in the Crisp app — that's where the AI training, segment definitions, and campaign rules live. SleekView only mirrors what arrives in WP, which is typically segment tags written to webhook payloads or lead captures. If your MagicReply flow writes outcomes to a WP webhook, those become a column. The cloud-side configuration stays cloud-side.

If you've enabled the contact sync feature, those user records sit in wp_users with metadata in wp_usermeta. SleekView can build a users-view scoped to Crisp-synced contacts with the relevant metadata as columns. Useful for spotting orphaned syncs (Crisp contact exists, no WP user) or duplicates (same email, multiple records).

If your store runs WooCommerce and you have lead emails captured locally, yes. Add a joined column counting orders per email or summing order total. A view filtered to leads-without-orders sorted by capture date oldest-first surfaces stale leads worth a follow-up; the inverse view surfaces recent converters worth segmenting in Crisp for upsell campaigns.