Turn every fixed ticket into a knowledge article

How to do it

1. 1

   Close the ticket with a closing reply that says what you did.

   Write at least 300 characters in plain words: what was wrong, what you changed, and that it works now. A one line "fixed it" makes no draft. The ticket also needs at least two replies. The full click path is in How to close a ticket and approve the article it drafts.

2. 2

   Watch for the KB draft ready notice.

   You get a bell notice titled KB draft ready with the ticket number. It links to Elise, Review, KB Review. A fix with three or more steps goes to Procedure Review instead. So does a ticket about onboarding, offboarding or migration. One close makes one draft, never both.

3. 3

   Accept it, edit and accept it, or reject it.

   Accept it as written when it is true and a tech could follow it. Choose Edit & accept when the fix is right but the title, body or tags need a tweak. Choose Reject for a one-off that nobody will hit again. Reject keeps it out of the knowledge base. An accepted article is saved as Approved right away, with no separate publish step.

4. 4

   Check who can see the new article.

   A new article starts hidden from the client portal and not marked internal. Pick one. Leave it hidden, turn on MSP Only so it is for your techs alone, or share it. To share with just a few people, use Visible to specific users and Add User.

5. 5

   Share only what you would say to the client's face.

   A restart guide for the front desk PC suits the client's own staff, so share it. A note with a password, a network detail or a mistake the client made stays on MSP Only. MSP Only always wins over the other two choices. The Choose which passwords and documents each client can see guide shows the lock icon and the Shared chip that tell you each row's exposure at a glance.

6. 6

   Check that it landed.

   Open the client's page, then Documentation, then Knowledge Base. The article shows AI Suggested and Approved. A draft nobody has decided yet shows as a Draft / proposed row in the same list, so you can finish it there.

The pages behind each click

• How to close a ticket and approve the article it drafts →
• How to document a client from one tab →
• Choose which passwords and documents each client can see →

What you will have

• Write a closing reply that lets GoTenix draft an article for you.
• Know when to accept a draft, edit it first, or turn it down.
• Choose whether the article is for your techs only or for the client too.
• Make it a quick habit for every ticket.

Why it works this way: Turn every fixed ticket into a knowledge article

Other ways to do this: Turn every fixed ticket into a knowledge article

If it did not work: Turn every fixed ticket into a knowledge article

• If no draft appears, check three tests. You need two replies. The closing reply needs 300 characters. It must not read like a throwaway close, such as duplicate, spam, user error or no action.
• If the ticket was merged, no draft is made. The same goes if it already has an article or a draft.
• If the draft is missing from KB Review, look in Procedure Review. A fix that reads as an ordered sequence goes there.
• If no AI is connected, the close still works and there is no draft to review.

Keep digging

• Turn on AI safely: set a cap, hide data, keep control
• What GoTenix runs itself and what it connects to
• Run security training for every client, every year
• How to give each client its own report on a schedule