Wiki interno: strumenti, struttura e il wiki che nasce dalla cronologia del canale (2026)

Un wiki interno è l'insieme delle pagine che un'organizzazione scrive per sé e per nessun altro: come si configura un nuovo distributore, dove si trova il listino aggiornato, cosa è stato deciso sugli sconti a giugno, chi chiamare quando il corriere è in ritardo. È interno perché chi legge è un collega, ed è un wiki perché qualsiasi membro può scrivere una pagina e qualsiasi pagina può rimandare a un'altra. Un'organizzazione da 10–200 persone ne ha uno dal giorno in cui una seconda persona fa la stessa domanda. L'unica scelta è se le pagine esistono oppure se la risposta resta nella testa di un collega e in una dozzina di thread di chat.

La maggior parte delle guide ai wiki interni è un elenco di software. Questa parte da prima, perché lo strumento è la più piccola delle decisioni: un wiki che funziona è una struttura in cui orientarsi, un formato di pagina che resta fedele alla realtà e un luogo che il team già apre ogni giorno. Prima viene il mestiere (la struttura, un modello di pagina da copiare, un esempio concreto da una clinica), poi la meccanica: dove vive il wiki negli strumenti che il tuo team già usa, secondo la loro stessa documentazione, e cosa fa ciascuno con la riunione in cui la regola è stata davvero stabilita. Perché la prova di un wiki non è il giorno del lancio. È il lunedì in cui un nuovo collega lo apre e trova la pagina in una lingua che legge.

Cos'è un wiki interno, e cosa non è

Quattro cose vengono chiamate wiki, e la confusione tra loro è il motivo per cui se ne costruiscono tanti e se ne aprono così pochi:

Il wiki è la prima riga, ed è quello da cui dipendono gli altri tre. Una knowledge base è un wiki con la struttura imposta: una voce per domanda e un responsabile per ciascuna; il metodo per costruirne una in 30 giorni è in quella guida, mentre questa riguarda la forma del wiki in sé. L'intranet è ciò che il wiki diventa quando solo tre persone possono scrivere. L'unità condivisa è il posto dove stanno i file del wiki, e il compito del wiki è indicare quello corrente. Un wiki non è nemmeno un documento di processo o una SOP: quelli descrivono un lavoro dall'inizio alla fine; una pagina del wiki dice dove trovarli e cosa è cambiato da allora.

Ciò che rende interno un wiki non è una password. È che le pagine sono scritte con le parole che il team usa («la regola Casablanca», «il giro del martedì») e che possono dire ciò che una pagina esterna non potrebbe mai: chi ha deciso, perché e cosa ha sostituito.

La struttura: sette sezioni, una pagina per domanda

La differenza tra un wiki che le persone aprono e uno che hanno smesso di aprire raramente è lo strumento. Sono tre decisioni prese, o non prese, prima della prima pagina.

Sezioni per domanda, non per reparto. Il collega che si chiede «come fatturiamo a un distributore in Svizzera?» non sa se la risposta spetti ad amministrazione, vendite o logistica; conosce la domanda. Un wiki organizzato per reparto lo manda a cercare in tre sezioni per trovare una pagina. Organizza invece per le domande che le persone fanno, con le loro parole, e tieni il livello principale a sette sezioni o meno. Oltre le sette, la struttura stessa ha bisogno di una ricerca, e una ricerca su un wiki che nessuno ha ancora riempito non restituisce nulla. Livelli principali tipici per una piccola organizzazione: clienti e ordini; denaro e fatturazione; persone e assunzioni; strumenti e accessi; regole e decisioni; chi chiamare.

Una pagina per domanda, meno di una schermata. Una pagina che risponde a una domanda viene trovata e letta; una pagina che spiega un'intera funzione finisce nei segnalibri e viene letta in diagonale. «Come fatturiamo alla Svizzera?» è una pagina. «Amministrazione» è una sezione. Se una pagina ha bisogno di un indice, sono due pagine.

Un responsabile e una data su ogni pagina. Una pagina che dice chi ne è responsabile e quando è stata controllata l'ultima volta viene creduta; lo stesso testo senza queste indicazioni è «probabilmente obsoleto». Il compito del responsabile è piccolo (una volta a trimestre rispondere a «è ancora corretto?» e cambiare la data) ed è l'unica cosa che tiene vivo un wiki oltre il primo anno. Una pagina per cui non si può indicare nessuno non è conoscenza: è un'ipotesi, e va tolta.

Due abitudini mantengono la struttura una volta creata. Ogni risposta data nel canale del team che viene chiesta due volte diventa una pagina, scritta da chi ha risposto e collegata dalla sezione a cui appartiene. E ogni decisione che cambia una regola riceve prima la sua riga nel registro delle decisioni; poi la pagina che enuncia la regola rimanda a quella riga, così sei mesi dopo la pagina può dire non solo qual è la regola ma anche perché.

Come creare un wiki interno in una settimana

Il piano presuppone una persona che lo guidi (il responsabile del team, o chi riceve più domande) e il resto del team che dedica pochi minuti.

Giorno 1: scegli il posto in base a dove il team già legge. Non in base a un confronto tra software. Il wiki vive dove si fanno le domande: il canale del team, la suite in cui sono già i file. Un wiki in un quinto strumento con il proprio login è un wiki che nessuno apre il lunedì mattina. La tabella più avanti dice cosa conserva ogni posto e dove ciascuno si ferma.

Giorni 1–3: raccogli le domande, non le risposte. Pubblica un messaggio nel canale: «Rispondi con ogni domanda che hai fatto a un collega questa settimana, con le parole che hai usato». Al terzo giorno ce ne sono da quaranta a sessanta; un terzo sono doppioni. Conta le ripetizioni: la domanda posta cinque volte è la pagina numero uno.

Giorno 4: ordina in sette sezioni, assegna i responsabili. I gruppi in cui cadono le domande sono le sezioni. Nomina un responsabile per sezione (chi ha risposto a più domande) e un responsabile per ciascuna delle prime quindici pagine. Non scrivere ancora niente, tranne l'elenco: sezione, domanda, responsabile. Rimandalo al team con una sola domanda: «cosa manca?»

Giorni 5–7: le prime quindici pagine, da ciò che già esiste. Ogni responsabile scrive le proprie pagine con il modello qui sotto, partendo dalla risposta in chat, dal riepilogo della riunione in cui la regola è stata stabilita, dal file allegato a marzo. La regola della prima settimana è «breve e vero batte lungo e completo»: una risposta di due frasi con un link al file, datata e firmata, è una pagina. Poi fissa l'indice delle sezioni dove il team legge, e il wiki esiste.

Cosa non succede nella settimana: migrare l'unità condivisa, scrivere una pagina per ogni processo, scegliere un nuovo strumento. Il wiki rimanda ai file dove sono e alle procedure dove vivono.

Un modello di pagina per il wiki interno

Una pagina, una domanda, meno di una schermata. Copialo come nota e compilalo; le righe più spesso saltate sono le ultime tre, ed sono quelle che mantengono la pagina fedele alla realtà.

[Domanda, con le parole che si usano per farla]
Responsabile: [nome] · Sezione: [una delle sette] · Ultima revisione: [data] · Prossima revisione: [data]
Risposta breve: [due frasi: cosa fare]
Si applica a: [team, sede, tipo di cliente] · Non si applica a: [il caso che le persone confondono con questo]
Come: [passaggi numerati, ciascuno con il sistema, la persona o il file coinvolto]
La regola alla base: [la decisione che l'ha stabilita, con data e motivo, con link al registro delle decisioni]
Eccezioni: [i casi fuori dal percorso normale e chi decide per ciascuno]
Dove sono i file: [link al modello, al listino, al contratto correnti]
Pagine collegate: [la SOP, il processo, la versione precedente di questa pagina]

Il modello è testo semplice con etichette in grassetto, quindi si incolla in un file Word, in un Google Doc, in una pagina wiki, in un canvas di Slack o in una nota di chat senza doverlo riformattare.

Un esempio concreto: il wiki di una clinica dopo una settimana

Una clinica di fisioterapia a Barcellona, 24 persone: una reception di quattro, quattordici terapisti, due in amministrazione contabile, il resto personale amministrativo. Metà dei terapisti è arrivata da Argentina, Colombia e Ucraina negli ultimi due anni; un terzo dei pazienti è composto da residenti britannici e tedeschi che prenotano in inglese. Tre giorni di raccolta hanno prodotto 52 domande; tolti i doppioni, 37. La struttura che ne è uscita, con le pagine per sezione al settimo giorno:

1. Pazienti e prenotazioni (5) — come si prenota una prima visita; cosa fare con un mancato appuntamento; come un paziente cambia terapista
2. Fatturazione e assicurazioni (4) — quali assicurazioni vengono fatturate direttamente; come si emette una ricevuta per un'assicurazione estera; quando una seduta viene rimborsata
3. Protocolli di trattamento (3) — dove stanno le schede di protocollo; chi approva un piano di trattamento; cosa si registra dopo ogni seduta
4. Strumenti e accessi (2) — chi dà accesso al sistema di prenotazione; dove sono i modelli di lettera per i pazienti
5. Regole e decisioni (2) — la regola di cancellazione entro 24 ore; il registro delle decisioni
6. Chi chiamare (1) — i contatti delle assicurazioni; la linea di assistenza per le attrezzature

Diciassette pagine. La domanda più frequente, «come emettiamo una ricevuta che un'assicurazione tedesca accetti?», aveva ricevuto risposta alla reception nove volte in un anno dalla stessa responsabile della fatturazione; la pagina le ha richiesto quindici minuti, perché la nona risposta era già scritta nel canale e bastava aggiungere la riga del responsabile e la data.

Una pagina compilata della sezione 2:

Come emettiamo una ricevuta che un'assicurazione estera accetti?
Responsabile: Responsabile fatturazione · Sezione: Fatturazione e assicurazioni · Ultima revisione: 6 novembre 2026 · Prossima revisione: 6 febbraio 2027
Risposta breve: Usa il modello «ricevuta per assicurazione», nella lingua del paziente, con il codice diagnosi e il numero di abilitazione del terapista su ogni riga.
Si applica a: pazienti che pagano di tasca propria e chiedono il rimborso a un'assicurazione all'estero · Non si applica a: assicurazioni che fatturiamo direttamente, che ricevono l'estratto conto mensile.
Come: 1. Apri il paziente nel sistema di prenotazione. 2. Scegli il modello di ricevuta per assicurazione. 3. Aggiungi il codice diagnosi dal piano di trattamento. 4. Verifica che il numero di abilitazione sia su ogni riga. 5. Invia in PDF e archivia una copia nella cartella del paziente.
La regola alla base: I numeri di abilitazione sono stati aggiunti dopo i rifiuti tedeschi di aprile 2026 (voce del registro delle decisioni 2026-04-22).
Eccezioni: Un paziente che ha bisogno di una ricevuta dettagliata per seduta si rivolge al responsabile della fatturazione; nessun altro ne emette.
Dove sono i file: Modello di ricevuta per assicurazione; elenco dei codici diagnosi; cartelle dei pazienti.
Pagine collegate: Quali assicurazioni vengono fatturate direttamente; quando una seduta viene rimborsata.

Dove vive il wiki negli strumenti che già usi

Un'organizzazione da 10–200 persone costruisce il proprio wiki nella suite che già paga, e ogni suite ha un posto per la pagina, un posto per i file e un percorso per ciò che una riunione lascia dietro di sé. Ognuna si ferma in un punto diverso, e in ognuna la pagina resta nella lingua in cui è stata scritta. Solo comportamenti documentati, dalle pagine dei fornitori stessi, con il mese in cui ciascuna pagina è stata verificata:

Tre cose sono uguali in tutti e quattro. La pagina è un documento o un messaggio nell'unica lingua in cui è stato scritto, e un membro che legge un'altra lingua legge quello oppure una copia fatta da qualcuno. I file sono in un secondo posto, trovato con una seconda ricerca. E la riunione, dove la regola è stata discussa e stabilita, arriva al wiki solo quando una persona la digita dopo: dove Teams e Meet conservano una trascrizione e un riepilogo, e come tenerli dopo la chiamata, è in dove Microsoft Teams e Google Meet conservano trascrizione, registrazione e riepilogo; i notetaker AI che molti team aggiungono per lo stesso motivo sono messi a confronto in alternative a Otter.ai, e ciascuno scrive il proprio riepilogo in una sola lingua.

La traduzione che queste suite documentano appartiene alla chiamata o allo schermo del lettore, non alla pagina: Microsoft documenta i sottotitoli tradotti in tempo reale nelle riunioni di Teams quando l'organizzatore ha una licenza Teams Premium o Microsoft 365 Copilot, Google documenta i sottotitoli tradotti in Meet nei piani Workspace idonei (entrambi verificati ad agosto 2026), e WhatsApp documenta la traduzione di un messaggio ricevuto sul telefono del lettore (verificato ad agosto 2026). Cosa copre ciascuno e dove ciascuno si ferma è in traduzione in diretta in Microsoft Teams, traduzione in diretta in Google Meet e traduzione su WhatsApp. La pagina della ricevuta che il terapista ucrainofono apre il lunedì è un oggetto distinto da quei sottotitoli, e si legge nella lingua in cui è stata scritta.

Il wiki che nasce dalla cronologia del canale

InterMIND è uno spazio di comunicazione in cui il lavoro di un team vive in un canale, quindi il wiki ha una casa ovvia: il canale del team che lo usa (la reception della clinica, il team export, il gruppo account dell'agenzia), che è anche il posto dove si fanno le domande e da cui partono le riunioni. Le tre decisioni descritte sopra vi si applicano direttamente.

Le pagine e i loro responsabili sono note nel canale. Una nota è un messaggio in rich text con titoli ed elenchi numerati, modificato in seguito dal proprio menu, e viene letta da ogni membro nella propria lingua con l'originale a un tocco di distanza; fissato in alto, l'indice delle sezioni è la prima cosa che un nuovo collega trova. Con la cronologia delle modifiche attiva, la formulazione precedente di una regola cambiata compare sopra il testo corrente come differenza parola per parola con la sua marca temporale: la traccia di revisione a cui rimanda la riga «ultima revisione» del responsabile. I file a cui una pagina rimanda (il modello di ricevuta, l'elenco dei codici diagnosi, il contratto con l'assicurazione) vengono caricati nello stesso canale e portano, su ogni piano, un riepilogo AI nella lingua del lettore con ogni punto collegato al paragrafo da cui proviene; nei piani a pagamento il file stesso si apre tradotto nella lingua del lettore (30 lingue per i documenti). Se la copia master resta in uno strumento di documenti, i suoi aggiornamenti arrivano nel canale via email: l'host del canale gli assegna un indirizzo dedicato, e un messaggio inviato lì compare come messaggio normale con il mittente indicato e gli allegati conservati. Un team che arriva da Slack porta con sé i propri canali: un'esportazione standard di uno spazio di lavoro Slack viene ripristinata come un canale per ogni canale Slack, con i messaggi in ordine e i loro orari originali, i messaggi fissati e le reazioni conservati, e ogni messaggio letto da ciascun membro nella propria lingua.

La storia dietro ogni pagina è il punto in cui il canale fa il lavoro che la tabella sopra lascia a una persona. La riunione in cui la regola viene stabilita parte dal canale; durante la chiamata la bozza della pagina compare sullo schermo di tutti accanto ai riquadri video con Share to conference (una nota, oppure un documento Google Docs o OneDrive collegato nella chat), e ogni partecipante lo scorre in modo indipendente e lo legge nella propria lingua, mentre chi condivide lo modifica in diretta. Quando la chiamata finisce, il riepilogo viene scritto a partire dalla riunione stessa: una sintesi, i punti segnati come concordati, aperti o contestati, gli action items con i responsabili, ogni riga con la propria marca temporale; e i documenti condivisi durante la sessione contribuiscono con i loro riepiloghi accanto a quanto è stato detto. Arriva via email, come messaggio nel canale e come link nell'evento del calendario, e ogni membro con accesso lo legge nella propria lingua: il documento di riferimento viene tradotto per ciascun lettore, non scritto una volta sola nella lingua che la stanza ha usato per caso. Qualsiasi membro può modificarlo, ogni modifica conserva autore e cronologia delle revisioni, e il canale conserva il riepilogo di ogni sessione passata, così la riunione che ha stabilito la regola del numero di abilitazione è a un clic dalla pagina che la enuncia. Questo è il wiki che nasce dalla cronologia del canale: la nona risposta alla reception, il riepilogo della chiamata in cui la regola è stata discussa, il modello allegato ad aprile, tutto in un unico posto, con la pagina sopra di essi. Confrontata con la tabella sopra, la differenza è un'affermazione semplice: i sottotitoli che quelle suite documentano traducono la chiamata mentre si svolge; qui la pagina, le riunioni che l'hanno prodotta, i suoi file e la sua cronologia sono un unico documento, letto da ogni membro nella propria lingua.

Il canale delle domande riceve lo stesso trattamento dall'altra direzione. L'assistente personale di un membro (Claude, ChatGPT, Copilot o Gemini, collegato tramite il connettore MCP) cerca in riepiloghi, trascrizioni, chat e testo dei file condivisi con una sola domanda, «come emettiamo una ricevuta che un'assicurazione tedesca accetti?», e restituisce i passaggi con la riunione, la data e il file da cui provengono; funziona per le organizzazioni con le funzioni AI attive, e la lettura tramite assistente è limitata alle riunioni e ai canali di cui il membro fa parte. La chat stessa ha una ricerca, e il wiki può essere portato via per intero: su ogni piano un backup da Impostazioni esporta i canali come ZIP con messaggi, trascrizioni e file, rispondendo alla questione della proprietà a livello di organizzazione e non di singola pagina.

Chi custodisce la conoscenza di un team non è sempre un dipendente. Il referente dei sinistri dell'assicurazione, il tecnico delle attrezzature, il commercialista freelance che conosce la regola tedesca sulle ricevute: un membro esterno del canale entra tramite email con un account gratuito e legge le pagine e la loro cronologia come tutti gli altri; una persona senza account è ospite di una sola riunione: entra nella chiamata con un link, da un telefono, senza costi, la ascolta in diretta nella propria lingua e dopo non riceve alcun documento. L'host mette a disposizione lo spazio e, in un piano a pagamento, paga solo per i membri attivi negli ultimi 28 giorni, cioè chi ha partecipato a una riunione, ha scritto in una chat o ha interrogato l'assistente; i membri che restano inattivi mantengono l'accesso senza costi, ed è ciò di cui un wiki ha bisogno: la persona che ha scritto la pagina due anni fa può ancora essere nel canale.

• Apri un riepilogo completo — un documento reale generato dallo stesso codice che scrive i tuoi.
• Prova la demo dal vivo — senza registrazione; parla, e ascolta la stanza tradotta per ogni ascoltatore.

Un wiki interno come mestiere sopravvive a ogni strumento: qualcuno deve comunque raccogliere le domande, tenere la struttura a sette sezioni, mettere un nome e una data su ogni pagina e rispondere nel canale invece che in messaggio diretto. Ciò che non deve sopravvivere è il secondo lavoro: ridigitare nel wiki ciò che la riunione ha deciso e mantenere a mano una copia tradotta di ogni pagina, una lingua alla volta, per i colleghi che leggono l'altra.

FAQ

Cos'è un wiki interno?

Un wiki interno è un insieme di pagine che un'organizzazione scrive per i propri membri (come si fanno le cose, dove sono i file, cosa è stato deciso e perché), conservate in un unico posto, dove qualsiasi membro può scrivere una pagina e qualsiasi pagina può rimandare a un'altra. Si distingue da un wiki pubblico per il lettore, un collega e non un cliente, e da un'intranet perché sono le persone che fanno il lavoro a scrivere e aggiornare le pagine, non un team centrale. Le pagine che vengono aperte sono quelle organizzate per le domande che le persone fanno, con un responsabile e una data di revisione su ciascuna.

Qual è la differenza tra un wiki interno e una knowledge base?

Un wiki è un insieme di pagine che chiunque può scrivere in qualsiasi struttura; una knowledge base è organizzata per le domande che le persone fanno, con una voce per domanda e un responsabile e una data di revisione indicati su ciascuna. Un wiki diventa una knowledge base aggiungendo la struttura e i responsabili; senza di essi cresce fino a centinaia di pagine in cui nessuno sa orientarsi e che nessuno ha controllato. Il software è spesso lo stesso, e il metodo per trasformare l'uno nell'altra in 30 giorni è in come costruire una knowledge base.

Come si crea un wiki interno?

Scegli il posto in base a dove il team già legge, non in base a un confronto tra software; raccogli per tre giorni le domande che il team pone davvero, con le parole usate; ordinale in non più di sette sezioni e nomina un responsabile per sezione e per pagina; scrivi le prime quindici pagine da ciò che già esiste (la risposta in chat, il riepilogo della riunione, il file) usando un modello di una pagina con risposta breve, passaggi, eccezioni e data di revisione; fissa l'indice delle sezioni dove il team legge. Poi mantieni il ciclo: ogni domanda a cui si risponde due volte diventa una pagina, e il responsabile di ogni pagina la rivede alla sua data.

Cosa dovrebbe includere un wiki interno?

Una pagina per domanda, ciascuna con la domanda nelle parole che le persone usano, un responsabile, la data dell'ultima revisione e quella della prossima, una risposta breve, i casi a cui si applica e a cui non si applica, i passaggi con il sistema o la persona coinvolta, la decisione alla base della regola con la sua data, le eccezioni e chi decide per ciascuna, i link ai file correnti e i link alle pagine collegate. Il wiki nel suo insieme ha bisogno di una struttura di sette sezioni o meno, organizzata per le domande poste e non per reparto, e di un indice delle sezioni fissato dove il team legge.

Qual è lo strumento migliore per un wiki interno?

Quello che il team già apre ogni giorno, perché un wiki in un quinto strumento con il proprio login è il wiki che nessuno controlla il lunedì. In Microsoft Teams pagine e file stanno nel canale e nel suo sito SharePoint, con le note della riunione come componente Loop; in Slack un canvas nel canale; in Google Workspace un Google Doc collegato dal calendario; in WhatsApp la chat di gruppo stessa, ciascuno con i limiti documentati nella tabella sopra, e ciascuno con la pagina che resta nella lingua in cui è stata scritta. InterMIND mantiene note, file, chat e riepiloghi delle riunioni di un team in un unico canale, letto da ogni membro nella propria lingua, accanto a quegli strumenti e non al loro posto.

Si può costruire un wiki interno in Microsoft Teams?

Secondo la documentazione di Microsoft, i file di un team sono archiviati in un sito SharePoint creato insieme al team, con tutti i canali standard che condividono quel sito e una cartella per canale, quindi la scheda File del canale è il posto dove vivono i documenti del wiki; le note della riunione sono un componente Loop che qualsiasi partecipante od organizzatore può modificare, salvato automaticamente e raggiungibile dal calendario di Teams e dal riepilogo della riunione. Due limiti documentati contano per un wiki: i partecipanti esterni non possono accedere alle note della riunione né modificarle, e chat e messaggi del canale possono essere eliminati dopo un periodo da una policy di conservazione di Teams, mentre i file seguono le proprie policy di SharePoint e OneDrive (pagine verificate a ottobre e novembre 2026).

Come si mantiene aggiornato un wiki interno?

Con un responsabile e una data di revisione su ogni pagina, e nient'altro. Il compito del responsabile è rispondere a «è ancora corretto?» una volta a trimestre e cambiare la data; una pagina il cui responsabile se n'è andato riceve un nuovo responsabile oppure viene tolta. Due abitudini alimentano le pagine: ogni risposta data due volte nel canale del team diventa una pagina, scritta da chi ha risposto, e ogni decisione che cambia una regola viene registrata per prima, così la pagina può rimandare al perché è cambiata. Un wiki tenuto così cresce di una pagina ogni volta che si risponde a una domanda, e nessuno lo riscrive come progetto.

Fonti: 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. La pagina di Microsoft Learn su Teams e SharePoint è stata verificata a novembre 2026; le pagine su conservazione di Teams e note della riunione, la pagina del modello canvas di Slack e la pagina Google «Take notes for me» a ottobre 2026; le pagine sulla traduzione dei messaggi e sui sottotitoli di Teams, le pagine Slack su prezzi, conservazione ed esportazione, le pagine sulla traduzione di Google Chat e sui sottotitoli di Meet e le pagine di WhatsApp ad agosto 2026. I fornitori cambiano nel tempo piani, funzionalità ed elenchi di lingue; consulta le loro pagine per lo stato attuale.