Writing Articles from Tickets

The best knowledge base article is a ticket you have already solved. When an agent closes a ticket, QueueDesk can open the article editor with that ticket's problem and fix already written in — so documenting a fix costs a few seconds of editing instead of a retype.

1. Agents Can Write Articles

Writing and publishing knowledge base articles is available to Owners, Admins and Agents. Agents get a Knowledge Base item in their sidebar and can create, edit, publish and unpublish articles — without gaining access to any other workspace settings.

There is no review or approval step. An agent who is trusted to reply to an employee is trusted to write down the answer; adding an approval queue would mostly mean articles never get written.

Employees can only read published articles. Nothing about this changes what the portal shows them.

2. From the Close Dialog

When an agent closes a ticket, the close dialog has a checkbox:

Also write a knowledge base article — Opens the editor with this ticket filled in. Internal notes are left out. Nothing publishes until you save it.

It is off by default and does not remember your last choice — most closures do not deserve an article, and a checkbox that remembered "yes" would quietly fill the knowledge base with one-offs.

Tick it, close the ticket, and the article editor opens pre-filled. The ticket closes first: if the close fails, you are never left writing an article about a still-open ticket.

3. From an Already-Closed Ticket

Not every ticket closes through that dialog — some are closed in bulk from the queue, some by automation. On any resolved or closed ticket, the More menu has Write KB article, which does exactly the same thing.

4. What Gets Pre-Filled

The draft is built from the ticket, free of charge and with no AI involved:

•Title from the ticket subject

•Category from the ticket's category, where it maps to one you already use

•Body from the description, the public conversation, and the resolution notes

Internal notes are never included. Neither are AI confidence scores or triage reasoning — the draft is built only from what the employee could already see, so a private note about a colleague or a system cannot leak into an employee-facing article.

The editor also shows which ticket the draft came from, so you can open the original while you edit.

5. Rewriting It with QueAssist

The pre-filled draft reads like a ticket, because it is one. To turn it into an article, click Write with AI in the editor toolbar: QueAssist rewrites the same source material into a clean problem/cause/resolution article with proper headings and steps.

•Costs 1 AI action from your monthly quota — see QueAssist Settings & Usage Quota.

•Optional. The free deterministic draft is perfectly publishable after a manual tidy-up.

•Replaces the body only. Your title and category edits survive, and Cmd/Ctrl+Z undoes it.

If your workspace is out of AI actions, the button reports it and the draft is left untouched.

6. Saving and Publishing

The pre-filled editor is exactly the editor described in Knowledge Base — same formatting toolbar, image upload, embeds and preview.

Nothing is saved or published until you save it. Articles start as Draft, so you can leave a half-written article and come back to it without employees ever seeing it. Flip it to Published when it is ready.

Once published, the article is searchable in /portal → Knowledge Base and immediately becomes grounding material for QueAssist's agentic auto-resolution — so the next employee with the same problem may never need to raise a ticket at all.

7. Seeing Who Wrote What

The article list in Settings → Knowledge Base shows the author of every article alongside its category and status, so you can tell which agents are documenting their fixes.

Next, read QueAssist Settings & Usage Quota to see how AI actions are metered across your workspace.