No. SleekView reads what your WordPress database already holds: captured leads, SSO mapping rows, synced rows where a sync layer writes them, and webhook records. Without a sync layer, full ticket history stays in the Kayako app.

Plugin configuration in wp_options, plus SSO mapping data when single sign-on is enabled. Captured leads depend on which form integration captures them, sometimes a custom table, sometimes postmeta, sometimes a direct pipe to Kayako without a WP record.

Yes. Select rows, change status inline, and the write goes through whichever API bridge or webhook listener your stack uses to propagate WP changes to Kayako. Without a bridge, the change stays on the WP row and the sync layer handles the round trip.

Only if your stack has an API bridge or webhook listener that propagates WP changes to Kayako. Without that, edits stay local to the WordPress row, which is still useful for marketing and sales workflows that never need to round-trip into the helpdesk.

No. SleekView is admin-side only. It does not enqueue scripts on the public site or intercept page requests. The Kayako messenger loads exactly as it always does, with no performance impact.

Yes. Table, kanban, and charts layouts read from the same source. Switching between them is a layout toggle, not a data migration, so a filter set saved at the source applies wherever you view it.

Yes. Any saved view exports to CSV directly from the table header, with the columns and filters intact. Useful for handing data to a non-WP stakeholder, monthly reporting, or pulling chat-lead data into a spreadsheet for ad-hoc analysis.

Yes. Saved views are gated by capability so marketing sees source-page columns, sales sees priority and assignee, and reporting roles get a read-only view of the same source. Editing rights remain tied to existing role caps.