Feature Requests & Voting gathers customer ideas and votes directly on your PrestaShop product pages. Installation adds the request tab, product boards and settings; enabling the module starts the collection.
Ideas scattered across email, chat and reviews are difficult to count. A request attached to its product keeps the buying context, while votes distinguish widely supported improvements from an isolated suggestion.
You decide whether submissions require login, approve new requests and control guest voting. Each customer votes once per request. Statuses and staff replies show progress, and merging duplicate requests preserves their votes. The same records serve product tabs, product boards and the store roadmap.
Your next product decision starts with a visible count of customer requests, instead of reconstructing demand from remembered support conversations.
Feature Requests & Voting turns feature wishes into a measurable, product-linked roadmap inside a PrestaShop store.
On the product page, at the exact moment they notice what is missing. The request travels with the product it concerns, so "please add a longer cable option" is never a loose note; it is a counted wish attached to one item in your catalogue. Voting sits beside it: one press, one vote per customer, with guest votes deduplicated.
The same records surface three ways without extra work: the tab on each product, a full board for that product, and a store-wide roadmap where all requests meet, searchable and grouped by status. The consequence is that demand stops being anecdotes. The capability with forty votes and the one with two are finally different sizes.
You decide, with switches. Submissions open to every visitor or only to signed-in customers. New requests wait in your approval queue and stay hidden until you release them, so spam and duplicates never reach the public board. Voting is enabled or disabled as a whole, guest voting is its own decision, and each customer votes once per request.
Display is governed the same way: vote counts, status badges and staff responses each appear only if you switch them on. A young store shows requests without counts until numbers look convincing; an established store shows everything.
It gets a life cycle: submitted, under review, planned, in progress, implemented, each shown as a badge the customer understands. A discussion runs under every request, where customers add detail and your team answers publicly, so the reasoning stays next to the wish. When two people ask for the same thing in different words, you merge the duplicates into one request and every vote is preserved.
Visible progress can encourage retention: a customer who sees "planned" on their wish may stay engaged, while one who sees "implemented" may return to buy. An idea board that answers is a reason to return; a silent inbox is not.
This one does, deliberately. Request pages have friendly addresses in every store language, correct canonical behaviour and clean pagination. The public hub takes part in search and in the sitemap when you allow it, while detail and filtered pages deliberately stay out, so the store gains one strong indexed hub instead of a thousand thin pages. A request address opened in the wrong language redirects to the right one.
So the person searching for exactly the capability you are building lands on your roadmap, one link away from the product that will have it. If you allow indexing, the public hub can appear in search results and be included in the sitemap.
The dashboard shows the workload per shop: totals, recent requests, the most voted ideas and the status breakdown. The request grid filters by product, status and votes, changes statuses in bulk, and carries a private note per request. An email notifies you when a new request arrives, at the address you choose.
Everything stays inside the store: pages inherit your theme automatically, only local files are served to shoppers, each request belongs to its shop and language in a multistore, and the public responses carry no customer email, no address, no identity. Your customers’ demand data is yours.
Requires PrestaShop 1.6 or later and PHP 7.1 or later.
30 days return right
Plug & Play Modules
Dedicated Support First
Built and maintained by David Miller and mypresta.rocks. David Miller has worked with PrestaShop since 2013, and the company behind this shop has been registered since 3 December 2018. Every module in this catalogue is our own work, so your questions to support reach the people who wrote the code. The changelog on this page lists every update with its date.
Feature Requests & Voting collects ideas and votes on your product pages and lets you manage their status, and Issue Tracker shows known issues and their status in a product tab. Customers see what is planned and what is being fixed.
Feature Requests & Voting gives ideas a public place with votes and statuses, and Support Revolution keeps individual problems in private tickets. Product feedback and customer support each go to the right channel.
Knowledge Base documents how your products work today, and Feature Requests & Voting shows what customers want next. Documentation and roadmap side by side.
Compliance & Legal
News & Updates
News & Updates
News & Updates
News & Updates
News & Updates
