Knowledge Assistant

Knowledge Assistant

The assistant reads the tickets your service desk has already closed and tells you what your knowledge base is missing. Then it writes the first draft.

It lives at Knowledge → Assistant, and there is a second way in from a solved ticket (see From a ticket below).

---

The problem it solves

Every service desk answers the same questions over and over without writing them down. Not through laziness — because no single ticket ever feels big enough to be worth an article. You fix the shared mailbox for the eleventh time, close it, and move on, and nobody ever stands back and notices it was the eleventh time.

The assistant is the thing that stands back.

I read 340 closed tickets from the last 90 days. Your knowledge base is missing six things.

Each of the six is a question your desk has genuinely answered several times, with nothing in the knowledge base that covers it:

Cannot open shared mailbox in Outlook — asked 14 times · 3 May – 22 July

You can expand any of them and see the fourteen tickets, so you are never asked to take the assistant's word for it.

---

Why it is allowed to say no

This is the most important thing to understand about the feature, and the reason it is built the way it is.

A ticket that reads "reset the user's password and asked them to log in again" is not an article. It records an action. It says nothing about why the account locked, how that was worked out, or what anyone should do next time.

An assistant that cheerfully turned that into an article would fill your knowledge base with padding. That is worse than an empty knowledge base: people search it, find something useless, and learn that searching is a waste of time. Deflection goes backwards.

So the assistant's first job is to refuse. It reads the ticket and decides whether there is an article in it at all. It is looking for at least two of:

• what actually caused the problem, not just what was done about it
• how the cause was identified — the diagnostic step, the error, the log line
• the specific fix, in enough detail that somebody else could repeat it
• how to confirm it worked, or how to stop it happening again

If it cannot find them, it says so, plainly.

A refusal is not a dead end

When it refuses, it asks you two to four specific questions about that ticket — not a generic form:

There is not enough here to write from. The ticket describes the resolution but not the cause or how it was diagnosed.

• What was the exact error message in the backup job log?
• How was it determined that the backup target was out of disk space?
• What was the capacity before and after archiving?
• Were other options considered before archiving to tape?

Answer what you can in the boxes, press Try again, and it writes the article from your answers. It treats them as authoritative — you were there and it was not — even where they contradict its reading of the thread.

This is the part that makes the feature work in practice. The analyst who wrote one line will happily type three sentences into a box. Thirty seconds, and now there genuinely is an article.

---

What it drafts from

When a group of tickets is written up, the assistant always drafts from the most detailed ticket in the group, never the newest.

That split is deliberate and it is the whole design:

• the thin tickets prove the question is worth answering — that is what the count is
• one good ticket supplies the answer

So the eleven two-line "shared mailbox not working" tickets are what earns the article, and the one where somebody actually explained the permissions fix is what it is written from.

What comes out

Articles are structured as symptom → cause → resolution → how to check it worked, with any section the tickets cannot support left out rather than padded.

Names, email addresses, phone numbers, job titles, individual machine names, IP addresses, ticket references and company names are stripped. Knowledge articles get published to a portal your customers can read, so the draft is written for that from the start. Product names, error messages, version numbers and file paths are kept — those are the entire point.

Nothing is published automatically

Every draft is saved to your knowledge base unpublished.

• It appears in your article list with a Draft badge, so it is easy to find and finish.
• It is not visible on the self-service portal, in the web chat widget, or to the AI answers — every one of those requires a published article.
• You read it, edit it, and publish it when you are happy.

Once you publish, that gap stops being reported.

---

The three states

State	What it means
To write	A recurring question with no article. The assistant is suggesting you write one.
Written	You drafted an article from it. Links straight to the article, and says if it is still a draft.
Not needed	You decided this does not want an article.

Not needed is a real decision, not a snooze. Plenty of recurring questions genuinely should not become articles — a weekly report request, a door that needs a facilities visit. Once marked, it stays gone even as more tickets pile into it. Bring back undoes it if you change your mind.

---

From a ticket

You do not have to wait for the assistant to notice. Finish a ticket and a Write up button appears in the ticket's action bar.

It runs exactly the same judgement, refusal and questions — so most of the time on a routine ticket it will tell you there is nothing to write, which is the correct answer. Use it when you have just solved something genuinely awkward and it is fresh in your head.

The button only appears when:

• the ticket is in a closed status — writing up a problem nobody has finished solving produces a half-true article
• you have access to the Knowledge module — it saves an article, so a tickets-only analyst never sees it

---

Settings

Knowledge → Settings → AI, under Assistant.

Setting	Default	What it does
Ask the same question this many times	3	How often a question must come round before the assistant mentions it. Lower it on a small desk where anything asked twice is worth writing down; raise it on a busy one.
How far back to read	90 days	Older than this and the answer has usually changed anyway.
How close an existing article must be to count as covering a ticket	0.75	Higher is stricter, so more tickets count as gaps.
How alike two tickets must be to count as the same question	0.82	Higher makes tighter groups. Too low and unrelated tickets get lumped together.

The last two only apply when an OpenAI key is set — see below.

Finding the gaps does not need an AI budget

The assistant runs in one of two modes, and it tells you which:

• Matching on meaning — with an OpenAI key set (the same one Knowledge already uses for search), it compares what tickets and articles are actually about. Better, and it costs a small amount per ticket, once.
• Matching on wording — with no key at all, it compares the words in ticket subjects. Cruder, free, and still perfectly capable of telling you that you have answered "printer on the second floor keeps jamming" eleven times.

Only drafting needs a language model, and it reuses the Knowledge AI provider and key you have already set up rather than asking for a second one. You can give it its own key if you want its spend on a separate line.

---

Who can do what

Action	Needs
See the findings, draft, dismiss	Knowledge module access
Run Look for gaps	Knowledge module access + the Manage embeddings capability (it spends money)
Change the settings above	Knowledge module access + the AI settings capability

Everything is scoped to your active company, exactly like the ticket list it is derived from. A recurring question in a company you cannot see is never reported to you.

---

Before you start

The assistant needs three new database tables. Run System → Database Verification once after updating. Until you do, the page loads and simply says it has nothing to show — it will not break the Knowledge module.

---

See also

• Knowledge Base — the module itself
• Knowledge Assistant Developer Guide — how it works underneath
• AI Providers — configuring providers, models and keys