Deskhero
Italiano
Inizia gratis

← Back to articles

Knowledge base interna per i team: creane una che tutti usino

Knowledge base interna per i team: creane una che tutti usino

Una knowledge base interna è il luogo centralizzato e consultabile in cui il tuo team conserva procedure, runbook, policy, passaggi di onboarding e decisioni passate, così nessuno deve fare la stessa domanda due volte. Se lo sai già e vuoi passare all’azione, ecco da dove iniziare questa settimana.

  • Analizza le conversazioni dell’ultimo mese su Slack e via email per individuare le 20 domande più frequenti.
  • Assegna un responsabile nominativo a ogni categoria di primo livello prima di scrivere anche un solo articolo.
  • Lancia un progetto pilota di 20 articoli che copra solo queste domande principali, poi amplia il progetto.

Fai queste tre cose e vedrai rapidamente i risultati: meno interruzioni che distolgono le persone dal lavoro concentrato e nuovi assunti che smettono di bussare alla spalla del collega ogni ora. Il resto di questa guida spiega perché funziona e come costruire correttamente una knowledge base.

Punti chiave

Una knowledge base interna utile parte da un responsabile nominativo per ogni categoria, da un progetto pilota di 20 articoli basato su domande reali e da un ciclo di revisione di 90 giorni che mantiene affidabili i contenuti.

Punto Dettagli
Inizia dalle domande reali Analizza gli ultimi 30-60 giorni di conversazioni su Slack e via email per individuare le 20 domande più frequenti prima di scrivere qualsiasi cosa.
Nomina un responsabile per ogni categoria Assegna una persona specifica, non un team, come responsabile effettivo di ogni categoria di primo livello.
Mantieni ridotta la tassonomia Usa un piccolo insieme di categorie di primo livello basate sulle funzioni, invece di rispecchiare l’organigramma.
Imposta una cadenza di revisione Inserisci in ogni articolo un ciclo di revisione di 90 giorni con la dicitura “ultima revisione”; prevedi una revisione immediata in caso di modifiche alle policy.
Affianca la KB all’AI in modo sicuro Il chatbot e le risposte automatiche basate sull’AI di Deskhero rispondono solo utilizzando elementi approvati delle FAQ pubbliche. Queste funzionalità sono opzionali e le azioni automatiche sono contrassegnate e registrate.

Indice

Perché una knowledge base interna è più importante di quanto si riconosca

Il motivo per creare una knowledge base aziendale non è astratto. Un sondaggio di Gartner ha rilevato che una parte significativa dei lavoratori digitali ha difficoltà a trovare le informazioni necessarie per svolgere il proprio lavoro. Si tratta di quasi metà della tua forza lavoro, che proprio in questo momento perde silenziosamente tempo cercando una risposta già esistente da qualche parte in una vecchia conversazione su Slack o nella casella di posta di qualcuno.

In cifre: una parte consistente dei lavoratori digitali non riesce a trovare in modo affidabile le informazioni di cui ha bisogno per svolgere il proprio lavoro. Ogni domanda senza risposta del tipo “dov’è il documento per X?” è quella statistica che si manifesta in tempo reale nel tuo team.

Un sistema funzionante di documentazione interna affronta direttamente questo problema. Riduce il tempo necessario per ottenere una risposta, perché le persone cercano invece di chiedere. Riduce i cambi di contesto, perché un esperto in materia non viene distolto dal proprio lavoro per ripetere qualcosa che ha già spiegato cinque volte. Accelera l’onboarding, perché un nuovo assunto può trovare la checklist di deployment senza aspettare uno spazio nel calendario di un ingegnere senior.

I vantaggi si manifestano in alcuni ambiti prevedibili:

  • Tempi di inserimento più rapidi per i nuovi assunti, poiché le domande della prima settimana hanno risposte scritte invece di dipendere da conoscenze tacite custodite nella testa di qualcuno.
  • Meno ticket ripetitivi o messaggi su Slack, perché la risposta si trova in un luogo consultabile invece che in una conversazione chiusa.
  • Meno cambi di contesto per il personale senior, che smette di funzionare come un motore di ricerca umano.
  • Risposte più uniformi, perché tutti attingono dalla stessa fonte invece di ricevere cinque spiegazioni verbali leggermente diverse.

Fai un calcolo approssimativo per il tuo team: se cinque persone dedicano ciascuna 20 minuti al giorno a rispondere a domande che una knowledge base per team potrebbe gestire, recuperi oltre otto ore settimanali di tempo del personale senior. Moltiplica il dato per un trimestre e il vantaggio diventa evidente, senza dover assumere nessuno.

Cosa inserire per prima cosa nella knowledge base

Non tutti gli strumenti di documentazione interna devono contenere tutto fin dal primo giorno. Cercare di acquisire l’intera azienda in una volta sola è il modo in cui la maggior parte dei progetti di knowledge base si blocca prima del lancio. Inizia dai tipi di contenuto che impediscono concretamente alle persone di interrompersi a vicenda.

Assegna la priorità in questo ordine:

  1. Runbook e guide alla risoluzione dei problemi per le emergenze ricorrenti (una procedura per riavviare un server, un flusso di rimborso, la correzione di un bug comune).
  2. Checklist di onboarding per la prima settimana e il primo mese.
  3. Policy sulle quali vengono poste continuamente domande (ferie e permessi, approvazione delle spese, regole sul lavoro da remoto).
  4. Articoli pratici per attività ripetibili (come richiedere l’accesso, come inviare un ordine di acquisto).
  5. Registri delle decisioni che spiegano perché è stata scelta una determinata soluzione, così nessuno dovrà ridiscuterla sei mesi dopo.
  6. Glossari per il gergo interno e gli acronimi che confondono i nuovi assunti.
  7. FAQ create direttamente a partire dalle domande più frequenti del supporto e dei team interni.
  8. Modelli per i documenti che il tuo team scrive ripetutamente.

Ecco alcuni esempi di struttura delle pagine da cui prendere spunto:

  • Modello di SOP o runbook: condizione di attivazione, azioni dettagliate passo dopo passo, persona a cui rivolgersi per l’escalation, tempo previsto per la risoluzione.
  • Checklist di onboarding della prima settimana: account da configurare, persone da incontrare, primo risultato da consegnare, persona a cui chiedere aiuto in caso di difficoltà.
  • Pagina rapida di una policy: un riepilogo di un paragrafo in alto, seguito dai dettagli completi e poi da una sezione sulle eccezioni.

Ogni articolo, indipendentemente dal tipo, deve avere gli stessi metadati nella parte superiore: un responsabile, una data dell’ultima revisione, un tag di stato (attuale, da rivedere, archiviato) e alcuni alias, affinché la ricerca intercetti il modo in cui le persone formulano realmente la domanda, non solo il termine ufficiale.

Come creare e strutturare una knowledge base interna

La costruzione di un database di conoscenze per i dipendenti che superi il terzo mese dipende dalla sequenza delle attività. Salta l’analisi e passa direttamente alla scrittura: riempirai la knowledge base di articoli che nessuno cerca. Ecco un piano in fasi che puoi seguire in circa quattro settimane.

Cronologia in quattro fasi per la costruzione di una knowledge base interna

Fase 1: Analisi (giorni da 1 a 5)

Raccogli le domande reali che le persone pongono. Cerca nelle conversazioni degli ultimi 30-60 giorni su Slack, nelle email e nei ticket di supporto i temi ricorrenti. Il punto di partenza più affidabile è rappresentato dalle 20 domande che i dipendenti pongono davvero, non da un elenco ipotetico di tutto ciò che il tuo reparto potrebbe documentare in teoria.

  • Chi: la persona responsabile del progetto, che raccoglie i dati da tre o quattro responsabili di reparto.
  • Cosa: un elenco ordinato delle 20-30 domande più frequenti.
  • Risultato: un foglio di calcolo con domanda, stima della frequenza e responsabile proposto.
  • Criteri di accettazione: ogni domanda presente nell’elenco deve essere comparsa almeno due volte nella finestra temporale dell’analisi.

Fase 2: Tassonomia e responsabilità (giorni da 6 a 10)

Resisti alla tentazione di costruire un elaborato albero di categorie. Una tassonomia funzionale utilizza un numero ridotto di categorie di primo livello organizzate per funzione. Pensa a “Per iniziare”, “IT e accessi”, “Risorse umane e policy” e “Procedure di assistenza clienti”, invece di rispecchiare l’organigramma. Assegna un responsabile nominativo a ogni categoria di primo livello. Non un team. Una persona. Una responsabilità senza un nome associato è il modo più rapido per far deteriorare gli articoli.

  • Chi: i responsabili delle categorie, confermati per iscritto.
  • Cosa: una tassonomia concisa di categorie di primo livello basate sulle funzioni.
  • Risultato: una mappa della tassonomia con il nome del responsabile accanto a ogni ramo.
  • Criteri di accettazione: ogni categoria deve avere esattamente un responsabile effettivo che abbia accettato il ruolo.

Fase 3: Costruzione del progetto pilota (giorni da 11 a 20)

Scrivi il progetto pilota di 20 articoli direttamente a partire dall’elenco delle domande analizzate. Usa i modelli della sezione precedente, così ogni articolo avrà la stessa struttura. Non trasferire qui il vecchio wiki in blocco. Porta selettivamente i contenuti che sono stati effettivamente utilizzati o consultati di recente, riscrivi ciò che appare obsoleto o incompleto e archivia il resto invece di trascinarlo avanti per abitudine.

  • Chi: i responsabili delle categorie, ciascuno impegnato a scrivere o assegnare i propri articoli.
  • Cosa: 20 articoli completati che corrispondano alle domande principali del progetto pilota.
  • Risultato: una sezione pilota pubblicata e revisionata da almeno una persona esterna al team dell’autore.
  • Criteri di accettazione: un lettore di prova deve riuscire a trovare e comprendere ogni articolo in meno di due minuti, senza dover porre una domanda successiva.

Fase 4: Integrazione della ricerca e lancio graduale (giorni da 21 a 28)

Collega la knowledge base ai luoghi in cui il tuo team trascorre già la giornata, che si tratti di Slack, Microsoft Teams o del tuo strumento di gestione dei ticket. Una KB che richiede l’apertura di una scheda separata è una KB di cui le persone dimenticano l’esistenza. Effettua dapprima un lancio graduale in un solo reparto, raccogli i feedback, correggi le lacune più evidenti e poi rendila disponibile a tutta l’azienda.

  • Chi: il responsabile del progetto e uno o due volontari del reparto pilota.
  • Cosa: integrazione della ricerca e un breve annuncio interno.
  • Risultato: dati di utilizzo delle prime due settimane e un elenco degli elementi di feedback.
  • Criteri di accettazione: almeno metà del gruppo pilota deve aver utilizzato la KB spontaneamente nei primi dieci giorni.

Consiglio pratico: Lancia un progetto più ristretto di quanto ti sembri comodo. Un progetto pilota ben delimitato di 20 articoli che viene realmente utilizzato genera molta più fiducia interna di una raccolta dispersiva di 200 articoli che viene ignorata.

Verifica la reperibilità prima di considerare il lavoro concluso. Consegna cinque domande reali a una persona che non ha partecipato alla scrittura dei contenuti e misura quanto tempo impiega a trovare la risposta. Se impiega più di un minuto, è la tua tassonomia o il sistema di tagging ad aver bisogno di lavoro, non di altri articoli.

Come scegliere lo strumento giusto per la knowledge base senza complicare troppo le cose

Come scegliere lo strumento giusto per la knowledge base senza complicare troppo le cose, diagramma panoramico

La scelta dello strumento paralizza molti team. La soluzione è una checklist breve e una visione chiara di ciò che è indispensabile rispetto a ciò che è semplicemente utile per le dimensioni della tua organizzazione.

Valuta ogni piattaforma candidata di gestione della conoscenza attraverso questa checklist:

  • Qualità della ricerca, inclusa la tolleranza agli errori di battitura e la corrispondenza dei sinonimi, non solo i risultati con parole chiave esatte.
  • SSO e autorizzazioni granulari, affinché le pagine riservate a Risorse umane o Finanza non siano visibili a tutti.
  • Integrazione con Slack o Microsoft Teams, così le risposte compaiono nei luoghi in cui le persone conversano già.
  • Un’API o un’esportazione pulita, soprattutto se prevedi di collegare in seguito assistenti AI.
  • Analisi, che mostrino quali articoli vengono visualizzati, quali ricerche non restituiscono risultati e dove le persone rinunciano.
  • Un’esperienza di modifica piacevole, perché uno strumento di scrittura macchinoso garantisce un numero inferiore di contributi.
  • Funzionalità per la gestione dei responsabili dei contenuti, come revisori assegnabili e date dell’ultimo aggiornamento visibili.

Valuta ogni candidato in base alle dimensioni della tua organizzazione, non rispetto a un elenco generico di funzionalità:

  1. Piccoli team (meno di 30 persone): ricerca, autorizzazioni ed esperienza di modifica sono indispensabili. Analisi avanzate e accesso all’API sono utili, ma non essenziali.
  2. Team di medie dimensioni: aggiungi l’integrazione con Slack o Teams e le analisi di base all’elenco delle funzionalità indispensabili.
  3. Team enterprise: l’accesso all’API, l’SSO e le autorizzazioni granulari passano da utili ma non essenziali a indispensabili, perché conformità e scalabilità li rendono necessari.

Quando confronti i prodotti, verifica la qualità della ricerca e i controlli di amministrazione con i tuoi contenuti e il tuo modello di autorizzazioni, invece di basarti sulla lunghezza dell’elenco di funzionalità riportato nella pagina commerciale. Se prevedi di aggiungere l’AI in futuro, privilegia gli strumenti che espongono markdown o un’API pulita, poiché i contenuti strutturati sono più facili da utilizzare in modo coerente per i sistemi di recupero rispetto a un insieme di formattazioni incoerenti.

Come rendere davvero reperibili le risposte

Una knowledge base che nessuno riesce a trovare è solo uno schedario con un branding migliore. La reperibilità è il punto in cui la maggior parte degli strumenti di documentazione interna fallisce silenziosamente, ma il problema si può risolvere con alcune abitudini concrete.

Inserisci i tag in base al modo in cui le persone cercano davvero, non al modo in cui scriveresti un titolo formale. Se l’articolo sulla policy di fatturazione si intitola “Procedure per i crediti commerciali”, ma tutti cercano “come posso ottenere un rimborso?”, aggiungi quella frase come alias. Inserisci anche gli errori di ortografia e le abbreviazioni comuni. Poi porta i contenuti fuori dalla barra di ricerca della KB e dentro gli strumenti che le persone usano ogni giorno, che si tratti di un bot Slack che risponde direttamente dagli articoli della KB o di un widget all’interno del sistema di gestione dei ticket.

Mantieni la tassonomia di primo livello organizzata per funzione, usa lo stesso tipo di articolo in modo coerente all’interno di ogni categoria ed elimina le pagine duplicate non appena le individui; due versioni della stessa policy che forniscono risposte leggermente diverse sono peggio dell’assenza totale di una pagina.

Tre metriche indicano se la ricerca funziona davvero:

  • Tasso di risultati nulli: la frequenza con cui una ricerca non restituisce nulla, segnalando contenuti mancanti o tag errati.
  • Tasso di clic dalla ricerca all’articolo: indica se le persone fanno clic su un risultato o rinunciano e chiedono invece a qualcuno.
  • Tempo alla prima risposta all’interno di Slack o del tuo strumento di chat, per verificare se una risposta automatica o proveniente dalla KB è più rapida di una risposta umana.

Se il tasso di risultati nulli sta aumentando, prima di essere un problema di contenuti è un problema di tassonomia e tagging. In relazione al punto precedente sulla reperibilità: quasi metà dei lavoratori dichiara già di avere difficoltà a trovare le informazioni, quindi un tasso elevato di risultati nulli nella ricerca della tua KB indica che lo stesso fallimento si sta verificando all’interno dello strumento creato per risolverlo.

Come mantenere affidabile la knowledge base nel tempo

Una knowledge base inizia a deteriorarsi nel momento in cui nessuno viene incaricato di supervisionarla. La governance è ciò che distingue una KB utile anche nel secondo anno da una che si trasforma silenziosamente in un cimitero di screenshot obsoleti.

Definisci chiaramente tre ruoli:

  • Una persona direttamente responsabile (DRI) per ogni categoria, lo stesso responsabile nominativo della fase di tassonomia, che risponde dell’accuratezza.
  • Editor, che possono aggiornare i contenuti senza bisogno dell’approvazione del DRI per le correzioni minori.
  • Revisori, che verificano l’accuratezza secondo una programmazione stabilita, invece di aspettare che qualcuno si accorga di un problema.

Alcuni team aggiungono un comitato operativo per la gestione della conoscenza quando la KB supera alcune centinaia di articoli, ma per la maggior parte delle organizzazioni una DRI chiara per categoria offre una struttura sufficiente per iniziare.

Imposta una cadenza di revisione per ogni articolo, non solo una data di lancio. Un ciclo di revisione di 90 giorni funziona bene per la maggior parte dei contenuti operativi: ogni articolo riporta un campo “ultima revisione” e tutto ciò che supera i 90 giorni senza revisione viene segnalato al relativo DRI. I contenuti collegati a una modifica delle policy devono essere sottoposti a una revisione immediata, fuori ciclo, invece di aspettare il proprio turno.

  1. Monitora la percentuale di articoli oltre la data di revisione, che segnala la trascuratezza prima che se ne accorgano i lettori.
  2. Monitora la percentuale di ricerche che restituiscono zero risultati, che segnala le lacune nei contenuti.
  3. Monitora l’adozione, ovvero i visitatori unici e le visualizzazioni per articolo, per capire cosa viene effettivamente utilizzato.
  4. Monitora i miglioramenti del tempo necessario per ottenere una risposta, confrontando quanto tempo serviva per risolvere una domanda prima e dopo l’introduzione della KB.

Consiglio pratico: Inserisci la data dell’“ultima revisione” direttamente nell’articolo, in modo che sia visibile ai lettori, non nascosta in un pannello di amministrazione. Vedere una data genera fiducia; non vederla la erode silenziosamente.

Come usare l’AI senza lasciarla tirare a indovinare

L’AI può velocizzare concretamente il modo in cui un team utilizza la propria knowledge base, ma solo quando è limitata dalle giuste protezioni. Se non viene controllato, un assistente AI sarà ben felice di inventare una risposta dal tono sicuro invece di ammettere di non sapere.

Le applicazioni utili sono specifiche: un chatbot che risponde utilizzando un insieme controllato di articoli approvati, risposte redatte dall’AI che una persona verifica prima dell’invio, articoli correlati mostrati a un User durante un ticket e suggerimenti di FAQ ricavati dai ticket che il team ha già risolto.

Niente di tutto questo funziona in modo sicuro senza protezioni:

  • Risposte limitate alle fonti, affinché l’AI utilizzi solo contenuti approvati invece di attingere da Internet o dai propri dati di addestramento.
  • Revisione umana e controlli espliciti, affinché le bozze vengano verificate prima dell’invio e l’invio automatico venga abilitato intenzionalmente.
  • Registri e tracce di audit, affinché ogni azione automatica possa essere ricostruita e verificata in seguito.
  • Soglie di affidabilità, affinché le risposte con un basso livello di certezza vengano inoltrate a una persona invece di essere tirate a indovinare.

Consiglio pratico: Considera il tasso di accuratezza del tuo assistente AI come qualsiasi altro KPI. Controlla a campione le sue risposte ogni settimana e, se iniziano a comparire risposte errate, prendilo come un segnale per reindicizzare i contenuti di origine, non per continuare ad andare avanti.

L’approccio di Deskhero a una knowledge base viva

Un test utile per qualsiasi hub della conoscenza interna consiste nel verificare se si collega al lavoro svolto nei ticket invece di restare in disparte come un wiki statico. In Deskhero, i ticket risolti possono contribuire a suggerire elementi per le FAQ pubbliche. Un User esamina e approva ogni suggerimento prima che il chatbot rivolto ai clienti o le risposte automatiche basate sull’AI possano utilizzarlo.

La protezione fondamentale è semplice: il chatbot rivolto ai clienti e le risposte automatiche basate sull’AI di Deskhero utilizzano solo le FAQ pubbliche approvate. Se il chatbot non riesce a rispondere con sufficiente sicurezza, torna al modulo di contatto.

Questo ciclo di approvazione è supportato da una serie specifica di controlli che vale la pena verificare in qualsiasi strumento:

  • Approvazione umana obbligatoria prima che un elemento FAQ suggerito venga reso pubblico.
  • Registrazione di ogni azione automatica, con apposita etichetta affinché nulla avvenga in modo silenzioso.
  • Risposte ai clienti limitate alle fonti, ovvero chatbot e risposte automatiche basate sull’AI utilizzano solo le FAQ pubbliche approvate.
  • Controlli di attivazione volontaria per le risposte automatiche basate sull’AI per ciascun gruppo e per il chatbot per ciascun widget.
  • Un chiaro requisito di attivazione, poiché il chatbot richiede almeno 100 elementi FAQ pubblici approvati.

Deskhero abbina questo flusso di lavoro alla sincronizzazione bidirezionale con Gmail, Google Workspace e Microsoft 365, a una REST API completa, al SSO di Google e Microsoft e al supporto per 14 lingue dell’interfaccia. La KB interna e le altre conoscenze dello spazio di lavoro alimentano le bozze di suggerimenti per gli User, mentre le FAQ pubbliche approvate alimentano il chatbot rivolto ai clienti e le risposte automatiche basate sull’AI.

Le insidie di cui nessuno ti avverte

Molti fallimenti delle knowledge base sono fallimenti di responsabilità, non di contenuti. I team possono trascorrere settimane a scrivere articoli curati, per poi lasciare che la raccolta si deteriori quando nessuno rimane responsabile degli aggiornamenti.

Il principale fattore di fallimento è l’assenza di un responsabile nominativo. “Il team” non è responsabile di nulla; le cose sono di competenza di una persona specifica. Il secondo è la migrazione eccessiva: trasferire ogni vecchio documento nel nuovo sistema fin dal primo giorno garantisce che metà dei contenuti sia errata e che i lettori smettano di fidarsi dell’intera KB la prima volta che incontrano una pagina obsoleta. Il terzo è l’eccessiva categorizzazione, ovvero costruire una tassonomia elaborata prima di avere abbastanza contenuti da giustificarla.

Considera la knowledge base come un’infrastruttura da gestire per sempre, non come un progetto da concludere. Inizia con dimensioni inferiori a quelle che ti sembrano comode, misura se le persone la utilizzano davvero entro il primo mese e apporta modifiche da lì.

Prova un helpdesk integrato con knowledge base incorporata

Se stai valutando se aggiungere l’AI al tuo wiki esistente o iniziare con uno strumento progettato per collegare i due elementi fin dal primo giorno, Deskhero evita il passaggio dell’integrazione successiva. Trasforma la tua casella di posta Gmail, Google Workspace o Microsoft 365 esistente in un helpdesk con ticket, dotato di una KB interna per i suggerimenti di risposta destinati agli User e di un chatbot AI che risponde solo utilizzando le FAQ pubbliche approvate.

Deskhero

Non è necessaria alcuna migrazione delle email né la gestione di un nuovo indirizzo. Le domande dei clienti arrivano come ticket in una casella di posta condivisa e le conversazioni risolte possono contribuire a suggerire elementi per le FAQ pubbliche. Dopo l’approvazione da parte di un User, questi elementi FAQ possono alimentare il chatbot del sito web e le risposte automatiche basate sull’AI. La KB interna e le altre conoscenze dello spazio di lavoro aiutano a redigere le risposte che gli User possono revisionare. Le azioni automatiche vengono registrate e contrassegnate, mentre le risposte automatiche complete ai clienti richiedono un’attivazione esplicita. Se stai valutando un software per knowledge base per un team di supporto piccolo o di medie dimensioni, inizia la prova gratuita di 30 giorni su Deskhero, senza carta di credito.

Fonti

FAQ

Cos’è una knowledge base interna?

È un archivio centralizzato e consultabile di informazioni aziendali che comprende procedure, policy, passaggi di onboarding e decisioni passate, creato affinché i dipendenti possano trovare autonomamente le risposte invece di chiedere a un collega.

Quali sono alcuni esempi di knowledge base interne?

Tra gli esempi più comuni rientrano un centro assistenza IT per la reimpostazione delle password e le richieste di accesso, un hub delle policy HR per benefit e ferie, una raccolta di runbook tecnici per la risposta agli incidenti e un wiki di sales enablement per presentazioni commerciali e gestione delle obiezioni.

Qual è un esempio di sistema di gestione della conoscenza?

Una piattaforma che combina una raccolta di contenuti consultabile con categorizzazione, analisi e feedback degli utenti può essere considerata un sistema di gestione della conoscenza. Deskhero estende questo modello collegando una KB interna e gli elementi delle FAQ pubbliche approvate a un helpdesk con ticket. Il suo chatbot risponde solo utilizzando le FAQ pubbliche approvate.

Qual è un altro termine per indicare una knowledge base?

Puoi sentirla chiamare anche wiki aziendale, sistema di documentazione interna, database delle conoscenze dei dipendenti o piattaforma di gestione della conoscenza, a seconda del fornitore o del team che la utilizza.