No. SleekView Feedback reads directly from the SureCart bump post type and the offer stats table. You point it at the source, pick the columns for votes, status, category, and title, and the board renders. No ETL job, no sync, no duplicated data. Anything SureCart writes shows up next page load.

Yes. SleekView ships with anonymous voting backed by cookies, so customers can vote on a public roadmap without an account. You can also restrict voting to logged in paying customers so the score reflects real buyers, and the same view supports both modes with a single toggle on the block.

Each visitor gets a cookie scoped vote token per item. Logged in WordPress users are tracked by user ID, so even if they switch devices they only count once per item. The plugin also exposes a per IP rate limit so a single network cannot brigade the experiments backlog with synthetic votes.

Yes. SleekView accepts a WHERE clause when you wire up the data source, so you can scope the board to one funnel, one product, one experiment window, or any combination of meta fields SureCart Bumps already stores. Different boards on different pages can use different filters.

Bug is just a category value on the row. You can write it into a meta key SureCart already understands or a dedicated column. Either way it shows up in the WordPress admin alongside the original bump record, so the developer who built the offer can see the flag without ever leaving WordPress.

They write back to the source column, which means SureCart Bumps and any of your own queries can sort future experiments by score. Several CRO teams use the score to gate which bumps reach A B testing, which makes the board operational instead of a vanity roadmap that nobody actually reads.

Both. SleekView ships as a Gutenberg block, an Elementor widget, a Bricks element, and a classic shortcode. Theme developers can also call the render function from PHP and pass a configuration array, so you can mount the experiments board inside your existing CRO dashboard layout.

The view paginates server side and only loads the rows it needs for the current page. Indexed columns stay fast even on long experiment tables. For really big programs, scoping the board by funnel or product keeps both the query and the audience focused, so the page feels snappy at full scale.