Community Setup: Roles, Bots and Moderation Handover

Define the community’s purpose before its channels

Our original community-service description listed Discord and Telegram setup, bot configuration, moderation and support. Those are separate responsibilities, and a useful brief needs to say which ones are included. A server configuration task does not by itself provide an ongoing moderation team.

Start with the people the community serves and the questions they need answered. A product-support community may need issue reporting and status information. A project discussion group may need announcements and a way to identify official team members. Channel structure should reflect those needs rather than copying every channel from another server.

Make roles and ownership clear

Identify the organisation that owns the community and the people who can change its settings. Document which roles can publish announcements, moderate conversations, manage integrations and grant permissions. Keep ownership and escalation details available to the people responsible for operating the group.

Members should be able to recognise official channels and find the right route for a problem. A clear support boundary also helps: explain whether a community reply is informal discussion, product support or a formal service commitment. Avoid making response-time promises unless the project has agreed coverage to support them.

Give each bot a defined job

Bots can assist with welcome messages, moderation workflows and recurring information. Each bot should have a purpose, an owner and the permissions necessary for its task. Review what information it can access and what actions it can perform before adding it.

Test the member journey after configuration. Check that a new member can reach the intended channels, that moderation actions go to the right people and that an integration failure does not prevent essential communication. Keep a record of configuration and where credentials are managed for the handover.

Plan moderation as an operating responsibility

Moderation requires decisions about acceptable behaviour, enforcement and escalation. Agree who reviews reports, who can remove content or members, and how decisions are recorded. If ongoing moderation is part of the engagement, state the coverage and responsibilities separately from the initial setup.

The earlier website copy implied that bot technology could proactively protect the community and that a dedicated moderation team was included. The revised description avoids that assumption. Automated controls can assist with specific tasks; they do not guarantee that abuse, impersonation or harmful content will be prevented.

Create a handover that survives a personnel change

The handover should explain the channel structure, roles, integrations, moderation rules and escalation contacts. Include the process for changing permissions and removing a bot or team member who no longer needs access. Identify the owner of each recurring operational task.

A practical acceptance check is to have the receiving team carry out the core member and moderator journeys using the documentation. Record gaps while the setup team is still available. This is more useful than handing over an unexplained collection of settings.

What to include in a community brief

Share the platform, audience, existing community structure, expected member journeys and the operating team. List the integrations required and whether you need initial configuration, a handover, ongoing support or a separately scoped moderation engagement.

Contact twelvebit to discuss the setup or integration work. We can define the technical scope alongside related web and blockchain application requirements. The deliverables and any ongoing responsibilities should be explicit in the engagement rather than inferred from a broad service label.