Turn Fixed Tickets Into a Searchable AI Knowledge Base

Export resolved tickets from your help desk or PSA, keep the recurring issues, strip passwords and personal details, and have AI group the tickets by root cause. Draft one article per problem from a fixed template, get a technician to test each fix, and publish where technicians already search, ideally your help desk's knowledge base with AI search on.

The drafting is the easy part. Ticket notes are messy: the real fix is often in the last line after three failed attempts, one technician's "fixed" is another's workaround, and the notes are full of admin passwords, IP addresses and staff names. Most of the effort goes into choosing, cleaning and testing, and that effort is what makes the result trustworthy enough for a technician to follow at 8am with a client on the phone.

Follow me on Instagram@sagnikteaches

Choose the tickets worth an article

Not every fixed ticket deserves an article. A one-off hardware failure teaches nothing reusable. Use rules like these, and adjust the thresholds to your volume:

Connect on LinkedInSagnik Bhattacharya

Most PSAs let you export closed tickets with category, client, subject, description, all notes, time logged and resolution. Export 12 months if you can; seasonal problems, such as year-end software updates, only show up over a full year.

Subscribe on YouTube@codingliquids

The thresholds scale with volume. A one-person shop closing 400 tickets a year averages about 100 a quarter, so "three times in 90 days" may leave only a handful of clusters. Loosen it to "twice in six months" and lean on the time rule instead: a 90-minute fix you've done twice is worth writing up even if it never comes back a third time.

Then check how many tickets actually record a fix. Filter the export for resolution notes under ten words ("fixed", "resolved remotely", "sorted, user happy"); in an illustrative export of 1,800 tickets, say 300 turn up. Those tickets still count towards a cluster's size, which tells you what recurs, but they can't supply steps. Set them aside, and for any cluster where most tickets look like that, ask the technician who closed the most of them to write the fix from memory in the template format below, then test it on the next occurrence.

Clean the export before any AI sees it

Redaction comes before clustering, not after. Once sensitive notes are in a chat or a knowledge base, you've lost control of where they end up. Replace, don't just delete, so the notes still make sense:

• Passwords, PINs, recovery keys, MFA codes: [CREDENTIAL]
• IP addresses, hostnames, serial numbers: [IP], [HOST], [SERIAL]
• People's names and email addresses: [USER], [CLIENT CONTACT]
• Client company names: a client code, kept in a separate lookup

A before and after on one ticket note, illustrative:

Before: "Rang [first name] at the main shop, till 2 receipt printer offline again. RDP to 192.168.10.24, local admin pw Summer2025!, printer showing in devices but spooler stuck. Restarted spooler, no joy. Reinstalled driver 3.1 from vendor site, working. [first name] happy."

After: "Called [USER] at [CLIENT-DL] site 2, till 2 receipt printer offline again. Remote session to [IP], signed in with local admin [CREDENTIAL], printer visible in devices but print spooler stuck. Restarted spooler: no change. Reinstalled printer driver version 3.1 from the manufacturer's site: working."

Do a first pass with pattern-matching, such as find-and-replace for IP formats and known password fields, then a second pass with an AI prompt that lists anything that still looks sensitive, then a human skim of a sample. The approach for documents generally is in redacting personal data with AI before sharing. Use a business AI plan where content isn't used for training by default, even for the redacted file.

The second-pass prompt can be short. Paste a batch of 50 redacted notes and ask:

Below are IT ticket notes that have already been redacted. List every
remaining item that could identify a person or company, or that would
let someone sign in to anything. Quote the item, give the ticket ID and
say why. Don't rewrite the notes.

An illustrative reply on a batch from the delicatessen client:

"T-2231: 'guest wifi key is deli2shops' is a network passphrase. T-2240: a mobile number inside a pasted email signature. T-2258: a 25-character product key for the till software. T-2263: a laptop hostname built from a staff member's first name."

All four were real misses. The pattern pass looked for IP formats and fields labelled "password", so a passphrase written in plain words, a phone number in a signature and a licence key slipped through. Add a pattern for each and rerun. Hostnames made from staff names are common, so replace every hostname with [HOST] as a rule. Expect the model to over-flag as well: it may list "till 2" or a printer model as sensitive, and those can stay, because the article needs them.

Cluster by root cause, not by symptom

Users report symptoms; articles should solve causes. "Outlook won't open" might be a corrupt profile, a licence that lapsed or a full mailbox. Ask the model to group tickets by what fixed them:

These are redacted, resolved IT tickets. Group them into clusters by the
ROOT CAUSE that the final successful step fixed, not by the user's
description. For each cluster give: a short name, the ticket IDs,
the count, the successful fix in one line, and any tickets you're unsure
about. Don't merge clusters whose successful fixes differ.

An illustrative extract of the reply for a small MSP whose clients include a three-shop delicatessen:

What you would fix: the Outlook cluster contains two causes. Sixteen tickets were cached credentials; six were licences that had lapsed after a billing change. Split them. The prompt told the model not to merge clusters with different fixes, and it partly obeyed by mentioning the licence tickets, which is why you read the "unsure" list and the fix column carefully rather than accepting the counts.

Draft every article from the same template

A fixed template makes articles scannable and makes gaps obvious. Here is one filled in from the printer cluster:

TITLE: Receipt printer offline on tills after a Windows update
APPLIES TO: [CLIENT-DL] tills 1-3, all sites; receipt printer model [X]
SYMPTOMS: printer shows in Devices but won't print; queue stuck;
  started after a Windows update
CAUSE: the update replaces the manufacturer's driver with a generic one
FIX:
  1. Remote to the till; sign in with the till admin account
     (credential in the password manager, entry "DL tills").
  2. Restart the Print Spooler service. If printing works, stop here.
  3. Uninstall the printer. Install driver 3.1 from the manufacturer's
     download page. Print a test receipt.
  4. In the RMM policy for "DL tills", confirm driver updates are
     excluded from Windows Update.
CHECK IT WORKED: test receipt prints; ask the shop to run one sale
ESCALATE IF: the printer isn't visible in Devices at all (likely cable
  or hardware; book a site visit)
TIME TO FIX: 10-15 minutes
LAST VERIFIED: 3 Oct 2026 by [tech initials]   SOURCE TICKETS: 14

Ask the model to draft each article from its cluster's tickets and this template, with one rule: "Use only steps that appear in the successful resolutions. If the tickets disagree, list both versions and flag it." Note that the credential lives in the password manager, referenced by entry name, never in the article.

Watch for near-duplicates when several clients share a problem. Drafting per cluster can produce "Outlook password loop" three times, once for each client whose tickets happened to cluster separately. Keep one article with an APPLIES TO line covering all three, plus a short client note where the steps genuinely differ (one client signs in through a different portal, say). Three copies means three places to update when the sign-in screen changes, and two of them will be forgotten.

Technician review: test the fix, then date it

Every article needs a technician's sign-off before publishing, ideally someone who has fixed that issue. They check the steps in order, remove anything that was a failed attempt dressed up as a step, and add the "check it worked" and "escalate if" lines, which tickets rarely contain. Budget about 15 minutes per article.

A realistic mistake shows why this matters. In one illustrative cluster about a line-of-business app failing to connect, the AI draft included "temporarily disable the firewall rule for the app" as step 2, because one technician had done that as a test months earlier and noted it. It wasn't part of the fix; it was a diagnostic that got reverted. Published as written, it would have become the step junior technicians followed, leaving client machines exposed. The reviewer deleted it and added a warning line.

The "last verified" date matters as much as the steps. Set a review interval, for instance six months, and treat anything older as unverified.

Make it searchable: three setups compared

For most small MSPs, the first option is best, because technicians already live in the PSA and the article shows up where it's needed. The general question of which knowledge-base option suits a small business is covered in AI knowledge base options compared, and the principles of structuring content AI can answer from are in building a company knowledge base AI can answer from.

Whichever you pick, test retrieval with the words technicians and users actually type, not the article titles. Pull ten ticket subjects from last month, such as "till not printing", "receipts coming out blank", "outlook password popup" and "card machine offline", search each one, and check the right article appears in the top three results. In an illustrative first run, seven of ten hit. The misses usually come down to vocabulary: users say "card machine", the article says "payment terminal". Add a SEARCH TERMS line to the template listing the everyday names for the problem and the kit, rerun the ten, and repeat each quarter with fresh subjects.

Turning a technician article into a client-facing one

Once an internal article has been used successfully a few times, some fixes can go into the client portal so users try them before raising a ticket. The client version keeps only what a user can safely do, in plain words, and ends with how to get help. Ask the AI to rewrite from the internal article with those rules, then check it. For the Outlook password prompts cluster, an illustrative result:

Outlook keeps asking for your password

1. Close Outlook completely, including from the system tray.
2. Open Outlook again and sign in once with your usual work password.
3. If it asks again within a few minutes, don't keep typing your password. Raise a ticket with the subject "Outlook password loop" so we can check your account.

Never share your password with anyone who calls or emails you, including us. We will never ask for it.

Compare that with the internal article, which covers clearing cached credentials and checking licence assignment in the admin centre. Neither of those belongs in front of a user. The last line of the client version is deliberate: every client-facing article is a chance to repeat the rule that stops password-phishing calls working.

A small MSP's year of tickets, start to finish

An illustrative four-technician MSP exports 1,800 closed tickets from the past 12 months. Applying the selection rules leaves 640 tickets. Clustering produces 71 clusters, of which 60 are worth an article after splitting and merging.

• Export and first-pass redaction: 5 hours
• AI clustering plus checking the unsure lists: 3 hours
• AI drafting of 60 articles: 4 hours of prompting and tidying
• Technician review at 15 minutes each: 15 hours, spread over a month

That's about 27 hours in total. The payback question is simple: if those 60 clusters generate around 50 tickets a month between them and a tested article saves 10 minutes on each, that's about eight hours a month back, and newer technicians need to escalate less. Your figures will differ; measure them.

Keep it alive with a weekly loop

A knowledge base built once and left alone goes stale within a year. Two habits keep it current. First, change how technicians write resolution notes, so future tickets arrive in article-ready form. A filled-in example of the note format:

CAUSE: shared mailbox permission removed during licence change
FIX: re-added Full Access in admin centre; mailbox appeared after
  about 30 minutes
ARTICLE: KB-031 (steps still correct)

Second, every Monday, ask the AI to compare last week's resolved tickets with existing articles: "Which of these tickets match an existing article? Which suggest a new cluster? Which contradict an article's steps?" Contradictions are gold, because they usually mean a vendor changed something. An illustrative reply from one Monday check:

"Matches existing articles: 31 tickets (KB-004 x9, KB-031 x6, others single). Possible new cluster: 4 tickets where Teams opened to a blank white window after an update, fixed by clearing the Teams cache. Contradiction: T-4471 followed KB-031, but the shared mailbox still hadn't appeared after an hour; the technician removed and re-added the account in Outlook."

Act on the contradiction, but carefully. It could mean KB-031 needs an extra step, or it could be a one-off. Check the next two shared-mailbox tickets before rewriting; if either needs the same step, add it as step 4 ("if the mailbox hasn't appeared after 30 minutes…") and reset the last-verified date. Don't let the AI edit articles directly from a single ticket, because one ticket is thin evidence. The Teams cluster joins the drafting queue once it reaches your recurrence threshold.

Measure three numbers monthly: the share of tickets with a linked article, median resolution time for clustered issues, and the number of articles past their review date. If the first two improve and the third stays low, the knowledge base is working. For using AI at the ticket-resolution stage itself, see how small IT support businesses resolve tickets faster.

Knowledge base questions from IT support teams

Should the knowledge base be internal, client-facing or both?

Start internal. Technician articles can include admin steps, tool names and escalation notes that clients shouldn't follow. Once an internal article has been used successfully several times, write a short client-facing version covering only the steps a user can safely do, and link the two so a fix to one prompts a review of the other.

How many articles do we need before it's useful?

Fewer than you'd think. A few dozen articles covering your most frequent problems usually cover a large share of repeat tickets, because IT support demand is lopsided: the same handful of issues come back every week. Start with the top 20 clusters by ticket count and measure before writing more.

Can the AI just answer from the raw tickets without writing articles?

It can search them, and some help desks suggest similar past tickets automatically. The trouble is that raw tickets contain failed attempts, wrong guesses and sensitive details alongside the real fix. An AI answering from them will sometimes repeat the failed attempt. Curated articles are slower to build but give technicians and clients answers you've actually tested.

Further reads

• Best AI Help Desk Tools for Small MSPs (2026) — Compare the help desks whose AI can host this knowledge.
• How to Deflect Password Resets and Routine Requests With AI — Use the new articles to deflect routine requests.
• AI Ticket Triage: Tag, Route, and Prioritise Support Requests — Route incoming tickets to the right article and technician.
• How MSPs Use AI to Write Quarterly Business Reviews — Turn ticket clusters into insight for client reviews.
• Is AI Ticket Automation Worth It for a Small IT Support Shop? — Check whether wider ticket automation pays for your shop.
• How to Write SOPs With AI: From Rough Notes to Clear Procedures — The same drafting method for internal procedures.
• Reusing Past Client Work With AI Without Leaking Client Data — How consultants and small firms turn old client reports into a reusable AI library: contract checks, three reuse tiers, sanitising, and access controls.
• How to Turn Support Tickets Into Help Centre Articles With AI — Export solved tickets, redact them, let AI group the real questions, score which deserve an article, then draft and fact-check each one.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Freshservice support pages on Freddy AI Copilot (solution articles from tickets); Atera support pages on AI Copilot; ConnectWise Sidekick for PSA page; Kaseya Cooper Copilot help pages (Smart Resolution Summary); Google help page on Gemini Notebook.