Internes Wiki: Tools, Struktur und das Wiki, das aus dem Channel-Verlauf wächst (2026)

Ein internes Wiki ist die Sammlung von Seiten, die eine Organisation für sich selbst schreibt und für niemanden sonst: wie ein neuer Distributor eingerichtet wird, wo die aktuelle Preisliste liegt, was im Juni über Rabatte entschieden wurde, wen man anruft, wenn der Spediteur zu spät ist. Es ist intern, weil die Leserschaft aus Kolleginnen und Kollegen besteht, und es ist ein Wiki, weil jedes Mitglied eine Seite schreiben kann und jede Seite auf eine andere verlinken kann. Eine Organisation mit 10–200 Personen hat ein solches Wiki an dem Tag, an dem eine zweite Person dieselbe Frage stellt. Die einzige Wahl ist, ob die Seiten existieren oder die Antwort im Kopf eines Kollegen und in einem Dutzend Chat-Threads liegt.

Die meisten Ratgeber zu internen Wikis sind Software-Listen. Dieser beginnt früher, denn das Tool ist die kleinste der Entscheidungen: Ein Wiki, das funktioniert, ist eine Struktur, in der sich Menschen zurechtfinden, ein Seitenformat, das stimmig bleibt, und ein Ort, den das Team ohnehin jeden Tag öffnet. Zuerst kommt das Handwerk – die Struktur, eine Seitenvorlage zum Kopieren, ein durchgespieltes Beispiel aus einer Klinik. Danach die Mechanik: wo das Wiki in den Tools lebt, die Ihr Team bereits nutzt (laut deren eigener Dokumentation), und was jedes davon mit dem Meeting macht, in dem die Regel tatsächlich festgelegt wurde. Denn der Test eines Wikis ist nicht der Tag, an dem es startet. Es ist der Montag, an dem eine neue Kollegin es öffnet und die Seite in einer Sprache findet, die sie liest.

Was ein internes Wiki ist – und was nicht

Vier Dinge werden Wiki genannt, und die Verwechslung zwischen ihnen ist der Grund, warum so viele gebaut und so wenige geöffnet werden:

Das Wiki ist die erste Zeile, und es ist diejenige, von der die anderen drei abhängen. Eine Wissensdatenbank ist ein Wiki mit erzwungener Struktur: ein Eintrag pro Frage und eine zuständige Person für jeden. Die Methode, eine in 30 Tagen aufzubauen, steht in diesem Leitfaden, und dieser hier handelt von der eigenen Form des Wikis. Das Intranet ist das, was aus dem Wiki wird, wenn nur drei Personen schreiben dürfen. Das gemeinsame Laufwerk ist der Ort, an dem die Dateien des Wikis liegen, und die Aufgabe des Wikis ist es, auf die aktuelle zu zeigen. Ein Wiki ist auch kein Prozessdokument und keine SOP: Diese beschreiben eine Aufgabe von Anfang bis Ende, eine Wiki-Seite sagt, wo man sie findet und was sich seither geändert hat.

Was ein Wiki intern macht, ist nicht ein Passwort. Es sind die Wörter, in denen die Seiten geschrieben sind, die das Team benutzt – „die Casablanca-Regel“, „die Dienstagstour“ –, und dass sie sagen können, was eine externe Seite nie könnte: wer entschieden hat, warum und was dadurch ersetzt wurde.

Die Struktur: sieben Bereiche, eine Seite pro Frage

Der Unterschied zwischen einem Wiki, das Menschen öffnen, und einem, das sie nicht mehr öffnen, liegt selten im Tool. Es sind drei Entscheidungen, die vor der ersten Seite getroffen werden oder eben nicht.

Bereiche nach Fragen, nicht nach Abteilungen. Die Kollegin, die fragt „Wie stellen wir einem Distributor in der Schweiz eine Rechnung?“, weiß nicht, ob die Antwort zu Finanzen, Vertrieb oder Logistik gehört; sie kennt nur die Frage. Ein nach Abteilungen gegliedertes Wiki schickt sie durch drei Bereiche, um eine Seite zu finden. Gliedern Sie nach den Fragen, die Menschen stellen, in ihren Worten, und halten Sie die oberste Ebene bei sieben Bereichen oder weniger. Darüber braucht die Struktur selbst eine Suche, und eine Suche über ein Wiki, das noch niemand gefüllt hat, liefert nichts. Typische oberste Ebenen für eine kleine Organisation: Kunden und Aufträge; Geld und Rechnungsstellung; Personal und Einstellung; Tools und Zugänge; Regeln und Entscheidungen; Wen anrufen.

Eine Seite pro Frage, unter einer Bildschirmseite. Eine Seite, die eine Frage beantwortet, wird gefunden und gelesen; eine Seite, die eine ganze Funktion erklärt, wird als Lesezeichen gesetzt und überflogen. „Wie stellen wir der Schweiz Rechnungen?“ ist eine Seite. „Finanzen“ ist ein Bereich. Braucht eine Seite ein Inhaltsverzeichnis, sind es zwei Seiten.

Eine zuständige Person und ein Datum auf jeder Seite. Einer Seite, die sagt, wer für sie zuständig ist und wann sie zuletzt geprüft wurde, glaubt man; derselbe Text ohne beides ist „wahrscheinlich veraltet“. Die Aufgabe der zuständigen Person ist klein – einmal im Quartal die Frage „Stimmt das noch?“ beantworten und das Datum ändern –, und sie ist das Einzige, was ein Wiki über sein erstes Jahr hinaus am Leben hält. Eine Seite, für die sich niemand nennen lässt, ist kein Wissen, sondern eine Vermutung, und sie fliegt raus.

Zwei Gewohnheiten erhalten die Struktur, sobald sie steht. Jede Antwort im Channel des Teams, die zweimal gefragt wird, wird zur Seite, geschrieben von der Person, die geantwortet hat, und verlinkt aus dem Bereich, zu dem sie gehört. Und jede Entscheidung, die eine Regel ändert, bekommt zuerst ihre Zeile im Entscheidungsprotokoll, dann verlinkt die Seite, die die Regel nennt, darauf – so kann die Seite sechs Monate später nicht nur sagen, wie die Regel lautet, sondern auch warum.

Wie Sie in einer Woche ein internes Wiki aufbauen

Der Plan geht von einer Person aus, die das Ganze vorantreibt – die Teamleitung oder wer am häufigsten gefragt wird –, und vom Rest des Teams, der nur Minuten aufwendet.

Tag 1 – Wählen Sie den Ort danach, wo das Team ohnehin liest. Nicht nach einem Software-Vergleich. Das Wiki lebt dort, wo die Fragen gestellt werden: im Channel des Teams, in der Suite, in der die Dateien schon liegen. Ein Wiki in einem fünften Tool mit eigenem Login ist ein Wiki, das am Montagmorgen niemand öffnet. Die Tabelle weiter unten zeigt, was jeder Ort aufbewahrt und wo er jeweils endet.

Tage 1–3 – Sammeln Sie die Fragen, nicht die Antworten. Posten Sie eine Nachricht im Channel: „Antwortet mit jeder Frage, die ihr diese Woche einer Kollegin oder einem Kollegen gestellt habt, in den Worten, die ihr benutzt habt.“ Bis Tag drei sind es vierzig bis sechzig, ein Drittel davon Dubletten. Zählen Sie die Wiederholungen: Die Frage, die fünfmal gestellt wurde, ist Seite eins.

Tag 4 – In sieben Bereiche sortieren, zuständige Personen benennen. Die Gruppen, in die die Fragen fallen, sind die Bereiche. Benennen Sie pro Bereich eine zuständige Person – die, die die meisten seiner Fragen beantwortet hat – und je eine für die ersten fünfzehn Seiten. Schreiben Sie noch nichts außer der Liste: Bereich, Frage, zuständige Person. Schicken Sie sie mit einer Frage ans Team zurück: „Was fehlt?“

Tage 5–7 – Die ersten fünfzehn Seiten, aus dem, was schon existiert. Jede zuständige Person schreibt ihre Seiten mit der Vorlage unten, ausgehend von der Chat-Antwort, dem Recap des Meetings, in dem die Regel festgelegt wurde, der im März angehängten Datei. Die Regel für die erste Woche lautet „kurz und wahr schlägt lang und vollständig“: Eine Antwort in zwei Sätzen mit Link zur Datei, datiert und gezeichnet, ist eine Seite. Dann pinnen Sie den Bereichsindex dort, wo das Team liest, und das Wiki existiert.

Was in dieser Woche nicht passiert: das gemeinsame Laufwerk migrieren, für jeden Prozess eine Seite schreiben, ein neues Tool auswählen. Das Wiki zeigt auf Dateien dort, wo sie liegen, und auf Verfahren dort, wo sie leben.

Eine Seitenvorlage für ein internes Wiki

Eine Seite, eine Frage, unter einer Bildschirmseite. Kopieren Sie sie als Notiz und füllen Sie sie aus. Die letzten drei Zeilen werden am häufigsten übersprungen, und gerade sie halten die Seite wahr.

[Frage, in den Worten, in denen Menschen sie stellen]
Zuständig: [Name] · Bereich: [einer der sieben] · Zuletzt geprüft: [Datum] · Nächste Prüfung: [Datum]
Kurze Antwort: [zwei Sätze – was zu tun ist]
Gilt für: [Team, Standort, Kundentyp] · Gilt nicht für: [der Fall, den man damit verwechselt]
Vorgehen: [nummerierte Schritte, jeder mit dem beteiligten System, der Person oder der Datei]
Die Regel dahinter: [die Entscheidung, die sie festgelegt hat, mit Datum und Begründung – Entscheidungsprotokoll verlinken]
Ausnahmen: [die Fälle abseits des Normalwegs und wer jeweils entscheidet]
Wo die Dateien liegen: [Link zur aktuellen Vorlage, Preisliste, zum Vertrag]
Verwandte Seiten: [die SOP, der Prozess, die vorherige Version dieser Seite]

Die Vorlage ist reiner Text mit fetten Beschriftungen und lässt sich daher ohne Neuformatierung in eine Word-Datei, ein Google Doc, eine Wiki-Seite, ein Slack-Canvas oder eine Chat-Notiz einfügen.

Ein durchgespieltes Beispiel: das Wiki einer Klinik nach einer Woche

Eine Physiotherapie-Klinik in Barcelona, 24 Personen: ein Empfang mit vier, vierzehn Therapeuten, zwei in der Abrechnung, der Rest Verwaltung. Die Hälfte des Therapieteams ist in den letzten zwei Jahren aus Argentinien, Kolumbien und der Ukraine dazugekommen; ein Drittel der Patienten sind britische und deutsche Residenten, die auf Englisch buchen. Drei Tage Sammeln ergaben 52 Fragen, nach Abzug der Dubletten 37. Die Struktur, die daraus entstand, mit den Seiten pro Bereich an Tag sieben:

1. Patienten und Termine (5) – wie ein Ersttermin gebucht wird; was bei einem Nichterscheinen zu tun ist; wie ein Patient den Therapeuten wechselt
2. Abrechnung und Versicherung (4) – welche Versicherer direkt abgerechnet werden; wie eine Quittung für einen ausländischen Versicherer ausgestellt wird; wann eine Sitzung erstattet wird
3. Behandlungsprotokolle (3) – wo die Protokollblätter liegen; wer einen Behandlungsplan freigibt; was nach jeder Sitzung dokumentiert wird
4. Tools und Zugänge (2) – wer Zugang zum Buchungssystem vergibt; wo die Vorlagen für Patientenbriefe liegen
5. Regeln und Entscheidungen (2) – die 24-Stunden-Stornoregel; das Entscheidungsprotokoll
6. Wen anrufen (1) – die Kontakte der Versicherer; die Service-Hotline für die Geräte

Siebzehn Seiten. Die am häufigsten gestellte Frage – „Wie stellen wir eine Quittung aus, die ein deutscher Versicherer akzeptiert?“ – war am Empfang im Lauf eines Jahres neunmal von derselben Abrechnungsleitung beantwortet worden. Die Seite kostete sie fünfzehn Minuten, weil die neunte Antwort bereits im Channel stand und nur noch die Zeile mit der zuständigen Person und das Datum brauchte.

Eine ausgefüllte Seite aus Bereich 2:

Wie stellen wir eine Quittung aus, die ein ausländischer Versicherer akzeptiert?
Zuständig: Abrechnungsleitung · Bereich: Abrechnung und Versicherung · Zuletzt geprüft: 6. November 2026 · Nächste Prüfung: 6. Februar 2027
Kurze Antwort: Verwenden Sie die Vorlage „Versicherer-Quittung“, in der Sprache des Patienten, mit dem Diagnosecode und der Zulassungsnummer des Therapeuten in jeder Zeile.
Gilt für: Patienten, die selbst zahlen und bei einem Versicherer im Ausland einreichen · Gilt nicht für: Versicherer, die wir direkt abrechnen und die die Monatsabrechnung erhalten.
Vorgehen: 1. Den Patienten im Buchungssystem öffnen. 2. Die Vorlage „Versicherer-Quittung“ wählen. 3. Den Diagnosecode aus dem Behandlungsplan ergänzen. 4. Prüfen, dass die Zulassungsnummer in jeder Zeile steht. 5. Als PDF senden und eine Kopie im Patientenordner ablegen.
Die Regel dahinter: Die Zulassungsnummern wurden nach den Ablehnungen durch deutsche Versicherer im April 2026 ergänzt (Eintrag im Entscheidungsprotokoll 2026-04-22).
Ausnahmen: Ein Patient, der eine nach Sitzungen aufgeschlüsselte Quittung braucht, wendet sich an die Abrechnungsleitung; niemand sonst stellt sie aus.
Wo die Dateien liegen: Vorlage Versicherer-Quittung; Liste der Diagnosecodes; Patientenordner.
Verwandte Seiten: Welche Versicherer direkt abgerechnet werden; wann eine Sitzung erstattet wird.

Wo das Wiki in den Tools lebt, die Sie bereits nutzen

Eine Organisation mit 10–200 Personen baut ihr Wiki in der Suite, die sie bereits bezahlt, und jede Suite hat einen Ort für die Seite, einen Ort für die Dateien und einen Weg für das, was ein Meeting hinterlässt. Jede endet an einer anderen Stelle, und in jeder liegt die Seite in der Sprache, in der sie getippt wurde. Nur dokumentiertes Verhalten, aus den eigenen Seiten der Hersteller, mit dem Monat, in dem die jeweilige Seite geprüft wurde:

Drei Dinge sind in allen vieren gleich. Die Seite ist ein Dokument oder eine Nachricht in der einen Sprache, in der sie getippt wurde, und ein Mitglied, das eine andere Sprache liest, liest diese oder eine Kopie, die jemand angefertigt hat. Die Dateien liegen an einem zweiten Ort, gefunden über eine zweite Suche. Und das Meeting – wo die Regel diskutiert und festgelegt wurde – erreicht das Wiki nur, wenn danach eine Person es eintippt. Ob und wie Teams und Meet überhaupt ein Transkript und eine Zusammenfassung aufbewahren und wie Sie diese nach dem Call sichern, steht in wo Microsoft Teams und Google Meet Transkript, Aufzeichnung und Zusammenfassung speichern. Die KI-Notetaker, die viele Teams aus demselben Grund ergänzen, werden in Otter.ai-Alternativen verglichen, und jeder von ihnen schreibt seine Zusammenfassung in einer Sprache.

Die Übersetzung, die diese Suiten dokumentieren, gehört zum Call oder zum Bildschirm der lesenden Person, nicht zur Seite: Microsoft dokumentiert übersetzte Live-Untertitel in Teams-Meetings, wenn der Organisator eine Teams-Premium- oder Microsoft-365-Copilot-Lizenz hat, Google dokumentiert übersetzte Untertitel in Meet in berechtigten Workspace-Tarifen (beides geprüft im August 2026), und WhatsApp dokumentiert das Übersetzen einer empfangenen Nachricht auf dem Telefon der lesenden Person (geprüft im August 2026). Was jedes davon abdeckt und wo es endet, steht in Live-Übersetzung in Microsoft Teams, Live-Übersetzung in Google Meet und WhatsApp übersetzen. Die Quittungsseite, die die ukrainischsprachige Therapeutin am Montag öffnet, ist ein anderes Objekt als diese Untertitel, und sie wird in der Sprache gelesen, in der sie getippt wurde.

Das Wiki, das aus dem Channel-Verlauf wächst

InterMIND ist ein Kommunikationsraum, in dem die Arbeit eines Teams in einem Channel lebt, und deshalb hat das Wiki ein naheliegendes Zuhause: den Channel des Teams, das es nutzt – der Empfang der Klinik, das Export-Team, die Kundengruppe der Agentur. Dieser Channel ist auch der Ort, an dem die Fragen gestellt werden und von dem aus die Meetings starten. Die drei Entscheidungen von oben lassen sich direkt darauf übertragen.

Die Seiten und ihre zuständigen Personen sind Notizen im Channel. Eine Notiz ist eine Rich-Text-Nachricht mit Überschriften und nummerierten Listen, die später über ihr eigenes Menü bearbeitet wird. Jedes Mitglied liest sie in der eigenen Sprache, das Original ist einen Klick entfernt; angepinnt ist der Bereichsindex das Erste, was eine neue Kollegin findet. Ist der Bearbeitungsverlauf eingeschaltet, erscheint die frühere Formulierung einer geänderten Regel über dem aktuellen Text als Diff auf Wortebene mit Zeitstempel – die Prüfspur, auf die die Zeile „Zuletzt geprüft“ der zuständigen Person verweist. Die Dateien, auf die eine Seite zeigt – die Quittungsvorlage, die Liste der Diagnosecodes, der Versicherungsvertrag –, werden in denselben Channel hochgeladen und tragen in jedem Tarif eine KI-Zusammenfassung in der Sprache der lesenden Person, bei der jeder Punkt mit dem Absatz verlinkt ist, aus dem er stammt; in bezahlten Tarifen öffnet sich die Datei selbst übersetzt in die Sprache der lesenden Person (30 Sprachen für Dokumente). Bleibt die Masterkopie in einem Dokument-Tool, landen deren Aktualisierungen per E-Mail im Channel: Der Host des Channels gibt ihm eine eigene Adresse, und eine dorthin gesendete Nachricht erscheint als reguläre Nachricht mit benanntem Absender und erhaltenen Anhängen. Ein Team, das von Slack kommt, bringt seine Channels mit: Ein standardmäßiger Slack-Workspace-Export wird als ein Channel pro Slack-Channel wiederhergestellt, mit Nachrichten in der richtigen Reihenfolge und mit ihren ursprünglichen Zeitstempeln, mit erhaltenen Pins und Reaktionen, und jede Nachricht wird von jedem Mitglied in der eigenen Sprache gelesen.

Der Verlauf hinter jeder Seite ist der Punkt, an dem der Channel die Arbeit übernimmt, die die Tabelle oben einer Person überlässt. Das Meeting, in dem die Regel festgelegt wird, startet aus dem Channel; während des Calls erscheint die Entwurfsseite mit Share to conference auf dem Bildschirm aller neben den Videokacheln – eine Notiz oder ein im Chat verlinktes Google-Docs- oder OneDrive-Dokument –, und jede teilnehmende Person scrollt unabhängig und liest in der eigenen Sprache, während die teilende Person live bearbeitet. Wenn der Call endet, wird das Recap aus dem Meeting selbst geschrieben – eine Zusammenfassung, die Punkte, die als vereinbart, offen oder strittig markiert sind, die Action items mit zuständigen Personen, jede Zeile mit ihrem Zeitstempel –, und die während der Sitzung geteilten Dokumente steuern ihre Zusammenfassungen neben dem Gesagten bei. Es kommt per E-Mail, als Nachricht im Channel und als Link im Kalendereintrag, und jedes angemeldete Mitglied liest es in der eigenen Sprache: Die Aufzeichnung wird pro lesender Person übersetzt, nicht einmal in der Sprache geschrieben, die der Raum zufällig benutzt hat. Jedes Mitglied kann es bearbeiten, jede Änderung behält Autor und Versionsverlauf, und der Channel bewahrt das Recap jeder vergangenen Sitzung auf – das Meeting, das die Regel mit der Zulassungsnummer festgelegt hat, ist also einen Klick von der Seite entfernt, die sie nennt. Das ist das Wiki, das aus dem Channel-Verlauf wächst: die neunte Antwort am Empfang, das Recap des Calls, in dem die Regel diskutiert wurde, die im April angehängte Vorlage, alles an einem Ort, mit der Seite obendrauf. Neben der Tabelle oben betrachtet, ist der Unterschied eine nüchterne Tatsachenfeststellung: Die Untertitel, die diese Suiten dokumentieren, übersetzen den Call, während er läuft; hier sind die Seite, die Meetings, die sie hervorgebracht haben, ihre Dateien und ihr Verlauf eine einzige Aufzeichnung, gelesen von jedem Mitglied in der eigenen Sprache.

Der Fragen-Channel wird von der anderen Seite aus genauso behandelt. Der eigene Assistent eines Mitglieds – Claude, ChatGPT, Copilot oder Gemini, verbunden über den MCP-Connector – durchsucht Recaps, Transkripte, Chats und den Text geteilter Dateien in einer Frage, „Wie stellen wir eine Quittung aus, die ein deutscher Versicherer akzeptiert?“, und liefert die Passagen mit dem Meeting, dem Datum und der Datei, aus der sie jeweils stammen; das läuft für Organisationen mit aktivierten KI-Funktionen, und das Lesen über den Assistenten ist auf die Meetings und Channels beschränkt, in denen das Mitglied ist. Der Chat selbst hat eine Suche, und das Wiki lässt sich als Ganzes mitnehmen: In jedem Tarif exportiert ein Backup aus den Einstellungen die Channels als ZIP mit ihren Nachrichten, Transkriptionen und Dateien – die Frage nach dem Eigentum, beantwortet auf der Ebene der Organisation statt der einzelnen Seite.

Die Menschen, die das Wissen eines Teams halten, sind nicht immer Angestellte. Der Ansprechpartner des Versicherers für Leistungsfälle, der Gerätetechniker, die freiberufliche Buchhalterin, die die deutsche Quittungsregel kennt: Ein externes Mitglied des Channels tritt per E-Mail mit einem kostenlosen Konto bei und liest die Seiten und ihren Verlauf wie alle anderen. Eine Person ohne Konto ist Gast eines Meetings – sie tritt dem Call per Link bei, auch vom Telefon, ohne Kosten, hört ihn live in der eigenen Sprache und erhält danach keine Aufzeichnung. Der Host stellt den Raum bereit und zahlt in einem bezahlten Tarif nur für die in den vorherigen 28 Tagen aktiven Mitglieder – wer einem Meeting beigetreten ist, in einem Chat geschrieben oder den Assistenten gefragt hat. Mitglieder, die ruhig werden, behalten ihren Zugang kostenlos, und genau das braucht ein Wiki: Die Person, die die Seite vor zwei Jahren geschrieben hat, kann weiterhin im Channel sein.

• Ein vollständiges Recap öffnen – eine echte Aufzeichnung, erzeugt vom selben Code, der Ihre schreibt.
• Live-Demo ausprobieren – ohne Anmeldung; sprechen Sie, und hören Sie den Raum pro Zuhörer übersetzt.

Ein internes Wiki als Handwerk überlebt jedes Tool: Jemand muss weiterhin die Fragen sammeln, die Struktur auf sieben Bereiche begrenzen, auf jede Seite einen Namen und ein Datum setzen und im Channel antworten statt per Direktnachricht. Was nicht überleben muss, ist der zweite Job – das, was das Meeting entschieden hat, noch einmal ins Wiki zu tippen und von Hand eine übersetzte Kopie jeder Seite zu pflegen, eine Sprache nach der anderen, für die Kolleginnen und Kollegen, die die andere lesen.

FAQ

Was ist ein internes Wiki?

Ein internes Wiki ist eine Sammlung von Seiten, die eine Organisation für ihre eigenen Mitglieder schreibt – wie Dinge gemacht werden, wo Dateien liegen, was entschieden wurde und warum –, an einem Ort gehalten, an dem jedes Mitglied eine Seite schreiben kann und jede Seite auf eine andere verlinken kann. Es unterscheidet sich von einem öffentlichen Wiki durch seine Leserschaft, Kolleginnen und Kollegen statt Kunden, und vom Intranet dadurch, dass die Menschen, die die Arbeit tun, die Seiten schreiben und aktualisieren, nicht ein zentrales Team. Die Seiten, die geöffnet werden, sind die, die nach den Fragen der Menschen gegliedert sind, mit zuständiger Person und Prüfdatum auf jeder.

Was ist der Unterschied zwischen einem internen Wiki und einer Wissensdatenbank?

Ein Wiki ist eine Sammlung von Seiten, die jeder in beliebiger Struktur schreiben kann; eine Wissensdatenbank ist nach den Fragen der Menschen gegliedert, mit einem Eintrag pro Frage und einer benannten zuständigen Person samt Prüfdatum für jeden. Ein Wiki wird zur Wissensdatenbank, indem man Struktur und zuständige Personen ergänzt; ohne sie wächst es zu Hunderten von Seiten, in denen sich niemand zurechtfindet und die niemand geprüft hat. Die Software ist oft dieselbe, und die Methode, das eine in 30 Tagen in das andere zu verwandeln, steht in Wissensdatenbank aufbauen.

Wie erstellt man ein internes Wiki?

Wählen Sie den Ort danach, wo das Team ohnehin liest, nicht nach einem Software-Vergleich; sammeln Sie drei Tage lang die Fragen, die das Team tatsächlich stellt, in den benutzten Worten; sortieren Sie sie in höchstens sieben Bereiche und benennen Sie eine zuständige Person pro Bereich und pro Seite; schreiben Sie die ersten fünfzehn Seiten aus dem, was bereits existiert – der Chat-Antwort, dem Meeting-Recap, der Datei – mit einer einseitigen Vorlage aus kurzer Antwort, Schritten, Ausnahmen und Prüfdatum; pinnen Sie den Bereichsindex dort, wo das Team liest. Halten Sie dann den Kreislauf aufrecht: Jede Frage, die zweimal beantwortet wird, wird zur Seite, und die zuständige Person jeder Seite prüft sie zum angegebenen Datum.

Was gehört in ein internes Wiki?

Eine Seite pro Frage, jede mit der Frage in den Worten, die Menschen benutzen, einer zuständigen Person, dem Datum der letzten Prüfung und dem Datum der nächsten, einer kurzen Antwort, den Fällen, für die sie gilt und nicht gilt, den Schritten mit dem beteiligten System oder der beteiligten Person, der Entscheidung hinter der Regel mit ihrem Datum, den Ausnahmen und wer sie entscheidet, Links zu den aktuellen Dateien und Links zu verwandten Seiten. Das Wiki als Ganzes braucht eine Struktur aus sieben oder weniger Bereichen, gegliedert nach den gestellten Fragen statt nach Abteilungen, und einen Bereichsindex, der dort angepinnt ist, wo das Team liest.

Was ist das beste Tool für ein internes Wiki?

Das, das das Team ohnehin jeden Tag öffnet, denn ein Wiki in einem fünften Tool mit eigenem Login ist das Wiki, das am Montag niemand prüft. In Microsoft Teams liegen die Seiten und Dateien im Channel und seiner SharePoint-Website, mit Meeting-Notizen als Loop-Komponente; in Slack ein Canvas im Channel; in Google Workspace ein Google Doc, verlinkt aus dem Kalender; in WhatsApp der Gruppenchat selbst – jeweils mit den dokumentierten Grenzen in der Tabelle oben, und jedes hält die Seite in der Sprache, in der sie getippt wurde. InterMIND hält Notizen, Dateien, Chat und Meeting-Recaps eines Teams in einem Channel, von jedem Mitglied in der eigenen Sprache gelesen, neben diesen Tools statt anstelle von ihnen.

Kann man ein internes Wiki in Microsoft Teams aufbauen?

Laut der Dokumentation von Microsoft liegen die Dateien eines Teams auf einer SharePoint-Website, die mit dem Team erstellt wird, wobei alle Standardkanäle diese Website mit je einem Ordner pro Kanal teilen – der Dateien-Tab des Channels ist also der Ort, an dem Wiki-Dokumente liegen. Meeting-Notizen sind eine Loop-Komponente, die jede teilnehmende Person und der Organisator bearbeiten können, automatisch gespeichert und erreichbar über den Teams-Kalender und das Meeting-Recap. Zwei dokumentierte Grenzen sind für ein Wiki wichtig: Externe Teilnehmende können die Meeting-Notizen weder aufrufen noch bearbeiten, und Chats und Kanalnachrichten können nach einer Frist durch eine Teams-Aufbewahrungsrichtlinie gelöscht werden, während Dateien eigenen SharePoint- und OneDrive-Richtlinien folgen (Seiten geprüft im Oktober und November 2026).

Wie hält man ein internes Wiki aktuell?

Mit einer zuständigen Person und einem Prüfdatum auf jeder Seite, und sonst nichts. Die Aufgabe der zuständigen Person ist es, einmal im Quartal die Frage „Stimmt das noch?“ zu beantworten und das Datum zu ändern; eine Seite, deren zuständige Person gegangen ist, bekommt eine neue oder fliegt raus. Zwei Gewohnheiten speisen die Seiten: Jede Antwort, die im Channel des Teams zweimal gegeben wird, wird zur Seite, geschrieben von der Person, die geantwortet hat, und jede Entscheidung, die eine Regel ändert, wird zuerst protokolliert, damit die Seite darauf verlinken kann, warum sie sich geändert hat. Ein so geführtes Wiki wächst um eine Seite, sobald eine Frage beantwortet wird, und niemand schreibt es als Projekt neu.

Quellen: Microsoft Learn — Teams and SharePoint integration; Microsoft Learn — Learn about retention for Teams; Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Translate a message in Microsoft Teams; Microsoft — Use live captions in Microsoft Teams meetings; Slack — Pricing; Slack — Customize data retention in Slack; Slack — Export your workspace data; Slack — Meeting agenda template (canvas); Google Chat — Use Automatic Translation in Chat; Google Meet — "Take notes for me" in Google Meet; Google Meet — Use translated captions; WhatsApp — How to export your chat history; WhatsApp — Privacy policy; WhatsApp blog — Introducing message translations. Die Microsoft-Learn-Seite zu Teams und SharePoint wurde im November 2026 geprüft; die Seiten zur Teams-Aufbewahrung und zu den Meeting-Notizen, die Seite zur Slack-Canvas-Vorlage und die Google-Seite zu „Take notes for me“ im Oktober 2026; die Seiten zur Teams-Nachrichtenübersetzung und zu den Untertiteln, die Seiten zu Slack-Preisen, -Aufbewahrung und -Export, die Seiten zur Google-Chat-Übersetzung und zu den Meet-Untertiteln sowie die WhatsApp-Seiten im August 2026. Anbieter ändern im Lauf der Zeit Tarife, Funktionen und Sprachlisten; prüfen Sie deren Seiten auf den aktuellen Stand.