Collaborazione cross-funzionale: come gestirla senza una riunione per ogni cosa (2026)

La collaborazione cross-funzionale è quella di persone di funzioni diverse (prodotto e assistenza, vendite e logistica, la reception di una clinica e il suo ufficio fatturazione, spesso anche un partner esterno all'azienda) che portano a termine insieme un unico pezzo di lavoro. Non si tratta di rispondere gli uni agli altri, né di partecipare alle riunioni altrui: si tratta di finire una cosa, con una persona che ne è responsabile, un luogo in cui se ne discute e una traccia di ciò che è stato deciso e di chi fa che cosa. Fatta bene, è quasi silenziosa. Le funzioni scrivono, il responsabile legge, e si fa una riunione quando due di esse devono scegliere tra delle opzioni entro la settimana.

Fatta male, diventa un calendario. Ogni passaggio di consegne ha il suo sync, ogni sync ha il suo follow-up, e chi lavora passa la settimana a spiegare il proprio lavoro a chi fa l'altra metà. Questa guida parte dal mestiere: le tre forme che prende il lavoro cross-funzionale, i quattro punti in cui si rompe, le cinque regole per gestirlo senza una riunione fissa. Poi propone un accordo di lavoro di una pagina da copiare, tre esempi compilati, il luogo documentato in cui il lavoro vive negli strumenti che il tuo team già paga e un modo per far sì che il canale in cui tutto avviene resti leggibile da ogni funzione nella propria lingua.

Che cos'è la collaborazione cross-funzionale, e che cosa non è

Il lavoro cross-funzionale prende tre forme, e la maggior parte dei problemi nasce dal gestirne una con le abitudini di un'altra:

La prima forma ha una sua guida; questa riguarda la seconda e la terza, che sono quelle in cui le riunioni si moltiplicano. Un progetto con quattro funzioni e un sync settimanale per ogni coppia fa sei riunioni a settimana prima ancora che il lavoro cominci. Una richiesta evasa in riunione costa a tutta la sala il tempo che a una persona sarebbe servito per scrivere la risposta.

La collaborazione cross-funzionale non coincide nemmeno con il coordinamento interdipartimentale. Il coordinamento consiste nel tenersi informati tra reparti mentre ciascuno fa il proprio lavoro; la collaborazione è un unico pezzo di lavoro che una sola funzione non può portare a termine da sola. Il criterio è il risultato da consegnare: se il marketing può pubblicare la campagna senza l'assistenza e l'assistenza può scrivere la macro senza il marketing, stanno coordinandosi, e basta un messaggio a settimana. Se il lancio non è concluso finché non sono concluse insieme entrambe le metà, stanno collaborando, e serve un luogo condiviso in cui farlo.

Dove si rompe: i quattro punti di rottura

Il lavoro cross-funzionale raramente fallisce al kick off. Fallisce nelle settimane successive, in quattro punti prevedibili:

1. Il passaggio di consegne. La funzione A finisce la sua parte e lo comunica alla funzione B: con un messaggio nel canale di A, in una riunione a cui B non partecipava, in un'email a una persona che è in ferie. B parte in ritardo, o parte dalla versione sbagliata. La soluzione non è un'altra riunione, ma un unico luogo in cui ogni passaggio viene scritto e ogni funzione lo legge.
2. La responsabilità. Quattro funzioni, quattro responsabili, e il lavoro appartiene al progetto, cioè a nessuno. Ciascuno risponde della propria metà e nessuno risponde della giunzione. La soluzione è un nome: un responsabile per l'intero risultato, di qualunque funzione sia, con l'autorità di chiedere una data a tutte le altre.
3. Il vocabolario. "Finito" per l'ingegneria significa testato, per il marketing annunciato, per l'assistenza documentato. "Il cliente" è un ospedale per le vendite e un infermiere per il team di prodotto. Metà delle riunioni di un progetto cross-funzionale esiste per scoprire che due persone si sono messe d'accordo usando parole diverse. La soluzione è un breve glossario, scritto una volta e tenuto dove si lavora.
4. La traccia. La decisione è stata presa in una chiamata tra due delle quattro funzioni; la terza lo scopre una settimana dopo e la riapre; la quarta non lo scopre mai. La soluzione è una regola: una decisione si scrive nel canale del progetto il giorno stesso in cui viene presa, e un registro delle decisioni raccoglie quelle di cui vanno conservate le motivazioni.

Un quinto punto di rottura compare quando le funzioni non condividono una lingua di lavoro: il team di sviluppo in un paese, il desk di assistenza in un altro, il responsabile di progetto del cliente in un terzo. Ogni funzione tiene allora il proprio canale nella propria lingua, e ogni passaggio di consegne attraversa un confine due volte: una tra funzioni, una tra lingue. Le regole che seguono valgono anche per questo caso, perché la soluzione è la stessa (un luogo, scritto per impostazione predefinita), con un requisito in più per quel luogo.

Come gestirla senza una riunione per ogni cosa

Cinque regole. Sostituiscono il sync fisso, non il kick off né le riunioni decisionali: quelle due restano.

1. Un solo responsabile per l'intero pezzo di lavoro. Nominato al kick off, dalla funzione che ne porta la parte più grande. Il responsabile non fa il lavoro di tutti: è la persona che può dire, in qualsiasi giorno, a che punto è il risultato e che cosa sta aspettando. Ogni funzione indica un referente al responsabile, e quel referente risponde della parte della propria funzione. Due nomi per funzione (il capo e chi fa il lavoro) sono già troppi: il responsabile deve sapere a chi chiedere.

2. Un canale, e tutti dentro. Un canale per ogni pezzo di lavoro, non per funzione, non per coppia di funzioni, con tutti i referenti di tutte le funzioni e anche le persone esterne all'azienda che fanno parte del lavoro: l'integratore, l'agenzia, il responsabile di progetto del cliente, l'addetto agli ordini del distributore. Nel canale si annunciano i passaggi di consegne, si fanno le domande e si scrivono le decisioni. Una funzione che discute del progetto nel proprio canale e poi riferisce in quello condiviso sta portando avanti due progetti, e quello condiviso è il più lento.

3. Scritto per impostazione predefinita; una riunione per decidere. La forma predefinita di un passaggio di consegne, di una domanda, di uno stato o di un rischio è un messaggio nel canale. Una riunione si fissa quando due o più funzioni devono scegliere tra delle opzioni entro la settimana e la scelta richiede le persone nella stessa stanza. Il test, prima di fissare: quale decisione prende questa riunione? Se la risposta è "aggiornare tutti", è un messaggio. Se la risposta è "abbiamo tre opzioni per la data di lancio e marketing e assistenza non sono d'accordo", è una riunione di 25 minuti con un'agenda della riunione e la decisione riletta alla fine.

4. Uno stato scritto, ogni settimana, entro un orario fissato. Ogni funzione pubblica nel canale tre righe, lo stesso giorno di ogni settimana, entro un'ora stabilita: fatto, prossimo, bloccato. Il responsabile le legge tutte e pubblica una riga sull'intero risultato: nei tempi, a rischio, oppure data spostata e perché. Una riunione settimanale di stato è questo, letto ad alta voce; la forma scritta costa a ogni funzione cinque minuti invece di un'ora, e chi non c'era può leggerla. Come migliorare la produttività del team contiene i conti dietro questo scambio.

5. Una sola traccia: decisioni, attività, riepiloghi, nel canale. Una decisione si scrive nel canale il giorno stesso in cui viene presa, con la data e il responsabile, anche se è stata presa per telefono o in corridoio, anzi, soprattutto allora. Ogni action item ha un nome e una data. Quando una riunione si tiene, il suo riepilogo va nello stesso canale lo stesso giorno, così la funzione che non era stata invitata legge che cosa è stato deciso senza chiederlo. A fine progetto il canale è la traccia: ogni passaggio di consegne, ogni decisione, ogni riepilogo, nell'ordine in cui sono avvenuti.

Il glossario è la sesta cosa, e si fa una tantum: al kick off, dieci termini che le funzioni usano in modo diverso, ciascuno con una definizione, pubblicati e fissati in alto nel canale. "Finito", "il cliente", "lancio", "consegnato", "approvato": le parole del progetto. Servono venti minuti e fanno sparire le riunioni il cui unico esito era "ah, intendevi quello".

Un accordo di lavoro cross-funzionale da copiare

Pubblicalo come nota nel canale del progetto al kick off, compila le parentesi, fissalo in alto. È di una pagina; una seconda pagina è un piano di progetto che cerca di entrare.

[Progetto] — accordo di lavoro cross-funzionale
Risultato: [una frase: che cosa è finito, e entro quando]
Responsabile: [nome, funzione] · Sponsor: [nome] · Concordato: [data] · Revisione: [data, a fine progetto o a metà]

Funzioni e referenti
[Funzione] — [nome], risponde di [la sua parte] · [Funzione] — [nome], [parte] · [Parte esterna] — [nome], [parte]

Dove si lavora
Canale: [un canale], con tutti i referenti sopra indicati, [parte esterna] inclusa. Passaggi di consegne, domande, rischi e stato vanno qui, per iscritto, il giorno in cui accadono. Nulla di questo progetto si decide nel canale di una singola funzione.

Che cosa merita una riunione
Una decisione tra opzioni che richiede più di una funzione nella stanza. Fissata con un'agenda e la domanda su cui decidere; 25 minuti; la decisione riletta alla fine e scritta nel canale lo stesso giorno. Tutto il resto è un messaggio.

Stato settimanale
Ogni funzione, [giorno] entro le [ora]: fatto · prossimo · bloccato. Il responsabile, entro le [ora + 2]: nei tempi / a rischio / data spostata, e perché.

Decisioni e attività
Una decisione si scrive qui il giorno stesso in cui viene presa, con la data e il responsabile; [regola del silenzio, es. un giorno lavorativo senza obiezioni vale come accordo]. Un'attività ha un nome e una data, altrimenti non è un'attività.

Glossario
[Termine] — [una definizione] · [Termine] — [definizione] · … (al massimo dieci)

Finito significa: [la lista di controllo che ogni funzione approva: testato, annunciato, documentato, fatturato]

L'accordo è testo semplice, quindi si incolla in un documento Word, in un Google Doc, in un canvas di Slack o in un messaggio di chat senza doverlo riformattare.

Tre esempi compilati

Un lancio di funzionalità tra prodotto, assistenza e marketing — un'azienda software di quaranta persone

Il team di prodotto a Valencia, un desk di assistenza di sei persone a Cluj che lavora in rumeno e una freelance di marketing a Buenos Aires. Tre funzioni, tre lingue, una data di lancio.

Risultato: la funzionalità di pianificazione è attiva per ogni cliente pagante entro il 12 dicembre, con l'articolo di aiuto pubblicato e l'annuncio inviato.
Responsabile: Marta, prodotto. Funzioni: prodotto — Marta, lo sviluppo e la data; assistenza — Andrei, l'articolo di aiuto, le macro e la prima settimana di ticket; marketing — Lucía, l'annuncio e il messaggio in-app.
Canale: #launch-scheduling; Lucía al suo interno come membro esterno.
Riunioni: una, la settimana prima del lancio, per scegliere tra le due opzioni di rilascio se il test dell'assistenza rileva qualcosa. Altrimenti nessuna.
Stato: giovedì entro le 11:00 CET, ogni funzione; Marta entro le 13:00.
Glossario: "finito" — testato dall'assistenza sull'account di staging, articolo di aiuto pubblicato, annuncio programmato; "il cliente" — il receptionist della clinica, non il titolare della clinica.
Finito significa: tutte e tre le righe della definizione di "finito" del glossario, e il numero di ticket della prima settimana di Andrei pubblicato nel canale.

La riunione prevista si è tenuta; l'opzione di rilascio è stata scelta in diciotto minuti perché i risultati del test erano già nel canale. Il lancio precedente, gestito con un sync settimanale tra tre funzioni, ne aveva richieste undici.

Un nuovo processo di accoglienza tra reception, assistenza infermieristica e fatturazione — una clinica con un integratore esterno

Una clinica a Lione che introduce l'accoglienza online dei pazienti. Reception, assistenza infermieristica, fatturazione e l'integratore che collega i moduli al software dello studio, un'azienda di Casablanca che lavora in francese e arabo.

Risultato: ogni nuovo paziente compila il modulo di accoglienza online prima della prima visita; la reception non digita nulla due volte; dal 1° febbraio.
Responsabile: Claire, responsabile della reception. Funzioni: reception — Claire, le domande del modulo e la procedura del primo giorno; assistenza infermieristica — Samir, i campi clinici; fatturazione — Inès, i campi assicurativi e l'esportazione; integratore — Youssef, la connessione e l'ambiente di test.
Canale: #intake-online, con Youssef al suo interno per la durata del progetto.
Riunioni: due: la revisione dei campi, in cui assistenza infermieristica e fatturazione scelgono a quali domande il paziente deve rispondere e quali possono attendere; e il go/no-go della settimana prima.
Stato: lunedì entro le 10:00, ogni funzione; Claire entro le 12:00.
Glossario: "modulo completo" — ogni campo obbligatorio compilato, non ogni campo; "attivo" — sul sito della clinica, non sull'indirizzo di test dell'integratore.
Finito significa: venti pazienti reali passati dal modulo nella prima settimana, zero dati ridigitati dalla reception, la nota di consegna di Youssef nel canale.

Una richiesta: la finanza ha bisogno delle previsioni delle vendite

Non è un progetto. Una funzione ha bisogno di una cosa da un'altra, una volta sola. L'intera collaborazione è un messaggio:

A: Pau (vendite) · Da: Inés (finanza)
Che cosa: le previsioni del Q1 per distributore, nel solito foglio.
Entro: giovedì alle 16:00, perché il pacchetto per il consiglio si chiude venerdì a mezzogiorno.
Perché è importante: il piano di produzione viene dimensionato su di esse; una previsione in ritardo è un piano in ritardo.
Se non puoi: dillo entro martedì, e useremo i numeri del trimestre scorso con una nota.

Una richiesta con il che cosa, il entro quando, il perché e l'alternativa si evade senza una riunione. Una richiesta che ne è priva ne diventa una.

Dove vive il lavoro cross-funzionale negli strumenti che usi già

Ogni suite ha un posto per un gruppo formato da più team, e ognuna si ferma in un punto diverso, di solito alla persona esterna all'organizzazione o al membro che legge un'altra lingua. Solo comportamenti documentati, tratti dalle pagine dei fornitori stessi, con il mese in cui ogni dato è stato verificato:

Due cose valgono ovunque. La traccia del gruppo (l'accordo, i passaggi di consegne, le decisioni) esiste nella lingua in cui è stata digitata, e un membro che legge un'altra lingua legge una traduzione per singolo lettore di un messaggio alla volta, oppure una copia fatta da qualcuno. E ciò che una riunione lascia dietro di sé è un documento accanto al canale, nella lingua della sala; dove finiscono la trascrizione e il riepilogo dopo la chiamata ne è la versione più estesa.

Come l'intero progetto vive in un unico canale

InterMIND è uno spazio di comunicazione in cui un pezzo di lavoro vive in un canale, quindi le cinque regole hanno una casa evidente. Il canale viene creato per il lancio, il progetto di accoglienza o l'onboarding del distributore, e ogni referente di ogni funzione è al suo interno, comprese le persone esterne all'azienda: un membro esterno entra tramite email con un account gratuito, legge la cronologia del canale precedente al suo ingresso ed è presente in ogni chiamata avviata da lì. L'accordo di lavoro e il glossario vengono pubblicati come note (messaggi in formato rich text con titoli e righe in grassetto, modificabili in seguito dal loro menu) e fissati in alto, così la prima cosa che un nuovo referente legge è la pagina che spiega come funziona il progetto.

Ogni funzione scrive nella propria lingua e legge il canale nella propria: il desk di Cluj scrive il proprio stato del giovedì in rumeno, il team di Valencia lo legge in spagnolo, Lucía lo legge in spagnolo da Buenos Aires, e l'originale è a un tocco di distanza per chi lo vuole. Un file lasciato nel canale (il foglio delle previsioni, l'elenco dei campi, la consegna dell'integratore) viene riassunto automaticamente e il riepilogo, come un PDF o un documento Office condiviso, si apre nella lingua di ciascun lettore. Quando si tiene l'unica riunione, parte dal canale con un clic, i membri del canale sono la lista degli invitati, e l'accordo o l'elenco delle opzioni compare sullo schermo di tutti accanto ai riquadri video con Share to conference: chi condivide lo modifica in diretta mentre la sala guarda, e ogni partecipante lo legge nella propria lingua. Quando la chiamata termina, il riepilogo viene scritto a partire dalla trascrizione della riunione stessa (il riassunto, la trascrizione e la registrazione) e arriva via email, come messaggio nel canale e come link nell'evento del calendario, leggibile da ogni membro con accesso nella propria lingua. Qualsiasi membro può modificarlo, ogni modifica conserva autore e cronologia delle revisioni, e il canale conserva il riepilogo di ogni sessione passata, così la funzione che non era nella stanza legge che cosa è stato deciso senza chiederlo a nessuno. Se uno strumento esterno al canale ha qualcosa da dire (il sistema di ticketing, la pipeline di build, il monitoraggio dell'integratore), l'host del canale gli assegna un indirizzo proprio, e l'email arriva nel canale come un normale messaggio, con il mittente indicato e gli allegati conservati. L'host può anche aggiungere una copia del riepilogo verso qualsiasi indirizzo, così il riepilogo del go/no-go raggiunge la casella in entrata del CRM o del tracker senza che nessuno debba inoltrarlo.

Le persone di un progetto cross-funzionale non sono tutte membri dell'azienda del progetto, e non tutte restano a lungo. L'integratore, la freelance e l'addetto del distributore entrano come membri esterni del canale, via email, con un account gratuito, e lo leggono come tutti gli altri, nella propria lingua. Chi non ha un account è ospite di una sola riunione: il direttore finanziario del cliente entra nel go/no-go tramite link, da un telefono, senza alcun costo, lo ascolta in diretta nella propria lingua e dopo non riceve alcuna traccia; i membri del canale sì.

L'host fornisce lo spazio e, su un piano a pagamento, paga solo i membri attivi nei 28 giorni precedenti: chi ha partecipato a una riunione, scritto in una chat o interpellato l'assistente. I membri che restano inattivi mantengono l'accesso senza costi, e i partecipanti al canale esterni al team non vengono conteggiati, che è ciò di cui un progetto ha bisogno: la responsabile della fatturazione che sta nel canale per due settimane di dicembre e resta in silenzio fino a febbraio non costa nulla nel frattempo e ritrova comunque la traccia dove l'aveva lasciata.

• Apri un riepilogo completo — una traccia reale, generata dallo stesso codice che scrive la tua.
• Prova la demo dal vivo — senza registrazione; parla, e ascolta la sala tradotta per ogni ascoltatore.

La collaborazione cross-funzionale come mestiere sopravvive a qualsiasi strumento: qualcuno deve comunque nominare il responsabile, scrivere il passaggio di consegne e rifiutare la riunione che non prende alcuna decisione. Ciò che non deve sopravvivere è il secondo lavoro: tenere a mano la copia della traccia di ogni funzione, nella sua lingua, una versione indietro rispetto alle altre.

FAQ

Che cos'è la collaborazione cross-funzionale?

La collaborazione cross-funzionale è quella di persone di funzioni diverse (prodotto, vendite, assistenza, finanza, operations, spesso con un partner esterno all'azienda) che portano a termine insieme un unico pezzo di lavoro che nessuna funzione da sola potrebbe finire. Si distingue dal coordinamento, in cui i reparti si tengono informati mentre ciascuno fa il proprio lavoro. Prende tre forme: un team cross-funzionale stabile, un progetto cross-funzionale con una scadenza e una richiesta una tantum da una funzione a un'altra.

Qual è un esempio di collaborazione cross-funzionale?

Un lancio di funzionalità: il prodotto la sviluppa, l'assistenza scrive l'articolo di aiuto e gestisce i ticket della prima settimana, il marketing invia l'annuncio, e il lancio non è concluso finché non lo sono tutti e tre. Altri esempi: una clinica che introduce l'accoglienza online tra reception, assistenza infermieristica, fatturazione e un integratore esterno; un esportatore che fa l'onboarding di un nuovo distributore tra vendite, logistica e finanza con l'addetto agli ordini del distributore nel canale; un ciclo di selezione tra HR e team che assume. In ogni caso una persona è responsabile dell'intero risultato e ogni funzione ha un referente.

Perché la collaborazione cross-funzionale è importante?

Perché la maggior parte del lavoro che un'organizzazione consegna non sta dentro una sola funzione. Un lancio, un nuovo processo, un nuovo cliente e un nuovo mercato richiedono ciascuno che le parti di più funzioni combacino, e la giunzione tra le parti è il punto in cui si perdono tempo e qualità: il passaggio di consegne che nessuno ha annunciato, la decisione che una funzione non ha mai saputo, la parola che due funzioni hanno usato in modo diverso. Ben gestita, la collaborazione cross-funzionale rende visibile la giunzione (un responsabile, un canale, una traccia) ed elimina le riunioni il cui unico scopo era scoprire che cosa avesse fatto l'altra funzione.

Come si migliora la collaborazione cross-funzionale?

Cinque cambiamenti, in ordine di efficacia. Nomina un solo responsabile per l'intero risultato, non uno per funzione. Metti il referente di ogni funzione, e le parti esterne, in un unico canale per quel pezzo di lavoro e non discuterne altrove. Fai della scrittura la forma predefinita e fissa una riunione solo per una decisione tra opzioni. Sostituisci la riunione di stato con tre righe scritte per funzione in un giorno stabilito. Scrivi ogni decisione nel canale il giorno stesso in cui viene presa, con un responsabile e una data su ogni attività. Un glossario di dieci termini al kick off elimina un'ulteriore categoria di riunioni.

Quali sono le sfide della collaborazione cross-funzionale?

Quattro ricorrono: il passaggio di consegne che una funzione annuncia in un luogo che l'altra non legge; la responsabilità divisa in modo che ogni funzione risponde della propria metà e nessuno della giunzione; il vocabolario, in cui "finito", "il cliente" o "approvato" significano cose diverse per funzioni diverse; e la traccia, in cui una decisione presa tra due funzioni viene riaperta da una terza che non l'ha mai saputa. Una quinta compare quando le funzioni non condividono una lingua: ciascuna tiene il proprio canale, e ogni passaggio di consegne attraversa un confine due volte. Ognuna ha la stessa forma di soluzione: un luogo, scritto, letto da tutti gli interessati.

Qual è la differenza tra collaborazione cross-funzionale e interdipartimentale?

Quella interdipartimentale, o coordinamento interdipartimentale, consiste nel fatto che i reparti si tengono informati mentre ciascuno porta a termine il proprio lavoro: un aggiornamento mensile tra vendite e finanza. La collaborazione cross-funzionale è un unico risultato che richiede il lavoro combinato di più funzioni, con un solo responsabile del risultato: il lancio non è concluso finché prodotto, assistenza e marketing non hanno finito ciascuno e le loro parti non combaciano. Il criterio è se una sola funzione potrebbe consegnare il risultato da sola. Se potesse, basta un messaggio a settimana; se non potesse, le funzioni hanno bisogno di un luogo condiviso e di un responsabile condiviso.

Quali competenze richiede la collaborazione cross-funzionale?

Soprattutto abitudini di scrittura più che talenti: formulare un passaggio di consegne con che cosa, chi e entro quando; fare una domanda con la scadenza e il motivo allegati; scrivere una decisione in una frase con il suo responsabile; leggere lo stato di un'altra funzione prima di chiedere una riunione. Dal responsabile, altre due: l'autorità di chiedere una data a qualsiasi funzione e la disciplina di rifiutare una riunione che non prende alcuna decisione. Da tutti, la disponibilità a concordare le dieci parole che il progetto usa e a usarle.

Come si misura la collaborazione cross-funzionale?

Dal risultato consegnato e dal calendario. Il risultato è stato consegnato entro la data indicata nell'accordo, con la riga "finito" di ogni funzione vera? Quante riunioni ha richiesto il progetto, e quante di esse hanno preso una decisione scritta nel canale? Quanti passaggi di consegne sono stati annunciati nel canale prima che la funzione ricevente lo chiedesse? Un progetto che consegna in tempo con poche riunioni, ciascuna con una decisione nella traccia, sta collaborando bene; un progetto con un sync settimanale per ogni coppia di funzioni e decisioni che nessuno riesce a ritrovare sta coordinando in modo costoso.

Fonti: Microsoft Learn — Shared channels in Microsoft Teams; Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Translate a message in Microsoft Teams; Google Chat — Use Automatic Translation in Chat; Google Meet — "Take notes for me" in Google Meet; Slack — Pricing; Slack — Export your workspace data; Slack — Guide to AI features in Slack; Slack — Meeting agenda template (canvas); WhatsApp — How to export your chat history; WhatsApp blog — Introducing message translations. La pagina di Microsoft Learn sui canali condivisi è stata verificata a novembre 2026; la pagina sulle note di riunione di Teams, la pagina del modello di canvas di Slack e la pagina di Google "Take notes for me" a ottobre 2026; la pagina sulla traduzione dei messaggi di Teams, le pagine di Slack su prezzi, esportazione e funzionalità AI, la pagina sulla traduzione di Google Chat e le pagine di WhatsApp ad agosto 2026. I fornitori modificano nel tempo piani, funzionalità ed elenchi di lingue; consulta le loro pagine per lo stato attuale. I team degli esempi sono illustrativi.