Your first week moderating a Telegram group
A practical start for volunteer moderators: understand authority, write usable rules, handle difficult messages and introduce automation with a recovery plan.
You have volunteered to help run a Telegram community. The owner has made you an administrator, people keep asking where the instructions are, and a disagreement is getting personal. A bot might handle some repetitive work, but you still need to decide what belongs in the group, what your authority covers and what happens when you make a mistake.
Your first week can be modest. Learn to identify the problem, choose a proportionate response, target the right message or person and check the result. Add automation when you can explain the rule it will apply. A poorly chosen rule can be repeated very efficiently.
The schedule below is a suggested learning order, not a requirement to finish everything in seven days. Its situations are hypothetical and can be used for practice with the group owner.
Day one: establish the job and its boundaries
Ask the owner what the group is for and what decisions you can make. “Keep things friendly” does not resolve whether a member can post a paid job listing or criticize a project maintainer.
Get concrete answers:
- Which topics, links and kinds of self-promotion are allowed?
- Which incidents can you handle yourself, and which need another administrator?
- Who may change the bot configuration or rewrite a rule?
- Who reviews a decision when a member disagrees with you?
- Who covers the group when you are unavailable?
Keep three kinds of authority distinct. Telegram member permissions determine what members may send. Telegram administrator rights grant powers within the group. Defendy roles control access to bot actions. A role name in the Mini App does not replace a missing Telegram permission. Defendy roles and permissions.
In a test group, check that you can perform the limited actions you have agreed to handle and that someone can restore your helper's access. If an action is unavailable, ask for the specific authority needed. Giving every volunteer every available power is not a useful substitute for deciding who is responsible.
Even a two-person moderation team needs this agreement. Otherwise one person may approve a post, another may remove it, and a member may be punished for following contradictory instructions.
Day two: turn intentions into usable rules
A rule should help a reader decide whether a specific message belongs. “No spam” does not explain whether a member can link to a tutorial they wrote. “Be respectful” does not show where criticism of a proposal becomes an attack on a person.
For a hypothetical open-source user group, a starting version might read:
Use this group for project questions, troubleshooting and relevant resources. Tutorials and issue links are welcome. Unsolicited sales pitches and invitations to unrelated groups will be removed. Challenge ideas without insulting people. Do not publish another person's private information. If you think a moderation decision was mistaken, contact the moderator listed in the group description.
Adapt this example to the actual community. It is not a complete legal policy. Agree with the person before listing them as an appeals contact, and avoid promising response times the team cannot cover.
Pin the rules and check that a newcomer can find them. If you use Defendy's Rules section, configure the text and save its form; the existence of a settings page does not mean your policy has been published. Rules setup.
Resolve a few edge cases together. Can someone advertise paid support when another member explicitly asks for it? Are recruitment posts allowed in a designated place? How should a member report suspicious private messages? These answers prevent a moderator from having to invent policy while annoyed or under pressure.
Give blocked members a route that does not depend on posting inside the group. An explanation published after a ban may be invisible to the person who needs it most.
Day three: understand the available interventions
Some actions deal with a message. Others change a person's access. You can often remove one inappropriate post and explain why without adding a wider restriction. Continued harassment may require a stronger intervention.
| Action | Immediate purpose | Question before using it |
|---|---|---|
| Explain the rule | Make the expected behavior clear | Did the member know the rule and have a practical way to follow it? |
| Delete a message | Remove the specific publication | Have I selected the right message and preserved necessary review context? |
| Defendy warning | Add a point that can activate a threshold | What is the current counter and escalation policy? |
| Mute | Restrict posting | Who is affected, for how long, and who will check the result? |
| Kick or ban | Remove a member; a ban also blocks return | Is this proportionate, and do I understand history and recovery consequences? |
A conversational warning and /warn are different actions. “Please stop the personal comments” does not itself add Defendy points. The command does, and the existing threshold may trigger a restriction. Before issuing your first point, open Warnings and inspect the profile, thresholds, durations and reset behavior. How warnings work.
Treat a ban with particular care. Lifting it is not a promise to restore the entire previous situation or message history. Do not use a real member as a practice target. Preserve only the information needed for a review before a destructive action, without making unnecessary copies of personal data.
Practise three situations before the next difficult conversation
A newcomer posts in the wrong place
Hypothetical situation: a person shares a recruitment notice in a support-only group. If the rule was hard to find, point to it and explain the appropriate destination, if one actually exists. Remove the post when your policy calls for it. Decide on any additional response from the person's behavior and the policy, rather than treating a first misunderstanding as deliberate abuse.
In the test group, reply to a harmless practice message with /del. Confirm that the intended message disappears. Before every message-targeted command, read the reply preview: selecting the adjacent message is an easy and avoidable mistake.
A disagreement becomes repeated personal abuse
Hypothetical situation: after a clear request to stop, a member continues insulting someone. State the boundary briefly and apply an authorized temporary restriction if that is appropriate under your group's rules.
A practice command, sent as a reply to the target's message, is /tmute 10m repeated personal insults. The duration means ten minutes and the remaining words record the reason. This is an illustrative duration, not a universal sanction. Confirm the correct author is restricted, then practise /unmute for that same target. Both your authority and the bot's permissions matter. Command reference.
Read enough context to distinguish criticism, an insult and a response to provocation. A higher number of complaints does not by itself identify the person at fault. If the dispute involves you, bring in another moderator where possible.
The bot removes a useful post
Hypothetical situation: a member shares an installation guide, and a filter deletes it. Find out which rule acted and whether the event also added warning points or restricted access. “The bot decided” does not explain the policy or offer a correction.
Pause the faulty rule, adjust the relevant exception or condition, and test a similar harmless example. Correct points and access separately. Once the rule is fixed, ask the author to repost the useful information if it is still needed. Do not promise automatic recovery of deleted content.
A brief acknowledgment can be factual: the rule matched too broadly, the restriction was corrected and the configuration is being checked. Avoid exposing the member's private appeal to the whole group merely to demonstrate transparency.
Days four and five: automate one understood rule
Open a private chat with @defendy_bot, choose Settings and select the group. Read its name before editing. Prepare changes in a separate test group with a helper who has no administrator role or exemption. First connection and setup.
Choose one observed problem. Anti-spam → Links handles unwanted destinations. Stopwords holds your own expressions. Captcha handles a supported newcomer-verification flow. Configure Logging separately and select the categories you need; it is not an unconditional record of every message and action.
One beginner trap matters immediately: None under text-filter punishment does not mean harmless observation. Text deletion is enabled by default, and the current page has no deletion switch. Warn can also remove text and bring a member to a punishment threshold. Learn those consequences in the test group first. Full anti-spam walkthrough.
For each prohibited example, write a similar allowed one. If the rule targets unsolicited paid offers, try a legitimate question about paid support. If it restricts links, try the resources members need. If you enable CAPTCHA, test successful completion and timeout, including the helper's way back in.
Do not judge behavior from one post sent by an administrator; exemptions can change the path. Telegram also documents special message visibility for administrator bots. Using hosted Defendy does not require creating a new bot or trying to change its BotFather settings. Telegram Bots FAQ.
Move one verified change into the real group during a period you can supervise. Ordinary switches save when changed; forms with Save need their own confirmation. After a failed request, reopen the section and read the actual value before continuing.
If legitimate content starts disappearing, pause the responsible rule or restore the previous value. Do not compensate by granting a broad exemption before you know which check caused the problem.
Day six: make appeals a repeatable process
A short, consistent review is easier to manage than an argument about the entire community. Use the same questions each time:
- Which group, approximate time and message were involved?
- What relevant context and selected log records are available?
- Which published rule and saved configuration explain the action?
- Should the action be corrected or the reasoning clarified?
- Does this reveal a policy ambiguity or a missing test case?
Ask only for information needed to answer those questions. Keep the review among people who need access. A useful internal note usually needs the incident, the decision, the reason and the responsible moderator, not an archive of the person's unrelated messages.
Correction can require several steps. /unwarn removes one point; /resetwarns clears the counter. Lifting a mute or ban is a separate task. Posting may still be prevented by a group-wide permission or an incomplete entry check. After a correction, verify what the member can actually do instead of relying solely on a successful command response.
If the complaint concerns your own conduct, ask another administrator to review it when possible. A fair process does not require automatically agreeing with every appeal; it requires checking the evidence and being able to explain the outcome.
At the end of the week, review the member experience
Look at the questions that keep repeating, the useful messages filters have caught and the points where newcomers get stuck. These are opportunities to improve the group even when there is little spam.
Choose one next change: clarify a rule, improve the join instructions, narrow a stop-word entry or agree on moderator coverage. Avoid adding punishments or filters just to make the configuration look complete. Basic reputation features such as votes, reactions and a leaderboard can be a separate community decision; they are not prerequisites for competent moderation.
Defendy's dedicated anti-flood module is still planned. If the immediate problem is conversation speed, consider Telegram's available settings and how the discussion is organized. If nobody is available to handle appeals, another automatic punishment will not create that coverage.
By the end of your first week, aim to explain a rule, choose an appropriate action, verify its effect and correct a mistake. Those skills will serve the community longer than memorizing commands without knowing when to use them.
About this guide
Reviewed on October 5, 2026 against current Defendy settings and command handlers and the linked Telegram primary source. The weekly plan and scenarios are editorial recommendations, not a required schedule or a report from a real community. Practise commands in a separate group with your helper's agreement.
