Running a giveaway on Discord

Decide what the giveaway is meant to produce

Before the prize, before the date, answer one question: what should this giveaway achieve? The answers lead to different settings.

• Reward your regulars → strict conditions, modest prize, internal communication only.
• Wake a sleepy server → moderate conditions, prize tied to your subject, announced on a notification role.
• Attract new members → the hardest, and the one that almost always disappoints. With no conditions you get disposable accounts; with conditions, newcomers cannot enter. You then have to accept the giveaway is a shop window, not recruitment.

The prize: what works and what does not

A prize unrelated to your server attracts people unrelated to your server. It is mechanical, and it is why so many giveaways leave a sour taste: the winner did not even know the subject.

A prize tied to your subject — a game key on a gaming server, an access, an item from your internal economy — filters naturally, with no rule needed.

A prize you do not yet own is a promise. Buy it, or have it in hand, before announcing: a giveaway whose prize never arrives costs more in reputation than ten successful ones earn.

Entry conditions

Three conditions cover nearly every need. They stack, and that is where restraint is needed.

• A required role — to reserve the giveaway for boosters, subscribers, or simply verified members.
• A minimum Discord account age, in days. Mind the meaning: it is the ACCOUNT’s age, not seniority on your server. It screens out accounts created for the occasion, not yesterday’s visitors.
• A minimum level, if you run a levelling system. By far the best condition: a level can only be obtained by actually taking part on YOUR server. A patient account can wait thirty days; it cannot fake a conversation.

Do not stack all three. Conditions that are too strict cut entries to the point where the giveaway is pointless — and a giveaway with four entrants is more demoralising than none at all.

Several winners rather than one

If the prize is divisible — three keys, several accesses, internal currency — draw several winners. Three winners out of a hundred entrants means three happy people and ninety-seven disappointed; one winner means one happy and ninety-nine disappointed, for the same spend.

Some systems also allow a different prize per rank: the first drawn gets the main prize, the others something smaller. It is the most effective way to drive entries without promising everyone the moon.

The delicate moment: the winner does not answer

It is the most frequent case, and the one nobody plans for. The draw names someone who has not been online for three days, and the giveaway hangs.

The remedy is one sentence, written in the announcement and not after the draw: “the winner has 48 hours to come forward, otherwise a new draw will be held”.

Announced in advance, that rule is accepted by everyone. Announced afterwards, it looks like an arrangement made to fit, and that kind of episode is what loses a server’s trust.

After the draw

• Announce publicly and mention the winner: transparency is what makes the next giveaway credible.
• Do not delete the original message. It is the record of the conditions announced if anyone disputes them.
• If the prize is a role, check before launching that the bot role sits above it: otherwise the grant fails at the worst moment, in front of everyone.
• Say what the winner received once handed over. A giveaway whose conclusion is never seen looks rigged, even when it is not.

How Kuratos helps

The Giveaways module handles the whole cycle: entry by button or reaction, required role, minimum account age, minimum level, multiple winners with a prize per rank, and rerolls when the winner does not come forward.

The deadline is stored in the database, not in memory: a bot restart or an update does not skip the draw, which is caught up on the next start.

An item from your internal shop can also act as an entry ticket, consumed on entry — tying the giveaway to the server’s economy instead of making it a separate event.