Der wichtigste Satz vorweg: Rocket.Chat ist eine Plattform, kein fertiger Dienst. Sie entscheiden, wo sie läuft, wie sie konfiguriert ist, welche Erweiterungen aktiv sind und welche Datenflüsse zugelassen werden. Diese Freiheit ist der Kern des Wertversprechens – und gleichzeitig der Grund, warum Rocket.Chat mehr Vorbereitung verlangt als das Anlegen eines Konten in einem Cloud-Dienst. Wer diese Verantwortung annehmen kann, bekommt eine Kommunikationsumgebung, deren Daten das eigene Haus nicht verlassen müssen. Wer sie nicht annehmen kann, sollte über einen betreuten Betrieb nachdenken, statt die Plattform nebenbei zu betreiben.
Rocket.Chat organisiert Kommunikation über vier ineinandergreifende Konstrukte, deren Unterschiede in der Praxis über die Übersichtlichkeit einer Installation entscheiden. Kanäle sind die Grundeinheit: themenbezogene Räume, entweder öffentlich und für alle Angemeldeten auffindbar oder privat und nur auf Einladung zugänglich. Wer aus der E-Mail-Welt kommt, versteht Kanäle am besten als dauerhafte Verteiler mit Gedächtnis – neue Mitglieder sehen in einem öffentlichen Kanal die Vorgeschichte, statt sie sich weiterleiten lassen zu müssen.
Teams sind eine Ebene darüber. Ein Team bündelt mehrere Kanäle unter einer gemeinsamen Zugehörigkeit und einem gemeinsamen Mitgliederkreis. Das klingt nach einer Kleinigkeit und ist in größeren Installationen der Unterschied zwischen einer navigierbaren und einer unbenutzbaren Kanalliste. Praktisch bildet man damit Abteilungen, Standorte, Projekte oder Gesellschaften ab: Das Team trägt die Mitgliedschaft, die Kanäle darin tragen die Themen. Beim Ausscheiden einer Person entfällt die Zugehörigkeit an einer Stelle, nicht an fünfzehn.
Diskussionen sind eigenständige Unterräume, die aus einer Nachricht heraus entstehen. Sie eignen sich, wenn ein Thema so viel Substanz gewinnt, dass es einen eigenen Raum mit eigener Mitgliedschaft und eigener Historie verdient – etwa eine Störung an einer Anlage, ein Kundenvorfall, eine Ausschreibung. Threads sind die kleinste Einheit: Antworten, die an einer Nachricht hängen und den Hauptverlauf nicht zerreißen. Die Regel, die wir Kunden empfehlen, ist einfach: Threads für Rückfragen, Diskussionen für abgrenzbare Vorgänge, Kanäle für Themen, Teams für Organisationseinheiten.
Rocket.Chat entstand als Community-Projekt und wird von einem Unternehmen weiterentwickelt, das damit kommerzielle Editionen und Dienstleistungen anbietet. Der Quellcode des Kerns ist öffentlich einsehbar, was in drei Situationen konkret hilft. Erstens bei der Sicherheitsbewertung: Ihre IT oder ein Prüfdienstleister kann nachvollziehen, was die Software tut, statt sich auf Zusicherungen zu verlassen. Zweitens bei der Verhandlungsposition: Sie sind nicht auf eine einzige Bezugsquelle angewiesen, weil die Plattform grundsätzlich auch ohne Herstellervertrag betrieben werden kann. Drittens bei der Ausstiegsfähigkeit: Daten liegen in einer Datenbank, auf die Sie Zugriff haben, nicht in einem fremden Mandanten.
Gleichzeitig ist Vorsicht geboten bei einer verbreiteten Verkürzung. Quelloffen bedeutet nicht kostenlos im Sinne von aufwandsfrei, und es bedeutet auch nicht, dass jede Funktion in jeder Edition verfügbar ist. Bei Rocket.Chat gilt – wie bei den meisten Produkten mit offenem Kern – dass ein Teil der Fähigkeiten den kommerziellen Editionen zugeordnet ist. Welche Funktion in welcher Edition liegt und ob sich diese Zuordnung geändert hat, ist eine Frage, die Sie beim Anbieter für den aktuellen Stand prüfen sollten, statt sie aus älteren Vergleichstabellen im Netz zu übernehmen.
Drei Eigenschaften beschreiben die Positionierung treffender als jede Funktionsliste. Erstens die Verbindung von interner und externer Kommunikation. Slack, Microsoft Teams und Mattermost sind primär für die Zusammenarbeit im Unternehmen gebaut; Kundenkommunikation ist dort ein Anbau oder eine Integration. Rocket.Chat behandelt beides als gleichrangige Aufgaben derselben Plattform. Ein Servicemitarbeiter kann in einem internen Kanal eine Rückfrage stellen und im gleichen Fenster einen Website-Besucher betreuen. Für Organisationen mit Kundenkontakt ist das der eigentliche Unterschied.
Zweitens die Betriebsflexibilität. Die Plattform lässt sich im eigenen Rechenzentrum, bei einem europäischen Auftragsverarbeiter, in einer betreuten Cloud oder in vollständig vom Internet getrennten Netzen betreiben. Diese Bandbreite ist selten, und sie erklärt die Präsenz im öffentlichen Sektor, in Verteidigung, Gesundheitswesen und in Bereichen, in denen ein Cloud-Dienst schlicht nicht in Frage kommt.
Drittens die Offenheit nach außen. Rocket.Chat setzt seit Jahren auf Anschlussfähigkeit: Schnittstellen für eigene Entwicklungen, ein Marktplatz für Erweiterungen, Anbindung an das offene Matrix-Protokoll, Webhooks, Slash-Kommandos, Bots. Wer Kommunikation nicht als isolierte Anwendung, sondern als Teil eigener Prozesse versteht, findet hier mehr Ansatzpunkte als in geschlosseneren Produkten.
Die Grundlogik entspricht dem verbreiteten Modell für Produkte mit offenem Kern: Es gibt eine frei verfügbare Ausgabe, die Sie selbst betreiben, und darüber gestaffelte kommerzielle Ausgaben, die zusätzliche Funktionen, Supportzusagen und vertragliche Absicherung mitbringen. Parallel dazu steht die Frage, wo die Plattform läuft – bei Ihnen, bei einem Dienstleister, in einer betreuten Cloud oder in einem abgeschotteten Netz. Diese beiden Achsen sind unabhängig voneinander, und genau deshalb entstehen in Gesprächen so häufig Missverständnisse.
In der Beratungspraxis stellt sich fast immer heraus, dass die Editionsfrage nachrangig ist. Die eigentliche Entscheidung lautet: Wollen und können Sie diese Plattform selbst betreiben? Daran hängen Kosten, Personalbedarf, Reaktionsfähigkeit bei Störungen und die Datenschutzargumentation gleichzeitig.
Für den Eigenbetrieb spricht die Kontrolle. Nachrichten, Dateien, Anmeldedaten und Auswertungsdaten liegen in einer Infrastruktur, deren Standort Sie bestimmen und deren Zugriffe Sie protokollieren. Sie entscheiden über Aktualisierungszeitpunkte, über die Aufbewahrung und über jede aktivierte Funktion. In Ausschreibungen mit Standortauflagen und in Organisationen mit hoher Vertraulichkeitsanforderung ist das häufig nicht verhandelbar, und dann ist der Eigenbetrieb kein Nachteil, sondern der Grund für die Auswahl.
Gegen den Eigenbetrieb spricht der Aufwand, und zwar dauerhaft, nicht einmalig. Sie betreiben eine Anwendung mit einer Datenbank, einem Dateispeicher, einem vorgeschalteten Webserver, Zertifikaten, Sicherungen und Wiederherstellungsübungen. Sie halten sie auf einem Stand, der Sicherheitsaktualisierungen erhält. Sie prüfen vor jedem größeren Sprung, ob Ihre Erweiterungen weiterhin funktionieren. Und Sie brauchen Menschen, die das nicht nebenbei machen. Unsere Erfahrung: Der Eigenbetrieb scheitert selten an der Technik, sondern daran, dass die Zuständigkeit nach dem Projekt niemandem verbindlich zugeordnet wurde.
Ein dritter Weg wird im Mittelstand oft übersehen und ist häufig der wirtschaftlich vernünftigste: der Betrieb bei einem europäischen Dienstleister, der die Plattform für Sie hostet und pflegt. Sie behalten die Datenhoheitsargumentation über Standort und Auftragsverarbeitungsvertrag, geben aber die Betriebslast ab. Wer weder eine große IT noch einen Cloud-Dienst außerhalb Europas möchte, findet hier meist die passende Antwort.
Fünf Punkte gehören in jedes Angebotsgespräch, weil sie sich nicht aus Produktseiten ableiten lassen. Erstens die Funktionszuordnung: Welche der für Sie unverzichtbaren Fähigkeiten sind in der angebotenen Edition tatsächlich enthalten – schriftlich, funktionsweise, für den aktuellen Stand. Zweitens die Abrechnungsgrundlage: Wird nach angemeldeten Personen, nach aktiven Personen, nach Servicearbeitsplätzen oder nach Instanzen gezählt, und wie werden externe Gesprächspartner im Live-Chat behandelt? Drittens der Supportumfang: Reaktionszeiten, Erreichbarkeit, Sprache, Eskalationswege und ob Unterstützung beim Eigenbetrieb überhaupt Teil des Vertrags ist. Viertens die Aktualisierungspflichten: Wie lange werden Versionen mit Sicherheitsaktualisierungen versorgt, und welche Aktualisierungsfrequenz erwartet der Vertrag von Ihnen? Fünftens die Ausstiegsbedingungen: In welcher Form sind Nachrichten, Dateien und Konfiguration exportierbar, und was passiert mit der Instanz nach Vertragsende.
Wenn ein Merkmal die Auswahl zugunsten von Rocket.Chat entscheidet, ist es meist dieses. Der Gedanke ist einfach: Anfragen von außen kommen heute über viele Wege – das Kontaktformular, das Chat-Fenster auf der Website, gängige Messenger, teils Telefon und E-Mail. In vielen mittelständischen Unternehmen bedeutet das mehrere Postfächer, mehrere Geräte, mehrere Zuständigkeiten und keinen gemeinsamen Verlauf. Omnichannel führt diese Wege in eine Warteschlange zusammen, verteilt Gespräche nach Regeln auf Abteilungen oder Personen und hält den Verlauf an einem Ort.
Praktisch heißt das: Ein Website-Besucher stellt eine Frage, das Gespräch landet nach Regelwerk bei der zuständigen Abteilung, die bearbeitende Person sieht den Verlauf, kann intern in einem Kanal rückfragen, Dateien anhängen und das Gespräch bei Bedarf weitergeben. Nach Abschluss bleibt eine nachvollziehbare Historie, aus der sich Bearbeitungsdauer, Aufkommen und Themenschwerpunkte auswerten lassen.
Zwei Hinweise aus Projekten. Erstens: Prüfen Sie genau, welche externen Kanäle in Ihrer Edition und in Ihrer Betriebsform tatsächlich anbindbar sind – die Anbindung populärer Messenger hängt an deren Geschäftsschnittstellen, deren Bedingungen sich ändern können, und ist datenschutzrechtlich eigenständig zu bewerten. Zweitens: Ein Live-Chat ohne Besetzungskonzept schadet mehr, als er nutzt. Klären Sie vor der Aktivierung Öffnungszeiten, Vertretung, Antwortzeiterwartung und was außerhalb der Zeiten passiert.
Die Möglichkeit, Räume mit Ende-zu-Ende-Verschlüsselung zu betreiben, ist ein starkes Argument – und ein Feld, auf dem in Auswahlprojekten viel Verwirrung entsteht. Zu trennen sind drei Ebenen. Die Transportverschlüsselung schützt die Verbindung zwischen Client und Server und ist selbstverständlicher Standard. Die serverseitige Verschlüsselung schützt Daten im Speicher, aber nicht vor dem Betreiber. Die Ende-zu-Ende-Verschlüsselung schützt Inhalte auch vor dem Betreiber, weil die Schlüssel bei den Endgeräten liegen.
Die dritte Ebene hat einen Preis, der nichts mit Geld zu tun hat. Was der Server nicht lesen kann, kann er auch nicht durchsuchen, nicht in Vorschauen anzeigen, nicht in Archive überführen und nicht in Prüfprozesse einbeziehen. Auch Benachrichtigungen zeigen weniger Inhalt. Deshalb ist die sinnvolle Entscheidung meist nicht Ende-zu-Ende-Verschlüsselung für alles, sondern eine bewusste Zuordnung: verschlüsselte Räume für Gremien, Personalthemen, Rechtsfälle oder Sicherheitsvorfälle – reguläre Räume mit serverseitiger Absicherung für den Arbeitsalltag, in dem Suchbarkeit den größeren Wert hat. Diese Zuordnung gehört in Ihr Betriebskonzept, nicht in die Entscheidung einzelner Beschäftigter.
Ehrlichkeit gehört zu einer Einordnung. Drei Punkte hören wir in Projekten regelmäßig. Erstens die Feinschliff-Frage: Die Oberfläche ist funktional und für Chat-erfahrene Menschen gut bedienbar, wirkt aber an manchen Stellen weniger poliert als bei den großen Cloud-Anbietern, die erheblich mehr in Bedienerfahrung investieren. In Belegschaften mit geringer Digitalerfahrung ist das ein Akzeptanzthema, das man mit Einführung und Begleitung adressieren muss, nicht mit Funktionslisten.
Zweitens die Dokumentwelt: Rocket.Chat ist eine Kommunikationsplattform, keine Office-Umgebung. Gemeinsames Bearbeiten von Texten und Tabellen im Chat-Fenster gehört nicht zum Kern, sondern entsteht über Anbindung an Ihre Dateiplattform. Wer eine integrierte Suite aus Chat, Dokumenten, Tabellen und Kalender erwartet, vergleicht das falsche Produkt.
Drittens der Umfang der Konfiguration: Die Plattform lässt außergewöhnlich viel zu. Das ist eine Stärke und in der Einführung eine Falle, weil ohne Betriebskonzept eine Vielzahl von Einstellungen unbewusst in der Voreinstellung bleibt. Wir empfehlen, die Konfiguration einmal vollständig durchzugehen und die getroffenen Entscheidungen zu dokumentieren – besonders bei Sichtbarkeiten, Gastzugängen, Dateifreigaben, Aufbewahrung und allem, was Daten nach außen sendet.
Der Kern des Ansatzes: Die Plattform bringt KI-gestützte Assistenzfunktionen mit, überlässt Ihnen aber die Entscheidung, welches Modell diese Funktionen bedient. Das kann ein extern betriebener Dienst sein, es kann ein europäischer Anbieter sein, und es kann ein Modell sein, das auf Ihrer eigenen Hardware läuft. Für Datenschutz und Betriebsrat ist der letzte Fall qualitativ etwas anderes als eine KI-Funktion, die fest an eine Anbieterwolke gebunden ist. Prüfen Sie beim Anbieter, welche Anbindungsmöglichkeiten in Ihrer Edition und Betriebsform vorgesehen sind, welche Voraussetzungen sie haben und was zusätzlich lizenziert werden muss – dieses Feld entwickelt sich schnell, und ältere Quellen sind hier besonders unzuverlässig.
Aus der Praxis heraus sind vier Anwendungen belastbar, und sie haben wenig mit spektakulären Demonstrationen zu tun. Zusammenfassungen sind der wirksamste Fall: Wer nach Urlaub, Schicht oder Krankheit in einen Kanal mit hunderten Nachrichten zurückkehrt, spart mit einer Zusammenfassung real Zeit. Übersetzungen sind der zweite Fall, und im produzierenden Mittelstand mit mehrsprachigen Belegschaften oft der wertvollste – eine Sicherheitsmeldung, die alle verstehen, ist mehr als eine Bequemlichkeit.
Antwortvorschläge im Kundenservice sind der dritte Fall: Die Assistenz liest den Gesprächsverlauf, schlägt eine Antwort vor, ein Mensch prüft und sendet. Das beschleunigt Bearbeitung ohne den Kontrollverlust einer automatisch verschickten Antwort. Der vierte Fall ist die Suche über den eigenen Wissensbestand: Fragen in natürlicher Sprache, beantwortet aus dem, was in Kanälen, Handbüchern oder angebundenen Ablagen steht. Dieser Fall hat den höchsten Nutzen und die höchste Anforderung an Vorarbeit, weil er ohne Ordnung in den Quellen nicht funktioniert.
Was in unseren Projekten regelmäßig enttäuscht, sind Erwartungen an vollautomatische Bearbeitung. Ein Bot, der Kundenanfragen ohne Aufsicht beantwortet, funktioniert für einen engen Kreis wiederkehrender Fragen und wird bei allem darüber hinaus zum Reputationsrisiko. Die tragfähige Konstruktion ist Assistenz mit menschlicher Freigabe, nicht Ersatz.
Der praktische Automatisierungsnutzen liegt selten in der KI, sondern in Mechanismen, die schon lange funktionieren und im Mittelstand erstaunlich wenig genutzt werden. Eingehende Webhooks erlauben es beliebigen Systemen, Nachrichten in einen Kanal zu schreiben. Das ist die einfachste und wirkungsvollste Automatisierung überhaupt: Die Maschinensteuerung meldet eine Störung, das Warenwirtschaftssystem meldet eine überfällige Lieferung, die Überwachung meldet einen Ausfall, das Ticketsystem meldet eine eskalierte Meldung – alles im Kanal des zuständigen Teams, mit Verlauf und Zuständigkeit.
Ausgehende Webhooks drehen die Richtung: Ein Ereignis im Chat löst eine Aktion in einem anderen System aus. Slash-Kommandos geben Beschäftigten kurze Befehle an die Hand, mit denen sie im Chat etwas anstoßen – eine Urlaubsanfrage, eine Raumbuchung, eine Statusabfrage. Bots schließlich sind Dienste, die auf Nachrichten reagieren und in beide Richtungen vermitteln.
Unsere Empfehlung für den Einstieg: Beginnen Sie mit genau einer Benachrichtigung, die heute per E-Mail oder Telefon läuft und regelmäßig zu spät ankommt. Bringen Sie sie in den richtigen Kanal, messen Sie die Wirkung, erweitern Sie danach. Wer mit einem großen Automatisierungskonzept beginnt, baut Dinge, die niemand braucht; wer mit einer schmerzhaften Meldung beginnt, hat innerhalb einer Woche einen Fürsprecher im Fachbereich.
Über einen Marktplatz lassen sich Erweiterungen einspielen, die Funktionen ergänzen oder Fremdsysteme anbinden. Zusätzlich existiert ein Rahmen für eigene Anwendungen, mit dem Entwicklungsteams Fachlogik direkt in die Plattform bringen können – Formulare, Genehmigungsschritte, Abfragen aus internen Systemen. Für Organisationen mit eigener Entwicklungskapazität ist das ein starkes Argument, weil Kommunikation dort zum Bedienelement eigener Prozesse wird.
Drei Betriebsregeln haben sich bewährt. Erstens: Jede Erweiterung ist ein zusätzlicher Vertrauens- und Aktualisierungspunkt – führen Sie eine Liste, wer sie freigegeben hat und wofür sie gebraucht wird. Zweitens: Prüfen Sie vor der Installation, ob Daten die Instanz verlassen und wohin. Drittens: Prüfen Sie vor jedem größeren Versionssprung die Verträglichkeit Ihrer Erweiterungen, bevor Sie aktualisieren. Diese drei Regeln kosten wenige Stunden im Jahr und verhindern die häufigste Ursache für Betriebsstörungen nach Aktualisierungen.
Wenn Sie nur eine Integration umsetzen, sollte es diese sein. Die Anbindung an Ihren vorhandenen Verzeichnisdienst oder Ihre Anmeldeplattform entscheidet über den Verwaltungsaufwand und über die Sicherheit der gesamten Installation. Technisch sind die üblichen Verfahren vorgesehen: Verzeichnisabfrage, Anmeldeweiterleitung über die verbreiteten Standards, Einmalanmeldung im Zusammenspiel mit Ihrer bestehenden Identitätslösung sowie Mehrfaktor-Anmeldung.
Praktisch geht es um vier Dinge, die in Projekten regelmäßig zu spät geklärt werden. Erstens die führende Quelle: Woher kommen Name, Abteilung, Standort und Rolle, und was passiert, wenn sich diese Angaben ändern? Zweitens die automatische Bereitstellung und Deaktivierung: Konten sollen mit dem Eintritt entstehen und mit dem Austritt gesperrt werden, ohne dass jemand daran denken muss. Drittens die Rollenabbildung: Welche Gruppe im Verzeichnis führt zu welcher Rolle in der Plattform? Viertens die Gruppe ohne Firmenkonto: Beschäftigte in Produktion oder Logistik haben häufig keine geschäftliche E-Mail-Adresse – wie melden sie sich an, und wie werden ihre Konten verwaltet? Diese vierte Frage ist im Mittelstand die schwierigste und entscheidet über die Erreichbarkeit genau der Gruppe, die man gewinnen wollte.
Ein Merkmal, das Rocket.Chat von den geschlossenen Wettbewerbern abhebt, ist die Anbindung an das offene Kommunikationsprotokoll Matrix. Der Gedanke der Föderation ist von E-Mail bekannt: Verschiedene Organisationen betreiben verschiedene Server, und Menschen können trotzdem miteinander schreiben, ohne dass eine Seite ein Konto bei der anderen braucht. Für Behörden, Forschungsverbünde, Verbände und Lieferketten ist das der strukturell überlegene Ansatz, weil Zusammenarbeit über Organisationsgrenzen ohne Gastkonten möglich wird.
Zur Ehrlichkeit gehört: Föderation ist anspruchsvoll, und das gilt für alle Beteiligten am Markt. Verschiedene Serverimplementierungen unterstützen unterschiedliche Teilmengen des Protokolls, Verschlüsselung über Servergrenzen hinweg ist besonders empfindlich, und Funktionen wie Threads, Reaktionen oder Dateifreigabe verhalten sich in föderierten Räumen nicht zwangsläufig wie in lokalen. Wenn Föderation für Ihren Anwendungsfall wesentlich ist – etwa weil Ihre Partnerorganisationen Matrix-Server betreiben – dann gehört sie in einen belastbaren Test mit den tatsächlichen Gegenstellen, nicht in eine Funktionsliste. Prüfen Sie außerdem beim Anbieter, welchen Reifegrad und welche Betriebsvoraussetzungen die Föderationsanbindung in Ihrer Edition aktuell hat.
Für viele Mittelständler ist Föderation kein Entscheidungskriterium, sondern eine Option, die man sich offenhält. Auch das ist ein legitimer Wert: Sie entscheiden sich für eine Plattform, die den Anschluss an eine offene Welt nicht ausschließt, selbst wenn Sie ihn zunächst nicht nutzen.
Die übrigen Integrationen lassen sich in vier Gruppen ordnen, und für jede gilt eine eigene Prüflogik.
Diese beiden Produkte stehen sich in Ausschreibungen am häufigsten gegenüber, und die Unterschiede sind feiner, als Vergleichstabellen vermuten lassen. Beide haben einen quelloffenen Kern, beide lassen sich selbst betreiben, beide bieten kommerzielle Editionen mit Unternehmensfunktionen, beide sind in Behörden und regulierten Branchen anzutreffen.
Der wesentliche Unterschied liegt in der Ausrichtung. Mattermost ist konsequent auf interne Zusammenarbeit gebaut und hat sich in Richtung technischer Teams, Entwicklungsorganisationen und operativer Lagebearbeitung profiliert – Werkzeuge für Abläufe, Checklisten und Vorfallsbearbeitung sind dort stärker ausgeprägt. Rocket.Chat deckt zusätzlich die Kommunikation nach außen ab und ist damit für Organisationen mit Kundenkontakt breiter aufgestellt. Wer intern zusammenarbeiten und externe Anfragen bearbeiten will, findet bei Rocket.Chat mehr in einem Produkt; wer ausschließlich interne Zusammenarbeit braucht und Wert auf ein schlankes, klar umrissenes Werkzeug legt, kommt mit Mattermost oft schneller zum Ziel.
Ein zweiter Unterschied betrifft die Offenheit nach außen: Die Matrix-Anbindung ist bei Rocket.Chat vorhanden, bei Mattermost spielt Föderation traditionell keine Rolle. Für Verbundszenarien ist das relevant, für einen einzelnen Mittelständler meist nicht. Unser praktischer Rat: Entscheiden Sie diese Frage nicht auf Papier. Setzen Sie beide Kandidaten für zwei Wochen mit demselben echten Anwendungsfall auf und lassen Sie dieselbe Gruppe damit arbeiten. Die Entscheidung fällt danach meist eindeutig – und aus Gründen, die vorher niemand aufgeschrieben hätte.
Dieser Vergleich wird oft als Funktionsvergleich geführt und ist in Wahrheit eine Grundsatzentscheidung. Slack und Microsoft Teams sind ausgereifte Cloud-Dienste mit hervorragender Bedienerfahrung, breitem Partnerökosystem und – im Fall von Teams – tiefer Verzahnung mit einer Office-Umgebung, die viele Mittelständler ohnehin lizenziert haben. Gegen diese Stärken gewinnt man mit Funktionslisten nicht.
Rocket.Chat gewinnt auf einem anderen Feld: dort, wo der Verarbeitungsort, der Zugriff durch Dritte, die Unabhängigkeit von einem Anbieter oder eine vertragliche Vorgabe den Ausschlag geben. Typische Konstellationen sind Organisationen im öffentlichen Umfeld, Zulieferer mit Vertraulichkeitsauflagen ihrer Kunden, Einrichtungen im Gesundheitswesen, Betriebe kritischer Infrastruktur und Unternehmen, deren Geschäftsführung eine strategische Abhängigkeit von außereuropäischen Anbietern reduzieren will.
Wenn Sie Microsoft 365 bereits im Haus haben und keine dieser Anforderungen zutrifft, ist die ehrliche Empfehlung meist, bei Teams zu bleiben – eine zweite Kommunikationsplattform neben einer bereits bezahlten kostet Aufwand, Verwirrung und Akzeptanz. Umgekehrt: Wenn eine dieser Anforderungen zutrifft, ist die Diskussion über Feinschliff nachrangig. Dokumentieren Sie in beiden Fällen die Abwägung – sie ist bei der nächsten Prüfung mehr wert als die Entscheidung selbst.
Element setzt vollständig auf das Matrix-Protokoll und stellt Föderation sowie Ende-zu-Ende-Verschlüsselung in den Mittelpunkt. Wo Verbundkommunikation zwischen Organisationen der eigentliche Zweck ist – etwa zwischen Behörden verschiedener Ebenen oder in Forschungsverbünden –, ist dieser Weg konzeptionell überlegen. Der Preis ist ein höherer Betriebs- und Erklärungsaufwand und eine Produktwelt, deren Bedienerfahrung je Client schwankt.
Nextcloud Talk beantwortet eine andere Frage: Wer bereits eine selbstbetriebene Dateiplattform als Zentrum der Zusammenarbeit hat, bekommt Chat und Video als integrierten Bestandteil dazu – ohne zweiten Server, ohne zweite Anmeldung, ohne zweite Datenschutzbewertung. Für kleinere Organisationen mit moderatem Chat-Bedarf ist das oft die pragmatischste Lösung. Wer Chat als Hauptwerkzeug mit hohem Nachrichtenvolumen, Kanalstruktur und Kundenkommunikation braucht, stößt dort an Grenzen, die Rocket.Chat nicht hat.
Rocket.Chat ist eine Anwendung auf Basis von Node.js mit MongoDB als Datenbank. Üblich ist die Bereitstellung über Container, entweder mit Docker und einem Verbundwerkzeug für einzelne Server oder mit Kubernetes für größere und ausfallsichere Installationen. Vor der Anwendung steht in der Regel ein Webserver oder Lastverteiler, der Zertifikate verwaltet und Verbindungen weiterleitet. Dateianhänge liegen entweder im Dateisystem oder – für größere Installationen empfehlenswert – in einem objektbasierten Speicher.
Zwei technische Punkte sind aus Betriebssicht die wichtigsten. Der erste ist MongoDB: Die Datenbank ist das Herz der Installation, ihre Konfiguration bestimmt Antwortzeiten und Ausfallsicherheit, und ihre Sicherung ist der einzige echte Schutz Ihrer Kommunikationshistorie. Ein Replikatverbund ist für produktive Installationen der Normalfall, nicht die Luxusvariante. Der zweite ist die Echtzeitverbindung: Chat lebt von dauerhaft offenen Verbindungen zwischen Client und Server. Vorgeschaltete Komponenten, Firewalls und Verbindungszeitbeschränkungen müssen das zulassen, sonst zeigt sich das Problem als scheinbar zufälliges Aussetzen der Aktualisierung – der häufigste Fehler bei Erstinstallationen.
Zur Skalierung: Für ein Team von einigen Dutzend Personen genügt eine überschaubare Maschine. Der Bedarf wächst weniger mit der Zahl der Konten als mit der Zahl gleichzeitig verbundener Clients, der Nachrichtenrate und dem Dateivolumen. Wachstumspfade sind der Ausbau der Datenbank, der Betrieb mehrerer Anwendungsinstanzen hinter einem Verteiler und die Auslagerung von Dateien. Belastbare Größenempfehlungen für Ihre Konstellation sollten Sie beim Anbieter oder Ihrem Dienstleister für den aktuellen Stand erfragen, statt sie aus fremden Erfahrungsberichten zu übernehmen.
Drei Betriebsdisziplinen entscheiden darüber, ob eine Installation nach zwei Jahren noch vertretbar ist. Sicherung und Wiederherstellung: Gesichert werden müssen Datenbank, Dateianhänge und Konfiguration – und zwar gemeinsam, weil eine Datenbank ohne die passenden Dateien nur die halbe Wahrheit enthält. Entscheidend ist nicht die Sicherung, sondern die geprobte Wiederherstellung. Wer sie nie geübt hat, hat keine Sicherung, sondern eine Hoffnung.
Aktualisierung: Eine Kommunikationsplattform mit Zugang aus dem Internet muss auf einem gepflegten Stand bleiben. Etablieren Sie einen festen Rhythmus, prüfen Sie Versionshinweise auf Datenbankanforderungen und Änderungen an Schnittstellen, aktualisieren Sie zuerst eine Testinstanz und prüfen Sie dort Ihre Erweiterungen. Größere Versionssprünge in einem Schritt sind die klassische Ursache für längere Ausfälle; kleine, regelmäßige Schritte sind langweiliger und deutlich billiger.
Überwachung: Erreichbarkeit, Datenbankzustand, Speicherplatz, Zertifikatslaufzeiten und Fehlerraten gehören in Ihre Überwachung – mit Alarmierung an Menschen, die reagieren dürfen. Ergänzend gehört die Frage geklärt, wie Beschäftigte einen Ausfall melden, wenn das Meldewerkzeug selbst ausgefallen ist. Ein Ersatzweg über Telefon oder E-Mail klingt banal und fehlt in überraschend vielen Betriebskonzepten.
Fast jede Einführung ist eine Ablösung. In der Praxis kommen drei Ausgangslagen vor, und sie verlangen unterschiedliche Vorgehen.
Ablösung eines Cloud-Chats: Wenn Slack oder ein vergleichbarer Dienst im Einsatz ist, existieren Exportwege für Nachrichten und Kanäle sowie Werkzeuge, die daraus einen Import erzeugen. Rechnen Sie damit, dass die Übernahme nicht verlustfrei ist: Anhänge, Threads, Reaktionen, Erwähnungen, private Nachrichten und Kanalzuordnungen verhalten sich unterschiedlich, und der Umfang des Exports hängt vom Tarif der Quelle ab. Unsere Empfehlung ist meist ein pragmatischer Schnitt: den aktiven Nachrichtenbestand übernehmen, das Archiv für eine Übergangszeit lesend verfügbar halten und ein Stichtagsdatum kommunizieren. Der Versuch, jede Reaktion aus vier Jahren zu retten, kostet mehr als er wert ist.
Ablösung von Microsoft Teams: Hier ist der Schnitt schwieriger, weil Teams selten nur Chat ist. An den Teams hängen Dateien, Besprechungen, Kalender und oft Prozesse. Eine Ablösung ist deshalb ein Architekturprojekt: Wohin gehen die Dateien, wohin die Besprechungen, was bleibt gegebenenfalls in der Office-Welt? Wer nur den Chat verschiebt und die Dateien liegen lässt, erzeugt zwei Wahrheiten.
Ablösung privater Messenger: Der häufigste und in der Praxis dringendste Fall. Wenn Schichtplanänderungen und Kundendaten über private Gruppen auf privaten Telefonen laufen, gibt es keinen Export – und das ist gut so, weil dieser Zustand datenschutzrechtlich ohnehin problematisch ist. Hier ist die Aufgabe keine Migration, sondern eine Ablösung mit Kommunikation, Regelwerk und einem sehr überzeugenden ersten Nutzen.
Die Frage nach dem Aufwand lässt sich nicht in Stunden beantworten, aber in Kategorien. Für eine mittelständische Installation mit einigen hundert Konten fallen dauerhaft an: ein regelmäßiges Aktualisierungsfenster mit Vorprüfung auf einer Testinstanz, die Kontrolle von Sicherungen und mindestens eine geübte Wiederherstellung im Jahr, die Bearbeitung von Konten- und Rechtefragen, die Pflege der Raumstruktur, die Betreuung von Erweiterungen und die Reaktion auf Störungen. Hinzu kommt ein fachlicher Anteil: jemand, der die Nutzung im Blick hat, Regeln nachschärft und neue Anwendungsfälle begleitet.
In Summe ist das im Mittelstand typischerweise ein anteiliger Personalbedarf, keine Vollzeitstelle – aber ein Bedarf, der benannt und zugeordnet sein muss. Der wichtigste Satz dieses Kapitels lautet deshalb: Wenn Sie die Frage, wer diese Plattform in achtzehn Monaten betreut, nicht mit einem Namen beantworten können, entscheiden Sie sich für einen betreuten Betrieb. Das ist keine Schwäche, sondern eine ehrliche Bewertung der eigenen Leistungsfähigkeit – und es ist deutlich günstiger als eine ungepflegte Installation, die irgendwann sicherheitsrelevant wird.
Wenn ein Szenario den Aufwand einer Einführung wirtschaftlich rechtfertigt, ist es dieses. Die Ausgangslage ist im Mittelstand fast überall dieselbe: Anfragen kommen über ein Sammelpostfach, über das Kontaktformular, über die Durchwahl einer Person und zunehmend über Messenger, die einzelne Mitarbeitende auf ihren Geräten betreuen. Niemand hat einen Überblick über Aufkommen, Bearbeitungsdauer oder wiederkehrende Themen, und bei Krankheit oder Urlaub liegen Anfragen still.
Omnichannel ändert das an drei Stellen. Erstens landen Anfragen in einer gemeinsamen Warteschlange mit Vertretungsregelung, statt an einzelnen Personen zu hängen. Zweitens entsteht ein Verlauf: Wer später übernimmt, sieht, was besprochen wurde. Drittens entsteht eine Auswertungsgrundlage, aus der sich ableiten lässt, welche Fragen so häufig sind, dass sie in eine Selbstauskunft oder in eine Automatisierung gehören.
Zwei Bedingungen entscheiden über den Erfolg. Die erste ist das Besetzungskonzept: Ein Chat-Fenster, das nicht besetzt ist, erzeugt Erwartungen und enttäuscht sie. Definieren Sie Zeiten, Vertretung und das Verhalten außerhalb der Zeiten – und zeigen Sie das dem Besucher. Die zweite ist die Erwartung an Bearbeitungszeit: Chat wird als Echtzeitmedium wahrgenommen. Wenn Sie das nicht leisten können, ist ein Formular mit klarer Rückmeldefrist die bessere Wahl.
Dieses Szenario hat den größten sichtbaren Nutzen und den größten Vorbereitungsaufwand. In einem typischen Produktionsbetrieb arbeitet nur ein Teil der Belegschaft am Rechner. Der Rest erfährt Betriebliches über Aushänge, über Vorgesetzte oder über eine private Messenger-Gruppe, die vor Jahren jemand angelegt hat und in der heute Schichtpläne, Krankmeldungen und gelegentlich Kundendaten kursieren. Dieser Zustand ist verbreitet, datenschutzrechtlich problematisch und der eigentliche Anlass vieler Projekte.
Damit eine betriebliche Plattform diesen Zustand ablöst, müssen drei Fragen vor dem Rollout beantwortet sein. Die Gerätefrage: Nutzen Beschäftigte private Telefone, und auf welcher Grundlage? Das ist keine technische, sondern eine arbeitsrechtliche und mitbestimmungsrelevante Frage. Alternativen sind Betriebsgeräte, gemeinsam genutzte Terminals in Pausenräumen oder eine freiwillige Nutzung mit klaren Regeln – jede Variante hat Folgen für Kosten und Akzeptanz.
Die Kontenfrage: Diese Gruppe hat häufig keine geschäftliche E-Mail-Adresse. Klären Sie, wie Anmeldung, Kontoanlage, Kennwortrücksetzung und Sperrung beim Austritt funktionieren – und wer das operativ macht. Die Nutzenfrage: Eine Anwendung, die nur Unternehmensnachrichten enthält, wird nach zwei Wochen nicht mehr geöffnet. Was diese Gruppe interessiert, ist der Schichtplan, der Diensttausch, die Urlaubsübersicht, die Ansprechperson in der Personalabteilung. Beginnen Sie mit Nutzwert, nicht mit Kommunikation – dann erreicht auch die Sicherheitsmeldung ihre Leserschaft.
Im Gesundheitswesen, bei Betreibern kritischer Infrastruktur, in behördennahen Unternehmen und bei Zulieferern mit Vertraulichkeitsauflagen ihrer Auftraggeber ist die Auswahl häufig vorentschieden: Ein Cloud-Dienst außerhalb des eigenen Verantwortungsbereichs kommt nicht in Frage. In diesen Konstellationen ist Rocket.Chat nicht deshalb attraktiv, weil es mehr Funktionen hätte, sondern weil es überhaupt zur Auswahl steht.
Für diese Fälle gelten drei Ergänzungen zum üblichen Vorgehen. Erstens gehört die Zuordnung von Vertraulichkeitsstufen zu Raumtypen ins Konzept: Welche Inhalte dürfen in reguläre Räume, welche nur in Ende-zu-Ende-verschlüsselte, welche gar nicht in den Chat. Zweitens gehört die Nachweisfähigkeit geplant: Protokollierung, Aufbewahrung, Export für Auskunftsverlangen und die Frage, wie ein Löschverlangen umgesetzt wird. Drittens gehört die Mitbestimmung früh an den Tisch, weil eine Kommunikationsplattform mit Anwesenheitsanzeige, Lesebestätigungen und Auswertungsmöglichkeiten regelmäßig mitbestimmungspflichtige Tatbestände berührt. Eine frühzeitige Betriebsvereinbarung ist einfacher als eine nachträgliche Auseinandersetzung – und sie schützt am Ende auch die Beschäftigten.
Die Gesamtkosten setzen sich aus fünf Blöcken zusammen, von denen höchstens der erste auf einem Angebot steht – und der teuerste steht dort nie.
Diesen Kosten steht ein benennbarer Nutzen gegenüber: weniger Sammelmails und weniger Suchzeit, erreichbare Beschäftigte ohne Bürorechner, kürzere Reaktionszeiten bei Störungen, gebündelte Kundenanfragen mit nachvollziehbarem Verlauf, das Ende privater Messenger-Gruppen mit betrieblichen Daten und eine reduzierte Abhängigkeit von einem einzelnen Anbieter. Wir empfehlen, diese Nutzenerwartung vor der Einführung schriftlich zu fixieren – mit zwei oder drei einfachen Messpunkten –, damit nach zwölf Monaten überprüfbar ist, ob sie eingetreten ist.
Der stärkste Datenschutzvorteil einer selbstbetriebenen Plattform ist strukturell: Wenn Nachrichten, Dateien, Anmeldedaten und Auswertungsdaten Ihre Infrastruktur nicht verlassen, entfallen die schwierigsten Fragen. Es gibt keinen Drittlandtransfer zu begründen, keine Kette von Unterauftragsverarbeitern zu bewerten und keine Diskussion über behördliche Zugriffsmöglichkeiten in fremden Rechtsräumen. In Ausschreibungen mit Standortauflagen ist das häufig der entscheidende Punkt, und in der Diskussion mit Datenschutzbeauftragten spart es erheblich Zeit.
Zwei Einschränkungen gehören zur ehrlichen Darstellung. Erstens: Selbstbetrieb verlagert die Verantwortung, er beseitigt sie nicht. Sie sind dann selbst für angemessene technische und organisatorische Maßnahmen zuständig – Zugriffsschutz, Verschlüsselung im Transport und im Speicher, Protokollierung, Löschkonzepte, Sicherungsschutz. Eine schlecht gepflegte eigene Installation ist datenschutzrechtlich nicht besser als ein gut geführter Dienst, sondern schlechter.
Zweitens: Datenhoheit ist keine Eigenschaft, die Sie mit der Betriebsentscheidung ein für alle Mal erwerben. Sie ist eine Eigenschaft, die Sie bei jeder Funktionsaktivierung erneut prüfen. Push-Benachrichtigungen, Marktplatzabfragen, Telemetrie, externe KI-Dienste, Messenger-Anbindungen und Übersetzungsdienste sind jeweils potenzielle Wege nach außen. Führen Sie eine kurze Liste, welche dieser Wege in Ihrer Installation aktiv sind, und halten Sie sie aktuell. Diese Liste ist bei einer Prüfung mehr wert als jede Produktzusicherung.
Push-Vermittlung. Mobile Benachrichtigungen erreichen Telefone im Regelfall über die Dienste der Betriebssystemhersteller. Das bedeutet: Selbst bei einer Installation im eigenen Keller läuft ein Teil des Benachrichtigungsweges über externe Infrastruktur. Wie viel Inhalt dabei übermittelt wird, hängt von Ihrer Konfiguration ab – Vorschauen lassen sich reduzieren, sodass nur ein Hinweis ohne Nachrichtentext ankommt. Für Umgebungen mit hohen Anforderungen ist zu prüfen, welche Möglichkeiten es gibt, die Vermittlung selbst zu betreiben, und mit welchen Einschränkungen das verbunden ist.
Telemetrie und Außenverbindungen. Selbstbetriebene Software fragt häufig Aktualisierungen, Marktplatzinhalte oder Nutzungsstatistiken ab. Das ist meist harmlos und muss trotzdem bekannt und dokumentiert sein – nicht zuletzt, weil ein Betrieb in abgeschotteten Netzen genau diese Verbindungen berücksichtigen muss. Sichten Sie die entsprechenden Einstellungen einmal vollständig und schreiben Sie Ihre Entscheidungen auf.
Auswertung und Mitbestimmung. Anwesenheitsanzeige, Lesebestätigungen, Antwortzeitauswertung im Kundenservice und Nutzungsstatistiken sind fachlich wertvoll und arbeitsrechtlich heikel, weil sie eine Verhaltens- und Leistungskontrolle ermöglichen können. Diese Funktionen gehören ausdrücklich auf die Agenda der Mitbestimmung, bevor sie aktiviert werden. Praktikabel ist meist eine Vereinbarung, die Auswertungen auf aggregierter Ebene erlaubt und personenbezogene Auswertungen ausschließt – mit klar begründeten Ausnahmen, etwa für den Nachweis sicherheitsrelevanter Unterweisungen.
Fünf Punkte gehören in jede Einführung. Erstens die Auftragsverarbeitungsverträge mit allen Beteiligten und die Aufnahme der Verarbeitung in das Verzeichnis – beim reinen Eigenbetrieb entsprechend die eigene Verantwortlichkeit sauber beschrieben. Zweitens ein Rollen- und Berechtigungskonzept: Wer legt Kanäle an, wer darf Nachrichten an alle senden, wer verwaltet Konten, wer darf Verläufe exportieren? Drittens eine Nutzungsrichtlinie mit einer klaren Aussage, welche Datenkategorien ausdrücklich nicht in den Chat gehören – Gesundheitsdaten, Personalvorgänge, Bewerbungsunterlagen, Zahlungsdaten. Weil Chat so bequem ist, entsteht dieses Risiko in der Praxis regelmäßig, nicht durch böse Absicht, sondern durch Gewohnheit.
Viertens die Einbindung der Mitbestimmung zu Anwesenheit, Lesebestätigungen, Auswertung, mobiler Nutzung und Gerätefrage. Fünftens Regeln zu Aufbewahrung, Archivierung und Löschung, einschließlich der Frage, was mit Nachrichten und Direktgesprächen beim Ausscheiden einer Person geschieht. Diese Frage klingt technisch und ist in Wahrheit die häufigste Lücke in Datenschutzkonzepten für Chat-Plattformen.
