Wiki intern: instrumente, structură și wiki-ul care crește din istoricul canalului (2026)

Un wiki intern este setul de pagini pe care o organizație le scrie pentru sine și pentru nimeni altcineva: cum se configurează un distribuitor nou, unde se află lista de prețuri actuală, ce s-a hotărât în iunie despre reduceri, pe cine suni când transportatorul întârzie. Este intern pentru că cititorul este un coleg și este wiki pentru că orice membru poate scrie o pagină, iar orice pagină poate trimite la alta. O organizație de 10–200 de persoane are unul din ziua în care al doilea om pune aceeași întrebare — singura alegere este dacă paginile există sau răspunsul rămâne în capul unui singur coleg și într-o duzină de conversații de chat.

Cele mai multe ghiduri despre wiki-uri interne sunt liste de software. Acesta pornește mai devreme, pentru că instrumentul este cea mai mică dintre decizii: un wiki care funcționează este o structură prin care oamenii se pot orienta, un format de pagină care rămâne adevărat și un loc pe care echipa îl deschide oricum în fiecare zi. Mai întâi vine meșteșugul — structura, un șablon de pagină pe care îl poți copia, un exemplu lucrat dintr-o clinică — apoi mecanica: unde trăiește wiki-ul în instrumentele pe care echipa le folosește deja, conform propriei documentații, și ce face fiecare dintre ele cu întâlnirea în care s-a stabilit de fapt regula. Pentru că testul unui wiki nu este ziua lansării. Este lunea în care un coleg nou îl deschide și găsește pagina într-o limbă pe care o citește.

Ce este un wiki intern — și ce nu este

Patru lucruri sunt numite wiki, iar confuzia dintre ele este motivul pentru care atâtea sunt construite și atât de puține sunt deschise:

Wiki-ul este primul rând și este cel de care depind celelalte trei. O bază de cunoștințe este un wiki cu structura impusă: o intrare pe întrebare și un responsabil pentru fiecare; metoda de a construi una în 30 de zile se află în ghidul respectiv, iar acesta tratează forma wiki-ului în sine. Intranetul este ce devine wiki-ul când au voie să scrie doar trei persoane. Unitatea partajată este locul unde trăiesc fișierele wiki-ului, iar treaba wiki-ului este să indice fișierul curent. Un wiki nu este nici un document de proces, nici un SOP: acelea descriu o activitate de la un capăt la altul; o pagină de wiki spune unde le găsești și ce s-a schimbat de atunci.

Ceea ce face un wiki intern nu este o parolă. Este faptul că paginile sunt scrise cu cuvintele echipei — „regula Casablanca”, „cursa de marți” — și că pot spune ce n-ar putea spune niciodată o pagină externă: cine a decis, de ce și ce a înlocuit.

Structura: șapte secțiuni, o pagină pe întrebare

Diferența dintre un wiki pe care oamenii îl deschid și unul pe care au încetat să îl mai deschidă rareori ține de instrument. Ține de trei decizii luate sau neluate înainte de prima pagină.

Secțiuni după întrebare, nu după departament. Colegul care întreabă „cum facturăm unui distribuitor din Elveția?” nu știe dacă răspunsul ține de finanțe, vânzări sau logistică; el știe întrebarea. Un wiki organizat pe departamente îl trimite prin trei secțiuni ca să găsească o singură pagină. Organizați după întrebările pe care le pun oamenii, cu cuvintele lor, și păstrați primul nivel la maximum șapte secțiuni. Peste șapte, structura însăși are nevoie de căutare, iar o căutare într-un wiki pe care nimeni nu l-a umplut încă nu returnează nimic. Niveluri superioare tipice pentru o organizație mică: clienți și comenzi; bani și facturare; oameni și angajări; instrumente și acces; reguli și decizii; pe cine sunăm.

O pagină pe întrebare, cât încape pe un ecran. O pagină care răspunde la o întrebare este găsită și citită; o pagină care explică o funcțiune întreagă este pusă la favorite și răsfoită. „Cum facturăm în Elveția?” este o pagină. „Finanțe” este o secțiune. Dacă o pagină are nevoie de cuprins, sunt două pagini.

Un responsabil și o dată pe fiecare pagină. O pagină care spune cine o deține și când a fost verificată ultima dată este crezută; același text fără ele este „probabil depășit”. Sarcina responsabilului este mică — o dată pe trimestru răspunde la „mai e corect?” și schimbă data — și este singurul lucru care ține un wiki viu după primul an. O pagină pentru care nu poate fi numit nimeni nu este cunoaștere; este o presupunere și iese din wiki.

Două obiceiuri păstrează structura odată ce există. Fiecare răspuns dat în canalul echipei și cerut a doua oară devine o pagină, scrisă de cel care a răspuns și legată din secțiunea căreia îi aparține. Iar fiecare decizie care schimbă o regulă își primește mai întâi rândul în jurnalul de decizii, apoi pagina care enunță regula trimite la el — astfel că, peste șase luni, pagina poate spune nu doar care este regula, ci și de ce.

Cum creezi un wiki intern într-o săptămână

Planul presupune o persoană care îl conduce — liderul echipei sau cel care primește cele mai multe întrebări — iar restul echipei petrece doar câteva minute.

Ziua 1 — alegeți locul după unde citește deja echipa. Nu după o comparație de software. Wiki-ul trăiește acolo unde se pun întrebările: canalul echipei, suita în care se află deja fișierele. Un wiki într-un al cincilea instrument, cu autentificare proprie, este un wiki pe care nimeni nu îl deschide într-o dimineață de luni. Tabelul de mai jos spune ce păstrează fiecare loc și unde se oprește.

Zilele 1–3 — adunați întrebările, nu răspunsurile. Postați un mesaj în canal: „Răspundeți cu fiecare întrebare pe care ați pus-o unui coleg săptămâna aceasta, cu cuvintele pe care le-ați folosit.” Până în ziua a treia sunt între patruzeci și șaizeci; o treime sunt duplicate. Numărați repetările: întrebarea pusă de cinci ori este pagina unu.

Ziua 4 — sortați în șapte secțiuni, numiți responsabilii. Grupurile în care cad întrebările sunt secțiunile. Numiți un responsabil pentru fiecare secțiune — persoana care a răspuns la cele mai multe dintre întrebările ei — și un responsabil pentru fiecare dintre primele cincisprezece pagini. Nu scrieți încă nimic în afară de listă: secțiune, întrebare, responsabil. Trimiteți-o înapoi echipei cu o singură întrebare: „ce lipsește?”

Zilele 5–7 — primele cincisprezece pagini, din ce există deja. Fiecare responsabil își scrie paginile cu șablonul de mai jos, pornind de la răspunsul din chat, de la rezumatul întâlnirii în care s-a stabilit regula, de la fișierul atașat în martie. Regula primei săptămâni este „scurt și adevărat bate lung și complet”: un răspuns de două propoziții cu un link către fișier, datat și semnat, este o pagină. Apoi fixați (pin) indexul secțiunilor acolo unde citește echipa, și wiki-ul există.

Ce nu se întâmplă în această săptămână: migrarea unității partajate, scrierea unei pagini pentru fiecare proces, alegerea unui instrument nou. Wiki-ul indică fișierele acolo unde sunt și procedurile acolo unde trăiesc.

Un șablon de pagină pentru wiki-ul intern

O pagină, o întrebare, cât încape pe un ecran. Copiați-l ca notă și completați-l; rândurile cel mai des omise sunt ultimele trei, iar ele sunt cele care păstrează pagina adevărată.

[Întrebarea, cu cuvintele cu care o pun oamenii]
Responsabil: [nume] · Secțiune: [una dintre cele șapte] · Ultima revizuire: [data] · Următoarea revizuire: [data]
Răspuns scurt: [două propoziții — ce trebuie făcut]
Se aplică pentru: [echipă, birou, tip de client] · Nu se aplică pentru: [cazul cu care îl confundă oamenii]
Cum: [pași numerotați, fiecare indicând sistemul, persoana sau fișierul implicat]
Regula din spatele ei: [decizia care a stabilit-o, cu data și motivul — cu link către jurnalul de decizii]
Excepții: [cazurile din afara traseului normal și cine decide pentru fiecare]
Unde sunt fișierele: [link către șablonul, lista de prețuri, contractul curent]
Pagini conexe: [SOP-ul, procesul, versiunea anterioară a acestei pagini]

Șablonul este text simplu cu etichete îngroșate, deci se lipește într-un fișier Word, un Google Doc, o pagină de wiki, un canvas Slack sau o notă de chat fără reformatare.

Un exemplu lucrat: wiki-ul unei clinici după o săptămână

O clinică de fizioterapie din Barcelona, 24 de persoane: un front desk de patru, paisprezece terapeuți, doi la facturare, restul administrație. Jumătate dintre terapeuți au venit din Argentina, Columbia și Ucraina în ultimii doi ani; o treime dintre pacienți sunt rezidenți britanici și germani care fac programări în engleză. Trei zile de colectare au produs 52 de întrebări; după eliminarea duplicatelor, 37. Structura rezultată, cu paginile pe secțiune în ziua a șaptea:

1. Pacienți și programări (5) — cum se programează prima consultație; ce se face cu o neprezentare; cum își schimbă un pacient terapeutul
2. Facturare și asigurări (4) — ce asigurători se facturează direct; cum se emite o chitanță pentru un asigurător străin; când se rambursează o ședință
3. Protocoale de tratament (3) — unde se află fișele de protocol; cine aprobă un plan de tratament; ce se înregistrează după fiecare ședință
4. Instrumente și acces (2) — cine dă acces la sistemul de programări; unde sunt șabloanele de scrisori pentru pacienți
5. Reguli și decizii (2) — regula de anulare cu 24 de ore înainte; jurnalul de decizii
6. Pe cine sunăm (1) — contactele asigurătorilor; linia de service pentru echipamente

Șaptesprezece pagini. Cea mai frecventă întrebare — „cum emitem o chitanță pe care o acceptă un asigurător german?” — primise răspuns la front desk de nouă ori într-un an, de aceeași responsabilă de facturare; pagina a luat-o cincisprezece minute, pentru că al nouălea răspuns era deja scris în canal și avea nevoie doar de rândul cu responsabilul și de dată.

O pagină completată din secțiunea 2:

Cum emitem o chitanță pe care o acceptă un asigurător străin?
Responsabil: Responsabila de facturare · Secțiune: Facturare și asigurări · Ultima revizuire: 6 noiembrie 2026 · Următoarea revizuire: 6 februarie 2027
Răspuns scurt: Folosiți șablonul „chitanță pentru asigurător”, în limba pacientului, cu codul de diagnostic și numărul de licență al terapeutului pe fiecare rând.
Se aplică pentru: pacienții care plătesc singuri și solicită decontarea de la un asigurător din străinătate · Nu se aplică pentru: asigurătorii pe care îi facturăm direct, care primesc extrasul lunar.
Cum: 1. Deschideți pacientul în sistemul de programări. 2. Alegeți șablonul de chitanță pentru asigurător. 3. Adăugați codul de diagnostic din planul de tratament. 4. Verificați că numărul de licență apare pe fiecare rând. 5. Trimiteți ca PDF și depuneți o copie în dosarul pacientului.
Regula din spatele ei: Numerele de licență au fost adăugate după refuzurile germane din aprilie 2026 (intrarea din jurnalul de decizii 2026-04-22).
Excepții: Un pacient care are nevoie de o chitanță detaliată pe ședință o cere responsabilei de facturare; nimeni altcineva nu emite una.
Unde sunt fișierele: Șablonul de chitanță pentru asigurător; lista codurilor de diagnostic; dosarele pacienților.
Pagini conexe: Ce asigurători se facturează direct; când se rambursează o ședință.

Unde trăiește wiki-ul în instrumentele pe care le folosiți deja

O organizație de 10–200 de persoane își construiește wiki-ul în suita pe care o plătește deja, iar fiecare suită are un loc pentru pagină, un loc pentru fișiere și o cale pentru ce lasă în urmă o întâlnire. Fiecare se oprește într-un alt punct și în fiecare pagina rămâne în limba în care a fost scrisă. Doar comportament documentat, din paginile proprii ale furnizorilor, cu luna în care a fost verificată fiecare pagină:

Trei lucruri sunt la fel în toate cele patru. Pagina este un document sau un mesaj în singura limbă în care a fost scrisă, iar un membru care citește altă limbă citește fie acel text, fie o copie făcută de cineva. Fișierele sunt într-un al doilea loc, găsite printr-o a doua căutare. Iar întâlnirea — în care regula a fost discutată și stabilită — ajunge în wiki doar când o persoană o scrie după aceea: unde păstrează Teams și Meet o transcriere și un rezumat, dacă o fac, și cum le păstrezi după apel se află în unde stochează Microsoft Teams și Google Meet transcrierea, înregistrarea și rezumatul; notetakerele AI pe care multe echipe le adaugă din același motiv sunt comparate în alternative la Otter.ai, iar fiecare dintre ele scrie rezumatul într-o singură limbă.

Traducerea pe care o documentează aceste suite aparține apelului sau ecranului cititorului, nu paginii: Microsoft documentează subtitrările traduse în timp real în întâlnirile Teams când organizatorul are o licență Teams Premium sau Microsoft 365 Copilot, Google documentează subtitrările traduse în Meet pe planurile Workspace eligibile (ambele verificate în august 2026), iar WhatsApp documentează traducerea unui mesaj primit pe telefonul cititorului (verificat în august 2026) — ce acoperă fiecare și unde se oprește se află în traducerea în direct în Microsoft Teams, traducerea în direct în Google Meet și WhatsApp translate. Pagina cu chitanța pe care terapeutul vorbitor de ucraineană o deschide luni este un obiect separat de aceste subtitrări și se citește în limba în care a fost scrisă.

Wiki-ul care crește din istoricul canalului

InterMIND este un spațiu de comunicare în care munca unei echipe trăiește într-un canal, deci wiki-ul are o casă evidentă: canalul echipei care îl folosește — front desk-ul clinicii, echipa de export, grupul de cont al agenției — iar acel canal este și locul unde se pun întrebările și de unde pornesc întâlnirile. Cele trei decizii de mai sus se aplică direct pe el.

Paginile și responsabilii lor sunt note în canal. O notă este un mesaj rich-text cu titluri și liste numerotate, editat ulterior din propriul meniu, și este citită de fiecare membru în limba lui, cu originalul la o comutare distanță; fixat (pinned), indexul secțiunilor este primul lucru pe care îl găsește un coleg nou. Cu istoricul de editări activat, formularea anterioară a unei reguli modificate apare deasupra textului curent ca o diferență la nivel de cuvânt, cu marca de timp — urma de revizuire spre care trimite rândul „ultima revizuire” al responsabilului. Fișierele spre care indică o pagină — șablonul de chitanță, lista codurilor de diagnostic, contractul asigurătorului — se încarcă în același canal și au, pe toate planurile, un rezumat AI în limba cititorului, cu fiecare punct legat de paragraful din care provine; pe planurile plătite, fișierul însuși se deschide tradus în limba cititorului (30 de limbi pentru documente). Dacă exemplarul de referință rămâne într-un instrument de documente, actualizările lui ajung în canal prin e-mail: gazda canalului îi dă o adresă proprie, iar un mesaj trimis acolo apare ca mesaj obișnuit, cu expeditorul numit și atașamentele păstrate. O echipă care vine din Slack își aduce canalele cu ea: un export standard al spațiului de lucru Slack se restaurează ca un canal pentru fiecare canal Slack, cu mesajele în ordine și cu marcajele de timp originale, cu pin-urile și reacțiile păstrate, iar fiecare mesaj este citit de fiecare membru în limba lui.

Istoricul din spatele fiecărei pagini este locul unde canalul face treaba pe care tabelul de mai sus o lasă pe seama unei persoane. Întâlnirea în care se stabilește regula pornește din canal; în timpul apelului, pagina-ciornă ajunge pe ecranul tuturor, lângă casetele video, cu Share to conference — o notă sau un document Google Docs ori OneDrive legat în chat — iar fiecare participant o derulează independent și o citește în limba lui, în timp ce cel care partajează o editează în direct. Când apelul se termină, rezumatul este scris din întâlnirea însăși — o sinteză, punctele marcate ca agreate, deschise sau disputate, action items cu responsabili, fiecare rând păstrându-și marca de timp — iar documentele partajate în timpul sesiunii contribuie cu rezumatele lor alături de ce s-a spus. Sosește prin e-mail, ca mesaj în canal și ca link în evenimentul din calendar, iar fiecare membru autentificat îl citește în limba lui: evidența este tradusă pentru fiecare cititor, nu scrisă o singură dată în limba pe care a folosit-o întâmplător camera. Orice membru îl poate edita, fiecare editare păstrează autorul și istoricul de revizii, iar canalul păstrează rezumatul fiecărei sesiuni trecute — deci întâlnirea care a stabilit regula numerelor de licență este la un clic de pagina care o enunță. Aceasta este wiki-ul care crește din istoricul canalului: al nouălea răspuns de la front desk, rezumatul apelului în care s-a discutat regula, șablonul atașat în aprilie, toate într-un singur loc, cu pagina deasupra lor. Pus lângă tabelul de mai sus, contrastul este o simplă constatare de fapt: subtitrările pe care le documentează acele suite traduc apelul cât timp rulează; aici pagina, întâlnirile care au produs-o, fișierele ei și istoricul ei formează o singură evidență, citită de fiecare membru în limba lui.

Canalul de întrebări primește același tratament din cealaltă direcție. Asistentul propriu al unui membru — Claude, ChatGPT, Copilot sau Gemini, conectat prin conectorul MCP — caută în rezumate, transcrieri, chaturi și în textul fișierelor partajate printr-o singură întrebare, „cum emitem o chitanță pe care o acceptă un asigurător german?”, și returnează pasajele cu întâlnirea, data și fișierul din care provine fiecare; aceasta funcționează pentru organizațiile cu funcțiile AI activate, iar citirea prin asistent se limitează la întâlnirile și canalele în care se află membrul. Chatul în sine are căutare, iar wiki-ul poate fi scos în întregime: pe toate planurile, o copie de rezervă din Settings exportă canalele ca ZIP, cu mesajele, transcrierile și fișierele lor — întrebarea proprietății, rezolvată la nivelul organizației, nu al paginii.

Oamenii care dețin cunoștințele unei echipe nu sunt întotdeauna angajați. Contactul de la asigurător pentru dosarele de daune, tehnicianul de echipamente, contabilul freelancer care știe regula chitanțelor germane: un membru extern al canalului se alătură prin e-mail, pe un cont gratuit, și citește paginile și istoricul lor ca toți ceilalți; o persoană fără cont este invitată a unei singure întrebări... mai exact, a unei singure întâlniri — intră în apel prin link, de pe telefon, fără cost, îl aude în direct în limba proprie și nu primește nicio evidență după aceea. Gazda oferă spațiul și, pe un plan plătit, plătește doar pentru membrii activi în ultimele 28 de zile — cei care au intrat într-o întâlnire, au scris într-un chat sau au întrebat asistentul; membrii care devin inactivi își păstrează accesul fără cost, ceea ce are nevoie un wiki: cel care a scris pagina acum doi ani poate fi în continuare în canal.

• Deschideți un rezumat complet — o evidență reală, generată de același cod care îl scrie pe al dumneavoastră.
• Încercați demonstrația live — fără înregistrare; vorbiți și auziți sala tradusă pentru fiecare ascultător.

Un wiki intern, ca meșteșug, supraviețuiește oricărui instrument: cineva tot trebuie să adune întrebările, să țină structura la șapte secțiuni, să pună un nume și o dată pe fiecare pagină și să răspundă în canal, nu prin mesaj direct. Ce nu trebuie să supraviețuiască este a doua muncă — retastarea în wiki a ceea ce a hotărât întâlnirea și păstrarea manuală a unei copii traduse a fiecărei pagini, într-o limbă pe rând, pentru colegii care o citesc pe cealaltă.

FAQ

Ce este un wiki intern?

Un wiki intern este un set de pagini pe care o organizație le scrie pentru proprii membri — cum se fac lucrurile, unde sunt fișierele, ce s-a hotărât și de ce — păstrate într-un singur loc, unde orice membru poate scrie o pagină și orice pagină poate trimite la alta. Diferă de un wiki public prin cititor, un coleg, nu un client, și de un intranet prin faptul că paginile sunt scrise și actualizate de oamenii care fac munca, nu de o echipă centrală. Paginile care sunt deschise sunt cele organizate după întrebările pe care le pun oamenii, cu un responsabil și o dată de revizuire pe fiecare.

Care este diferența dintre un wiki intern și o bază de cunoștințe?

Un wiki este un set de pagini pe care oricine le poate scrie în orice structură; o bază de cunoștințe este organizată după întrebările pe care le pun oamenii, cu o intrare pe întrebare și un responsabil numit și o dată de revizuire pe fiecare. Un wiki devine bază de cunoștințe prin adăugarea structurii și a responsabililor; fără ele crește în sute de pagini prin care nimeni nu se poate orienta și pe care nimeni nu le-a verificat. Software-ul este adesea același, iar metoda de a transforma una în cealaltă în 30 de zile se află în cum construiești o bază de cunoștințe.

Cum creezi un wiki intern?

Alegeți locul după unde citește deja echipa, nu după o comparație de software; colectați timp de trei zile întrebările pe care le pune efectiv echipa, cu cuvintele folosite; sortați-le în cel mult șapte secțiuni și numiți un responsabil pentru fiecare secțiune și pagină; scrieți primele cincisprezece pagini din ce există deja — răspunsul din chat, rezumatul întâlnirii, fișierul — folosind un șablon de o pagină cu un răspuns scurt, pași, excepții și o dată de revizuire; fixați indexul secțiunilor acolo unde citește echipa. Apoi mențineți bucla: fiecare întrebare la care s-a răspuns de două ori devine o pagină, iar responsabilul fiecărei pagini o revizuiește la data ei.

Ce ar trebui să conțină un wiki intern?

O pagină pe întrebare, fiecare cu întrebarea formulată cu cuvintele oamenilor, un responsabil, data ultimei revizuiri și data următoarei, un răspuns scurt, cazurile în care se aplică și în care nu se aplică, pașii cu sistemul sau persoana implicată, decizia din spatele regulii cu data ei, excepțiile și cine decide asupra lor, linkuri către fișierele curente și linkuri către paginile conexe. Wiki-ul, în ansamblu, are nevoie de o structură de maximum șapte secțiuni, organizate după întrebările puse, nu după departament, și de un index al secțiunilor fixat acolo unde citește echipa.

Care este cel mai bun instrument pentru un wiki intern?

Cel pe care echipa îl deschide deja în fiecare zi, pentru că un wiki într-un al cincilea instrument, cu autentificare proprie, este wiki-ul pe care nimeni nu îl verifică într-o zi de luni. În Microsoft Teams, paginile și fișierele stau în canal și în site-ul lui SharePoint, cu notele întâlnirii ca o componentă Loop; în Slack, un canvas în canal; în Google Workspace, un Google Doc legat din calendar; în WhatsApp, chatul de grup în sine — fiecare cu limitele documentate din tabelul de mai sus și fiecare păstrând pagina în limba în care a fost scrisă. InterMIND păstrează notele, fișierele, chatul și rezumatele întâlnirilor unei echipe într-un singur canal, citit de fiecare membru în limba lui, alături de aceste instrumente, nu în locul lor.

Poți construi un wiki intern în Microsoft Teams?

Conform documentației Microsoft, fișierele unei echipe sunt stocate într-un site SharePoint creat odată cu echipa, toate canalele standard folosind acel site, cu un dosar pe canal, deci fila Files a canalului este locul unde trăiesc documentele wiki-ului; notele întâlnirii sunt o componentă Loop pe care o poate edita orice participant sau organizator, salvată automat și accesibilă din calendarul Teams și din rezumatul întâlnirii. Două limite documentate contează pentru un wiki: participanții externi nu pot accesa sau edita notele întâlnirii, iar chaturile și mesajele din canal pot fi șterse după o perioadă printr-o politică de retenție Teams, în timp ce fișierele urmează propriile politici SharePoint și OneDrive (pagini verificate în octombrie și noiembrie 2026).

Cum ții un wiki intern la zi?

Cu un responsabil și o dată de revizuire pe fiecare pagină și nimic altceva. Sarcina responsabilului este să răspundă la „mai e corect?” o dată pe trimestru și să schimbe data; o pagină al cărei responsabil a plecat primește un responsabil nou sau iese din wiki. Două obiceiuri alimentează paginile: fiecare răspuns dat de două ori în canalul echipei devine o pagină, scrisă de cel care a răspuns, iar fiecare decizie care schimbă o regulă este înregistrată mai întâi, ca pagina să poată trimite la motivul schimbării. Un wiki ținut astfel crește cu o pagină de fiecare dată când se răspunde la o întrebare, iar nimeni nu îl rescrie ca pe un proiect.

Surse: 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. Pagina Microsoft Learn despre integrarea Teams–SharePoint a fost verificată în noiembrie 2026; paginile despre retenția Teams și notele întâlnirii, pagina șablonului de canvas Slack și pagina Google „Take notes for me” au fost verificate în octombrie 2026; paginile despre traducerea mesajelor și subtitrările Teams, paginile Slack despre prețuri, retenție și export, paginile Google Chat despre traducere și Meet despre subtitrări și paginile WhatsApp au fost verificate în august 2026. Furnizorii își schimbă în timp planurile, funcțiile și listele de limbi; consultați paginile lor pentru starea curentă.