Knowledge Base Gap Search

The AI agent regularly scans the stream of customer requests in the helpdesk and matches them against the current knowledge base content. The result is a list of topics that customers ask about but where documentation is missing or outdated. The support team gets a prioritized article backlog and ready-made drafts instead of the abstract feeling of 'we need to update the KB'.

Automation turns the repetitive audit work into a background process that runs on a schedule. The team's focus shifts from finding gaps to reviewing and refining the content that customers actually need right now. This is especially noticeable in SaaS products, where the pace of releases outpaces the pace of documentation updates.

The key difference from a manual audit is regularity. The team does not search for gaps once a quarter when someone remembers the KB. The AI agent runs continuously and raises a flag as soon as a new topic reaches a critical volume of requests. This eliminates the drift between customer reality and documentation content.

What automation does, step by step

1. Collects tickets, chats, and calls from the helpdesk for a specified period — a day, a week, or a quarter.
2. Filters out operational requests (billing, access, bugs), leaving content-related topics for analysis.
3. Normalizes the data: removes personal information and brings it to a unified format.
4. Groups requests by topic using clustering — similar questions are placed in the same group.
5. For each topic, extracts the key intent: what exactly the customer wanted to learn or solve.
6. Searches for a matching article in the knowledge base CMS by title, content, tags, and metadata.
7. Evaluates topic coverage: whether an article exists, whether it is sufficiently complete, and whether it is outdated.
8. Generates a list of gaps, ordered by request frequency and business priority.
9. Generates an article draft based on real customer conversations and support agent responses.
10. Sends the draft to the responsible editor via the knowledge manager or a review ticket.

What automation does not do

• Does not publish articles without human review — drafts always go through an editor and a product expert.
• Does not replace the product knowledge of support agents: the AI agent relies on existing answers in tickets, not on invented ones.
• Does not resolve the problem of outdated articles automatically — it identifies candidates for updating, but the decision to rewrite remains with the team.

The automation is built as custom-code using an LLM with integration into helpdesk and knowledge base CMS. Runs on a schedule — once a day or week depending on ticket volume. The architecture is divided into three layers: data collection, analysis, and artifact generation.

Technical flow

1. Data extraction. The worker retrieves closed tickets from helpdesk via API for the selected period. Fields: subject, description, correspondence, category, CSAT, close date.
2. Cleaning and anonymization. The script removes PII (names, addresses, numbers), normalizes the text, and splits it into chunks for processing.
3. Ticket clustering. Embeddings via a text-embedding model, grouping by cosine similarity. Output — topics with ticket counts and average CSAT.
4. Knowledge base search. For each topic, a query to the CMS via API or RAG on top of the article export. Returns the top-3 candidates by relevance.
5. Coverage assessment. The LLM analyzes the topic and retrieved articles, and outputs a verdict: covered, partially covered, gap, outdated.
6. Prioritization. Ranking by formula: ticket frequency × negative CSAT × absence of coverage.
7. Draft generation. The LLM creates an article structure based on real conversations and sample agent responses.
8. Delivery. The draft lands in the CMS as a draft or in the ticket tracker as a task for the knowledge manager.

Step-by-step implementation

1. Deploy the worker in the cloud (AWS Lambda, Cloud Run, or a self-hosted container).
2. Configure API access to helpdesk and CMS, prepare a service user with the required permissions.
3. Collect a historical ticket sample covering 3-6 months to calibrate clustering.
4. Index the current knowledge base — export articles and build the vector index.
5. Configure prompts for the LLM: coverage assessment, draft generation, formatting.
6. Test on historical data, compare the results against a manual team audit.
7. Run a pilot on one product or ticket category.
8. Expand to the full base after validating draft quality.

Solution components

For the first version, a minimal stack is sufficient: scheduler, ticket collection script, LLM call for clustering and assessment, a simple dashboard or email distribution of drafts. Complex optimizations — editor feedback loop, continuous learning on accepted drafts — are added after the pilot.

Result quality depends on how cleanly ticket categories are labeled in the helpdesk. If categorization is chaotic, the first step is to agree on a taxonomy with the support team before launching the pilot.

To launch automation, the team needs access to the systems and a minimum level of knowledge base readiness.

Data and access

• API access to the helpdesk with read permission for tickets from the last 3-6 months.
• API access or knowledge base export from the CMS: titles, content, tags, update dates.
• A service account with permission to create drafts in the CMS or create tasks in the ticket tracker.
• A deployment environment for the worker: cloud or internal infrastructure.
• LLM provider keys.

Team readiness

• A designated knowledge manager or editor who accepts drafts and takes them through to publication.
• An agreed-upon taxonomy of helpdesk ticket categories — without a clean tag structure, the output will be noisy.
• A review rule: who checks the generated draft before publication and within what timeframe.
• Product expertise is available to clarify technical details in articles.

Timelines

A pilot with one product or category — 2-4 weeks. Includes API integration, knowledge base indexing, prompt configuration, and validation on historical data. Expansion to the full knowledge base — an additional 1-2 weeks after the pilot. Timelines increase if ticket categorization in the helpdesk requires preliminary cleanup.