The Suggestions module
A suggestion box is less about finding good ideas than about showing the bad ones were considered. The module frames the whole cycle: submission, vote, decision, and answer.
Updated 12 September 2026
The life of a suggestion
- Submission: the member proposes their idea, by command or from a submission block placed in a channel.
- Publication: the suggestion is posted in the designated channel, with voting buttons.
- Voting: members weigh in. The result does not bind staff — it only tells them what the community thinks.
- Decision: staff accept, refuse or hold, with a reason. That step is where the module’s entire value sits.
A suggestion refused without a reason does more harm than having no suggestion box at all: it proves the opinion was asked for as a formality.
Category mode
The submission block can offer categories — channels, events, rules, technical. Two gains: the person thinks about what they are asking, and after three months you see what the demand is really about.
Three to five categories are enough. Beyond that, the choice is made at random and the statistic stops meaning anything.
Destination and voting
The destination decides who sees what. A public channel for open suggestions, a staff channel for internal matters: that stops a sensitive proposal going to public debate before staff have discussed it.
The voting mode is configurable: for and against, or for only. Removing the downvote changes a suggestion channel’s atmosphere more than any other setting — an anonymous “against” reads as an attack, where an absence of “for” does not.
Closing votes and post-decision
Closing votes stops the count at the decision. Without it, a settled suggestion keeps accumulating votes and suggests the decision might still change.
The post-decision setting determines what happens to the message: it stays with its label (accepted, refused), it moves to an archive channel, or the buttons disappear. Archiving is the most useful: the next suggestion can be refused with a link to the one already handled.
Auto-rejection
Auto-rejection closes suggestions left undecided after a set time, or that fail to reach a minimum number of votes.
This is not a convenience for staff: it is what stops the channel filling with dead suggestions. A channel where the last thirty proposals went unanswered discourages the thirty-first.
Key points
- A decision without a reason is worse than no suggestion box.
- Three to five categories: beyond that, the choice is random.
- Removing the downvote changes the atmosphere more than any other setting.
- Close votes at the decision, or the count implies it can still change.
- Auto-rejection stops the channel filling with dead suggestions.
Frequently asked questions
Do you have to follow the vote?
No, and it is better said in advance. The vote informs staff, it does not decide for them. What is resented is not a well-voted suggestion being refused, it is being refused without explanation.
Can the author be stopped from voting for their own suggestion?
It is a module setting. On a server where vote counts trigger something, disabling it avoids mechanical self-promotion.
What happens to handled suggestions?
Per the “post-decision” setting: they stay with their label, move to an archive channel, or lose their buttons. Archiving lets you point at a decision already made instead of re-explaining it.
Put this guide into practice
Kuratos sets up in minutes what this guide describes, and is configured from a web interface rather than through commands.