Ein Discord-Build von innen: Vom Erstgespräch zum laufenden Server, Phase für Phase

Jemanden mit dem Bau von Community-Infrastruktur zu beauftragen sollte sich nicht wie eine Blackbox anfühlen. Das hier ist unser Prozess, was in jeder Phase passiert und was du erhalten solltest — so geschrieben, dass du jede Agentur daran messen kannst, uns eingeschlossen.

Phase 1: Discovery

Ein kostenloses Gespräch, in dem wir Ziele, Zielgruppe und bestehendes Setup erfassen. Die Fragen, auf die es ankommt, sind enger als sie klingen: Wofür ist diese Community da, was soll ohne Menschen passieren, und wie sieht Erfolg in sechs Monaten aus? Vage Antworten hier erzeugen später vage Architektur, deshalb bohren wir nach, bis sie konkret sind.

Du bekommst eine ehrliche Einschätzung, einschließlich der Argumente dagegen, uns zu beauftragen. Wenn ein kleines strukturiertes Setup deinen Bedarf deckt, sagen wir das. Einer Community mit achtzig Mitgliedern einen Custom-Bot zu verkaufen ist leicht und erzeugt einen Kunden, der es bereut.

Phase 2: Strategie

Aus der Discovery wird ein Architekturplan: Kategorie- und Kanalkarte, ein Rollenmodell, das Zugriff, Identität und Fähigkeit trennt, eine Berechtigungsmatrix, ein Moderationskonzept und — bei größeren Builds — die Automatisierungs- und Bot-Logik samt ihrer Eskalationsgrenzen.

In dieser Phase fallen die Entscheidungen, deren Umkehr teuer ist. Deshalb wird sie schriftlich festgehalten und freigegeben, bevor gebaut wird. Eine Kanalliste nach dem Launch umzusortieren kostet einen Nachmittag. Ein Berechtigungsmodell zu ändern, nachdem zweitausend Mitglieder Rollen haben, kostet erheblich mehr.

Phase 3: Build

Struktur, Berechtigungen, Branding, Onboarding-Flow und Bot-Konfiguration werden auf einem Staging-Server umgesetzt und getestet, nicht vor deinen Mitgliedern. Custom-Bots entstehen gegen die freigegebene Spezifikation: Slash-Commands, Ticket-Panels, Integrationen und der Zustand, den die Personalisierung braucht.

Berechtigungen werden mit Testkonten geprüft, die je genau eine Rolle tragen — das Einstellungsmenü zeigt Absicht, Testkonten zeigen Verhalten. Hier werden auch AutoMod-Regeln und Verifizierungsstufe gesetzt und das Logging eingerichtet, das spätere Moderationsentscheidungen belegbar macht.

Phase 4: Launch

Wir migrieren oder eröffnen den Server, führen dein Team durch jedes System und übergeben schriftliche Dokumentation: Rollenübersicht, Berechtigungsmatrix, Bot-Befehlsreferenz und einen Moderations-Leitfaden, der festhält, was eine Verwarnung ist, wann sie eskaliert und wer Einsprüche prüft.

Der Leitfaden ist der Teil, den die meisten Übergaben auslassen, und der darüber entscheidet, ob deine Moderation konsistent bleibt, wenn die einrichtende Person nicht verfügbar ist. Dir gehört alles: der Server, der Bot-Code, die Dokumentation.

Phase 5: Optimierung

Auf den Launch folgt ein Support-Zeitraum, in dem Konfigurationen an echtem Mitgliederverhalten ausgerichtet werden statt an Annahmen. Die ersten vier Wochen bringen immer etwas zutage, das der Plan nicht vorhergesehen hat — ein Fragenkanal, der zur Support-Warteschlange wird, ein Onboarding-Zweig, den niemand wählt, ein zu scharfer Filter.

Laufende Wartung, Moderation und Hosting gibt es als optionale monatliche Add-ons. Optional ist Absicht: Ein Build, der nur funktioniert, solange du uns weiterbezahlst, ist keine Übergabe, sondern eine Abhängigkeit.

Zeitrahmen und was ihn verschiebt

Ein strukturiertes Setup dauert typischerweise fünf bis zehn Werktage, ein größerer Build mit Ticket- und Moderationssystemen sieben bis zwölf, Custom-Bot-Projekte werden individuell geschätzt. Die Variable ist fast nie unsere Umsetzungsgeschwindigkeit, sondern wie schnell in Phase zwei Entscheidungen zurückkommen.

Ein Hinweis lohnt sich: Wenn du dich für Discords Server-Discovery bewerben willst, rechne mit dem Mindestalter von acht Wochen und den Aktivitätsanforderungen. Diese Uhr läuft bei Discord, nicht bei uns — und das sollte man wissen, bevor man eine Launch-Kampagne darauf plant.

Was wir von dir brauchen

Drei Dinge bestimmen den Zeitrahmen, und alle drei liegen bei dir. Entscheidungen in Phase zwei, zurück in wenigen Tagen statt wenigen Wochen. Markenmaterial, falls der Server nach deiner Marke aussehen soll — Logo, Farben und geltende Tonalitätsregeln. Und Zugang, also Administratorrechte auf dem Zielserver oder die klare Ansage, dass wir auf einem neuen bauen.

Was wir nicht brauchen, ist eine fertige Kanalliste. Mit einer festen Struktur anzukommen ist verbreitet und meist kontraproduktiv: Die Struktur sollte sich aus den Zielen ergeben, die wir in der Discovery festhalten, und eine vorgefertigte Liste kodiert in der Regel Annahmen, die niemand geprüft hat.

Warum wir auf Staging bauen

Konfigurationsarbeit auf einem laufenden Server ist für Mitglieder sichtbar, während sie halbfertig ist. Kanäle erscheinen und verschwinden, Rechte flackern, und ein Bot postet Testnachrichten in einen Raum, in dem gerade geredet wird. Das ist vermeidbar, also vermeiden wir es: Der Build entsteht auf einem separaten Server und wandert erst hinüber, wenn er vollständig und getestet ist.

Die Ausnahme ist die Migration einer bestehenden Community, bei der die Historie erhalten bleiben muss. Dort ändert sich die Reihenfolge: Wir bereiten alles vor, was sich vorbereiten lässt, stimmen ein Zeitfenster mit dir ab und nehmen die sichtbaren Änderungen in einem Durchgang vor statt über mehrere Tage verteilt.

Was in der Dokumentation wirklich steht

Eine Rollenübersicht, die jede Rolle benennt, was sie gewährt und welche Kategorie sie öffnet. Eine Berechtigungsmatrix nach Kategorien, damit ein künftiger Admin das Modell sieht, statt es aus zwölf Einstellungsmenüs zu rekonstruieren. Eine Befehlsreferenz für jede Bot-Funktion, ihre Parameter und wer sie nutzen darf.

Und ein Moderations-Leitfaden: was als Verwarnung gilt, wann sie eskaliert, wer Einsprüche prüft, wie die Raid-Reaktion aussieht und wo Entscheidungen protokolliert werden. Genau dieses Dokument hält die Durchsetzung über Schichten und Personalwechsel hinweg konsistent — und genau dieses lassen die meisten Übergaben weg.

Umfang, Änderungen und wie wir sie bepreisen

Der am Ende von Phase zwei freigegebene Plan ist der Umfang. Änderungen danach sind normal, und uns ist eine Änderung lieber als ein System, das zu einem veralteten Plan passt — aber sie werden vor der Umsetzung angeboten und nicht stillschweigend aufgenommen und später berechnet.

Kleine Anpassungen während des Builds gehören schlicht zum Build. Ein neues Teilsystem — eine zweite Bot-Funktion, ein Ticket-Ablauf, der nicht im Plan stand — ist eine abgegrenzte Erweiterung mit eigener Schätzung. Die Regel, nach der wir arbeiten: Von einer Zahl solltest du nie überrascht werden.

Was fast immer einen zweiten Durchgang braucht

Nach vier Wochen echter Nutzung tauchen bei nahezu jedem Build dieselben drei Dinge auf. Ein Onboarding-Zweig, den niemand wählt — die Option stammte aus unserer Annahme statt aus deinem Publikum. Ein Kanal, der als Diskussion gedacht war und zur Support-Warteschlange geworden ist, was meistens ein Forum mit Tags werden will.

Und eine AutoMod-Regel, die etwas zu scharf greift und einen Begriff erwischt, den deine Community legitim benutzt. Nichts davon ist ein Planungsfehler; das sind die Dinge, die sich nur aus echter Nutzung lernen lassen — und genau deshalb gibt es den Support-Zeitraum, statt dass der Build mit dem Launch einfach endet.