Documentazione e knowledge base

Cosa copre questa categoria

Luoghi dove mettere le cose per iscritto perché altre persone possano trovarle: centri assistenza rivolti ai clienti, manuali interni, documentazione per sviluppatori e la ricerca che rende utile tutto questo.

La distinzione che conta è il pubblico. La documentazione per i clienti richiede un indirizzo pubblico, un processo di revisione e un linguaggio scritto per qualcuno che è già bloccato. La documentazione per il personale può essere più disordinata e ha bisogno di permessi.

La conoscenza personale e di piccoli team appartiene a note e wiki. La coda di ticket in cui arrivano le domande senza risposta è assistenza clienti.

La struttura decide se qualcosa viene trovato

Ogni progetto di documentazione inizia ordinato e finisce come un mucchio. Gli strumenti o rallentano questo processo o lo accelerano.

Guarda come funziona la gerarchia: categorie, sottopagine, collegamenti incrociati e se una pagina può stare in due posti senza essere duplicata. Poi guarda cosa succede a trecento pagine, che è dove la navigazione pensata per trenta crolla.

La ricerca è la prova onesta. Prova una query con le parole che userebbe un cliente e non con il tuo vocabolario interno. I prodotti che trovano corrispondenze solo nei titoli falliranno questa prova, e i lettori finiranno nella tua coda di assistenza.

Tag e suggerimenti di articoli correlati aiutano quando sono mantenuti. Nessuno li mantiene a mano a lungo, quindi preferisci prodotti che generano i collegamenti dal contenuto.

Scrivere, rivedere e mantenere vere le pagine

La documentazione marcisce in silenzio. Una pagina che era corretta a marzo è un ticket a settembre, e nulla in essa sembra sbagliato.

I prodotti utili portano con sé responsabile, date di revisione e un timbro dell’ultimo controllo che il lettore può vedere. Gli stati di bozza e il flusso di revisione contano quando scrivono più di due persone, e la cronologia delle versioni conta la prima volta che qualcuno chiede cosa dicesse una pagina prima del cambiamento.

Vale la pena controllare anche il riuso. Un limite, un prezzo o un elenco di versioni supportate dovrebbe esistere una volta ed essere incluso ovunque compaia, e non incollato in undici pagine che entro il prossimo trimestre si contraddiranno.

Pubblicazione e il tema della ricerca

Un centro assistenza pubblico è un sito web e dovrebbe comportarsi come tale.

• URL puliti che sopravvivono alla riorganizzazione, con redirect quando non ci riescono.
• Titoli e descrizioni modificabili per ogni articolo, non generati dalla prima riga.
• Pagine veloci, senza un’applicazione pesante che si carica prima che compaia il testo.
• Sitemap che si aggiornano quando pubblichi e non secondo una pianificazione che nessuno ricorda.
• Un dominio personalizzato, così il materiale costruisce autorevolezza per il tuo sito e non per quello del fornitore.

Quest’ultimo punto vale la pena di sostenerlo internamente. La documentazione è spesso il contenuto con le migliori prestazioni di un’azienda di software, e ospitarla su un sottodominio del fornitore regala quel traffico.

Misurazione, e l’unica metrica che conta

Le visualizzazioni di pagina non dicono quasi nulla. Due numeri dicono molto.

Il primo sono le ricerche che non hanno restituito un risultato utile, che è un elenco scritto di cosa creare dopo. Il secondo è se i lettori che hanno aperto un articolo hanno comunque contattato l’assistenza, il che richiede di collegare il centro assistenza al sistema di ticket.

Riscrivi a partire da quell’elenco e non da un’opinione. I cinque articoli che falliscono più spesso meritano più attenzione di cinquanta che nessuno visita.

Come sono prezzati questi prodotti

Utenti per gli autori, a volte lettura gratuita per tutti, a volte per lettore interno registrato. I centri assistenza pubblici di solito addebitano per autore e per volume di articoli, le wiki interne per utente.

Attenzione a tre confini. Domini personalizzati, versionamento e single sign-on tendono ciascuno a stare un livello sopra il piano di ingresso. La profondità delle statistiche è un quarto. I fornitori che includono un centro assistenza con un prodotto di supporto spesso lo prezzano come componente aggiuntivo invece di includerlo, ed è una delle abitudini raccolte in cosa nascondono le pagine dei prezzi.

Prima di impegnarti, esporta tutto e leggi il risultato. Markdown o markup pulito significa che puoi andartene. Un formato proprietario significa che l’archivio è in ostaggio.

Avviare un centro assistenza da zero

La prima versione dovrebbe essere imbarazzantemente piccola.

Prendi le venti domande che la tua coda di assistenza riceve più spesso e rispondi bene. Copre la maggior parte dei contatti e richiede una settimana, mentre pianificare prima una struttura completa richiede un trimestre e nel frattempo non risponde a nulla.

Scrivi ogni articolo per qualcuno che è già bloccato, cioè prima la risposta e poi la spiegazione. Gli screenshot invecchiano male, quindi usali dove aiutano davvero e metti in conto di sostituirli.

Poi lascia emergere la struttura. Dopo trenta articoli le categorie diventano ovvie, e imporle all’articolo cinque significa riorganizzare comunque.

Pubblica come coda di scrittura i termini di ricerca che non hanno restituito nulla. È l’unico piano editoriale di questa categoria che non finisce mai e non sbaglia mai.