The Simple Feature Requests alternative built on your real WordPress posts
Simple Feature Requests stores ideas and votes in its own custom post type and plugin tables. SleekView reads any CPT you point it at, renders upvotes as a meta field on the post, and gives the same data a kanban and table view too.
♾️ Lifetime License available
Feature requests as a view, not a separate plugin app
Simple Feature Requests is a long-running WordPress plugin for collecting product feedback. It ships a self-contained idea board with voting, statuses (Pending, Planned, Completed), and an admin area for triage. The free version covers the basics, with a Pro upgrade for private boards and additional roles. The plugin handles the full feedback workflow inside wp-admin, which is part of its appeal for sites that want a one-click public roadmap.
SleekView is shaped differently. The feedback board is one of three view types over a CPT (alongside tables and kanban), so an idea is just a post in whichever CPT the site already uses. ACF or Meta Box fields drive the card content, a status field drives filtering and grouping, and upvotes live as a meta field on the post. There is no parallel ideas table, because there is nothing to store separately from the posts.
The trade-off is honest. Simple Feature Requests is a focused feedback plugin with a working board out of the box; SleekView is a data-views plugin that becomes a feedback board when pointed at the right CPT. For sites where the ideas need to surface anywhere else (a public roadmap page, an internal dashboard, a kanban for the team), the CPT-backed approach removes a layer of bridging. For sites that just want a feedback wall and nothing more, Simple Feature Requests is the simpler install.
Workflow
How a Simple Feature Requests board becomes a SleekView feedback view
Choose the CPT
Add the supporting fields
Configure the feedback view
Embed and add other views
Comparison
SleekView vs Simple Feature Requests at a glance
Differences
What changes when you move off Simple Feature Requests
The Simple Feature Requests way
- Ideas stored in a plugin-owned CPT with helper tables
- ACF and Meta Box fields are not first-class on cards
- Locked to a feedback-board shape, no kanban or table view
- Pro features (private boards, roles) are paywalled separately
- Reuse on the frontend usually means custom queries
The SleekView way
- Feedback board over any CPT, no parallel data store
- Upvotes live as a meta field on the post
- Same data also as kanban or table
- ACF and Meta Box fields render on cards directly
- Shortcode and block embed in any builder
Features
Three things that actually change how you work
Ideas are full WordPress posts
SleekView feedback cards are regular posts in a CPT of your choice, with slug, author, comments, and theme template fall-through. Anything else on the site that reads posts already sees the ideas, with no plugin-table integration code to write.
Upvotes on a meta field
The vote count is stored as a meta field on the post, with a separate ledger of which user voted. That count is queryable with WP_Query, visible to themes, and easy to reuse on a public roadmap page or internal dashboard.
Same data, three views
A SleekView CPT becomes a feedback board for users, a kanban grouped by status for the team, and a sortable table for reporting. One data set, three renderings, none of them duplicates.
Migration
Moving from Simple Feature Requests to SleekView
1. Define an idea CPT
Create or reuse a CPT for ideas, with ACF or Meta Box fields for description, area, and status. Add a vote-count meta field that SleekView's feedback board can read and update.
2. Export ideas and votes
Use Simple Feature Requests' export (or a custom WP-CLI script over its CPT and tables) to dump existing ideas, their statuses, and per-idea vote counts. Note any private or staff-only items separately.
3. Import into the new CPT
Bring the data into the new CPT via WP All Import or a similar tool, mapping each field one to one. Set initial vote counts as meta values; SleekView takes over the voting ledger from there.
4. Embed and decommission
Drop a SleekView feedback-board shortcode or block where the original board lived, group an admin kanban over the same CPT, and once verified, retire Simple Feature Requests.
Audience
Where teams move from Simple Feature Requests to SleekView
Public roadmap plus internal kanban
When the same ideas need a public board (with voting) and an internal kanban (grouped by status), SleekView ships both views over one CPT. Simple Feature Requests covers the public side but leaves the internal kanban to another tool.
Sites with ACF or Meta Box already in use
Teams that structure content with ACF or Meta Box can extend an idea CPT with the same fields they use elsewhere. SleekView reads those fields onto cards and filters; Simple Feature Requests works in its own field model.
Feedback as reportable data
When product or support needs to slice ideas by tag, area, or vote count in a table for weekly reviews, having the data as a CPT (queryable by WP_Query) beats reaching into plugin tables. SleekView's table view ships with that out of the box.
The bigger picture
Why feedback boards work better as a view over real data
Feedback plugins look interchangeable at first glance because the public board is the visible part: a list of cards with upvotes, a status badge, a few filters. The interesting differences are underneath. Simple Feature Requests, like most dedicated feedback plugins, treats the board as the product and stores ideas and votes in its own model.
That keeps the install simple and the UI predictable, but it puts a layer between the feedback data and the rest of WordPress. A top-voted idea is hard to surface on a public roadmap page without bridging code; a planned idea is hard to feed into an internal kanban without a second tool; a reportable list of all ideas by tag or area is hard to build without dropping into the plugin's tables. SleekView's contribution is to make the feedback board a rendering of CPT data, not its own product.
The ideas live as posts, the votes live as a meta field, the statuses live as a taxonomy or select. From there, the same data renders as a kanban for the team, a table for reporting, and a feedback wall for users, with no duplicate data set. The trade-off is real: SleekView does not ship as a feedback-management product (no NPS, no in-product messaging, no SaaS-style status email digests), so teams that want a turnkey feedback app may still prefer Simple Feature Requests or a SaaS tool.
For sites where the feedback data has a life beyond the board, the cards being posts is the choice that compounds over the years.
Questions
Common questions about switching from Simple Feature Requests
No. Simple Feature Requests is a focused feedback plugin with a free tier and a well-understood feature set. For sites that want a self-contained feedback wall and nothing more, it is a reasonable pick. SleekView is the better fit when the ideas should live as a CPT, with ACF or Meta Box fields, and possibly be rendered as a kanban or table for the team as well.
In a plugin-defined custom post type and helper tables for votes and user mappings. The CPT is visible to WP_Query, but the votes and other relational data sit in plugin tables that the rest of WordPress does not see without bridging code.
As regular posts in whichever CPT the view points at. The vote count is a meta field on the post, with a ledger of voter user IDs maintained separately to enforce one vote per user. Everything is queryable through standard WordPress tooling.
Yes. They do not share data or hooks. A site can keep Simple Feature Requests for an existing public board and add SleekView for new CPT-backed feedback boards. Most teams pick one over time to avoid two ways of doing the same thing.
Configurable per view. Many sites require login (which prevents most vote-stuffing and ties voting to WordPress user roles), but anonymous voting throttled by IP is also a supported option for public roadmaps that need a low-friction sign-up path.
As a status field on the CPT, typically an ACF select or a taxonomy. The feedback board uses it for filtering and badges; a kanban view over the same CPT uses it for grouping. Updating the status anywhere updates it everywhere, because there is one source of truth.
Yes, as initial meta values on the imported posts. SleekView treats the imported count as the starting number, then adds and subtracts from there as users vote inside the new board. The historical voter mapping does not migrate, but the visible totals do.
Yes. SleekView lets you choose which fields appear on each card and in what order, with control over labels and inline templates. For deeper customisation, the feedback view ships filters that the theme or a child plugin can hook into.
Pricing
More than 1000+
happy customers
Explore our flexible licensing options tailored to your needs. Upgrade your license anytime to access more features, or opt for a lifetime license for ongoing value, including lifetime updates and lifetime support. Our hassle-free upgrade process ensures that our platform can grow with you, starting from whichever plan you choose.
Lifetime ♾️
Most popular
EUR
once
- Unlimited websites
- Lifetime updates
- Lifetime support
...or get the Bundle Deal
and save €250 🎁
The Bundle (unlimited sites)
Pay once, own it forever
Elevate your WordPress site with our exclusive plugin bundle that includes all of our premium plugins in one package. Enjoy lifetime updates and lifetime support. Save significantly compared to buying plugins individually.
What’s included
-
SleekAI
-
SleekByte
-
SleekMotion
-
SleekPixel
-
SleekRank
-
SleekView
€749
Continue to checkout