Support Ticket Analyser

Support teams solve valuable problems every day, but the knowledge created during those investigations is easy to lose.

An engineer resolves a difficult ticket, writes a strong customer response, and moves on. If the resolution is not captured in the knowledge base, the next person who sees the same issue has to rediscover it.

The operational problem is therefore bigger than response speed. It is how to turn solved tickets into reusable organisational knowledge before that context disappears.

I built Support Ticket Analyser to explore a repeatable loop from ticket resolution to documentation rather than treating knowledge creation as a separate task someone has to remember later.

I designed and built the workflow from documentation matching and gap detection through response drafting, KB generation, human review and Notion publishing, with Cloudflare Workers keeping API credentials outside the browser.

The workflow is designed around two users who need different things from the same support case.

Support engineers need fast access to trustworthy existing knowledge so they do not repeat investigation work unnecessarily.

Support Operations and Knowledge teams need visibility into where documentation is missing, outdated, or repeatedly recreated inside tickets.

The system therefore had to do two jobs at once: help the person handling the ticket now, while capturing a signal that improves the support system for the next person.

This project came from patterns I had seen repeatedly in technical support rather than from a hypothetical product exercise.

A solved ticket is not automatically reusable knowledge. The resolution often lives inside one conversation unless someone deliberately turns it into documentation.

Documentation gaps are operational signals. If engineers repeatedly cannot find a strong knowledge match, that tells the team where the knowledge base is failing to support the work.

Trust matters more than automation. Support engineers need to understand why a document matched, and generated content should remain reviewable before it becomes shared knowledge.

Why detect gaps instead of just generating an answer?
If AI always produces a response, a missing-documentation problem can remain invisible. I wanted the system to distinguish between "we know this" and "we solved this once but have not captured it yet."

Why keep matching deterministic?
The support engineer needs to see why an article was considered relevant. Explainable matching makes it easier to challenge false positives and tune the workflow over time.

Why use AI only for drafting?
Drafting structured support content is repetitive and well suited to AI assistance. Deciding whether the content is accurate enough to become shared knowledge still requires human judgment.

Why publish into an existing knowledge tool?
The workflow should reduce friction, not introduce another repository. Publishing to Notion demonstrates how the output can move into a system a team already uses.

The finished prototype connects ticket handling and knowledge operations in one workflow.

A support engineer can check existing documentation, understand the evidence behind a match, identify a real gap, draft a response, create a KB article, review it, and move the new knowledge into the shared repository.

The outcome I care about is not simply a faster AI-generated reply. It is a support system where useful investigation work is less likely to disappear after a ticket closes.

If this were deployed in a real support environment, I would measure:

I originally thought about this as a way to improve documentation creation.

Building it made the broader systems problem clearer: support organisations generate knowledge continuously, but most workflows are optimised for closing tickets rather than retaining what was learned.

If I continued the project, the next step would be testing the matching and review workflow with real support users. I would want to understand which gap signals are genuinely useful, when engineers trust suggested documentation, and where the workflow creates additional friction.

The goal would be to improve the feedback loop before adding more automation.