Un'eccellente knowledge base fa risparmiare ore di assistenza e velocizza la ricerca di risposte da parte degli utenti. Con Trupeer, puoi risparmiare ore nella progettazione della tua knowledge base partendo da un modello gratuito, personalizzandolo con le tue linee guida del brand e utilizzando i nostri strumenti di knowledge base per lanciare un hub completamente ricercabile.

Cos'è un modello di knowledge base e cosa contiene effettivamente?

Un modello di knowledge base è la struttura del contenitore: le categorie, le regole su cosa può essere aggiunto, chi possiede ciascuna area e come viene rimosso qualcosa. Non è la struttura delle pagine al suo interno.

Questa distinzione è importante perché le due cose vengono solitamente vendute insieme e risolvono problemi diversi. Una struttura di pagina rende chiara una singola risposta. Una struttura di contenitore rende qualsiasi risposta trovabile tra altre quattromila. Puoi avere articoli eccellenti in una knowledge base inutilizzabile, e questo è il più comune dei due fallimenti.

Se ciò di cui hai bisogno è la struttura delle pagine stesse, ovvero titoli, ambito, passaggi e i campi richiesti da ciascun tipo, questo è trattato nei nostri modelli di articoli per la knowledge base. Questa pagina copre tutto ciò che li circonda.

Perché le knowledge base falliscono per accumulo e non per abbandono

La storia che la maggior parte dei team si aspetta è che la knowledge base diventi obsoleta perché nessuno la aggiorna. Questo succede, ma di solito non è ciò che la decreta la fine.

Ciò che accade di solito è che funziona bene per circa diciotto mesi, poi si ferma silenziosamente. Niente è stato cancellato, niente si è rotto e nessuno ha preso una decisione. La libreria è semplicemente cresciuta e un giorno la ricerca di una procedura restituisce trenta risultati, la maggior parte dei quali sono note di riunione che casualmente la menzionano. Le persone ci provano due volte, non ottengono nulla di utile e tornano a chiedere a un collega. Dopodiché, la knowledge base è tecnicamente completa e funzionalmente morta.

Il meccanismo è la diluizione della ricerca. Una knowledge base è valida solo quanto il suo peggior risultato di ricerca, perché un lettore che non sa distinguere quale dei nove risultati sia autorevole non ha effettivamente trovato nulla. L'aggiunta di buoni contenuti non risolve questo problema. Rifiutare i contenuti scadenti sì.

Come personalizzare questo modello in Trupeer

Passaggio 1: Apri la sezione Modelli

Vai alla sezione Modelli dal menu di navigazione principale.

Passaggio 2: Seleziona e apri un modello

Fai clic su qualsiasi modello con cui desideri lavorare per aprirlo.

Passaggio 3: Espandi la visualizzazione del modello

Se necessario, espandi la visualizzazione del modello per vedere chiaramente il layout completo e i dettagli.

Passaggio 4: Modifica il modello

Fai clic su Modifica per iniziare a modificare il modello selezionato.

All'interno dell'editor, puoi:

• Aggiungere nuove sezioni

• Definire o aggiornare le regole di formattazione

• Aggiungere un logo e regolarne la posizione e le relative impostazioni

Passaggio 5: Salva il tuo modello personalizzato

Dopo aver apportato tutte le modifiche necessarie, fai clic su Salva per memorizzare il modello aggiornato come tuo.

Passaggio 6: Visualizza in anteprima e perfeziona il modello

Quando vuoi vedere come appare il tuo modello personalizzato, apri l'Anteprima.

Dalla schermata di anteprima, puoi continuare a apportare modifiche direttamente se necessario, assicurandoti che il modello appaia esattamente come desideri.

Con un modello di knowledge base puoi:

• Risparmiare ore sulla configurazione: Evita la pagina bianca con una struttura creata appositamente per le knowledge base.

• Ridurre i ticket di supporto: Contenuti chiari e ricercabili aiutano gli utenti a fare self-service.

• Rimanere in linea con il brand: Applica il tuo logo, font e colori utilizzando il brand kit di Trupeer.

• Aggiungere video tutorial: Associa gli articoli a video tutorial incorporati.

• Standardizzare i contenuti: Utilizza gli stessi modelli di articolo per una qualità costante.

• Raggiungere utenti globali: Traduci i contenuti della knowledge base in oltre 65 lingue con un solo clic.

La regola di ammissione che viene prima di qualsiasi struttura di categoria

La maggior parte dei team progetta prima l'albero delle categorie. Questo è l'ordine sbagliato, perché l'albero è a valle di ciò che ammetti, e un albero progettato per il materiale di riferimento si riempirà di scarti di progetto non appena nessuno controlla.

Scrivi prima la regola di ammissione, pubblicala e inseriscila nel modello che appare quando qualcuno crea una pagina. Tre domande, a cui la risposta deve essere sempre sì.

Qualcuno che non era presente nella stanza ne avrà bisogno? Se il pubblico è composto dalle quattro persone già presenti nella discussione, si tratta di un messaggio, non di un articolo.

Sarà ancora vero tra sei mesi? Qualsiasi cosa con una data allegata, un numero di sprint o un evento specifico appartiene allo strumento che possiede quella cosa, non qui.

È questo l'unico posto in cui risiede? Se la versione autorevole è un contratto, un ticket, un repository o un foglio di calcolo, inserisci un link ad essa. Una copia nella knowledge base diventa errata nel momento in cui l'originale cambia, e una copia errata è peggio di nessuna perché sembra aggiornata.

Tutto ciò che non supera una delle tre domande va da un'altra parte. Non cancellato e non conteso: spostato in uno spazio escluso dalla ricerca della knowledge base.

Cosa appartiene a una knowledge base e cosa no

La riga su cui si discute di più sono le note di riunione. Sembrano conoscenza e sono la singola fonte principale di diluizione della ricerca in ogni knowledge base interna che ho visto descritta. Conservale, rendile rintracciabili per il team che le ha scritte, ma tienile fuori dall'indice della knowledge base.

Modello gratuito di knowledge base: la struttura delle categorie da copiare

Sette categorie di primo livello, nessuna sotto-sotto-categoria, nominate in base a ciò che il lettore sta facendo piuttosto che al team proprietario del contenuto.

Primi passi. Percorsi ordinati per ruolo, ciascuno con uno stato finale. Nuovo collaboratore, nuovo amministratore, nuovo cliente.

Procedure (How-to). Istruzioni per le attività destinate a persone che sanno già cosa vogliono fare.

Risoluzione dei problemi. Accesso per sintomo, non per sistema.

Politiche e regole. Ciò che è richiesto e ciò che non è consentito, con un proprietario e una data di entrata in vigore per ciascuno.

Riferimento. Valori, codici, limiti, soglie e contatti. Principalmente tabelle.

Sistemi e accessi. A cosa serve ciascuno strumento, chi può ottenerlo e come richiederlo.

Problemi noti. Problemi attuali, soluzioni temporanee e ora dell'ultimo aggiornamento.

Adatta i nomi, mantieni il numero. Due regole lo rendono solido. Nessuna categoria prende il nome da un team, perché i lettori non conoscono il tuo organigramma e le riorganizzazioni finirebbero per rendere orfane intere sezioni. E nulla si trova al livello superiore al di fuori di queste sette, perché alla prima eccezione ne seguono sempre altre nove.

Dovresti gestire una o due knowledge base?

Due, in quasi tutti i casi, e la suddivisione avviene per pubblico piuttosto che per argomento. I clienti ne hanno una. Lo staff ne ha un'altra. Lo stesso argomento può comparire in entrambe, scritto in modo diverso.

Cercare di servire entrambi da un'unica base produce il peggio di ciascuna. O i dettagli interni trapelano nei contenuti rivolti ai clienti, oppure la versione interna viene privata delle avvertenze, dei percorsi di escalation e delle limitazioni note che la rendono utile per un operatore. I team di supporto finiscono per tenere un documento privato di ciò che gli articoli pubblici tralasciano, il che è il segno più chiaro che la suddivisione era necessaria e non è mai stata fatta.

Il punto di collegamento tra le due è al momento del passaggio di consegne. Un articolo interno su un problema ricorrente dovrebbe contenere un link all'articolo rivolto ai clienti a cui l'operatore rimanderà, e i tuoi modelli di risposta dell'help desk dovrebbero fare riferimento all'articolo pubblico anziché riformularlo.

Un esempio di knowledge base: 6.400 pagine e nessuno riusciva a cercare

Havenlark, un'azienda di software di circa quattrocento persone, gestiva la propria knowledge base interna in un wiki. Nel 2022 conteneva circa novecento pagine e un sondaggio interno indicava la soddisfazione per la ricerca al settantuno percento.

Tre anni dopo conteneva circa seimilaquattrocento pagine e la soddisfazione per la ricerca era scesa al ventiquattro percento. I team IT e delle risorse umane rispondevano alle stesse domande che avevano documentato anni prima.

Un audit ha catalogato le pagine. Circa duemilacento erano note di riunione. Quattordici cento erano pagine di progetti terminati. Novecento erano bozze duplicate o abbandonate. Seicento erano spazi di appunti personali. Ciò lasciava circa millequattrocento pagine che erano presumibilmente materiale di riferimento, di cui circa novecento erano attuali.

Il contenuto di riferimento non si era ridotto. Aveva quasi esattamente le stesse dimensioni del 2022. Era diventato invisibile. La ricerca della politica sulle spese restituiva trentaquattro risultati, di cui trentuno erano note di riunione che menzionavano le spese di sfuggita.

La soluzione non ha richiesto la scrittura di alcun nuovo contenuto. Due persone hanno trascorso una settimana a spostare le note delle riunioni, le pagine dei progetti terminati e gli spazi personali in aree separate escluse dall'indice di ricerca della knowledge base, e hanno inserito un banner sulle politiche superate. Nulla è stato cancellato, il che ha reso possibile farlo rapidamente e senza discussioni.

Il sondaggio successivo ha registrato una soddisfazione per la ricerca al sessantatré percento.

Due cose vale la pena trarre da questo esempio. Il problema non è mai stato la stesura dei testi, quindi nessuna quantità di scrittura lo avrebbe risolto. E il ripristino ha richiesto una settimana perché il contenuto era ancora tutto lì, il che è la dimostrazione a favore dello spostamento anziché della cancellazione quando si eredita una knowledge base in questo stato.

Chi possiede una knowledge base e come viene assegnata la proprietà

Ogni categoria ha un unico proprietario nominato. Non un team, perché la proprietà di un team significa che nessuno controlla, e non una funzione di documentazione, perché non possono giudicare se il contenuto è ancora vero.

Il compito del proprietario è piccolo e specifico: confermare che la categoria corrisponda ancora alla realtà due volte all'anno, approvare o rifiutare nuove pagine di primo livello nella propria area e archiviare ciò che è stato superato. Mezza giornata, due volte all'anno, e la persona che se ne occupa dovrebbe essere comunque colui che risponde alle domande su quell'argomento.

Al di sopra dei sette proprietari c'è una persona responsabile del contenitore stesso, vale a dire la regola di ammissione, la configurazione della ricerca e l'archivio. Questo ruolo è il punto in carenza solitamente le knowledge base, perché non sembra il lavoro di nessuno finché la ricerca non smette di funzionare. Laddove la struttura è abbastanza grande da richiedere una gestione più formale, il nostro modello di gestione della conoscenza copre il ciclo di vita e l'acquisizione su più sistemi.

Come configurare un modello di knowledge base in due settimane

La prima settimana è dedicata alla sottrazione. Se stai ereditando una base esistente, esegui l'audit sopra descritto: suddividi tutto in ciò che appartiene e ciò che va altrove, quindi sposta anziché eliminare. Se parti da zero, scrivi la regola di ammissione e falla approvare, perché concordarla dopo che i contenuti esistono è molto più difficile.

La seconda settimana è dedicata alla struttura. Crea le sette categorie, nomina i sette proprietari e inserisci in ciascuna le tre domande che il tuo team fa effettivamente più spesso, attinte dalla coda dei ticket o dal canale di supporto, piuttosto che da un brainstorming.

Poi fermati. Una knowledge base che parte con ventuno pagine realmente utili e una regola su ciò che viene dopo supererà sempre una che parte con duecento pagine importate, e sarà ancora utilizzabile tra tre anni.

Modelli di siti web per knowledge base, temi HTML e scelta della piattaforma

Alcune persone che cercano un modello di knowledge base gratuito desiderano un sito web: un tema HTML o un help center ospitato piuttosto che una struttura di contenuti. Questo è un bisogno reale e separato, e si manifesta direttamente in questi risultati, con una raccolta di temi per sviluppatori che si posiziona sulla stessa query.

Le due decisioni sono indipendenti e solo una di esse influisce sulla possibilità che le persone trovino risposte. Un help center a tema senza regole di ammissione si riempie degli stessi detriti di un wiki. Ciò che conta davvero in una piattaforma è la qualità della ricerca, la possibilità di escludere spazi dall'indice, la granularità dei permessi e il modo in cui si presenta su un telefono. L'aspetto visivo è il meno rilevante dei quattro e il più facile da cambiare in seguito.

Se stai scegliendo dove risiederà la knowledge base, testa la ricerca su un volume realistico di contenuti prima di qualsiasi altra cosa. La maggior parte delle dimostrazioni delle piattaforme utilizza cinquanta pagine perfette, il che non dice nulla su come si comporta la ricerca a quattromila.

Posso ottenere un modello di knowledge base gratuito in Word o PDF?

La struttura delle categorie, la regola di ammissione e la tabella dei contenuti descritte sopra sono scritte per essere incollate in Word o Google Docs e utilizzate come documento di configurazione. Vale la pena conservare questo documento, perché è ciò a cui fare riferimento quando qualcuno chiede perché le sue note di riunione sono state spostate.

Il formato PDF è adatto per la versione da distribuire una volta concordata la struttura. Ciò che non funziona in nessuno dei due formati è la knowledge base stessa. Una knowledge base si definisce per il fatto di essere ricercabile, e una cartella di file Word è solo un'unità condivisa con passaggi aggiuntivi.

Cosa rende il miglior modello di knowledge base gratuito per il tuo team

Non il numero di categorie o la raffinatezza del layout. Valuta un modello di knowledge base in base a tre elementi: se ti dice cosa tenere fuori, se ogni area ha un proprietario umano nominato e se sopravvive all'abbandono di qualcuno.

La maggior parte delle gallerie di modelli gratuiti di knowledge base offre un albero delle categorie e nulla più, che è la parte più facile da progettare e la meno predittiva del funzionamento della struttura al terzo anno. Se un modello non menziona l'archiviazione, non ha considerato il problema che effettivamente decreta la fine delle knowledge base.

Come riempire una nuova knowledge base senza un progetto di creazione contenuti

Il divario tra l'approvazione della struttura e l'effettiva presenza di contenuti è il punto in cui la maggior parte delle knowledge base si arena. Sette categorie vuote sono un impegno che nessuno ha il tempo di onorare, e il progetto per riempirle viene pianificato due volte e cancellato due volte.

L'IA di Trupeer colma questo divario trasformando una registrazione dello schermo in un articolo finito, in modo che la persona che conosce la risposta si registri mentre esegue l'operazione una volta e poi modifichi anziché scrivere da zero. Ventuno pagine di partenza diventano il lavoro di un pomeriggio anziché di un trimestre.

Registra. Personalizza con il brand. Traduci. Usa Trupeer.

La stessa registrazione ti fornisce una guida scritta, un video e un documento per la tua knowledge base con un branding coerente, e la traduzione significa che un'unica struttura serve ogni area geografica anziché veder nascere silenziosamente iniziative isolate in ciascuna. Per la documentazione tecnica vale lo stesso, e le istruzioni di configurazione si trovano nella guida alla configurazione del modello di documento.

Domande frequenti

Esiste un modello di knowledge base gratuito in Word?

La struttura sopra descritta si incolla direttamente in Word o Google Docs come documento di configurazione e governance, coprendo categorie, proprietari e regole di ammissione. Non ci sono download protetti o moduli da compilare. Gli articoli stessi non dovrebbero risiedere in Word, poiché una knowledge base è definita dalla ricerca e i file Word non sono ricercabili in alcun modo utile.

Esiste un modello di knowledge base gratuito in PDF?

Esporta il tuo non appena le sette categorie e i nomi dei proprietari sono stati concordati, e distribuiscilo come versione di riferimento. Mantieni modificabile la copia di lavoro, poiché la regola di ammissione richiede solitamente un aggiustamento dopo il primo mese di discussioni reali su cosa includere.

Posso scaricare un modello di knowledge base gratuito?

La struttura delle categorie, la regola di ammissione, la tabella dei contenuti e il modello di proprietà sono gratuiti e senza restrizioni. Utilizzali, rinomina le categorie per adattarle alla tua organizzazione e inseriscili nei tuoi documenti di governance senza necessità di attribuzione.

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

Un wiki è una tecnologia in cui chiunque può creare e modificare pagine. Una knowledge base è uno scopo, ovvero un insieme curato di risposte con proprietari e una regola di ammissione. La maggior parte delle knowledge base fallite sono wiki a cui non è mai stata data la seconda parte, che è esattamente il modello Havenlark descritto sopra.

Con quanti articoli dovrebbe iniziare una knowledge base?

Circa venti, scelti tra le domande che il tuo team o i tuoi clienti hanno effettivamente posto più spesso nell'ultimo mese. Iniziare con un numero maggiore è l'errore più comune, perché i contenuti importati arrivano senza proprietari e stabiliscono il precedente che qualsiasi cosa può essere aggiunta, che è esattamente il precedente che stai cercando di evitare.

La nostra knowledge base dovrebbe essere pubblica o protetta da login?

Pubblica per tutto ciò che un potenziale cliente potrebbe cercare, perché quegli articoli svolgono una doppia funzione di acquisizione. Protetta da login per qualsiasi cosa che nomini sistemi interni, percorsi di escalation, soglie o personale specifico. Se un articolo ha bisogno di entrambi i trattamenti, questo è il segnale più chiaro che hai bisogno di due knowledge base anziché di una con permessi complessi.

Ogni quanto tempo deve essere revisionata una knowledge base?

I proprietari delle categorie confermano la loro area due volte all'anno, il che è sufficiente per la struttura. I singoli articoli dovrebbero essere verificati nuovamente in base a eventi scatenanti piuttosto che a una pianificazione temporale, ovvero quando viene aperto un ticket nonostante l'esistenza dell'articolo o quando l'elemento descritto cambia. Revisionare il contenitore e revisionare i contenuti sono compiti separati con tempistiche diverse.