AI Generated Documents from Bulk Tickets

The Bulk Tickets tab of the AI Generated Documents window allows you to see and choose tickets that were clustered together during the Knowledge Generation job.

The Bulk tab includes the following Filter Options:

Search: The system will allow users to search for 'Knowledge Clusters' or 'Knowledge Documents' (both have the similar names). You can input the desired knowledge cluster or document name to retrieve relevant results. If no search result found, the application displays the message, No results found under the Knowledge Document section.

Job Run Drop down Filter option:  This option should be enabled by default with the latest job run. It has the list of last job runs that are executed. Users will have an option to choose the job run and the corresponding clusters should get displayed in the ‘Knowledge Generation’ tab. Format should be in Date followed with time.  By default, this option is selected with the latest run date/time details.

Filter options: Users can click on the "+" icon and add the following fields.

Similar Documents: This is a drop-down menu displaying options for Yes and No: Yes filters the documents in the return list by similarity.

No filters the documents in the return by dissimilarity.

Similar Documents Count

Similar Documents = Yes (integer)

The count represents the number of original (data source) documents (Tickets) that this AI-generated document matches with.

Example:

Assume you have 3 generated documents:

Data Source Ticket 1 → AI-generated docs matched: (1, 2)

Data Source Ticket 2 → AI-generated docs matched: (2, 3)

Data Source Ticket 3 → AI-generated docs matched: (1, 3)

For AI-generated Document 1:

The generated document matches with the original Data Source Ticket 1 and Data Source Ticket 3.

So, Similar Documents = Yes (2)

Count Selection

When you select Yes (2), the Similar Documents window opens.

This page displays the crawled documents that match this AI-generated document in this example:

• Ticket 1

• Ticket 3

The Similar Documents count is also a link in the side panel of the AI-Generated Document Details page.

KB Accuracy Feedback: allows you to filter and view generated documents based on the feedback application/bot users have provided.

KB Accuracy Feedback values include: 

• ALL

• Highly Accurate 

• Moderately Accurate

• Inaccurate

• None

Published to Repository: displays the list of documents in the External data source knowledge repository where the AI generated documents have been uploaded (when the Publish to SOR toggle is selected in the application/bot Details window.). The data store type is also displayed, such as ‘ServieNow’, ‘Salesforce’ or the ‘Aisera’ option that uploads documents to the internal tenant data store.

Status: filters documents to track their publishing progress to  the source system.

• In progress – Document publishing is in progress.

• Published – Document has been successfully published.

• Failed – Publishing was unsuccessful due to an issue. (see section above: Failure messages when any of the configurations are missing

Generated By: displays the name of the user who triggered the Knowledge Generation job for that application/bot.

Template: a drop down menu with the following options:

• Default

• KCS

• Master Default

• Master KCS

Default: This template is simple and includes the Title, Description, and Solution fields. It is extracted by one representative ticket in the cluster.

KCS is an industry standard template using the Knowledge-Centered Service methodology, which is a process that involves collecting, structuring, reusing, and improving knowledge content to enhance the customer experience.  It has Title, Issue, Cause, Environment, and Solution. Extracted with one Representative ticket in the cluster.

Master KCS (sample): Multiple Resolution, Environment, and other sections are displayed, each containing multiple representative tickets within the cluster instead of just one. The same behavior applies to the Master Default view.

Tags: displays the list of tags associated with the document. Tags are shared across Aisera modules, meaning that metadata tags created in Tickets, Requests, or Knowledge in the original source systems will be available and visible in this list.

You can add tags to the AI-generated knowledge articles to help organize and filter documents more effectively.

For example, if the article relates to VPN issues and John is the SME responsible for review, you can add tags such as VPN Issues or John. These tags can then be used as filters to quickly retrieve relevant documents for further review.

Knowledge Clusters

The bar graph displays the clusters in descending order. Each cluster represents a distinct set of similar Ticket pools.

When you click on a cluster, the Recommended Knowledge Document associated with that cluster is filtered in the table column, to keep it consistent with other pages. You have the ability to choose from the data visualization options listed below. There is also a Download option.

Fields in Tabular Section

Knowledge Cluster: displays the knowledge cluster name

Knowledge Cluster Representatives: displays the recommended knowledge document that is generated for the specific cluster. You can click on the Knowledge Document, which will route you to the corresponding Knowledge Document Details page, where you can view the generated document.

Tickets: displays the count of tickets per cluster, representing groups of tickets related to similar issues.

Similar Documents: contains the similar documents found for the specific cluster representatives.

• Yes: Indicates that the cluster representative has similar documents among the committed (alias live) documents available for downstream consumption. These documents will be auto-approved and auto-committed automatically when no duplicates are found.

• No: Indicates that the cluster representative has no similar documents. These documents will also be auto-approved and auto-committed automatically when no duplicates are found. They will be available for downstream consumption.

For documents with duplicates, you need to review them and then either Publish to SOR, Publish to Aisera, or delete the duplicate document, as shown in the Actions section below.

Template: displays the Template for the document.

Published to Repository: displays the data store where the document has been uploaded, for example, ServiceNow, or Aisera.

Status: tracks document publishing progress to the source system.

KB Gen Accuracy Feedback: holds the feedback provided by the application/bot users and displays the corresponding feedback for each document. This field is not displayed by default, so to view this field, locate the Add/Remove Columns command, represented by three dots, and add the field to your display.

Application/bot users have the option to edit and resubmit their feedback. They can also delete the feedback, which will reset the section, making it appear new with all radio options unselected. The application/bot user can then choose to add new feedback or ignore it.  

Date: holds the Date & Time of the cluster when it has been extracted.

Generated By: This will show the user id who triggered the job.

Tags: This will show the assigned tags to the specific document.

Job Run On: displays the job name provided by the person who ran the Knowledge Generation job along with the date and time when the document was generated.

Action Button

In the Actions dropdown, along with Job Configuration, the following options are available:

• Set Recurring Schedule

• Publish to Aisera

• Publish to SOR

• Delete Document

Publishing AI-Generated Documents

You can publish AI-generated documents either to Aisera or to their external System of Record (SOR) by selecting single or multiple documents from the AI Generated Documents page.

Publish to Aisera: When a document is published to Aisera, the document is stored under SOR → Knowledge within your Aisera tenant module. This makes the document available for indexing. It can be consumed by downstream systems, such as application/bots that use the same tenant endpoint..

This option is particularly useful for customers with a limited external data source knowledge base (such as people who have Tickets in Zendesk, Salesforce, ServiceNow or other system but do not have a lot of Knowledge Articles within the Support Knowledge Base for that system) who want to quickly review and enable content within Aisera for bot consumption, helping reduce ticket inflow.

Publish to SOR:

Publishing to SOR is intended for customers who:

• Have an established a review and approval process in their external knowledge management system.

• Prefer to review and approve AI-generated documents externally before making them available.

Once the document is approved and published in the external system, the Aisera Gen AI platform can ingest the content for bot consumption.

Publishing AI Generated Documents

To Publish AI Generated Documents:

1. Make sure the Publish to SOR toggle swith on your application/bot Details window has the correct data source set with Publish to SOR enabled, unless you just plan to Publish to Aisera (the internal data store for your Aisera tenant).

2. Select one or multiple documents on the AI Generated Documents page.

3. Choose Actions → Publish to SOR or Actions → Publish to Aisera.

4. Select one or multiple documents on the AI Generated Documents page.

5. Select Actions → Publish to SOR or Actions → Publish to Aisera.

You can also publish directly from the Document Details page.

NOTE: After a document has been published, it cannot be republished.

Deleting AI-Generated Documents

You can delete AI-generated documents by selecting single or multiple documents from the AI Generated Documents page.

1. Select one or more documents.

2. Navigate to Actions → Delete.

When an AI-generated document is deleted:

• The associated representative tickets are released.

• These tickets become eligible for consideration in subsequent runs.

• You can delete a document directly from the Document Details page by clicking the Delete icon.

Automatic Knowledge Base Generation Trigger

The Aisera Gen AI platform supports automated recurring Knowledge Base (KB) generation based on user-defined schedules and configurations.

After the schedule is configured, this process runs automatically without manual intervention.

Once configured, this process runs automatically without manual intervention.

Schedule Options are:

• Available Recurrence Options

• Monthly

• Bi-Monthly

• Quarterly

Steps to Configure Recurring KB Generation

1. Navigate to Content Generation → AI Generated Documents in the Aisera Admin UI.

2. Select Actions → Set Recurring Schedule to open the recurring configuration window.

3. Navigate to Content Generation → AI Generated Documents.

4. Select Actions → Set Recurring Schedule to open the recurring configuration window.

5. Configure the following options as described below.

Configuration Details

Frequency Selection: You can select the recurrence frequency:

Select the recurrence frequency:

• Monthly

• Bi-Monthly

• Quarterly

Start Date: after selecting the frequency, you must specify a Start Date.

The Start Date determines when the recurring Knowledge Generation job begins.

Ticket Threshold Setting: To ensure high-quality clustering, a minimum of approximately 40,000 tickets is recommended.

After selecting the frequency, specify a Start Date. The Start Date determines when the recurring Knowledge Generation job begins. Past dates are disabled. You can only select current or future dates.

Lower ticket volumes may result in:

• Looser clusters

• Broader topics

• Less meaningful document generation

Since you may not have 40K tickets for a specific configuration, the system allows document generation with lower ticket volumes.

You can disable the Ticket Threshold option to lower the ticket count.

If the Ticket Threshold is Enabled:

• The system checks the total ticket count on the scheduled job run date.

• If the ticket count is below the threshold, the Knowledge Generation job will not run.

• The skipped job will not appear as scheduled or canceled in the UI.

If Ticket Threshold is Disabled:

• The system ignores the ticket count threshold.

• All available tickets will be processed when the job is triggered.

Additional Configurations:

• The system ignores the ticket count threshold.

• All available tickets will be processed when the job is triggered.

Additional Configuration:

All other configurations remain the same as those available for a regular job run, including:

• Ticket Conditions

• Knowledge Field Mapping

• Pre-Generation Configuration

Troubleshooting a 0 Cluster Result

There is a possibility that there will not be any similar tickets found, resulting in zero clusters. This situation is more likely to occur when a very small number of tickets are inserted as input, so no clusters can be formed.

In such cases, even if auto-publish is enabled, no Knowledge Base articles will be automatically published. This is because the absence of clusters indicates a lack of similar tickets, making the generated documents less valuable for the customer, due to the infrequency of the tickets.

As an example, consider a scenario where 1000 tickets are present, but no clusters are found.

f auto-publish is enabled, the Aisera Gen AI platform will publish 1000 documents to the source system, leading to an influx of unwanted documents.

To address this issue, you can implement the following solution:

1. Generate a cluster for each ticket, assuming that if no cluster is formed, each ticket is distinct and not similar to others. This allows the Aisera Gen AI platform to create multiple clusters, displaying ticket-specific documents under the Recommended Knowledge Document section.

2. Keep Auto Publish turned OFF, which means that even if the configuration states YES, the document will not be automatically published to the source system.

For now, if you need the document to be published, please contact our Customer Success Team. We will help you publish the requested document.

Data Processing & Ticket Quality Transparency

The Knowledge Generation process offers limited visibility into ticket selection, making it difficult for an observer to understand why only certain tickets are used for Knowledge Base Article creation while others are not.

This often leads to questions, especially when a large volume of tickets is ingested but only a subset is utilized.

Additionally, Knowledge Article quality is directly impacted by Ticket quality, which can raise concerns about accuracy and completeness.

Providing transparency into Ticket quality is essential for evaluating Knowledge Article quality effectively. It also enables you to identify poor-quality tickets, improve them, and then train your human agents to add better comments, or train your application/bot to skip poor quality tickets for improved knowledge generation.

During testing and validation, you may need to perform detailed investigations to understand why specific tickets were selected, and manually review numerous ticket comments to trace solution sources and selection criteria. These efforts demand significant time from both technical teams analyzing system logs and support teams conducting manual reviews.

To address this, the Aisera Gen AI platform includes a Data Processing Funnel that provides visibility into each step of the Knowledge Generation job process.

Breakdown of Data Processing Stages

Before getting into the details, lets understand the limitations

The Data Processing Funnel (shown in the section above) will not be available for past jobs that have already been executed. (The reason is that these are new calculations and newly added schemas, and the corresponding data will not be available for past runs executed before April 2025).

There is no stored metadata that was extracted from the runs prior to April 2025. Therefore, you can't access quality data and a few other parameters for tickets from previous runs.

Since there is no metadata for past runs, when you run a Knowledge Generation job, the platform analyzes all tickets, regardless of whether they were part of past runs. This is important because the Data Funnel needs metadata for all tickets. As the consideration of tickets for consecutive jobs increases, the platform gradually starts eliminating very good and good quality tickets that were part of past runs.

Therefore, we recommend rerunning each Knowledge Generation for all tickets, even if they have already been processed. (Refer to the ticket consideration in consecutive runs for clarity).

The following table describes each of the Data Funnel components.

Data Processing Stages	Summary	Data Navigation
Total Tickets	Represents the total number of tickets in the selected ticket data source/'s on the day of execution.	Currently the Total Tickets command will be disabled and non-clickable. However, when you click on Total Tickets the csv file is downloaded.
Filtered & Processed Ticket Set	This stage displays the list of tickets that remain after applying filters in Action → Configuration and removing those that do not meet preprocessing criteria. Preprocessing Criteria: Title Validation: The ticket title must not be null or an empty string. Content Check: Either the comment or resolution notes must contain text and must not be null or empty. Timestamp Validation: Comments without timestamps are eliminated. Filtering: Tickets marked as Good or Very Good from previous clustering runs are filtered out. Check if any of the prompts or models have been changed, if yes, then all bad quality tickets (even though it is not updated) will be reconsidered. If no, then only the bad quality tickets that are updated will be considered.	Select Filtered & Processed Ticket Set to navigate to the pre processed Tickets page, to view the list of tickets. The grey box beside this stage represents tickets that do not meet the filtering criteria. This section is non-clickable.
Tickets with Resolution	Represents the subset of filtered tickets that contain a solution and are part of clusters (There are a few tickets that, despite being of good or very good quality, did not meet the minimum threshold criteria for clustering. As a result, they will be considered outliers and will not be included in any clusters.) The grey box beside this stage represents filtered tickets that do not have a solution.	Click on Tickets with Resolution to navigate to the Ticket Details page, as shown in the screenshot. Similarly by clicking on the Grey box (beside purple), it will navigate to a new Ticket Details page that shows all the bad quality tickets with all their associated meta data.
Total Clusters	Displays the number of ticket clusters formed, which are visible on the Knowledge Generation window.	After you select the Total Clusters box, you can see the total clusters formed in the Knowledge Generation window.

Ticket Quality Transparency

This feature enhances transparency in the Knowledge Base Article Generation process by allowing you to assess the quality of processed tickets.

Recognizing that knowledge article quality is directly proportional to ticket quality, this feature classifies tickets into three categories:

• Very Good – A ticket that has a resolution and also has acknowledgment from the end user.

• Good – A ticket that has a resolution but no acknowledgment from the end user.

• Poor – A ticket that has no resolution.

During Knowledge Generation, only tickets rated as Very Good and Good are considered for inclusion into the generated knowledge article, while Poor quality tickets are excluded. This classification enables you to evaluate your ticket quality and, consequently, the resulting knowledge article quality.

Access Ticket Quality Details

To access the Quality information for a ticket:

1. Navigate to Knowledge Generation and select the desired configuration.

2. Click on the Generate Knowledge button.

3. Once the job completes successfully, you will see the knowledge clusters.

4. Click on Tickets with Resolution (Purple Box) or Tickets Without Resolution (grey box) in the data processing funnel or click on the Ticket Count at each cluster level, to access the Ticket Details window, that provides comprehensive information about each ticket.

Ticket Details Page Overview

The following table describes the parameters on the Ticket Details window.

Column Names	Description
ID	Shows the unique identifier of the ticket.
Title	Presents the ticket's title.
Ticket Type	Indicates the type of ticket (incident, problem, request, alert).
Priority	Reflects the priority level assigned to the ticket from your Ticket Management System.
Quality	Specifies the quality classification of the ticket as determined by the Knowledge Generation job, based on the presence of a resolution.
Resolution Category	Identifies the category under which the ticket's resolution falls. The fixed categories include: Cannot Be Self-Resolved – Internal Fix Needed: Issues arising from internal company systems that require specific personnel intervention like Developer. No Resolution Found / Agent Support Required to Resolve: Issues that the user can partially resolve but necessitate assistance from an agent for certain steps, such as granting permissions. Issue Reviewed in Other Channels & No Resolution Captured: Cases where no resolution exists, which falls under the Poor category. Resolution Without Feedback: Situations where a solution is provided, but the end user has not confirmed that the issue is resolved. Resolution with Feedback: A situation where a solution is provided, and the end user has confirmed that the issue is resolved.
Quality Classification Reason	Provides the rationale for assigning a quality category to the ticket. As an example, the reason for a ticket titled, 'Resolution with Feedback' might be, The agent provided a resolution action which the user followed and confirmed that it resolved the issue.
Created Date	Indicates when the ticket was created.

Acknowledgement Messages after the job runs

During the Knowledge Base Article Generation process, tickets undergo multiple stages of processing. In some cases, certain tickets may not proceed further due to various reasons.

To ensure transparency, we provide messages for each scenario.

Case 1: No Tickets in the Data Source

Description: No tickets are available in the ticket data source due to ingestion failure, or while ingestion was successful, no tickets were actually ingested.

 Acknowledgment Message: No tickets found in the data source.

Case 2: Data Source Has Tickets, but None Meet the Applied Conditions

Description: After applying ticket filter conditions, no tickets qualify for further processing.

Acknowledgment Message: No tickets match the specified conditions.

Cases 3, 4 are related to backend techincal processing.

Case 3: Tickets Exist but Are Filtered Out During Preprocessing

Description: The data source contains tickets, but preprocessing or database joins result in zero tickets before sending them for resolution classification. Acknowledgment Message: No tickets found after preprocessing the filtered set.

Case 4: Tickets Exist but Are Marked as Invalid

Description: The system detects tickets, but GPT-4 determines them to be invalid based on content analysis. Acknowledgment Message: No tickets found after preprocessing the filtered set.

Case 5: Tickets Exist but None Contain a Valid Solution

Description: All retrieved tickets are classified as poor quality and do not provide a valid solution for KB generation. Acknowledgement Message: No tickets have a valid solution to process.

Case 6: No Knowledge Clusters Found

Description: Despite having high-quality tickets, the number of qualifying tickets does not meet the minimum threshold required to form a knowledge cluster. Acknowledgment Message: No clusters identified as tickets are unique and do not meet the minimum requirement.