5 esempi di knowledge base da copiare

Questi esempi di knowledge base sono cinque articoli completi, resi interamente in questa pagina e scaricabili in PDF: esempi di articoli di knowledge base rivolti ai clienti insieme a esempi di knowledge base interna per un service desk e per un wiki dedicato ai nuovi assunti.

Vai direttamente agli esempi.

Cosa rende valido un esempio di knowledge base

• Un solo compito per articolo, indicato nel titolo. Rispettato: il titolo indica un unico compito completabile ("Reimpostare il dispositivo MFA di un utente") e l'articolo finisce lì. Mancato: il titolo è un argomento generico ("Sicurezza dell'account") che copre tre compiti scollegati.
• Trovabile con le parole del lettore. Rispettato: il titolo riprende la frase che un lettore digiterebbe, e l'articolo contiene termini alternativi così la ricerca lo trova comunque. Mancato: il titolo usa il gergo interno, quindi solo l'albero delle categorie porta fino a lì.
• Prova visiva a ogni punto decisionale. Rispettato: uno screenshot compare a ogni passaggio in cui il lettore sceglie tra opzioni o conferma la schermata giusta. Mancato: i passaggi scorrono come un muro di testo, oppure un solo screenshot principale porta il peso di tutto l'articolo.
• Linguaggio semplice, senza gergo interno. Rispettato: l'articolo espande gli acronimi alla prima occorrenza e i suoi verbi corrispondono a ciò che il lettore vede a schermo. Mancato: l'articolo usa il nome interno del team per una schermata che il prodotto etichetta diversamente.
• Un responsabile nominato e una data di revisione sull'articolo. Rispettato: l'articolo indica chi lo mantiene e quando quella persona lo ha controllato l'ultima volta. Mancato: l'articolo è senza data e senza responsabile, così una procedura viva si legge come una procedura morta.
• Prerequisiti dichiarati e una via d'uscita. Rispettato: indica quale accesso serve al lettore prima del primo passaggio, e cosa fare quando i passaggi non risolvono il problema. Mancato: il lettore si scontra con un blocco di permessi al terzo passaggio senza alcuna alternativa.

5 esempi di knowledge base, resi per intero

Ognuno di questi esempi di articoli di knowledge base è un articolo completo che puoi leggere da cima a fondo, con la propria anteprima e il proprio PDF. Due sono rivolti ai clienti, due sono esempi di knowledge base interna, e uno è stato scritto da un'agenzia per un cliente. Leggi l'anteprima, prendi il PDF e sostituisci i valori.

Esempio 1: Help center di un prodotto SaaS (rivolto ai clienti)

Un team di supporto contenuti di un SaaS per la gestione progetti ha scritto questo articolo per un utente finale senza diritti da amministratore che vuole completare un'esportazione senza aprire un ticket.

Cosa funziona: il titolo, "Come esportare la timeline del tuo progetto in CSV", indica un solo compito completabile e l'articolo si ferma quando il file arriva, il che è "Un solo compito per articolo, indicato nel titolo" fatto correttamente. Gli screenshot compaiono ai passaggi 2 e 3, gli unici due punti in cui il lettore sceglie un'opzione, quindi soddisfa anche "Prova visiva a ogni punto decisionale" senza appesantire la pagina di immagini.

Attenzione a: l'esportazione si trova dietro un menu "...", e il mittente riporta exports@[product].com, un segnaposto. Entrambi vanno sostituiti con quelli del tuo prodotto prima di pubblicare.

Scarica il PDF

Esempio 2: Knowledge base interna del supporto IT (interno)

Un agente del service desk di primo livello usa questo articolo per reimpostare l'MFA di un chiamante che ha sostituito il telefono, sotto un livello di priorità P3 con quattro ore lavorative per la risoluzione.

Cosa funziona: l'articolo apre con l'accesso e i due campi di verifica HR necessari all'agente prima del primo passaggio, e si chiude con "Escalation quando", indicando la reperibilità Identity come via d'uscita. Questo è "Prerequisiti dichiarati e una via d'uscita" su un articolo in cui un controllo mancato è un incidente di sicurezza. Il blocco separato "Non fare" tiene le due regole rigide fuori dall'elenco dei passaggi, dove verrebbero lette come facoltative.

Attenzione a: le regole di verifica presuppongono un'unica console identità. Un team con strumenti diversi deve riscrivere i passaggi da 2 a 5 invece di riutilizzarli.

Scarica il PDF

Esempio 3: Wiki di onboarding per i nuovi assunti (interno)

Un team di developer experience consegna questo articolo a un nuovo ingegnere il primo giorno, così può concludere la prima settimana senza interrompere nessuno.

Cosa funziona: Sam O. è il responsabile dell'articolo e il campo dell'ultima revisione riporta 2026-08-11, così un nuovo assunto può vedere che la configurazione è aggiornata prima di fidarsene. Questo è "Un responsabile nominato e una data di revisione sull'articolo", e la stima di 90 minuti più il buddy nominato dicono al lettore cosa fare del tempo e a chi rivolgersi.

Attenzione a: l'articolo si appoggia a un canale #dx-help e a un buddy di onboarding assegnato. Un team di cinque persone non ha né l'uno né l'altro, quindi questi due riferimenti vanno sostituiti con il nome di una persona reale.

Scarica il PDF

Esempio 4: Libreria di risoluzione dei problemi per il supporto clienti (rivolto ai clienti)

Un venditore su una piattaforma di ecommerce arriva a questo articolo con un sintomo invece che con un compito: il checkout rifiuta i pagamenti e la causa non è chiara.

Cosa funziona: il titolo cita il sintomo con le parole del venditore, "I pagamenti falliscono al checkout", e la riga del sintomo riprende esattamente il messaggio di errore che vedono i clienti. La ricerca lo trova con le parole che digita un venditore in difficoltà, il che è "Trovabile con le parole del lettore". La checklist esegue prima il controllo più economico, la pagina di stato del fornitore, prima di qualsiasi cosa che comporti una modifica di configurazione.

Attenzione a: la tabella causa-soluzione presuppone un solo fornitore di pagamenti. Un negozio che usa due fornitori ha bisogno di una colonna che indichi quale è fallito, altrimenti le righe su valuta e chiave puntano all'account sbagliato.

Scarica il PDF

Esempio 5: Knowledge base di passaggio di consegne di un'agenzia al cliente (rivolto al cliente)

Un'agenzia che chiude un progetto ha scritto questo articolo per un team marketing del cliente che ora gestisce il sito senza accesso da sviluppatore.

Cosa funziona: i passaggi indicano i pulsanti che vede il cliente, Posts, New post, Publish, e specificano le dimensioni dell'immagine di copertina come 1600x900 invece di "un'immagine di dimensioni adeguate". Questo è "Linguaggio semplice, senza gergo interno" per un lettore che non ha mai aperto un CMS. Il blocco "Non modificare" traccia il confine dell'ambito direttamente nel documento, dove il cliente lo troverà ancora dopo che l'email di passaggio di consegne sarà sepolta nella casella di posta.

Attenzione a: la finestra di supporto ha come data 2026-11-30 e diventa obsoleta il giorno in cui termina l'incarico, lasciando un cliente a seguire un articolo che promette un aiuto che non fornisci più.

Scarica il PDF

Come adattare un esempio di knowledge base

Prendi l'esempio 2, l'articolo interno di reimpostazione dell'MFA, e trasformalo nel tuo. Ogni esemplare funziona anche come base di partenza, quindi apri il suo PDF accanto al tuo editor e copia la struttura.

1. Rinomina il titolo indicando un compito che supporti tu. "Reimpostare il dispositivo MFA di un utente dopo la sostituzione del telefono" diventa l'unico compito che il tuo articolo porta a termine, formulato come lo chiederebbe un collega.
2. Riscrivi il blocco di campi per il tuo team. Destinatari, Responsabile, Ultima revisione, e qualsiasi riga di gravità o SLA sostituiscono Marcus L. e 2026-07-22 con i tuoi nomi e le tue date.
3. Sostituisci i prerequisiti con i tuoi requisiti di accesso reali. Indica la console, il ruolo e i controlli che avvengono prima del primo passaggio.
4. Sostituisci i passaggi con i tuoi strumenti, mantenendo un'azione per passaggio. Percorri il compito una volta mentre scrivi, e registra i nomi delle schermate così come compaiono.
5. Segna i punti decisionali che richiedono uno screenshot. Ogni passaggio in cui il lettore sceglie tra opzioni riceve un'immagine accanto.
6. Elimina le sezioni che il tuo processo non ha. Un articolo senza livello di gravità elimina quel campo invece di lasciarlo vuoto.
7. Scrivi per ultima la sezione degli errori e la via d'uscita. Indica cosa fare quando i passaggi smettono di funzionare, e nomina la persona o la coda che prende in carico da lì.
8. Verifica il risultato rispetto ai sei criteri sopra, etichetta per etichetta, poi pubblica e imposta la data di revisione.

Quando serve una knowledge base

Il segnale è la stessa domanda che arriva per la terza volta nella tua casella di supporto. Liveagent riporta che il 66% dei clienti cerca di risolvere i propri problemi prima di contattare i team di assistenza clienti, quindi una domanda ricorrente segnala che la risposta esiste già da qualche parte, in privato. L'esempio 1, l'articolo dell'help center SaaS, è come appare quella risposta una volta che qualcuno la mette per iscritto.

Costruiscine una nella settimana in cui inizia un nuovo assunto e ti ritrovi a spiegare la configurazione alla sua scrivania. L'esempio 3, il wiki di onboarding, sposta quella spiegazione in un documento che il prossimo assunto può completare da solo.

Un service desk ne ha bisogno nel momento in cui una procedura ha un passaggio che l'agente non può saltare. L'esempio 2 esiste perché leggere un codice ad alta voce a un chiamante ha un costo, e un agente sotto un vincolo di quattro ore non dovrebbe ricostruire la regola a memoria.

Errori comuni nella knowledge base

• Un articolo senza un responsabile nominato resta senza revisione. Slite stima che oltre il 94% dei contenuti di una knowledge base resti intoccato in un dato mese, una libreria di cui i tuoi lettori smettono di fidarsi.
• La struttura smette di evolversi, così la conoscenza finisce per essere isolata. Swifteq cita un dato di Gartner secondo cui il 47% dei lavoratori digitali fatica a trovare le informazioni di cui ha bisogno, e una ricostruzione costa più della potatura che hai saltato.
• Design sovraccarico e muri di solo testo seppelliscono la risposta. Una pagina disordinata spinge sotto la piega il paragrafo che risolve il problema, e il tuo lettore apre comunque un ticket.
• Nessuna via d'uscita verso una persona. Un lettore il cui problema sopravvive all'articolo e non trova un modo per contattare qualcuno se ne va senza risposta, e tu perdi un ticket da cui avresti potuto imparare.
• Conservare ciò che non dovrebbe stare lì. Credenziali, dati personali e tutto ciò che appartiene ad altri team trasformano un articolo di aiuto in una responsabilità. La versione più comune è un articolo che copre tre compiti, inutile per tutti e tre.

Salta la pagina vuota: registra invece

Ognuno degli esemplari sopra è partito una volta da una pagina vuota. La strada più veloce è registrare il compito e lasciare che la registrazione diventi l'articolo.

Hinto AI trasforma registrazioni dello schermo e video dimostrativi in documentazione strutturata, procedure operative standard e help center, per i team che preferiscono mostrare e raccontare in video piuttosto che scrivere guide a mano. Registra con lo screen recorder integrato nel browser o nell'estensione Chrome, oppure porta un video che hai già: Loom, Zoom, YouTube o un caricamento locale.

Da lì, il rilevamento delle azioni basato su AI identifica i cambiamenti di stato dell'interfaccia e i clic sui pulsanti nella registrazione ed estrae screenshot e passaggi scritti, esattamente il tipo di elenco di passaggi che porta l'esempio 2. Una singola registrazione lunga si converte in un intero indice con più articoli organizzati, usando i modelli per help center o per procedure operative standard interne. Sfoca qualsiasi elemento sensibile nell'editor di immagini, poi ospita il risultato su un URL pubblico con un dominio personalizzato.

Altri esempi di knowledge base da studiare

Gli esemplari sopra sono scritti per essere copiati. Questi quattro sono in produzione, live, e rispondono a utenti reali:

• Documentazione di Gentler Streak, l'intera knowledge base pubblica di un'app fitness, organizzata in categorie orientate ai compiti e pubblicata in nove lingue.
• Come iniziare un allenamento sul tuo Apple Watch, un solo compito, passaggi numerati, screenshot nei tocchi che contano.
• Cos'è la variabilità della frequenza cardiaca (HRV)?, il tipo esplicativo, che definisce una metrica su cui si appoggiano gli articoli how-to.
• Versione 5.12.8 (9 luglio 2026), note di rilascio conservate dentro la knowledge base, così una schermata modificata e il suo articolo restano collegati.

FAQ sulla knowledge base

C'è un posto dove trovare modelli ed esempi per creare articoli di knowledge base dall'aspetto professionale?

Usa i cinque esemplari sopra. Ognuno è reso per intero qui e scaricabile come PDF, così ottieni l'ordine delle sezioni e la formattazione dei passaggi invece di un link a un help center live.

Quali sono alcuni buoni esempi di knowledge base?

Valutane uno rispetto a sei criteri: un solo compito per articolo indicato nel titolo, trovabile con le parole del lettore, prova visiva a ogni punto decisionale, linguaggio semplice, un responsabile nominato e una data di revisione, e prerequisiti dichiarati con una via d'uscita.

Cos'è una knowledge base interna e come se ne crea una?

Una knowledge base interna serve i dipendenti anziché i clienti, il più delle volte per l'onboarding, il supporto IT e la risoluzione dei problemi. Gli esempi 2 e 3 sono esemplari interni. Inizia con i due articoli che il tuo team spiega più spesso a voce.

Cos'è un articolo di knowledge base?

Un articolo di knowledge base indica nel titolo un compito completabile e finisce quando quel compito è concluso. La forma di riferimento è: titolo, destinatari, responsabile, ultima revisione, prerequisiti, passaggi numerati con screenshot ai punti decisionali, una sezione sugli errori e una via per raggiungere una persona.

Questi esempi funzionano su SharePoint, Confluence o ServiceNow?

Sì. Ogni esemplare è testo strutturato semplice: intestazioni, un blocco di campi, passaggi numerati, una tabella. Nulla dipende da una funzione specifica della piattaforma, quindi si incolla in quegli editor mantenendo l'ordine.