Una knowledge base è utile solo quanto lo sono gli articoli al suo interno. Con Trupeer, puoi risparmiare ore nella stesura degli articoli della knowledge base partendo da modelli di articoli pronti all'uso, personalizzandoli con le tue linee guida del brand e trasformando articoli ricchi di testo in chiare procedure video con cui clienti e dipendenti possono effettivamente interagire.

Che cos'è un articolo di una knowledge base e cosa risolve un modello?

Un articolo di una knowledge base è una singola risposta autonoma, scritta per qualcuno che è arrivato da una barra di ricerca con un problema già in mente. Non è documentazione, che descrive un sistema, e non è un manuale, che si legge in ordine.

Un modello risolve tre problemi. Impedisce a chi scrive di reinventare una struttura ogni volta, operazione che richiede ore. Rende gli articoli sufficientemente coerenti in modo che i lettori imparino dove cercare. E forza l'inserimento di quei campi che i redattori tendono a saltare se lasciati soli, che non sono quasi mai i passaggi.

Ciò che non può risolvere è una libreria in cui nessuno può effettuare ricerche, un articolo sull'argomento sbagliato o un team che non aggiorna mai nulla.

Perché gli articoli della knowledge base falliscono ai margini, non nel mezzo

Leggi un brutto articolo di una knowledge base e di solito la scrittura va bene. I passaggi sono corretti, gli screenshot aggiornati, qualcuno conosceva chiaramente l'argomento.

Ciò che fallisce è il confine. L'articolo descrive una versione della situazione, il lettore ne ha una leggermente diversa e nessuno glielo dice. Seguono le istruzioni, queste silenziosamente non funzionano, e aprono comunque un ticket, ora più infastiditi rispetto a se non avessero trovato nulla.

Nei dati questo si presenta come il pattern più strano in qualsiasi centro assistenza: articoli con visualizzazioni elevate e un alto volume di ticket sullo stesso argomento. L'articolo viene trovato. Viene letto. Non risolve nulla.

La soluzione non è una scrittura migliore. Sono due righe per le quali la maggior parte dei modelli non ha alcun campo, sopra ogni altra cosa, che dicono cosa tratta questo articolo e dove andare se questo non è il tuo caso.

Come personalizzare questo modello in Trupeer

Passaggio 1: Apri la sezione Modelli

Vai alla sezione Modelli dalla 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 desideri vedere l'aspetto del tuo modello personalizzato, apri l'Anteprima.

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

Con i modelli di articoli della knowledge base puoi:

• Risparmiare ore di scrittura: Utilizza strutture collaudate per guide pratiche, domande frequenti e articoli per la risoluzione dei problemi.

• Ridurre i ticket di supporto: Articoli chiari aiutano gli utenti a risolverli autonomamente, riducendo il carico di supporto e liberando gli agenti per problemi più complessi.

• Rimanere in linea con il brand: Applica il tuo logo, font e colori utilizzando il brand kit di Trupeer, in modo che ogni articolo sembri appartenere al tuo prodotto.

• Migliorare la reperibilità: Le strutture standard rendono gli articoli più facili da scansionare, cercare e aggiornare.

• Localizzare a livello globale: Traduci gli articoli della knowledge base in oltre 65 lingue con un solo clic.

• Aggiungere procedure video: Associa agli articoli video incorporati per passaggi difficili da spiegare solo con il testo.

Le due righe di cui ogni modello di articolo della knowledge base ha bisogno

La riga sull'ambito di applicazione. Una frase che definisce la situazione a cui si applica questo articolo, nei termini del lettore anziché nei tuoi. Non "Questo articolo si applica agli account del piano Standard" ma "Se accedi con un indirizzo email e una password". Il lettore deve essere in grado di verificarlo rispetto a qualcosa che può vedere.

La riga di uscita. Una frase che indica la situazione adiacente più comune e rimanda ad essa. "Se la tua azienda utilizza il single sign-on, vai invece qui".

Entrambe vanno posizionate sopra i passaggi, mai in una nota in fondo. Un lettore che ha iniziato a seguire le istruzioni non si fermerà per un avvertimento, e un lettore nell'articolo sbagliato dovrebbe andarsene entro circa otto secondi.

La disciplina conta più delle righe. Scrivere una riga di uscita ti costringe a nominare i casi adiacenti e nominarli di solito rivela che due o tre di essi non hanno affatto un articolo.

Tipi di articoli della knowledge base e quando utilizzare ciascuno

L'errore strutturale più comune è scrivere un problema di risoluzione dei problemi come una guida pratica. Se il lettore non sa ancora cosa c'è che non va, i passaggi numerati sono la forma sbagliata, perché il passaggio uno presuppone una diagnosi che non ha fatto. Parti dal sintomo e dirama. Il nostro modello di articolo per guide pratiche copre la prima riga in modo più approfondito.

Modello di articolo della knowledge base gratuito: la struttura da copiare

Copia da qui. I campi contrassegnati come obbligatori rimangono in ogni articolo indipendentemente dal tipo.

Titolo, obbligatorio. La domanda del lettore con le parole del lettore. "Non riesco a effettuare l'accesso" è meglio di "Risoluzione dei problemi di autenticazione". I titoli scritti come etichette anziché come problemi sono il motivo più comune per cui un buon articolo non viene mai trovato.

Termini di ricerca, obbligatori. Da tre a sei formulazioni alternative che le persone usano effettivamente, prese dal registro delle ricerche a zero risultati anziché inventate. La maggior parte delle piattaforme ha questo campo e la maggior parte dei team lo lascia vuoto.

Riga di ambito, obbligatoria. Come sopra.

Riga di uscita, obbligatoria. Come sopra.

Risposta o primo passaggio, obbligatorio. Per una domanda breve, la risposta completa entro due righe. Per una procedura, il passaggio uno. Niente tra la riga di uscita e questo, e nello specifico nessuna introduzione che spieghi di cosa tratta l'articolo.

Corpo. Passaggi, ramificazioni o tabella, a seconda del tipo.

Cosa fare se questo non ha funzionato. Il passaggio successivo stabilito: un altro articolo specifico, un modulo o una coda. Non "contatta il supporto".

Proprietario e data dell'ultima verifica. Una persona e la data in cui qualcuno ha confermato l'ultima volta che l'articolo corrisponde ancora alla realtà. Non la data in cui è stata modificata la dicitura.

Copia fino a qui. Se un campo sembra non necessario per un determinato articolo, eliminalo in quell'articolo anziché rimuoverlo dal modello, perché quelli che i redattori saltano sono proprio quelli che stavano svolgendo il lavoro.

Esempi di modelli di articoli della knowledge base per quattro tipi comuni

FAQ. Titolo: "Posso cambiare la data di fatturazione?" Ambito: account con fatturazione mensile. Risposta, nelle prime due righe: sì, una volta per ciclo di fatturazione, da Fatturazione e poi Pianificazione, e la modifica ha effetto dal ciclo successivo. Uscita: piani annuali, vai qui. Questo è l'intero articolo.

Guida pratica. Titolo: "Aggiungere un utente alla tua area di lavoro". Ambito: sei un amministratore. Uscita: se non vedi Impostazioni allora non sei un amministratore, chiedi al tuo. Passaggi: quattro, ciascuno con il risultato atteso. Poi: cosa fare se l'invito non arriva.

Risoluzione dei problemi. Titolo: "L'esportazione termina ma il file è vuoto". Ambito: esportazioni dalla schermata Report. La prima ramificazione è l'elemento che il lettore può verificare senza aiuto, che di solito è l'intervallo di date. La seconda ramificazione riguarda le autorizzazioni. La terza è il limite noto. Ogni ramificazione termina o con la risoluzione o con un passaggio successivo stabilito.

Errore noto. Titolo: "I report sono in ritardo per gli account UE". Stato, chi è interessato, cosa fare nel frattempo, quando verrà pubblicato il prossimo aggiornamento e l'ora dell'ultimo aggiornamento, che è il campo che i lettori cercano effettivamente.

Un esempio di articolo della knowledge base: visualizzazioni elevate, ticket elevati

Loxwell, un prodotto per la gestione delle buste paga con circa undicimila clienti commerciali, aveva un centro assistenza di circa millecento articoli e un team di contenuti molto stimato.

Il loro articolo sulla reimpostazione della password riceveva circa quattordicimila duecento visualizzazioni a trimestre. I ticket relativi alle password nello stesso periodo si attestavano intorno ai novecento e non si erano mossi per due anni. Entrambi i numeri venivano segnalati mensilmente, in presentazioni diverse, a persone diverse.

Qualcuno alla fine li ha affiancati. L'articolo copriva la reimpostazione standard: inserisci la tua email, fai clic sul link, scegli una nuova password. Circa il sessanta percento dei ticket sulle password proveniva da utenti le cui aziende avevano abilitato il single sign-on, dove il link di reimpostazione non serve a nulla perché l'identity provider conserva la password. L'articolo non menzionava mai il single sign-on. Quei lettori lo trovavano, lo seguivano, lo guardavano fallire senza un messaggio di errore e aprivano un ticket.

La soluzione ha richiesto un pomeriggio. Due righe in cima all'articolo esistente che definivano il caso standard e indirizzavano gli utenti con single sign-on altrove, più un nuovo breve articolo per quegli utenti, oltre alla frase che le persone avevano effettivamente digitato nella casella di ricerca aggiunta a entrambi.

I ticket sulle password sono scesi a circa trecentodieci nel trimestre successivo. Anche le visualizzazioni sull'articolo originale sono scese, a circa novemila ottocento, e quel calo è stato il successo, non un regresso. Quattromila di quei lettori si trovavano nell'articolo sbagliato.

Lo stesso pomeriggio ha rivelato un secondo dato. Dei millecento articoli, trecentoquaranta non avevano ricevuto alcuna visualizzazione in dodici mesi. Anche in essi non c'era nulla di sbagliato.

Come scrivere un buon articolo per la knowledge base, passo dopo passo

Inizia dal ticket, non dalla funzionalità. Apri gli ultimi dieci ticket sull'argomento e leggi la prima frase del cliente in ciascuno di essi. Quella frase è il tuo titolo e quelle parole sono i tuoi termini di ricerca.

Scrivi la riga di ambito prima di ogni altra cosa. Se non riesci a dichiarare per chi è questo articolo in una sola frase verificabile, l'argomento è troppo ampio e si tratta di due articoli diversi.

Scrivi la risposta o il primo passaggio immediatamente dopo la riga di uscita. Resisti alla tentazione dell'introduzione: a nessuno che arrivi da un risultato di ricerca deve essere spiegato di cosa tratta l'articolo.

Scrivi il corpo, poi taglia ogni frase che spiega perché il sistema funziona in questo modo. Questo appartiene alla documentazione, e in un articolo spinge la parte utile sotto la piega.

Finisci con il passaggio successivo stabilito e il proprietario, poi consegnalo a qualcuno che ha il problema e guardalo usarlo senza aiutarlo.

Cosa dovrebbe includere ogni modello di articolo della knowledge base?

Sei campi, in questo ordine: un titolo formulato come il problema del lettore, termini di ricerca alternativi, una riga di ambito, una riga di uscita, la risposta o il primo passaggio e un passaggio successivo stabilito per il fallimento. Un proprietario e la data dell'ultima verifica risiedono nei metadati.

Tutto il resto è specifico del tipo. Passaggi, ramificazioni, tabelle, blocchi di stato e screenshot variano tutti in base al tipo di articolo, e un modello che li impone per ogni articolo produce FAQ gonfiate e guide alla risoluzione dei problemi scarne in egual misura.

Come distribuire i modelli in una knowledge base esistente

Non rinnovare l'intera libreria. I team che ci provano si bloccano intorno all'articolo novanta e lasciano in vigore due standard visibilmente diversi, il che è peggio di uno cattivo.

Applica il modello ai nuovi articoli a partire da una data fissa. Quindi prendi i venti articoli esistenti più visualizzati e aggiungi solo la riga di ambito, la riga di uscita e i termini di ricerca, lasciando intatto il corpo. Quei venti di solito portano con sé una quota cospicua di tutte le visualizzazioni, quindi il ritorno arriva in due settimane anziché in un trimestre.

Dopodiché, lascia che siano i ticket a guidare il processo. Qualsiasi articolo che genera un ticket viene rielaborato quando quel ticket si chiude, dalla persona che lo ha chiuso. La libreria si converte da sola nell'ordine che conta, e nessuno pianifica uno sprint di documentazione che poi viene cancellato.

Come si misurano le prestazioni di un articolo della knowledge base?

Le visualizzazioni da sole non dicono quasi nulla, come mostra l'esempio sopra. Associa ogni articolo al volume dei ticket sul suo argomento e leggili insieme. Visualizzazioni elevate con ticket elevati significano che l'articolo viene trovato e fallisce. Visualizzazioni basse con ticket elevati significano che l'articolo manca o non è reperibile, che sono problemi diversi con lo stesso sintomo. Visualizzazioni basse con ticket bassi di solito significano che l'articolo va eliminato.

Altri due dati valgono l'impegno. Il registro delle ricerche a zero risultati, che è un elenco di cose che i tuoi clienti hanno cercato e che non hai, e la percentuale di articoli verificati negli ultimi sei mesi. Entrambi sono solitamente disponibili in un pomeriggio ed entrambi non compaiono nella maggior parte dei report.

Come mantenere gli articoli della knowledge base senza un ciclo di riscrittura

I cicli di revisione pianificati falliscono perché arrivano quando non è cambiato nulla e mancano il momento in cui qualcosa è cambiato. Usa invece i trigger.

Verifica nuovamente un articolo quando viene aperto un ticket nonostante la sua esistenza, quando l'interfaccia che descrive cambia, quando appare nel registro a zero risultati con una formulazione a cui avrebbe dovuto corrispondere e quando il suo proprietario se ne va. Qualsiasi cosa rimasta intatta da tutti e quattro questi eventi per dodici mesi è candidata all'eliminazione piuttosto che alla revisione.

Eliminare è la parte che i team evitano. Trecentoquaranta articoli non visualizzati non se ne stanno lì tranquilli, diluiscono i risultati di ricerca e rendono più difficili da raggiungere gli articoli utili. Una libreria che cresce soltanto non viene mantenuta. Dove la disciplina più ampia conta, il nostro modello di gestione della conoscenza copre la proprietà e il ciclo di vita dell'intero patrimonio.

Posso ottenere un modello di articolo della knowledge base in Word o Excel?

Word si adatta all'articolo stesso se il tuo team redige le bozze prima della pubblicazione, anche se redigere direttamente nel centro assistenza è solitamente più veloce perché vedi il rendering e i campi di ricerca. Excel si adatta all'indice degli articoli, che è l'elenco di ogni articolo con proprietario, tipo, data dell'ultima verifica, visualizzazioni e volume dei ticket, e quell'indice è ciò che rende possibile la misurazione di cui sopra.

L'indice è il più prezioso dei due e quello che quasi nessuno crea. Sei colonne e un'esportazione mensile ti diranno sulla tua knowledge base più di quanto farà qualsiasi modello.

Modelli di siti web di knowledge base e HTML: cosa non è questa pagina

Alcune persone che cercano questo termine desiderano un modello di sito web di una knowledge base o un tema HTML, ovvero il sito che ospita gli articoli anziché gli articoli stessi. Questa pagina non serve a questo e non può pretendere di farlo.

È opportuno essere chiari sulla distinzione, perché le due decisioni non sono correlate. Scegliere una piattaforma o un tema per il centro assistenza è una decisione di web e design che riguarda la ricerca, la navigazione, il rendering mobile e le autorizzazioni. La struttura dell'articolo è una decisione di scrittura. Un bellissimo centro assistenza pieno di articoli senza righe di ambito genera comunque ticket, mentre uno semplice pieno di buoni articoli no.

Se stai scegliendo dove risiederanno gli articoli piuttosto che cosa inserire in essi, il nostro modello di knowledge base copre struttura, categorie e proprietà.

Come trasformare una registrazione dello schermo in articoli della knowledge base

L'ostacolo in ogni centro assistenza non è sapere cosa scrivere. È che la persona che conosce la risposta ha già risolto il problema ed è andata avanti, e scriverla richiede un'ora che non ha.

L'intelligenza artificiale di Trupeer trasforma una registrazione dello schermo in un articolo formattato con i passaggi e gli screenshot al loro posto, così la persona che lo ha risolto registra la soluzione una volta e modifica anziché scrivere. Aggiungi tu stesso il titolo, la riga di ambito e la riga di uscita, perché quelle richiedono giudizio e il resto è trascrizione.

Registralo. Brandizzalo. Traducilo. Usa Trupeer.

La stessa registrazione produce un video per i lettori che preferiscono guardare, un documento per la tua knowledge base e una formattazione coerente per ogni articolo senza che nessuno debba mantenere una guida di stile. La traduzione qui conta più che nella maggior parte dei casi, perché un centro assistenza in una sola lingua indirizza silenziosamente tutti gli altri clienti verso la tua coda di supporto. Le Guide coprono il flusso di lavoro più ampio e le istruzioni di configurazione si trovano nella guida alla configurazione del modello di documento.

Domande frequenti

Esiste un modello di articolo della knowledge base gratuito in Word?

La struttura a sei campi sopra descritta è scritta per essere incollata direttamente in Word o Google Documenti e conservata come schema per le bozze. Non c'è alcun download protetto, il che significa anche nessun modulo tra te e la struttura. La maggior parte dei team scopre di smettere di usare la versione Word entro un mese per scrivere direttamente nel centro assistenza, il che va bene ed è più veloce.

Esiste un modello di knowledge base in Excel?

Usa Excel per l'indice degli articoli anziché per gli articoli. Colonne per titolo, tipo, proprietario, data dell'ultima verifica, visualizzazioni in questo trimestre e ticket su questo argomento. Quel foglio è ciò che trasforma un centro assistenza da un cumulo di pagine in qualcosa che puoi gestire, e richiede circa un'ora per essere configurato.

Dove posso trovare esempi di modelli di articoli della knowledge base?

Quattro esempi compilati si trovano nella sezione degli esempi sopra riportata e coprono FAQ, guide pratiche, risoluzione dei problemi ed errori noti. L'esercizio più utile consiste nel prendere i tuoi tre articoli più visualizzati e aggiungere a ciascuno una riga di ambito e una riga di uscita, poiché i tuoi casi limite sono specifici del tuo prodotto e nessun esempio li riporta.

Esiste un modello di FAQ gratuito in Word?

Un articolo FAQ ha bisogno di meno struttura rispetto a qualsiasi altro tipo. Domanda come intestazione, formulata esattamente come la pongono i clienti, risposta completa entro due righe e nient'altro. Se la risposta non può stare in due righe non è una FAQ, è una guida pratica o un articolo sulla risoluzione dei problemi che è stato classificato in modo errato.

Esistono modelli di articoli per Zendesk Guide?

Zendesk Guide supporta i modelli di articoli attraverso il suo sistema di temi, e i sei campi sopra descritti si mappano su di esso senza difficoltà: il titolo e le parole chiave di ricerca sono campi nativi, mentre la riga di ambito e la riga di uscita si trovano in cima al corpo. La struttura qui è indipendente dalla piattaforma di proposito, perché i team migrano da un centro assistenza all'altro più spesso di quanto si aspettino.

Esiste un modello di knowledge base HTML gratuito?

Si tratta di un elemento diverso, ovvero del sito anziché dell'articolo, ed è trattato nella sezione precedente su cosa non è questa pagina. Se hai bisogno di un centro assistenza a tema, la maggior parte delle piattaforme ne fornisce uno e la personalizzazione è un lavoro di front-end piuttosto che di scrittura.

Esiste un modello di sito web di knowledge base gratuito?

Stessa risposta. La scelta del contenitore è una decisione legata alla piattaforma, guidata dalla qualità della ricerca, dalle autorizzazioni e dal rendering mobile. Nulla in questa pagina ti aiuterà a sceglierne uno, e la struttura dell'articolo conta più per il volume dei ticket rispetto al tema.

Quanto dovrebbe essere lungo un articolo della knowledge base?

Abbastanza breve da consentire di visualizzare la risposta senza dover scorrere su un telefono. Per una FAQ, sono due righe. Per una guida pratica, meno di circa nove passaggi, e oltre questa soglia si tratta solitamente di due articoli diversi. La lunghezza non è l'obiettivo, però: l'obiettivo è che un lettore possa capire entro otto secondi se si trova nel posto giusto.

Chi dovrebbe scrivere gli articoli della knowledge base?

Chiunque abbia risolto il problema, con la revisione di chi gestisce la libreria. Gli articoli scritti da un team di documentazione a partire dal riepilogo di un ticket perdono le parole stesse del cliente, che sono le parole che il cliente successivo cercherà. L'articolo abbozzato di un agente di supporto con il titolo giusto è migliore di uno rifinito che nessuno trova.