No. Conversation volume, Lyro AI resolution rate and agent workload stay inside the Tidio panel, which is the right tool for those views. SleekView only renders the WordPress-side surface: widget coverage, exclusions, captured leads and any local webhook event records.

WordPress-native rows: the Tidio plugin's wp_options entries, any postmeta used for per-page overrides, the form plugin's submissions table for captures routed to Tidio and a webhook log table if the site stores one. No Tidio API call is required for these cards.

SleekView resolves the plugin's enable and exclusion rules into a per-URL flag column. Group by that column in a Number or Pie card to see total Tidio-enabled pages and the split across post types or exclusion reasons in a single card.

Yes. Each form plugin stores submissions in its own table. Add each table as a dataset and group by form_id or a normalised source column to build a single Bar card spanning Gravity Forms, WPForms, Forminator, Fluent Forms and any database-extended Contact Form 7 setup.

Then the webhook-events Area card simply has no data. The other three cards (embed total, exclusion pie, captures per form) still work entirely from settings and form rows. Adding a small custom logger is the usual next step if webhook visibility matters.

Queries hit standard WordPress indexes on options, postmeta and form submissions. Filters and sorts use indexed columns where possible, and expensive resolutions like per-URL embed flags are cached per page-load, so default dashboards stay quick even on installs with high traffic.

Yes. Every SleekView dashboard is gated by WordPress capability, so a marketing-facing Tidio dashboard can be limited to marketing and support roles while developers see a separate, more technical view with raw event logs and override meta.

Yes. The plugin that embeds the Tidio widget stores its public key and visibility rules as standard WordPress options. SleekView reads those options without needing a paid Tidio plan to render the WordPress-side charts.