Configuração de módulos
Knowledge base
Artigos de conhecimento que aparecem automaticamente quando se criam tickets — orientados por correspondência de classificação, de conteúdo e visibilidade de grupo.
Atualizado em 23/01/2026
Configuração · Módulos · 4.2
A knowledge base no Gfacility está concebida para que os utilizadores vejam automaticamente os artigos mais relevantes — sobretudo enquanto criam e tratam tickets. Um bom artigo pode evitar dezenas de tickets. O mecanismo assenta em regras claras: classificação, grupo e tags decidem o que aparece, para quem e por que ordem.
Porque é relevante para o negócio
"O mesmo ticket vezes sem conta"
O artigo aparece automaticamente na criação do ticket → self-service antes de o ticket existir.
"Respostas erradas às pessoas erradas"
Filtragem por grupo → externos não veem procedimentos internos, e vice-versa.
"Equipas internacionais"
Stop words filtradas em NL/EN/FR/DE/SE → o matching funciona através de fronteiras linguísticas.
"Rascunhos a passar"
Durante a criação de tickets só aparecem artigos aprovados — os rascunhos ficam ocultos.
Três campos decidem quando um artigo aparece
Classificação
Uma ou mais classificações por artigo. A correspondência com a classificação do ticket é o sinal de maior peso.
Grupo
Determina a visibilidade. Os utilizadores só veem artigos associados ao(s) seu(s) grupo(s).
Tags
Palavras-chave usadas para fazer o matching de conteúdo com o título do ticket.
Como o Gfacility escolhe um artigo
| Passo | O que acontece |
|---|---|
| 1. Correspondência de classificação | Compara a classificação do ticket com as classificações dos artigos. Sinal mais forte — topo da lista. |
| 2. Correspondência de conteúdo | Compara o título do ticket com o título do artigo, tags e nomes de classificação. Mais palavras coincidentes = pontuação mais elevada. |
| 3. Ordenação | Os artigos com correspondência de classificação aparecem primeiro, seguidos das correspondências de conteúdo. Menos relevantes = mais abaixo. |
Palavras comuns (“o”, “e”, “de”) são ignoradas automaticamente. A descrição longa de um ticket não é utilizada — o foco está no título e nas tags para maximizar a precisão.
Dois casos de uso
Na knowledge base
Os utilizadores procuram manualmente com filtros — todos os artigos publicados que podem ver.
Durante a criação de tickets
Apenas artigos com estado aprovado, visíveis para o grupo e com correspondência de conteúdo.
Que decisões irá tomar?
Que temas principais primeiro?
Comece pelos 10 tickets mais frequentes — é onde obtém maior desvio.
Que grupos veem o quê?
Parceiros externos em grupos distintos → procedimentos internos não saem.
Um artigo, várias classificações?
Sim — útil para temas transversais ("esqueci a palavra-passe" toca TI e RH).
Quem aprova os artigos?
Gate pelo estado de workflow "aprovado" — só visível durante a criação de tickets após revisão.