Jeder Kunde will eine Community: Der Leitfaden „Erst den Umfang klären, dann bauen“

Zusammenfassung

Beim ersten Kickoff-Gespräch sagt fast jeder Mitgliedschafts-Kunde: „Wir wollen eine Community“ – und dieser Satz kann das Projekt stillschweigend zu einem Portal mit Foren, Veranstaltungen, Kursen und Live-Räumen ausweiten, die beim Launch niemand nutzen wird. Dieser Artikel gibt Agenturen ein wiederholbares Scoping-Gespräch an die Hand, um aus dieser vagen Anfrage eine kleine, lieferbare Mitglieder-Website zu machen. Er beginnt mit dem Satz-Test („Mitglieder zahlen, weil sie ___ bekommen“), zwingt den Kunden in ein Geschäftsmodell, verschiebt Community-Funktionen, bis es ein echtes Publikum gibt, und behandelt jede Funktionsanfrage als Änderungsauftrag. Der Artikel enthält ein konkretes Beispiel eines Kunden, der eine vollständige Community wollte und stattdessen ein durchsuchbares Archiv plus ein monatliches Live-Q&A startete. Er warnt auch davor, Engagement zu versprechen: Du kannst die Tür liefern, aber du kannst Menschen nicht dazu bringen, hindurchzugehen. Das Ergebnis ist eine Produktlinie statt einer Rettungsmission – und Kunden, die dir dafür danken, dass du dich geweigert hast, etwas zu bauen.

Beim ersten Kickoff-Gespräch sagt der Kunde: „Wir wollen eine Community.“ Du nickst, tippst das Wort in deine Notizen und spürst, wie sich deine Roadmap stillschweigend verdoppelt. Denn „Community“ kann ein Forum, eine private Chat-Gruppe, eine Paywall, eine Kursbibliothek, eine Veranstaltungsreihe, ein Mitgliederverzeichnis oder alles zusammen bedeuten. Wenn du es als alles zusammen interpretierst, verbringst du ein Quartal damit, Dinge zu bauen, die niemand nutzt, und stellst dem Kunden dann die Rechnung dafür, dass er zusieht, wie sie nicht genutzt werden. Die Lösung ist keine raffiniertere Plattform. Es ist ein ehrlicheres Gespräch, das jedes Mal gleich geführt wird, damit deine nächsten sieben Kunden nicht jeweils zu einmaligen Einzelprojekten werden.

Dieser Artikel basiert auf den Fragen, die wir bei dieser Arbeit tatsächlich immer wieder beantworten. Nicht „Welches Tool sollten wir verwenden?“ – das kommt später –, sondern die Fragen, die entscheiden, ob ein Projekt termingerecht geliefert wird, profitabel bleibt und der Kunde das Gefühl hat, dass du weißt, was du tust.

„Wir wollen eine Community“ – Was verkaufen wir eigentlich?

Bringe den Kunden dazu, einen Satz zu vervollständigen, bevor du überhaupt Plattformen erwähnst: „Mitglieder zahlen uns, weil sie ___ bekommen.“ Das ist alles. Wenn sie die Lücke nicht mit etwas Konkretem füllen können, bist du nicht bereit, eine Plattform zu wählen, eine Seite zu skizzieren oder einen Preis zu nennen. Die gesamte Mitglieder-Website – die Paywall, die Stufen, die Funktionen, die du aktiviert lässt – ist nur der Liefermechanismus für diese Antwort.

Was die meisten Kunden wirklich kaufen, wenn sie „Community“ sagen, fällt in der Regel in vier Kategorien. Wenn wir wiederholbar scopen, erzwingen wir die Entscheidung für eine davon:

Wofür Mitglieder zahlen	Was du tatsächlich baust	Was du gefahrlos verschieben kannst
Inhalte (Kurse, Archive, Tools)	Geschützte Bibliothek, Zahlungsablauf, einfacher Player	Live-Räume, Veranstaltungskalender, Zertifikate
Zugang (ein Produkt, Service oder Tool)	Mitglieder-Login, Berechtigungen, Kontosperren	Ein öffentliches Forum und Social Feed
Verbindung (Peers, Verbindlichkeit, Networking)	Ein Diskussionsbereich, Profile, Einladungen	Vollständige Kursplattform, Inhalte nach und nach, Zertifikate
Status (Insider, Frühzugang, exklusive Vorteile)	Abgestufter Zugang, Badge-/Label-Logik, einfache Vorteile	Foren, nutzergenerierte Inhalte, Live-Veranstaltungen

Die Tabelle ist ein Spickzettel für das Scoping, keine Speisekarte. Der Kunde bekommt eine Kategorie. Wenn er versucht, zwei zu kombinieren, solltest du die Hand heben und langsamer machen, denn deine Kosten sind gerade gestiegen. Die Falle ist, alle vier für einen Kunden zu tun und es als „eine engagierte Community-Plattform“ zu bezeichnen. Das ist kein Produkt, sondern ein Portal, und Portale gehen nicht pünktlich online.

Diese Tabelle ist bewusst klein. In dem Moment, in dem du eine Mitglieder-Website vier Dinge gleichzeitig sein lässt, hast du aufgehört, ein Produkt zu bauen, und beginnst, einen kleinen Medienverlag zu betreiben. Der Kunde will selten einen Medienverlag; er will wiederkehrende Einnahmen. Halte den Umfang so klein, dass das Umsatzmodell von der Startseite aus sichtbar ist.

Wenn ein Kunde „Kurs“ und „Forum“ im selben Satz sagt, frag, welches die Rechnungen bezahlt. Wenn die Antwort „beides“ ist, siehst du tatsächlich einen Kunden, der noch nicht weiß, was er verkauft. Einige finden es während des Scopings heraus und kommen mit einem klareren Angebot zurück; diejenigen, die es nicht tun, sagen dir, dass sie nicht bereit sind. Das ist eine nützliche Erkenntnis, bevor du ein Angebot schreibst – nicht danach.

Aber sie haben bereits hundertmal „Community“ gesagt

Hier ist der konträre Punkt, und es ist keine Bescheidenheits-Nummer: Die meisten Mitglieder-Websites sollten überhaupt keine Community-Funktionen beim Launch haben. „Community“ ist kein Feature. Es ist ein Verhalten, das entsteht, wenn eine kleine Gruppe von Menschen wiederkehrenden Wert voneinander bekommt, und keine Plattform kann das auf Abruf erzeugen. Das Wort ist zu einem Ersatz für „Abo-Umsatz“ geworden, weshalb es jeder Kunde sagt. Du bist für sie nützlicher, wenn du es zurückübersetzt.

Führe einen Community-Realitätscheck durch, bevor du den Umfang wachsen lässt. Stelle drei Fragen:

1. In der ersten Woche: Welches konkrete Verhalten soll ein neues Mitglied zeigen? (Nicht „interagieren“ – sondern „eine Vorstellung posten“, „einen Kommentar hinterlassen“, „die erste Lektion abschließen“.)
2. Wer aus deinem Team wird im ersten Monat Zeit in diesem Bereich verbringen, antworten, steuern und Unordnung beseitigen?
3. Gibt es bereits eine Handvoll Menschen, die dieses Problem haben und sich kennen – oder hoffst du, dass sich Fremde zu einem Team zusammenschließen, weil die Website existiert?

Wenn alle drei Antworten vage sind, baust du keine Community; du baust einen leeren Raum und nennst es Architektur. Der pragmatische Schritt ist, jede Community-Funktion zu verschieben und stattdessen das Mitgliedschafts-Skelett zu starten. Du kannst später immer einen Diskussionsbereich hinzufügen, und wenn du ihn zu einer Gruppe hinzufügst, die bereits Gründe hat zu kommen, hat er eine Chance zu funktionieren. Die ganze Frage verdient eine ausführlichere Behandlung – Community sollte erst nach echten Mitgliedern kommen – aber die Ein-Satz-Version lautet: Baue das Amphitheater nicht, bevor das Publikum existiert.

Was ist das kleinste Ding, das funktionieren könnte?

Sobald du das Angebot klassifiziert hast, gestalte den Launch als Skelett. Eine Zahlungsoption, eine Stufe, ein geschütztes Asset, eine Kommunikationsschleife. Nimm die Funktionsliste deiner Plattform und schalte alles andere aus. Ja, die Plattform kann Live-Videoräume, Mitgliederprofile, Event-Management und Analyse-Dashboards. Genau das ist das Problem.

Ein Kunde kam mit einer von ihm sogenannten vollständigen Community-Vision für sein B2B-SaaS-Produkt zu uns. Er sprach über Foren, einen Veranstaltungskalender, eine Ressourcenbibliothek und einen Bereich „Mitglieder im Rampenlicht“. Während des Scopings ließen wir ihn den Satz vervollständigen: „Mitglieder zahlen, weil sie ___ bekommen.“ Seine Antwort war ein durchsuchbares Archiv mit den Ratschlägen des Gründers plus ein monatliches Live-Q&A. Genau das haben wir also gestartet. Kein Forum, keine Mitgliederprofile, kein Veranstaltungskalender. Kurz darauf wurde das Archiv genutzt, das Q&A hatte Stammgäste, und der Kunde fragte nach einer privaten Diskussionsgruppe, weil Mitglieder bereits außerhalb des Produkts miteinander sprachen. Die Gruppe wurde gebaut, nachdem sie einen Grund zu existieren hatte. Das ist die Reihenfolge, die funktioniert.

Hätten wir die vollständige Vision gebaut, wären wir spät gestartet, mit mehr beweglichen Teilen und ohne Möglichkeit zu erkennen, welche davon tatsächlich die Gewohnheit erzeugt hat. Das Archiv konnte auf ein echtes Verhalten verweisen; ein Live-Raum, der nie genutzt wurde, wäre nur eine Rechnung gewesen. Die Lektion ist langweilig, aber zuverlässig: Je kleiner der Launch, desto wahrscheinlicher kann dir der Kunde sagen, was tatsächlich funktioniert. Ein schlankes Produkt gibt dir auch Raum, das Nächste gut zu machen – eine Stufe hinzufügen, ein Forum öffnen – als bewussten Änderungsauftrag statt als hastiges Extra im Launch-Monat. Wenn du nach einer wiederholbaren Methode suchst, über Stufen und Umsatzstruktur nachzudenken, gibt es den Artikel über Mitgliedschaftsstufen für wiederkehrende Einnahmen, aber das Scoping kommt zuerst.

Was passiert, wenn die Anfragen sich stapeln?

Seien wir ehrlich, wie die meisten Mitgliedschaftsprojekte sterben: nicht aus Inkompetenz, sondern wegen „noch einer Sache“. Der Kunde sieht eine Demo der Community eines Konkurrenten und möchte ein passendes Feature. Die richtige Antwort ist weder „ja“ noch „nein“ – sondern „fügen wir es der Verschubliste hinzu“.

Mache die Liste der verschobenen Funktionen zu einem erstklassigen Deliverable in deinem Projekt. Nimm sie in das Angebot auf, halte sie sichtbar und füge jede Anfrage außerhalb des Umfangs hinzu. Gib jedem Punkt eine Auslösebedingung. Nicht „irgendwann“, sondern „das geht live, wenn 200 aktive Mitglieder einen Monat lang im Raum waren“ oder „wenn der Kunde zwei Stunden Mitarbeiterzeit pro Woche für die Moderation bereitstellt“. Du bist nicht schwierig; du gibst dem Feature einen Grund zu existieren.

So hörst du auf, dieselbe Mitglieder-Website für jeden Kunden neu zu bauen: indem du jeden neuen Kunden als Konfiguration eines Skeletts behandelst, das du bereits geliefert hast, mit einer Liste von Dingen, die du bewusst nicht gebaut hast. Wenn ein Feature auf der Verschubliste steht, ist es ein zukünftiges Projekt, was auch zukünftiger Umsatz ist. Formuliere es so, und der Kunde wird in der Regel zustimmen.

Wie verhindern wir, dass uns der Kunde die Schuld für das leere Forum gibt?

Du musst früh und schriftlich Erwartungen setzen, was du kontrollieren kannst und was nicht. Du kannst den Zahlungsablauf, die Zugangsbeschränkungen, die E-Mail-Automationen und das Design liefern. Du kannst nicht liefern, dass Menschen sich entscheiden, miteinander zu sprechen. Das „Engagement-Problem“ des Kunden ist kein Bauproblem; es ist ein Betriebsproblem und liegt in seinem Verantwortungsbereich.

Das ist wichtig, weil Kunden drei Wochen nach dem Launch stillschweigend anfangen zu fragen, warum die „Community“ so ruhig ist. Wenn du die Grenze von Anfang an setzt, kannst du ein nützliches Gespräch über Anreize und Anschubhilfe führen. Wenn nicht, debuggt du eine Plattform, die nicht kaputt ist. Ein praktischer Weg, das zu formalisieren: Nimm einen separaten Posten für „Community-Hosting und Anschubhilfe“ in deinen Wartungsvertrag auf oder gib dem Kunden eine Checkliste für die Anschubhilfe, die Teil seines Projekt-Kickoffs ist. Der Punkt ist, die Arbeitsteilung explizit zu machen. Das Tool ist nicht die Bindungsstrategie; die Mythen über Mitglieder-Websites sind meist der Übeltäter, wenn Menschen erwarten, dass eine Plattform das Verkaufen für sie übernimmt.

Wenn sie trotzdem auf einer Community bestehen, was schalten wir ein?

Wenn der Kunde den Realitätscheck besteht und tatsächlich eine Community betreibt, schalte genau ein Diskussionsformat ein. Nicht drei. Ein Forum ist verschachtelt, durchsuchbar und asynchron; ein Live-Raum ist unmittelbar, vergänglich und personalintensiv. Du kannst nicht beides mit einem kleinen Team gut moderieren, und der Versuch, es zu tun, wird deinem Kunden beibringen, dass „Community“ ständige Aktivität bedeutet – ein Standard, den du nicht versprechen solltest.

Praktische Regel: ein Raum, ein Format, ein benannter Moderator. Wähle das Format, das zum Verhalten passt, das du im Realitätscheck identifiziert hast. Wenn das gewünschte Verhalten „eine Frage stellen und eine Antwort bekommen“ ist, beginne mit einem Forum. Wenn es „Dienstag mittag kommen, um Herausforderungen zu besprechen“ ist, beginne mit einer Live-Veranstaltung. Setze dann eine leichtgewichtige Metrik für die ersten neunzig Tage: nicht Gesamtmitglieder, nicht Anmeldungen, sondern die Anzahl der Mitglieder, die das Zielverhalten mindestens zweimal gezeigt haben. Zwei Erwähnungen von Aktivität reichen aus, um zu wissen, ob der Raum lebendig oder ein Museum ist.

Wie bepreisen wir das, sodass es eine Produktlinie ist, keine Rettungsmission?

Mache das Discovery-Gespräch selbst zu einem abrechenbaren Produkt. Erstelle ein Festpreis-Paket für die Einrichtung einer Mitglieder-Website, das den Scoping-Anruf, den Skelett-Bau (ja, wirklich), die Zahlungskonfiguration und eine Runde Revisionen umfasst. Alles darüber hinaus – Community-Design, kundenspezifische Funktionen, Moderationsstunden, Integrationen – ist ein separater Leistungsnachweis. Das ist der ganze Trick. Wenn du jede optionale Funktion als Änderungsauftrag anbietest, lernt der Kunde plötzlich zu priorisieren. Wenn du alles in einen einzigen eskalierenden Kostenvoranschlag packst, bringst du ihnen bei, dass mehr Umfang kostenlos ist.

Ein wiederholbarer Prozess sieht so aus: ein Fragebogen, den du vor dem Anruf sendest, ein einseitiges Leistungsverzeichnis mit Festpreis, ein Bauplan, den dein Team schon einmal durchgeführt hat, und eine Vorlage für die Liste der verschobenen Funktionen. Du solltest dem Kunden das Startdatum nennen können, bevor das Design-Moodboard existiert. Du bekommst auch ein besseres Gespräch: Der Kunde sieht, was das absolute Minimum kostet, was die Community-Extras kosten und was seine eigene Zeit kostet. Wenn sie davor zurückschrecken, für ein Skelett zu zahlen, wirst du das erfahren, bevor es wehtut.

Der Teil, den niemand hören will

Jede Mitglieder-Website ist eine Wette auf wiederkehrendes Verhalten. Die Plattform ist nur der Umschlag. Deine Aufgabe als Person, die das für viele Kunden baut, ist es, den Umschlag zu adressieren und zu frankieren, während du sicherstellst, dass niemand sich verpflichtet hat, eine Live-Aufführung von Hand zu liefern. Du kannst keine Community erzwingen. Du kannst die Bedingungen schaffen, die kleinstmögliche Version wählen und dem Kunden eine klare Liste dessen geben, was du nicht baust.

Dieser letzte Teil ist dein echter Wert. Der Kunde hat dich engagiert, weil er nicht sehen kann, was er weglassen soll. Also lass es für ihn aus – selbstbewusst, absichtlich, schriftlich. Sobald du gescope hast, wird die Lieferung fast langweilig: Mitglieder-Website-Launches werden tatsächlich geliefert, wenn sie klein sind und die Entscheidungen im Voraus getroffen wurden. Leere Foren und ausufernde Custom-Portale sind teuer. Das Skelett, pünktlich geliefert, ist weit mehr wert als die „leistungsstarke Community-Plattform“, die nie richtig online ging.