Interne wiki: tools, structuur en de wiki die uit de kanaalgeschiedenis groeit (2026)

Een interne wiki is de verzameling pagina's die een organisatie voor zichzelf schrijft en voor niemand anders: hoe een nieuwe distributeur wordt ingericht, waar de actuele prijslijst staat, wat er in juni over kortingen is besloten, wie je belt als de vervoerder te laat is. Hij is intern omdat de lezer een collega is, en het is een wiki omdat elk lid een pagina kan schrijven en elke pagina naar een andere kan linken. Een organisatie van 10–200 mensen heeft er een zodra een tweede persoon dezelfde vraag stelt. De enige keuze is of de pagina's bestaan, of dat het antwoord in het hoofd van één collega zit en in een dozijn chatthreads.

De meeste gidsen over interne wiki's zijn lijsten met software. Deze begint eerder, omdat de tool de kleinste van de beslissingen is: een wiki die werkt is een structuur waarin mensen kunnen navigeren, een paginaformaat dat klopt en een plek die het team toch al elke dag opent. Eerst komt het vakwerk: de structuur, een paginasjabloon dat je kunt kopiëren, een uitgewerkt voorbeeld van een kliniek. Daarna de techniek: waar de wiki leeft in de tools die je team al gebruikt, volgens hun eigen documentatie, en wat elk van die tools doet met de meeting waarin de regel daadwerkelijk is bepaald. Want de test van een wiki is niet de dag van de lancering. Het is de maandag waarop een nieuwe collega hem opent en de pagina vindt in een taal die hij leest.

Wat een interne wiki is — en wat niet

Vier dingen heten een wiki, en de verwarring daartussen is de reden dat er zoveel worden gebouwd en zo weinig worden geopend:

De wiki is de eerste rij, en de andere drie hangen ervan af. Een kennisbank is een wiki met afgedwongen structuur: één item per vraag en een eigenaar op elk item; de methode om er in 30 dagen een te bouwen staat in die gids, en deze gaat over de eigen vorm van de wiki. Het intranet is wat de wiki wordt wanneer maar drie mensen mogen schrijven. De gedeelde schijf is waar de bestanden van de wiki staan, en de taak van de wiki is om naar het actuele bestand te wijzen. Een wiki is ook geen procesdocument of SOP: die beschrijven één taak van begin tot eind; een wikipagina zegt waar je ze vindt en wat er sindsdien is veranderd.

Wat een wiki intern maakt, is niet een wachtwoord. Het is dat de pagina's zijn geschreven in de woorden die het team gebruikt — "de Casablanca-regel", "de dinsdagronde" — en dat ze kunnen zeggen wat een externe pagina nooit kan: wie het besloot, waarom en wat het verving.

De structuur: zeven secties, één pagina per vraag

Het verschil tussen een wiki die mensen openen en een wiki die ze niet meer openen, zit zelden in de tool. Het zijn drie beslissingen die vóór de eerste pagina wel of niet zijn genomen.

Secties op vraag, niet op afdeling. De collega die vraagt "hoe factureren we een distributeur in Zwitserland?" weet niet of het antwoord bij finance, sales of logistiek hoort; die kent de vraag. Een wiki die naar afdeling is ingedeeld stuurt hem langs drie secties om één pagina te vinden. Orden op de vragen die mensen stellen, in hun eigen woorden, en houd het bovenste niveau op maximaal zeven secties. Bij meer dan zeven heeft de structuur zelf een zoekfunctie nodig, en zoeken in een wiki die nog niemand heeft gevuld levert niets op. Typische bovenste niveaus voor een kleine organisatie: klanten en bestellingen; geld en facturatie; mensen en werving; tools en toegang; regels en besluiten; wie je belt.

Eén pagina per vraag, korter dan een scherm. Een pagina die één vraag beantwoordt wordt gevonden en gelezen; een pagina die een hele functie uitlegt wordt in de bladwijzers gezet en vluchtig doorgelezen. "Hoe factureren we Zwitserland?" is een pagina. "Finance" is een sectie. Als een pagina een inhoudsopgave nodig heeft, zijn het twee pagina's.

Een eigenaar en een datum op elke pagina. Een pagina die zegt wie hem beheert en wanneer hij voor het laatst is gecontroleerd wordt geloofd; dezelfde tekst zonder die gegevens is "waarschijnlijk verouderd". De taak van de eigenaar is klein — eens per kwartaal beantwoorden of het nog klopt en de datum aanpassen — en het is het enige dat een wiki voorbij het eerste jaar in leven houdt. Een pagina waarvoor niemand kan worden aangewezen is geen kennis maar een gok, en die gaat eruit.

Twee gewoontes houden de structuur in stand zodra hij bestaat. Elk antwoord in het kanaal van het team dat twee keer wordt gevraagd wordt een pagina, geschreven door wie het beantwoordde en gelinkt vanuit de sectie waar het hoort. En elk besluit dat een regel wijzigt krijgt eerst zijn regel in het besluitenlogboek, waarna de pagina die de regel vastlegt ernaar linkt — zodat de pagina zes maanden later niet alleen kan zeggen wat de regel is, maar ook waarom.

Een interne wiki maken in een week

Het plan gaat uit van één persoon die het trekt — de teamlead, of wie de meeste vragen krijgt — terwijl de rest van het team er minuten aan besteedt.

Dag 1 — kies de plek op basis van waar het team al leest. Niet op basis van een softwarevergelijking. De wiki leeft waar de vragen worden gesteld: het kanaal van het team, de suite waarin de bestanden al staan. Een wiki in een vijfde tool met een eigen login is een wiki die niemand op maandagochtend opent. De tabel verderop laat zien wat elke plek bewaart en waar elke ophoudt.

Dag 1–3 — verzamel de vragen, niet de antwoorden. Plaats één bericht in het kanaal: "Reageer met elke vraag die je deze week aan een collega hebt gesteld, in de woorden die je gebruikte." Op dag drie zijn het er veertig tot zestig; een derde zijn dubbelen. Tel de herhalingen: de vraag die vijf keer is gesteld is pagina één.

Dag 4 — sorteer in zeven secties, benoem de eigenaren. De groepen waarin de vragen vallen zijn de secties. Benoem een eigenaar per sectie — de persoon die de meeste vragen daarvan beantwoordde — en een eigenaar voor elk van de eerste vijftien pagina's. Schrijf nog niets behalve de lijst: sectie, vraag, eigenaar. Stuur hem terug naar het team met één vraag: "wat ontbreekt er?"

Dag 5–7 — de eerste vijftien pagina's, op basis van wat er al is. Elke eigenaar schrijft zijn pagina's met het onderstaande sjabloon, uitgaand van het chatantwoord, de recap van de meeting waarin de regel werd bepaald, het bestand dat in maart is bijgevoegd. De regel voor de eerste week is "kort en waar wint van lang en volledig": een antwoord van twee zinnen met een link naar het bestand, gedateerd en ondertekend, is een pagina. Pin dan de sectie-index waar het team leest, en de wiki bestaat.

Wat er in die week niet gebeurt: de gedeelde schijf migreren, een pagina schrijven voor elk proces, een nieuwe tool kiezen. De wiki wijst naar bestanden waar ze staan en naar procedures waar ze leven.

Een paginasjabloon voor een interne wiki

Eén pagina, één vraag, korter dan een scherm. Kopieer het als notitie en vul het in; de laatste drie regels worden het vaakst overgeslagen, en juist die houden de pagina waar.

[Vraag, in de woorden waarmee mensen hem stellen]
Eigenaar: [naam] · Sectie: [een van de zeven] · Laatst gecontroleerd: [datum] · Volgende controle: [datum]
Kort antwoord: [twee zinnen — wat te doen]
Geldt voor: [team, kantoor, type klant] · Geldt niet voor: [het geval waarmee mensen het verwarren]
Hoe: [genummerde stappen, elk met het betrokken systeem, de persoon of het bestand]
De regel erachter: [het besluit dat de regel bepaalde, met datum en reden — link naar het besluitenlogboek]
Uitzonderingen: [de gevallen buiten het normale pad, en wie elk daarvan beslist]
Waar de bestanden staan: [link naar het actuele sjabloon, de prijslijst, het contract]
Gerelateerde pagina's: [de SOP, het proces, de vorige versie van deze pagina]

Het sjabloon is platte tekst met vetgedrukte labels, dus het is zonder opmaakwerk te plakken in een Word-bestand, een Google Doc, een wikipagina, een Slack-canvas of een chatnotitie.

Een uitgewerkt voorbeeld: de wiki van een kliniek na één week

Een fysiotherapiepraktijk in Barcelona, 24 mensen: een balie van vier, veertien therapeuten, twee in de facturatie, de rest administratie. De helft van de therapeuten kwam de afgelopen twee jaar uit Argentinië, Colombia en Oekraïne; een derde van de patiënten zijn Britse en Duitse inwoners die in het Engels boeken. Drie dagen verzamelen leverden 52 vragen op; na ontdubbeling 37. De structuur die eruit kwam, met de pagina's per sectie op dag zeven:

1. Patiënten en afspraken (5) — hoe een eerste afspraak wordt ingepland; wat te doen bij een no-show; hoe een patiënt van therapeut wisselt
2. Facturatie en verzekering (4) — welke verzekeraars direct worden gefactureerd; hoe een kwitantie voor een buitenlandse verzekeraar wordt uitgegeven; wanneer een sessie wordt terugbetaald
3. Behandelprotocollen (3) — waar de protocolbladen staan; wie een behandelplan goedkeurt; wat er na elke sessie wordt vastgelegd
4. Tools en toegang (2) — wie toegang geeft tot het boekingssysteem; waar de sjablonen voor patiëntbrieven staan
5. Regels en besluiten (2) — de annuleringsregel van 24 uur; het besluitenlogboek
6. Wie je belt (1) — de contactpersonen van de verzekeraars; de servicelijn voor apparatuur

Zeventien pagina's. De meestgestelde vraag — "hoe geven we een kwitantie uit die een Duitse verzekeraar accepteert?" — was in een jaar tijd negen keer aan de balie beantwoord door dezelfde facturatielead; de pagina kostte haar vijftien minuten, omdat het negende antwoord al in het kanaal stond en alleen de eigenaarsregel en de datum nog nodig had.

Een ingevulde pagina uit sectie 2:

Hoe geven we een kwitantie uit die een buitenlandse verzekeraar accepteert?
Eigenaar: Facturatielead · Sectie: Facturatie en verzekering · Laatst gecontroleerd: 6 november 2026 · Volgende controle: 6 februari 2027
Kort antwoord: Gebruik het sjabloon "kwitantie verzekeraar", in de taal van de patiënt, met de diagnosecode en het licentienummer van de therapeut op elke regel.
Geldt voor: patiënten die zelf betalen en bij een verzekeraar in het buitenland declareren · Geldt niet voor: verzekeraars die we direct factureren, die het maandoverzicht krijgen.
Hoe: 1. Open de patiënt in het boekingssysteem. 2. Kies het sjabloon kwitantie verzekeraar. 3. Voeg de diagnosecode uit het behandelplan toe. 4. Controleer of het licentienummer op elke regel staat. 5. Verstuur als pdf en bewaar een kopie in de map van de patiënt.
De regel erachter: Licentienummers zijn toegevoegd na de Duitse weigeringen in april 2026 (besluitenlogboek, vermelding 2026-04-22).
Uitzonderingen: Een patiënt die een gespecificeerde kwitantie per sessie nodig heeft, vraagt het aan de facturatielead; niemand anders geeft er een uit.
Waar de bestanden staan: Sjabloon kwitantie verzekeraar; lijst met diagnosecodes; patiëntmappen.
Gerelateerde pagina's: Welke verzekeraars direct worden gefactureerd; wanneer een sessie wordt terugbetaald.

Waar de wiki leeft in de tools die je al gebruikt

Een organisatie van 10–200 mensen bouwt haar wiki in de suite waarvoor ze al betaalt, en elke suite heeft een plek voor de pagina, een plek voor de bestanden en een pad voor wat een meeting achterlaat. Elke suite houdt op een ander punt op, en in elk staat de pagina in de taal waarin hij is getypt. Alleen gedocumenteerd gedrag, van de eigen pagina's van de leveranciers, met de maand waarin elke pagina is gecontroleerd:

Drie dingen zijn in alle vier hetzelfde. De pagina is een document of een bericht in de ene taal waarin hij is getypt, en een lid dat een andere taal leest, leest dat of een kopie die iemand heeft gemaakt. De bestanden staan op een tweede plek, die je met een tweede zoekopdracht vindt. En de meeting — waar de regel is bediscussieerd en vastgesteld — bereikt de wiki alleen wanneer iemand hem achteraf intypt: waar Teams en Meet wel een transcript en een samenvatting bewaren en hoe je die na het gesprek bewaart, staat in waar Microsoft Teams en Google Meet je transcript, opname en samenvatting opslaan; de AI-notulisten die veel teams om dezelfde reden toevoegen worden vergeleken in alternatieven voor Otter.ai, en elk daarvan schrijft zijn samenvatting in één taal.

De vertaling die deze suites documenteren hoort bij het gesprek of bij het scherm van de lezer, niet bij de pagina: Microsoft documenteert live vertaalde ondertitels in Teams-meetings wanneer de organisator een Teams Premium- of Microsoft 365 Copilot-licentie heeft, Google documenteert vertaalde ondertitels in Meet bij in aanmerking komende Workspace-abonnementen (beide gecontroleerd in augustus 2026), en WhatsApp documenteert het vertalen van een ontvangen bericht op de telefoon van de lezer (gecontroleerd in augustus 2026) — wat elk dekt en waar elk ophoudt staat in Microsoft Teams live translation, Google Meet live translation en WhatsApp translate. De kwitantiepagina die de Oekraïens sprekende therapeut op maandag opent is een ander object dan die ondertitels, en hij wordt gelezen in de taal waarin hij is getypt.

De wiki die uit de kanaalgeschiedenis groeit

InterMIND is een communicatieruimte waarin het werk van een team in een kanaal leeft, dus de wiki heeft een vanzelfsprekend thuis: het kanaal van het team dat hem gebruikt — de balie van de kliniek, het exportteam, de accountgroep van het bureau — en dat kanaal is ook waar de vragen worden gesteld en waar de meetings vandaan beginnen. De drie beslissingen hierboven vertalen zich er direct naartoe.

De pagina's en hun eigenaren zijn notities in het kanaal. Een notitie is een rich-textbericht met koppen en genummerde lijsten, dat later via het eigen menu kan worden bewerkt, en elk lid leest het in de eigen taal, met het origineel een schakelaar verderop; vastgepind is de sectie-index het eerste wat een nieuwe collega vindt. Met bewerkingsgeschiedenis ingeschakeld verschijnt de eerdere formulering van een gewijzigde regel boven de huidige tekst als een diff op woordniveau met tijdstempel — het reviewspoor waarnaar de regel "laatst gecontroleerd" van de eigenaar verwijst. De bestanden waarnaar een pagina wijst — het kwitantiesjabloon, de lijst met diagnosecodes, het contract met de verzekeraar — worden naar hetzelfde kanaal geüpload en krijgen, op elk abonnement, een AI-samenvatting in de taal van de lezer, waarbij elk punt is gelinkt aan de alinea waaruit het komt; bij betaalde abonnementen opent het bestand zelf vertaald in de taal van de lezer (30 talen voor documenten). Als het hoofdexemplaar in een documenttool blijft staan, komen de updates per e-mail in het kanaal terecht: de host van het kanaal geeft het een eigen adres, en een bericht dat daarheen wordt gestuurd verschijnt als gewoon bericht met de afzender genoemd en de bijlagen behouden. Een team dat van Slack komt neemt zijn kanalen mee: een standaard Slack-workspace-export wordt hersteld als één kanaal per Slack-kanaal, met berichten in volgorde en met hun oorspronkelijke tijdstempels, pins en reacties behouden, en elk bericht wordt door elk lid in de eigen taal gelezen.

De geschiedenis achter elke pagina is waar het kanaal het werk doet dat de tabel hierboven aan een persoon overlaat. De meeting waarin de regel wordt bepaald begint vanuit het kanaal; tijdens het gesprek komt de conceptpagina op ieders scherm naast de videotegels met Share to conference — een notitie, of een Google Docs- of OneDrive-document dat in de chat is gelinkt — en elke deelnemer scrolt er zelfstandig doorheen en leest hem in de eigen taal, terwijl degene die deelt hem live bewerkt. Als het gesprek eindigt, wordt de recap geschreven op basis van de meeting zelf — een samenvatting, de punten gemarkeerd als afgesproken, open of omstreden, de actiepunten met eigenaren, elke regel met zijn tijdstempel — en de documenten die tijdens de sessie zijn gedeeld dragen hun samenvattingen bij naast wat er is gezegd. Hij komt per e-mail, als bericht in het kanaal en als link in het agenda-item, en elk ingelogd lid leest hem in de eigen taal: het verslag wordt per lezer vertaald, niet eenmaal geschreven in de taal die de zaal toevallig gebruikte. Elk lid kan hem bewerken, elke bewerking bewaart auteur en revisiegeschiedenis, en het kanaal bewaart de recap van elke eerdere sessie — dus de meeting waarin de licentienummerregel werd bepaald is één klik verwijderd van de pagina die hem vastlegt. Dat is de wiki die uit de kanaalgeschiedenis groeit: het negende antwoord aan de balie, de recap van het gesprek waarin de regel werd bediscussieerd, het sjabloon dat in april werd bijgevoegd, alles op één plek, met de pagina erbovenop. Naast de tabel hierboven gelegd is het verschil een nuchtere vaststelling: de ondertitels die die suites documenteren vertalen het gesprek terwijl het loopt; hier zijn de pagina, de meetings die haar hebben voortgebracht, haar bestanden en haar geschiedenis één verslag, gelezen door elk lid in de eigen taal.

Het vragenkanaal krijgt dezelfde behandeling vanuit de andere richting. De eigen assistent van een lid — Claude, ChatGPT, Copilot of Gemini, verbonden via de MCP-connector — doorzoekt recaps, transcripten, chats en de tekst van gedeelde bestanden in één vraag, "hoe geven we een kwitantie uit die een Duitse verzekeraar accepteert?", en geeft de passages terug met de meeting, de datum en het bestand waaruit elk komt; dit werkt voor organisaties met AI-functies ingeschakeld, en lezen via de assistent is beperkt tot de meetings en kanalen waarin het lid zit. De chat zelf heeft een zoekfunctie, en de wiki kan als geheel worden meegenomen: op elk abonnement exporteert een back-up vanuit Instellingen de kanalen als ZIP met hun berichten, transcripties en bestanden — de eigendomsvraag beantwoord op het niveau van de organisatie in plaats van de pagina.

De mensen die de kennis van een team bezitten zijn niet altijd medewerkers. De schadecontactpersoon van de verzekeraar, de technicus van de apparatuur, de freelance boekhouder die de Duitse kwitantieregel kent: een extern lid van het kanaal komt via e-mail binnen met een gratis account en leest de pagina's en hun geschiedenis zoals ieder ander; een persoon zonder account is gast van één meeting — die sluit via een link aan bij het gesprek, vanaf een telefoon, kosteloos, hoort het live in de eigen taal en krijgt achteraf geen verslag. De host biedt de ruimte en betaalt, op een betaald abonnement, alleen voor de leden die in de afgelopen 28 dagen actief waren — die aan een meeting deelnamen, in een chat schreven of de assistent iets vroegen; leden die stil worden behouden hun toegang kosteloos, en dat is precies wat een wiki nodig heeft: de persoon die twee jaar geleden de pagina schreef kan nog steeds in het kanaal zitten.

• Open een volledige recap — een echt verslag, gerenderd door dezelfde code die het jouwe schrijft.
• Probeer de live demo — zonder aanmelding; spreek, en hoor de zaal per luisteraar vertaald.

Een interne wiki als vakwerk overleeft elke tool: iemand moet nog steeds de vragen verzamelen, de structuur op zeven secties houden, op elke pagina een naam en een datum zetten en in het kanaal antwoorden in plaats van via een direct bericht. Wat niet hoeft te overleven is de tweede klus — overtypen wat de meeting heeft besloten in de wiki, en van elke pagina met de hand een vertaalde kopie bijhouden, één taal tegelijk, voor de collega's die de andere taal lezen.

FAQ

Wat is een interne wiki?

Een interne wiki is een verzameling pagina's die een organisatie voor haar eigen leden schrijft — hoe dingen worden gedaan, waar bestanden staan, wat er is besloten en waarom — op één plek bewaard, waar elk lid een pagina kan schrijven en elke pagina naar een andere kan linken. Hij verschilt van een openbare wiki in zijn lezer, een collega in plaats van een klant, en van een intranet doordat de mensen die het werk doen de pagina's schrijven en bijwerken in plaats van een centraal team. De pagina's die worden geopend zijn die welke zijn geordend op de vragen die mensen stellen, met een eigenaar en een reviewdatum op elke pagina.

Wat is het verschil tussen een interne wiki en een kennisbank?

Een wiki is een verzameling pagina's die iedereen in elke structuur kan schrijven; een kennisbank is geordend op de vragen die mensen stellen, met één item per vraag en een benoemde eigenaar en reviewdatum op elk item. Een wiki wordt een kennisbank door structuur en eigenaren toe te voegen; zonder die groeit hij uit tot honderden pagina's waarin niemand kan navigeren en die niemand heeft gecontroleerd. De software is vaak dezelfde, en de methode om het ene in 30 dagen in het andere te veranderen staat in hoe je een kennisbank bouwt.

Hoe maak je een interne wiki?

Kies de plek op basis van waar het team al leest, niet op basis van een softwarevergelijking; verzamel drie dagen lang de vragen die het team daadwerkelijk stelt, in de gebruikte woorden; sorteer ze in maximaal zeven secties en benoem een eigenaar per sectie en per pagina; schrijf de eerste vijftien pagina's op basis van wat er al is — het chatantwoord, de meetingrecap, het bestand — met een sjabloon van één pagina met een kort antwoord, stappen, uitzonderingen en een reviewdatum; pin de sectie-index waar het team leest. Houd daarna de lus gaande: elke vraag die twee keer wordt beantwoord wordt een pagina, en de eigenaar van elke pagina controleert hem op de afgesproken datum.

Wat hoort er in een interne wiki?

Eén pagina per vraag, elk met de vraag in de woorden die mensen gebruiken, een eigenaar, de datum van de laatste controle en de datum van de volgende, een kort antwoord, de gevallen waarvoor het wel en niet geldt, de stappen met het betrokken systeem of de betrokken persoon, het besluit achter de regel met zijn datum, de uitzonderingen en wie die beslist, links naar de actuele bestanden en links naar gerelateerde pagina's. De wiki als geheel heeft een structuur van zeven secties of minder nodig, geordend op de gestelde vragen in plaats van op afdeling, en een sectie-index die is vastgepind waar het team leest.

Wat is de beste tool voor een interne wiki?

Degene die het team al elke dag opent, want een wiki in een vijfde tool met een eigen login is de wiki die niemand op maandag controleert. In Microsoft Teams staan de pagina's en bestanden in het kanaal en de bijbehorende SharePoint-site, met meetingnotities als Loop-component; in Slack een canvas in het kanaal; in Google Workspace een Google Doc dat vanuit de agenda is gelinkt; in WhatsApp de groepschat zelf — elk met de gedocumenteerde beperkingen in de tabel hierboven, en elk met de pagina in de taal waarin hij is getypt. InterMIND houdt de notities, bestanden, chat en meetingrecaps van een team in één kanaal, gelezen door elk lid in de eigen taal, naast die tools in plaats van in plaats ervan.

Kun je een interne wiki bouwen in Microsoft Teams?

Volgens de documentatie van Microsoft worden de bestanden van een team opgeslagen op een SharePoint-site die met het team wordt aangemaakt, waarbij alle standaardkanalen die site delen met één map per kanaal, dus het tabblad Bestanden van het kanaal is waar wikidocumenten staan; meetingnotities zijn een Loop-component die elke deelnemer of organisator kan bewerken, automatisch wordt opgeslagen en bereikbaar is via de Teams-agenda en de meetingrecap. Twee gedocumenteerde beperkingen zijn voor een wiki van belang: externe deelnemers kunnen de meetingnotities niet openen of bewerken, en chats en kanaalberichten kunnen na een bepaalde periode worden verwijderd door een Teams-bewaarbeleid, terwijl bestanden hun eigen SharePoint- en OneDrive-beleid volgen (pagina's gecontroleerd in oktober en november 2026).

Hoe houd je een interne wiki actueel?

Met een eigenaar en een reviewdatum op elke pagina, en niets anders. De taak van de eigenaar is om eens per kwartaal te beantwoorden of het nog klopt en de datum aan te passen; een pagina waarvan de eigenaar is vertrokken krijgt een nieuwe eigenaar of gaat eruit. Twee gewoontes voeden de pagina's: elk antwoord dat twee keer in het kanaal van het team wordt gegeven wordt een pagina, geschreven door wie het gaf, en elk besluit dat een regel wijzigt wordt eerst vastgelegd, zodat de pagina kan linken naar waarom het veranderde. Een wiki die zo wordt bijgehouden groeit met een pagina telkens wanneer een vraag wordt beantwoord, en niemand herschrijft hem als project.

Bronnen: 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. De Microsoft Learn-pagina over Teams en SharePoint is gecontroleerd in november 2026; de pagina's over Teams-bewaring en meetingnotities, de pagina met het Slack-canvassjabloon en de Google-pagina "Take notes for me" in oktober 2026; de pagina's over berichtvertaling en ondertitels in Teams, de pagina's van Slack over prijzen, bewaring en export, de pagina's van Google Chat over vertaling en Meet-ondertitels en de WhatsApp-pagina's in augustus 2026. Leveranciers wijzigen na verloop van tijd abonnementen, functies en talenlijsten; raadpleeg hun pagina's voor de actuele stand.