Come costruire una knowledge base in 30 giorni: struttura, fonti, responsabilità — e la base che nasce da ciò che il team già dice (2026)

Una knowledge base è l'insieme delle risposte che un'organizzazione dà più di una volta, scritte una sola volta e conservate dove chi ne ha bisogno può trovarle senza chiedere. «Come fatturiamo a un distributore in Svizzera?», «cosa diciamo al genitore il cui figlio ha perso la scadenza?», «quale corriere per i bancali verso il Marocco?»: alla quarta volta che una di queste domande viene posta, l'organizzazione ha una knowledge base, che l'abbia costruita o no. Semplicemente vive nella testa di un collega e in una dozzina di thread di chat.

La maggior parte delle guide su come costruirne una parte dalla scelta del software. Questa parte prima, perché il software è la parte meno importante: una knowledge base è fatta di tre decisioni — una struttura, un insieme di fonti e un nome su ogni voce — e di un mese per prenderle in ordine. Il piano di 30 giorni qui sotto porta un'organizzazione da 10 a 200 persone a una base che le persone aprono davvero, con un modello di voce da copiare, un esempio svolto, una tabella che mostra dove vive la base negli strumenti che il tuo team usa già, e poi la parte che la maggior parte delle guide salta: la base è in gran parte già scritta, in ciò che il team dice nelle riunioni e scrive nelle chat, e il lavoro consiste nel tenerlo in un unico posto, leggibile da tutto il team.

Che cos'è una knowledge base — e che cosa non è

Quattro cose vengono chiamate knowledge base, e la confusione tra loro è il motivo per cui se ne costruiscono tante e se ne usano così poche:

La knowledge base è la prima riga, e dipende dalle altre tre. Il wiki è ciò che diventa senza struttura; la libreria di documenti è dove stanno i suoi file; la cronologia delle chat è dove la maggior parte delle sue voci viene scritta per la prima volta, per caso, come risposte. Il mestiere sta nello spostare una risposta dalla quarta riga alla prima — una volta sola, con un nome sopra — e il metodo qui sotto è costruito attorno a questo passaggio.

Prima di costruire contano altre due distinzioni. Una knowledge base interna è per il team: come facciamo le cose, dove stanno le cose, cosa abbiamo deciso. Una esterna è per i clienti: come funziona il prodotto, cosa fare quando qualcosa non va. Questa guida riguarda quella interna; una base esterna si scrive più avanti a partire da quella interna, riscrivendo le voci che i clienti possono vedere. E una knowledge base non è un documento di processo né una SOP: questi descrivono un intero lavoro dall'inizio alla fine; una voce risponde a una sola domanda e rimanda alla procedura quando la risposta è «seguila».

Le tre decisioni: struttura, fonti, responsabilità

Struttura: per domanda, non per reparto. Chi chiede «come fatturiamo alla Svizzera?» non sa se la risposta appartenga all'amministrazione, alle vendite o alla logistica; conosce la domanda. Una base organizzata per reparto lo manda in tre sezioni per trovare una sola risposta. Organizza per le domande che le persone fanno — con le loro parole — e tieni il primo livello a sette sezioni al massimo. Oltre le sette, la struttura stessa ha bisogno di una ricerca, e una ricerca su una base che nessuno ha ancora riempito non restituisce nulla. Primi livelli tipici per una piccola organizzazione: clienti e ordini; denaro e fatturazione; persone e assunzioni; strumenti e accessi; regole e decisioni; chi chiamare.

Fonti: ciò che esiste già, prima di qualsiasi cosa nuova. Nessuno ha il tempo di scrivere una knowledge base partendo da una pagina bianca, e nessuno ne ha bisogno. Le risposte esistono — nella risposta che un collega ha dato martedì scorso, nel riepilogo della riunione in cui è stata fissata la regola, nel listino che qualcuno ha allegato a un messaggio a marzo, negli appunti di onboarding che l'ultimo neoassunto ha tenuto. La prima versione della maggior parte delle voci è copiata, non scritta. Dove vivono le fonti, e quanto di ciascuna resta raggiungibile in seguito, è il tema della tabella più avanti; in breve, nella maggior parte delle suite la chat, i file e gli appunti delle riunioni sono tre luoghi separati, e la riunione stessa è quella che lascia meno dietro di sé.

Responsabilità: un nome e una data su ogni voce. L'unica cosa che separa una knowledge base di cui ci si fida da una che si è smesso di aprire è se una voce dice chi ne è responsabile e quando è stata controllata l'ultima volta. A una voce con un nome e «rivista il 14 ottobre 2026» si crede; lo stesso testo senza questi elementi è «probabilmente obsoleto». Il compito del responsabile è piccolo: una volta a trimestre, rispondere a «è ancora giusto?» e cambiare la data. Non è riscrivere la base. Se per una voce non si riesce a indicare nessuno, la voce non è conoscenza; è un'ipotesi, e va tolta.

Come costruire una knowledge base in 30 giorni

Il piano presuppone una persona che lo guida — il responsabile del team, o chi riceve più domande — che dedica circa due ore a settimana, mentre il resto del team dedica pochi minuti.

Settimana 1 — raccogli le domande, non le risposte. Apri un canale, o una nota in uno esistente, e per sette giorni fai in modo che tutti vi inseriscano ogni domanda che hanno fatto a un collega o che hanno ricevuto, con le parole usate. Ancora nessuna risposta. Entro venerdì ci sono da quaranta a ottanta domande; un terzo sono doppioni. Conta le ripetizioni: la domanda posta cinque volte è la voce numero uno. Il posto in cui vive l'elenco è anche il posto in cui vivrà la base; la scelta del luogo si fa qui in base a ciò che il team già apre ogni giorno, non con un confronto tra software.

Settimana 2 — la struttura e i responsabili. Raggruppa le domande; i gruppi sono le sezioni, e non sono più di sette. Nomina un responsabile per sezione — la persona che ha risposto a più domande nella settimana 1. Poi nomina un responsabile per voce per le venti domande più frequenti. Per ora non scrivere nulla se non l'elenco: sezione, domanda, responsabile. Invialo al team e chiedi una cosa sola: «quali domande mancano?». L'elenco torna con dieci domande in più.

Settimana 3 — le prime venti voci, dalle fonti. Ogni responsabile scrive le proprie voci usando il modello qui sotto, partendo da ciò che esiste già: la risposta in chat, il riepilogo, il file. La regola della settimana 3 è «breve e vero batte lungo e completo»: una risposta di due frasi con un link al file, datata e firmata, è una voce. Una pagina che spiega la storia della regola è un documento, e può venire dopo. Le voci che dipendono da una decisione che nessuno riesce a ritrovare vanno prima nel registro delle decisioni, poi nella base con un link.

Settimana 4 — pubblica, poi avvia il ciclo. Fissa la base dove il team legge. Poi stabilisci le due abitudini che la tengono in vita: ogni domanda posta d'ora in poi nel canale delle domande ottiene una voce o un link a una voce, scritta da chi ha risposto; e il responsabile di ogni voce mette la data di revisione nel proprio calendario. Il giorno 30 non è una base finita. Sono da venti a trenta voci, ciascuna con un responsabile e una data, e un ciclo che ne aggiunge una ogni volta che si risponde a una domanda. Sei mesi dopo sono duecento, e nessuno le ha scritte come un progetto.

Ciò che non succede nei 30 giorni: migrare la libreria di documenti, scegliere un nuovo strumento, scrivere una pagina per ogni processo. La base rimanda ai file dove stanno e alle procedure dove vivono. Spostarli è un altro progetto, e spesso inutile.

Un modello di voce per la knowledge base

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

[Domanda, con le parole che le persone 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 la sua data, e il perché]
Eccezioni: [i casi fuori dal percorso normale, e chi decide ciascuno]
Dove sono i file: [link al modello, al listino, al contratto aggiornati]
Voci correlate: [la SOP, il processo, la versione precedente]

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 svolto: la base di un'azienda esportatrice dopo 30 giorni

Un'azienda italiana esportatrice di macchinari, 38 persone, un ufficio commerciale a Milano e distributori in Spagna, Romania e Marocco. La settimana 1 ha prodotto 61 domande; tolti i doppioni, 44. La struttura che ne è uscita, con il numero di voci per sezione al giorno 30:

1. Distributori e ordini (7) — come si attiva un nuovo distributore; chi approva un fido; cosa serve a un ordine prima di andare in produzione
2. Fatturazione e pagamenti (5) — fatturare a un distributore in Svizzera; quando si usa una pro forma; cosa fare quando un pagamento è in ritardo di 30 giorni
3. Spedizioni e dogana (6) — corrieri per destinazione; i documenti che servono a un bancale per il Marocco; chi firma la dichiarazione di esportazione
4. Assistenza e garanzia (4) — cosa copre la garanzia; come si prenota un intervento di assistenza; quali ricambi sono tenuti a magazzino
5. Strumenti e accessi (3) — chi dà l'accesso al CRM; dove sta il listino; come raggiungere la casella condivisa
6. Regole e decisioni (3) — la regola delle due firme sopra i 10.000; il tetto agli sconti; il registro delle decisioni
7. Chi chiamare (2) — lo spedizioniere doganale; i contatti dei corrieri per paese

Trenta voci. La domanda più frequente della settimana 1 — «quali documenti servono a un bancale per il Marocco?» — aveva ricevuto risposta nel canale undici volte in un anno dalla stessa responsabile della logistica; la voce le è costata venti minuti, perché l'undicesima risposta era già scritta e mancavano solo la riga del responsabile e la data.

Una voce compilata della sezione 3:

Quali documenti servono a un bancale per il Marocco?
Responsabile: Responsabile logistica · Sezione: Spedizioni e dogana · Ultima revisione: 3 novembre 2026 · Prossima revisione: 3 febbraio 2027
Risposta breve: Fattura commerciale in tre copie, packing list, certificato EUR.1 e il numero di licenza di importazione del distributore sulla fattura.
Si applica a: tutte le spedizioni ai distributori marocchini · Non si applica a: ricambi sotto i 1.000 EUR spediti con corriere, che viaggiano con il modulo del corriere stesso.
Come: 1. Esporta la fattura dal sistema con il modello Marocco. 2. Aggiungi il numero di licenza dalla scheda del distributore. 3. Richiedi l'EUR.1 alla camera di commercio, tre giorni lavorativi. 4. Allega la packing list. 5. Invia il set allo spedizioniere doganale e metti in copia il distributore.
La regola alla base: Il numero di licenza è stato aggiunto dopo il blocco di marzo 2026 a Casablanca (voce del registro delle decisioni 2026-03-19).
Eccezioni: Le macchine dimostrative viaggiano in ammissione temporanea; decide la responsabile logistica.
Dove sono i file: Modello di fattura Marocco; modulo di richiesta EUR.1; schede dei distributori.
Voci correlate: Corrieri per destinazione; chi firma la dichiarazione di esportazione.

Dove vive la knowledge base negli strumenti che usi già

Un'organizzazione da 10 a 200 persone costruisce la propria base nella suite che già paga, e ogni suite ha un posto per la voce, un posto per i file e un percorso per ciò che una riunione lascia dietro di sé. Ciascuna si ferma in un punto diverso, e in ciascuna il record è nella lingua in cui è stato scritto. Solo comportamenti documentati, dalle pagine dei fornitori stessi, con il mese in cui ogni pagina è stata verificata:

Tre cose sono uguali in tutte e quattro. La voce è un documento o un messaggio nell'unica lingua in cui è stato scritto, e un membro che legge un'altra lingua legge quello o una copia fatta da qualcuno. I file stanno in un secondo posto, trovato da una seconda ricerca. E la riunione — dove la regola è stata discussa e fissata — arriva alla base solo quando una persona la riscrive dopo: dove Teams e Meet conservano una trascrizione e un riepilogo, se lo fanno, e come tenerli dopo la chiamata, è in dove Microsoft Teams e Google Meet archiviano trascrizione, registrazione e riepilogo; i notetaker AI che molti team aggiungono per lo stesso motivo sono confrontati in alternative a Otter.ai, e ciascuno scrive il proprio riepilogo in una sola lingua.

La traduzione documentata da queste suite appartiene alla chiamata o allo schermo del lettore, non al record: Microsoft documenta i sottotitoli tradotti dal vivo 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 ciascuna e dove si ferma è in traduzione dal vivo in Microsoft Teams, traduzione dal vivo in Google Meet e traduzione su WhatsApp. La voce che l'impiegato del distributore a Casablanca apre il lunedì è un oggetto distinto da quei sottotitoli, e si legge nella lingua in cui è stata scritta.

La base che nasce da ciò che il team già dice

InterMIND è uno spazio di comunicazione in cui il lavoro di un team vive in un canale, quindi la knowledge base ha una casa naturale: il canale del team che la usa — il team export, la reception della clinica, il gruppo clienti dell'agenzia — e quel canale è anche il canale delle domande e il luogo da cui partono le riunioni. Le tre decisioni di cui sopra vi si mappano direttamente.

Struttura e responsabilità sono le voci stesse. Pubblicata come nota — un messaggio in rich text con titoli ed elenchi numerati, modificabile in seguito dal proprio menu — una voce viene letta da ogni membro nella propria lingua con l'originale a un tocco di distanza, e fissata in alto, così la versione corrente è 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 il suo orario, che è la traccia di revisione a cui rimanda la riga «ultima revisione» del responsabile. I file a cui una voce rimanda — il listino, il modello per il Marocco, il contratto con il distributore — vengono caricati nello stesso canale e portano, in 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 documentale, i suoi aggiornamenti arrivano nel canale via email: l'host del canale gli assegna un indirizzo dedicato, e un messaggio inviato lì compare come un normale messaggio con il mittente indicato e gli allegati conservati. Un team che arriva da Slack porta con sé i propri canali: un'esportazione standard di un workspace Slack viene ripristinata come un canale per ogni canale Slack, con i messaggi in ordine e i loro orari originali, con pin e reazioni conservati, e ogni messaggio letto da ogni membro nella propria lingua.

Le fonti sono dove il canale svolge il lavoro che la tabella qui sopra lascia a una persona. La riunione in cui si fissa la regola parte dal canale; durante la chiamata la bozza della voce compare sullo schermo di tutti accanto ai riquadri video con Share to conference — una nota, o 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 — un sommario, i punti segnati come concordati, aperti o contestati, gli action items con i responsabili, ogni riga con il proprio orario — e i documenti condivisi durante la sessione contribuiscono con i loro riepiloghi accanto a ciò che è stato detto. Arriva via email, come messaggio nel canale e come link nell'evento del calendario, e ogni membro autenticato lo legge nella propria lingua: il record è tradotto per ciascun lettore, non scritto una volta sola nella lingua che la stanza ha usato. 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 fissato la regola per il Marocco è a un clic dalla voce che la enuncia. Questa è la base che nasce da ciò che il team già dice: l'undicesima risposta nel canale, il riepilogo della chiamata in cui la regola è stata discussa, il file allegato a marzo, tutto in un unico posto, con la voce sopra di essi.

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, «quali documenti servono a un bancale per il Marocco?», e restituisce i passaggi con la riunione, la data e il file da cui ciascuno proviene; questo funziona per le organizzazioni con le funzioni AI attive, e la lettura tramite l'assistente è limitata alle riunioni e ai canali di cui il membro fa parte. La chat stessa ha una ricerca, e la base può essere portata fuori per intero: in ogni piano un backup dalle Impostazioni esporta i canali come ZIP con i loro messaggi, trascrizioni e file, il che risponde alla questione della responsabilità a livello dell'organizzazione anziché della singola voce. Posto accanto alla tabella qui sopra, il confronto è una semplice constatazione di fatto: i sottotitoli che quelle suite documentano traducono la chiamata mentre si svolge; qui la voce, le riunioni che l'hanno prodotta, i suoi file e la sua cronologia sono un unico record, letto da ogni membro nella propria lingua.

Chi custodisce la conoscenza di un team non è sempre un dipendente. L'impiegato ordini del distributore, lo spedizioniere doganale, il commercialista freelance che conosce la regola svizzera: un membro esterno del canale entra via email con un account gratuito e legge le voci e la loro cronologia come tutti gli altri; una persona senza account è ospite di una sola riunione — entra nella chiamata tramite link, da un telefono, senza costi, la ascolta dal vivo nella propria lingua, e dopo non ottiene alcun record. L'host mette a disposizione lo spazio e, in un piano a pagamento, paga solo i membri attivi nei 28 giorni precedenti — che hanno partecipato a una riunione, scritto in una chat o interrogato l'assistente; i membri che restano inattivi mantengono l'accesso senza costi, ed è ciò di cui ha bisogno una knowledge base: la persona che ha scritto la voce due anni fa può ancora essere nel canale.

• Apri un riepilogo completo — un vero record generato dallo stesso codice che scrive i tuoi.
• Prova la demo live — senza registrazione; parla, e ascolta la stanza tradotta per ciascun ascoltatore.

Costruire una knowledge base 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 voce e rispondere nel canale anziché in un messaggio diretto. Ciò che non deve sopravvivere è il secondo lavoro — riscrivere nella base ciò che la riunione ha deciso e tenere a mano una copia tradotta di ogni voce, una lingua alla volta, per l'ufficio che legge l'altra.

FAQ

Che cos'è una knowledge base?

Una knowledge base è una raccolta di risposte alle domande che a un'organizzazione vengono poste più di una volta, scritte una sola volta, ciascuna con un responsabile e una data, e conservate dove chi ha bisogno della risposta può trovarla senza chiedere a un collega. Una knowledge base interna risponde alle domande del team stesso — come fatturiamo, dove sono i file, cosa abbiamo deciso; una esterna risponde alle domande dei clienti su un prodotto. Si distingue da un wiki perché ha una struttura e dei responsabili, e da una libreria di documenti perché contiene risposte anziché file.

Come si crea una knowledge base?

Raccogli per una settimana le domande che il team pone davvero, con le parole usate; raggruppale in non più di sette sezioni; nomina un responsabile per ogni sezione e per ciascuna delle venti domande più frequenti; fai scrivere ai responsabili quelle voci a partire da ciò che esiste già — risposte in chat, riepiloghi delle riunioni, file — usando un modello di una pagina con una risposta breve, i passaggi, le eccezioni e una data di revisione; pubblica nel luogo che il team già legge; poi mantieni attivo il ciclo, in cui ogni domanda risolta diventa una voce e il responsabile di ogni voce la rivede alla sua data.

Che cosa dovrebbe includere una knowledge base?

Una voce 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 le decide, i link ai file aggiornati e i link alle voci correlate. La base nel suo insieme ha bisogno di una struttura di sette sezioni al massimo, organizzata per le domande poste anziché per reparto.

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

Un wiki è un insieme di pagine che chiunque può scrivere con 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 può diventare una knowledge base aggiungendo la struttura e i responsabili; senza di essi, un wiki cresce fino a centinaia di pagine in cui nessuno riesce a orientarsi e che nessuno ha controllato. Il software è spesso lo stesso; la differenza sono le due decisioni.

Come si struttura una knowledge base?

Per domanda, non per reparto: chi chiede non sa a quale reparto appartenga la risposta, ma sa cosa sta chiedendo. Raggruppa le domande raccolte nella prima settimana in non più di sette sezioni di primo livello — per una piccola organizzazione, tipicamente clienti e ordini, denaro e fatturazione, persone e assunzioni, strumenti e accessi, regole e decisioni, e chi chiamare — e mantieni ogni voce su una sola domanda. Se una sezione supera circa trenta voci, dividila per le domande che le persone fanno anziché per chi risponde.

Quanto tempo ci vuole per costruire una knowledge base?

Trenta giorni per arrivare a una base che le persone aprono: una settimana per raccogliere le domande, una per struttura e responsabili, una per scrivere le prime venti voci dalle fonti esistenti, una per pubblicare e impostare il ciclo di revisione. Chi guida il progetto dedica circa due ore a settimana; ogni responsabile dedica venti minuti per voce, perché la maggior parte delle voci è copiata da una risposta già data anziché scritta da zero. La base non è finita al giorno 30; cresce di una voce ogni volta che si risponde a una domanda.

Si può costruire una knowledge base gratis?

Sì — il modello di questa guida è testo semplice, e la base può vivere in una nota, in un documento o in un canale negli strumenti che un team già usa: un canvas in Slack, un Google Doc, la scheda File di un canale Teams, una nota fissata in una chat. Ciò che non costa nulla in software costa comunque il tempo di revisione dei responsabili, e i limiti sono quelli della suite: il piano Free di Slack conserva 90 giorni di cronologia dei messaggi, e in ogni suite la voce è nella lingua in cui è stata scritta. In InterMIND il piano Basic è gratuito, e i prezzi dei piani a pagamento sono sulla pagina dei prezzi.

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 Microsoft Learn su Teams e SharePoint è stata verificata a novembre 2026; le pagine su retention di Teams e appunti delle riunioni, 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, retention ed esportazione, le pagine Google Chat sulla traduzione e Meet sui sottotitoli e le pagine di WhatsApp ad agosto 2026. I fornitori cambiano nel tempo piani, funzioni ed elenchi delle lingue; consulta le loro pagine per lo stato attuale.