Cum construiți o bază de cunoștințe în 30 de zile: structură, surse, responsabili — și baza care crește din ceea ce spune deja echipa (2026)

O bază de cunoștințe este ansamblul răspunsurilor pe care o organizație le dă de mai multe ori, scrise o singură dată și păstrate acolo unde cel care are nevoie de ele le poate găsi fără să întrebe pe cineva. „Cum facturăm unui distribuitor din Elveția?", „ce îi spunem unui părinte al cărui copil a ratat termenul?", „ce transportator alegem pentru paleți spre Maroc?" — a patra oară când se pune oricare dintre aceste întrebări, organizația are o bază de cunoștințe, fie că a construit-o, fie că nu. Doar că ea trăiește în capul unui singur coleg și în o duzină de conversații de chat.

Majoritatea ghidurilor pentru construirea unei astfel de baze încep cu alegerea software-ului. Acesta începe mai devreme, pentru că software-ul este partea cea mai mică: o bază de cunoștințe înseamnă trei decizii — o structură, un set de surse și un nume pe fiecare articol — și o lună în care le parcurgeți în ordine. Planul de 30 de zile de mai jos duce o organizație de 10–200 de persoane la o bază pe care oamenii chiar o deschid, cu un șablon de articol pe care îl puteți copia, un exemplu lucrat, un tabel cu locul în care trăiește baza în instrumentele pe care echipa dumneavoastră le folosește deja și, apoi, partea pe care majoritatea ghidurilor o omit: baza este în mare parte deja scrisă, în ce spune echipa în ședințe și în ce tastează în chaturi, iar treaba este să păstrați toate acestea într-un singur loc, lizibil pentru toată lumea din echipă.

Ce este o bază de cunoștințe — și ce nu este

Patru lucruri sunt numite bază de cunoștințe, iar confuzia dintre ele este motivul pentru care atâtea sunt construite și atât de puține sunt folosite:

Baza de cunoștințe este primul rând și depinde de celelalte trei. Wiki-ul este ce devine ea fără structură; biblioteca de documente este locul în care stau fișierele ei; istoricul chatului este locul în care sunt scrise prima oară cele mai multe dintre articolele ei, din întâmplare, sub formă de răspunsuri. Meșteșugul constă în a muta un răspuns din rândul al patrulea în primul — o singură dată, cu un nume pe el — iar metoda de mai jos este construită în jurul acestei mutări.

Mai contează două distincții înainte de a construi. O bază de cunoștințe internă este pentru echipă: cum facem lucrurile, unde se găsesc, ce am decis. Una externă este pentru clienți: cum funcționează produsul, ce de făcut când ceva nu merge. Acest ghid este despre cea internă; o bază externă se scrie mai târziu pornind de la cea internă, rescriind articolele pe care clienții au voie să le vadă. Și o bază de cunoștințe nu este un document de proces și nici un SOP: acestea descriu o muncă întreagă, de la un capăt la altul; un articol răspunde la o singură întrebare și trimite la procedură atunci când răspunsul este „urmați-o".

Cele trei decizii: structură, surse, responsabilitate

Structura: pe întrebări, nu pe departamente. Cel care întreabă „cum facturăm în Elveția?" nu știe dacă răspunsul ține de financiar, de vânzări sau de logistică; el cunoaște întrebarea. O bază organizată pe departamente îl trimite prin trei secțiuni ca să găsească un singur răspuns. Organizați după întrebările pe care le pun oamenii — în cuvintele lor — și păstrați nivelul de sus la cel mult șapte secțiuni. Peste șapte, structura însăși are nevoie de o căutare, iar o căutare într-o bază pe care nimeni nu a umplut-o încă nu returnează nimic. Niveluri de sus 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.

Sursele: ce există deja, înainte de orice lucru nou. Nimeni nu are timp să scrie o bază de cunoștințe de la pagina goală și nici nu e nevoie. Răspunsurile există — în replica dată de un coleg marțea trecută, în rezumatul ședinței în care s-a stabilit regula, în lista de prețuri atașată de cineva la un mesaj în martie, în notițele de integrare păstrate de ultimul angajat nou. Prima versiune a majorității articolelor este copiată, nu scrisă. Unde stau sursele și cât din fiecare poate fi regăsit ulterior este subiectul tabelului de mai jos; pe scurt, în cele mai multe suite chatul, fișierele și notițele din ședințe sunt trei locuri separate, iar ședința în sine este cea care lasă cel mai puțin în urmă.

Responsabilitatea: un nume și o dată pe fiecare articol. Singurul lucru care separă o bază de cunoștințe în care oamenii au încredere de una pe care au încetat s-o mai deschidă este dacă un articol spune cine îl deține și când a fost verificat ultima oară. Un articol cu un nume și cu „revizuit la 14 octombrie 2026" este crezut; același text fără ele este „probabil depășit". Sarcina responsabilului este mică: o dată pe trimestru, să răspundă la „mai este corect?" și să schimbe data. Nu este vorba de rescrierea bazei. Dacă nu poate fi numit nimeni pentru un articol, articolul nu este cunoaștere; este o presupunere și iese din bază.

Cum construiți o bază de cunoștințe în 30 de zile

Planul presupune o singură persoană care îl coordonează — liderul echipei sau cel căruia i se pun cele mai multe întrebări — și care dedică aproximativ două ore pe săptămână, în timp ce restul echipei dedică minute.

Săptămâna 1 — adunați întrebările, nu răspunsurile. Deschideți un canal, sau o notiță într-unul existent, și timp de șapte zile rugați pe fiecare să lase acolo fiecare întrebare pe care a pus-o unui coleg sau care i-a fost pusă, în cuvintele folosite. Fără răspunsuri deocamdată. Până vineri sunt patruzeci–optzeci de întrebări; o treime sunt duplicate. Numărați repetările: întrebarea pusă de cinci ori este articolul unu. Locul în care stă lista este și locul în care va sta baza; alegerea locului se face acum, după ce deschide echipa în fiecare zi, nu după o comparație de software.

Săptămâna 2 — structura și responsabilii. Sortați întrebările în grupuri; grupurile sunt secțiunile și nu sunt mai mult de șapte. Numiți un responsabil pentru fiecare secțiune — persoana care a răspuns la cele mai multe dintre întrebările ei în săptămâna 1. Apoi numiți un responsabil pentru fiecare articol, pentru cele douăzeci de întrebări cele mai frecvente. Nu scrieți nimic încă, în afară de listă: secțiune, întrebare, responsabil. Trimiteți-o echipei și cereți un singur lucru: „ce întrebări lipsesc?" Lista se întoarce cu încă zece.

Săptămâna 3 — primele douăzeci de articole, din surse. Fiecare responsabil își scrie articolele folosind șablonul de mai jos, pornind de la ce există deja: replica din chat, rezumatul, fișierul. Regula săptămânii 3 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 un articol. O pagină care explică istoria regulii este un document și poate veni mai târziu. Articolele care depind de o decizie pe care nu o mai găsește nimeni se duc mai întâi în registrul de decizii, apoi în bază, cu un link.

Săptămâna 4 — publicați, apoi porniți bucla. Fixați baza (pin) acolo unde citește echipa. Apoi stabiliți cele două obiceiuri care o țin vie: fiecare întrebare pusă de acum înainte în canalul de întrebări primește un articol sau un link către unul, scris de cel care a răspuns; iar fiecare responsabil de articol primește data de revizuire în calendar. Ziua 30 nu înseamnă o bază terminată. Înseamnă douăzeci–treizeci de articole, fiecare cu responsabil și dată, și o buclă care adaugă unul ori de câte ori se răspunde la o întrebare. După șase luni sunt două sute și nimeni nu le-a scris ca proiect.

Ce nu se întâmplă în cele 30 de zile: migrarea bibliotecii de documente, alegerea unui instrument nou sau scrierea unei pagini pentru fiecare proces. Baza trimite la fișiere acolo unde sunt și la proceduri acolo unde trăiesc. Mutarea lor este un alt proiect și adesea unul inutil.

Un șablon de articol pentru baza de cunoștințe

Un articol, o întrebare, sub o pagină. Copiați-l ca notiță și completați-l; rândurile cel mai des omise sunt ultimele trei și ele sunt cele care țin articolul adevărat.

[Întrebarea, în cuvintele pe care le folosesc oamenii când o pun]
Responsabil: [nume] · Secțiune: [una dintre cele șapte] · Ultima revizuire: [dată] · Următoarea revizuire: [dată]
Răspuns scurt: [două propoziții — ce de 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 numind sistemul, persoana sau fișierul implicat]
Regula din spatele lui: [decizia care a stabilit-o, cu data ei, și de ce]
Excepții: [cazurile aflate în afara drumului normal și cine decide în fiecare]
Unde sunt fișierele: [link către șablonul curent, lista de prețuri, contract]
Articole conexe: [SOP-ul, procesul, versiunea anterioară]

Ș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 notiță de chat fără reformatare.

Un exemplu lucrat: baza unui exportator după 30 de zile

Un exportator italian de utilaje, 38 de persoane, un birou de vânzări la Milano și distribuitori în Spania, România și Maroc. Săptămâna 1 a produs 61 de întrebări; după eliminarea duplicatelor, 44. Structura care a rezultat din ele, cu numărul de articole pe secțiune în ziua 30:

1. Distribuitori și comenzi (7) — cum se înființează un distribuitor nou; cine aprobă o limită de credit; de ce are nevoie o comandă înainte să meargă în producție
2. Facturare și plăți (5) — facturarea unui distribuitor din Elveția; când se folosește o factură proformă; ce de făcut când o plată întârzie 30 de zile
3. Transport și vamă (6) — transportatori pe destinații; documentele de care are nevoie un palet spre Maroc; cine semnează declarația de export
4. Service și garanție (4) — ce acoperă garanția; cum se programează o vizită de service; ce piese se țin în stoc
5. Instrumente și acces (3) — cine dă acces la CRM; unde se află lista de prețuri; cum se ajunge la căsuța poștală comună
6. Reguli și decizii (3) — regula celor două semnături peste 10.000; plafonul de discount; registrul de decizii
7. Pe cine sunăm (2) — brokerul vamal; contactele transportatorilor pe țări

Treizeci de articole. Cea mai frecventă întrebare a săptămânii 1 — „de ce documente are nevoie un palet spre Maroc?" — primise răspuns în canal de unsprezece ori într-un an, de aceeași responsabilă de logistică; articolul i-a luat douăzeci de minute, pentru că al unsprezecelea răspuns era deja scris și avea nevoie doar de rândul cu responsabilul și de dată.

Un articol completat, din secțiunea 3:

De ce documente are nevoie un palet spre Maroc?
Responsabil: Responsabila de logistică · Secțiune: Transport și vamă · Ultima revizuire: 3 noiembrie 2026 · Următoarea revizuire: 3 februarie 2027
Răspuns scurt: Factură comercială în trei exemplare, listă de colete, certificat EUR.1 și numărul licenței de import a distribuitorului pe factură.
Se aplică pentru: toate expedierile către distribuitorii din Maroc · Nu se aplică pentru: piese de schimb sub 1.000 EUR trimise prin curier, care merg cu formularul propriu al curierului.
Cum: 1. Exportați factura din sistem cu șablonul pentru Maroc. 2. Adăugați numărul licenței din dosarul distribuitorului. 3. Solicitați EUR.1 de la camera de comerț, trei zile lucrătoare. 4. Atașați lista de colete. 5. Trimiteți setul brokerului vamal și puneți distribuitorul în copie.
Regula din spatele lui: Numărul licenței a fost adăugat după blocajul din martie 2026 la Casablanca (intrarea 2026-03-19 din registrul de decizii).
Excepții: Utilajele de demonstrație merg sub regim de admitere temporară; decide responsabila de logistică.
Unde sunt fișierele: Șablonul de factură pentru Maroc; formularul de solicitare EUR.1; dosarele distribuitorilor.
Articole conexe: Transportatori pe destinații; cine semnează declarația de export.

Unde trăiește baza de cunoștințe în instrumentele pe care le folosiți deja

O organizație de 10–200 de persoane își construiește baza în suita pentru care plătește deja, iar fiecare suită are un loc pentru articol, un loc pentru fișiere și o cale pentru ce lasă în urmă o ședință. Fiecare se oprește într-un alt punct, iar în fiecare înregistrarea este în limba în care a fost tastată. 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. Articolul este un document sau un mesaj în singura limbă în care a fost tastat, iar un membru care citește în 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 ședința — locul în care regula a fost discutată și stabilită — ajunge în bază doar atunci când o persoană o tastează ulterior: unde păstrează Teams și Meet o transcriere și un rezumat, dacă o fac, și cum le păstrați după apel este explicat în unde stochează Microsoft Teams și Google Meet transcrierea, înregistrarea și rezumatul; notetaker-ele 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 documentată de aceste suite ține de apel sau de ecranul cititorului, nu de înregistrare: Microsoft documentează subtitrări traduse live în ședințele Teams atunci când organizatorul deține o licență Teams Premium sau Microsoft 365 Copilot, Google documentează subtitrări 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 găsește în traducerea live în Microsoft Teams, traducerea live în Google Meet și traducerea în WhatsApp. Articolul pe care funcționarul distribuitorului din Casablanca îl deschide luni este un obiect separat de aceste subtitrări și este citit în limba în care a fost tastat.

Baza care crește din ceea ce spune deja echipa

InterMIND este un spațiu de comunicare în care munca unei echipe trăiește într-un canal, deci baza de cunoștințe are o casă evidentă: canalul echipei care o folosește — echipa de export, recepția clinicii, grupul de conturi al agenției — iar acel canal este și canalul de întrebări și locul din care pornesc ședințele. Cele trei decizii de mai sus se leagă direct de el.

Structura și responsabilitatea sunt articolele înseși. Postat ca notă — un mesaj cu text îmbogățit, cu titluri și liste numerotate, editat ulterior din propriul meniu — un articol este citit de fiecare membru în limba sa, cu originalul la un comutator distanță, și fixat (pin) astfel încât versiunea curentă să fie 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 diferență la nivel de cuvânt, cu data și ora, iar aceasta este urma de revizuire către care trimite rândul „ultima revizuire" al responsabilului. Fișierele la care trimite un articol — lista de prețuri, șablonul pentru Maroc, contractul distribuitorului — 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 principal 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 de la Slack își aduce canalele cu ea: un export standard al workspace-ului 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, fiecare mesaj fiind citit de fiecare membru în limba sa.

Sursele sunt locul în care canalul face treaba pe care tabelul de mai sus o lasă pe seama unei persoane. Ședința în care se stabilește regula pornește din canal; în timpul apelului, proiectul de articol apare 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 îl derulează independent și îl citește în limba sa, în timp ce cel care îl partajează îl editează live. Când apelul se încheie, rezumatul este scris din ședința însăși — o sinteză, punctele marcate ca agreate, deschise sau disputate, action items cu responsabili, fiecare rând păstrându-și marcajul de timp — iar documentele partajate în timpul sesiunii contribuie cu rezumatele lor alături de ce s-a spus. Rezumatul ajunge prin e-mail, ca mesaj în canal și ca link în evenimentul din calendar, iar fiecare membru autentificat îl citește în propria limbă: înregistrarea este tradusă pentru fiecare cititor, nu scrisă o singură dată în limba pe care a folosit-o întâmplător sala. Orice membru îl poate edita, fiecare modificare păstrează autorul și istoricul de revizii, iar canalul păstrează rezumatul fiecărei sesiuni trecute — astfel încât ședința care a stabilit regula pentru Maroc se află la un clic de articolul care o enunță. Aceasta este baza care crește din ce spune deja echipa: al unsprezecelea răspuns din canal, rezumatul apelului în care s-a discutat regula, fișierul atașat în martie, toate într-un singur loc, cu articolul deasupra lor.

Canalul de întrebări primește același tratament din direcția opusă. Asistentul propriu al unui membru — Claude, ChatGPT, Copilot sau Gemini, conectat prin conectorul MCP — caută într-o singură întrebare în rezumate, transcrieri, chaturi și în textul fișierelor partajate, „de ce documente are nevoie un palet spre Maroc?", și returnează pasajele împreună cu ședința, data și fișierul din care provine fiecare; aceasta funcționează pentru organizațiile cu funcțiile AI activate, iar citirea prin asistent este limitată la ședințele și canalele în care se află membrul. Chatul însuși are o căutare, iar baza poate fi scoasă întreagă: pe toate planurile, o copie de siguranță din Settings exportă canalele ca ZIP, cu mesajele, transcrierile și fișierele lor, ceea ce răspunde la întrebarea despre proprietate la nivelul organizației, nu al articolului. Pus lângă tabelul de mai sus, contrastul este o simplă constatare de fapt: subtitrările documentate de acele suite traduc apelul cât timp se desfășoară; aici articolul, ședințele care l-au produs, fișierele lui și istoricul său sunt o singură înregistrare, citită de fiecare membru în propria limbă.

Cei care dețin cunoștințele unei echipe nu sunt întotdeauna angajați. Funcționarul de comenzi al distribuitorului, brokerul vamal, contabilul independent care cunoaște regula elvețiană: un membru extern al canalului se alătură prin e-mail, pe un cont gratuit, și citește articolele și istoricul lor ca toți ceilalți; o persoană fără cont este invitat al unei singure ședințe — se alătură apelului prin link, de pe telefon, fără costuri, îl aude live în limba sa și nu primește nicio înregistrare 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 ședință, au scris într-un chat sau au întrebat asistentul; membrii care devin inactivi își păstrează accesul fără costuri, ceea ce are nevoie o bază de cunoștințe: persoana care a scris articolul acum doi ani poate fi în continuare în canal.

• Deschideți un rezumat complet — o înregistrare 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.

Construirea unei baze de cunoștințe ca meșteșug supraviețuiește oricărui instrument: tot cineva trebuie să adune întrebările, să țină structura la șapte secțiuni, să pună un nume și o dată pe fiecare articol și să răspundă în canal, nu prin mesaj direct. Ceea ce nu trebuie să supraviețuiască este a doua muncă — retastarea în bază a ceea ce a decis ședința și păstrarea manuală a unei copii traduse a fiecărui articol, câte o limbă pe rând, pentru biroul care o citește pe cealaltă.

FAQ

Ce este o bază de cunoștințe?

O bază de cunoștințe este o colecție de răspunsuri la întrebările care i se pun unei organizații de mai multe ori, scrise o singură dată, fiecare cu un responsabil și o dată, și păstrate acolo unde cel care are nevoie de răspuns îl poate găsi fără să întrebe un coleg. O bază de cunoștințe internă răspunde la întrebările proprii ale echipei — cum facturăm, unde sunt fișierele, ce am decis; una externă răspunde la întrebările clienților despre un produs. Se deosebește de un wiki prin faptul că are structură și responsabili, iar de o bibliotecă de documente prin faptul că ține răspunsuri, nu fișiere.

Cum creați o bază de cunoștințe?

Adunați timp de o săptămână întrebările pe care le pune efectiv echipa, în cuvintele folosite; grupați-le în cel mult șapte secțiuni; numiți un responsabil pentru fiecare secțiune și pentru fiecare dintre cele douăzeci de întrebări cele mai frecvente; puneți responsabilii să scrie acele articole pornind de la ce există deja — replici din chat, rezumate de ședințe, fișiere — folosind un șablon de o pagină cu un răspuns scurt, pași, excepții și o dată de revizuire; publicați în locul pe care echipa îl citește deja; apoi țineți bucla în mișcare, în care fiecare întrebare cu răspuns devine un articol, iar responsabilul fiecărui articol îl revizuiește la data stabilită.

Ce ar trebui să includă o bază de cunoștințe?

Un articol pentru fiecare întrebare, fiecare cu întrebarea în cuvintele pe care le folosesc oamenii, un responsabil, data ultimei revizuiri și data următoarei, un răspuns scurt, cazurile în care se aplică și în care nu, pașii care numesc 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 articolele conexe. Baza în ansamblu are nevoie de o structură de cel mult șapte secțiuni, organizată după întrebările puse, nu pe departamente.

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

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 un articol pe întrebare și cu un responsabil numit și o dată de revizuire pentru fiecare. Un wiki poate fi transformat într-o bază de cunoștințe prin adăugarea structurii și a responsabililor; fără ele, un wiki ajunge la sute de pagini prin care nimeni nu poate naviga și pe care nimeni nu le-a verificat. Software-ul este adesea același; diferența o fac cele două decizii.

Cum structurați o bază de cunoștințe?

Pe întrebări, nu pe departamente: cel care întreabă nu știe cărui departament îi aparține răspunsul, dar știe ce întreabă. Grupați întrebările adunate în prima săptămână în cel mult șapte secțiuni de nivel superior — pentru o organizație mică, de obicei clienți și comenzi, bani și facturare, oameni și angajări, instrumente și acces, reguli și decizii și pe cine sunăm — și păstrați fiecare articol la o singură întrebare. Dacă o secțiune depășește aproximativ treizeci de articole, împărțiți-o după întrebările pe care le pun oamenii, nu după cine răspunde la ele.

Cât durează construirea unei baze de cunoștințe?

Treizeci de zile până la o bază pe care oamenii o deschid: o săptămână de adunat întrebări, o săptămână pentru structură și responsabili, o săptămână pentru scrierea primelor douăzeci de articole din surse existente, o săptămână pentru publicare și stabilirea buclei de revizuire. Cel care coordonează dedică aproximativ două ore pe săptămână; fiecare responsabil dedică douăzeci de minute pe articol, pentru că majoritatea articolelor sunt copiate dintr-un răspuns deja dat, nu scrise de la zero. Baza nu este terminată în ziua 30; ea crește cu un articol de fiecare dată când se răspunde la o întrebare.

Puteți construi o bază de cunoștințe gratuit?

Da — șablonul din acest ghid este text simplu, iar baza poate sta într-o notă, un document sau un canal din instrumentele pe care o echipă le folosește deja: un canvas în Slack, un Google Doc, fila Files a unui canal Teams, o notă fixată într-un chat. Ce nu costă nimic în software costă totuși timpul de revizuire al responsabililor, iar limitele sunt cele ale suitei: planul Free din Slack păstrează 90 de zile de istoric al mesajelor, iar în orice suită articolul este în limba în care a fost tastat. În InterMIND, planul Basic este gratuit, iar prețurile planurilor plătite se află pe pagina de prețuri.

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 notițele din ședințe, pagina cu șablonul de canvas Slack și pagina Google „Take notes for me" au fost verificate în octombrie 2026; paginile despre traducerea mesajelor și subtitrările din Teams, paginile Slack despre prețuri, retenție și export, paginile despre traducerea din Google Chat și subtitrările din Meet ș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ă.