Configurazione moduli
Base di conoscenza
Articoli della base di conoscenza che emergono automaticamente durante la creazione dei ticket — guidati dal match di classificazione, dal match di contenuto e dalla visibilità di gruppo.
Aggiornato il 23 gen 2026
Configurazione · Moduli · 4.2
La base di conoscenza in Gfacility è impostata in modo che gli utenti vedano automaticamente gli articoli più rilevanti — soprattutto durante la creazione e la gestione dei ticket. Un buon articolo può evitare decine di ticket. Il meccanismo si basa su regole chiare: classificazione, gruppo e tag decidono cosa appare, per chi e in quale ordine.
Perché è importante per il business
"Lo stesso ticket ripetutamente"
L'articolo appare automaticamente quando si crea un ticket → self-service prima che il ticket esista.
"Risposte sbagliate alle persone sbagliate"
Filtro di gruppo → gli esterni non vedono le procedure interne, e viceversa.
"Team internazionali"
Stop word filtrate in NL/EN/FR/DE/SE → il matching funziona oltre le barriere linguistiche.
"Articoli in bozza che trapelano"
Durante la creazione del ticket appaiono solo gli articoli approvati — le bozze restano nascoste.
Tre campi decidono quando un articolo appare
Classificazione
Una o più classificazioni per articolo. Il match con la classificazione del ticket ha il peso maggiore.
Gruppo
Determina la visibilità. Gli utenti vedono solo gli articoli collegati al loro gruppo o gruppi.
Tag
Parole chiave usate per confrontare il contenuto con il titolo del ticket.
Come Gfacility sceglie un articolo
| Passo | Cosa succede |
|---|---|
| 1. Match di classificazione | Confronta la classificazione del ticket con quelle degli articoli. Segnale più forte — in cima alla lista. |
| 2. Match di contenuto | Confronta il titolo del ticket con il titolo dell'articolo, i tag e i nomi delle classificazioni. Più parole corrispondenti = punteggio più alto. |
| 3. Ordinamento | Gli articoli con match di classificazione vengono per primi, poi i match di contenuto. Meno rilevante = più in basso. |
Le parole comuni (“il”, “e”, “di”) vengono ignorate automaticamente. La descrizione lunga di un ticket non viene usata — l’attenzione resta sul titolo e sui tag per la massima precisione.
Due casi d’uso
Nella base di conoscenza
Gli utenti cercano manualmente con i filtri — tutti gli articoli pubblicati che hanno il permesso di vedere.
Durante la creazione del ticket
Solo articoli con stato approvato, visibili al gruppo e con match di contenuto.
Quali decisioni dovrà prendere?
Quali topic prioritari per primi?
Inizi dai 10 ticket più frequenti — è lì che ottiene la massima deflection.
Quali gruppi vedono cosa?
Partner esterni in gruppi separati → nessuna procedura interna trapela.
Un articolo, più classificazioni?
Sì — utile per topic trasversali alle categorie ("password dimenticata" tocca IT e HR).
Chi approva gli articoli?
Gate sullo stato di workflow "approvato" — visibile durante la creazione del ticket solo dopo la revisione.