Ticket Categories allow administrators to organize different types of support concerns within a Ticket Profile.
Instead of creating a separate Ticket Profile for every concern, related support requests can be grouped into categories while sharing the same overall ticket workflow.
Categories can also control which forms, AI instructions, routing rules, structured mappings, and integrations apply to a specific type of ticket.
What Is a Ticket Category?
A Ticket Category represents a specific type of concern inside a Ticket Profile.
For example, a Technical Support Ticket Profile might contain:
- Client Issues
- Launcher Issues
- Login Issues
- Connection Issues
- Installation Issues
- Game Crashes
A Donation Support Ticket Profile might contain:
- Donation Inquiry
- Purchase Request
- Payment Concern
- Service Request
The Ticket Profile defines the overall support workflow, while categories help Novus determine what kind of assistance the user needs.
Ticket Profile vs Ticket Category
Ticket Profiles and Ticket Categories serve different purposes.
Ticket Profile
A Ticket Profile defines the overall support environment and lifecycle.
It may control:
- Ticketing environment
- AI behavior
- Staff takeover
- Resolution detection
- Inactivity handling
- Closing behavior
- Transcript handling
- Knowledge Review
- Concurrent ticket controls
- Integrations
Ticket Category
A Ticket Category identifies a specific concern within that workflow.
It may determine:
- Which form is used
- Which fields are collected
- Which routing instructions apply
- Which structured mappings are available
- Which integration configuration is used
- Which category-specific AI behavior applies
A simple way to understand the relationship is:
Ticket Profile → Ticket Category → Form / Routing / Mapping / Integration
When to Use Categories
Use categories when several concerns belong to the same general support workflow but require different information or handling.
For example:
General Support
- Account Concern
- Client Problem
- Launcher Problem
- Connection Problem
These concerns can share the same Ticket Profile while using different categories.
You usually do not need a separate Ticket Profile for each one.
Create a separate Ticket Profile when the entire workflow is significantly different.
For example:
General Support and Staff Applications may require completely different AI instructions, forms, lifecycle rules, and permissions.
In that situation, separate Ticket Profiles may be more appropriate.
Creating a Ticket Category
Open the Novus AI dashboard and navigate to the Ticket System configuration.
Select the Ticket Profile where the category should belong.
Choose the option to create or add a category.
Configure the available category settings, then save the changes.
The exact options available may depend on the Ticket Profile and ticketing environment being used.
Category Name
Give the category a short and recognizable name.
Good examples include:
- Technical Support
- Account Concern
- Donation Purchase
- Event Reward
- Bug Report
Avoid vague names such as:
- Help
- Other 1
- Request
- Problem
The category name should immediately communicate what type of concern belongs there.
Category Description
Use the description to explain what the category is intended to handle.
Example:
Use this category for client, launcher, installation, update, crash, DLL, and other technical troubleshooting concerns.
A clear description helps users select the correct category before creating their ticket.
It also helps administrators understand the purpose of the category when maintaining the Ticket Profile.
Assigning Forms to Categories
Categories can use forms to collect structured information from users.
For example:
Technical Support
Possible fields:
- Issue Type
- Operating System
- Error Message
- Screenshot
- Description
Event Reward
Possible fields:
- Event Name
- Character Name
- Screenshot Proof
- Reward Information
Donation Purchase
Possible fields:
- Item or Package
- Character Name
- Quantity
- Additional Information
Forms should only request information that is necessary for the selected concern.
Reusing Forms Across Categories
Where supported, the same reusable form can be used by multiple categories.
For example, both Donation Purchase and Event Reward may require payment information.
Instead of recreating the same fields for both categories, a reusable Payment Information form can be used where appropriate.
This helps maintain consistent field configuration across the Ticket Profile.
Conditional Fields Within Categories
Forms assigned to a category may contain conditional fields.
This allows the information requested from the user to change based on previous answers.
For example:
Service Type
If the user selects:
Item Transfer
Show:
- Character Name
- Item Name
- Current Race
- Destination Race
If the user selects:
Class Change
Show:
- Character Name
- Current Class
- Requested Class
Conditional fields allow one category to support multiple related scenarios without displaying every possible field to every user.
Category-Specific AI Instructions
A category can provide additional context that helps Novus understand how the selected concern should be handled.
For example:
Technical Support
Assist with documented client, launcher, patcher, login, DLL, installation, connection, update, and crash concerns.
Event Reward
Handle documented event reward claims. Request required proof and escalate when manual reward verification is required.
Category instructions should complement the main Ticket Profile instructions rather than unnecessarily duplicate them.
The Ticket Profile defines the overall role.
The category provides context for the specific concern.
Category Routing
Categories can be used to route tickets into different support paths.
For example:
Donation Inquiry
→ AI can answer documented pricing or package questions.
Donation Purchase
→ AI provides documented information and escalates when manual processing is required.
Technical Support
→ AI attempts documented troubleshooting before escalation.
Event Reward
→ Required proof is collected before staff verification.
Routing allows different concerns inside the same Ticket Profile to follow different support behavior.
Staff Escalation by Category
Some categories may require staff involvement more frequently than others.
For example:
Technical Support
Novus may be able to resolve many documented problems automatically.
Payment Concern
Manual verification may be required.
Event Reward
Staff may need to verify proof and deliver the reward.
Category-specific instructions should clearly define when Novus can continue handling the concern and when staff intervention is required.
Avoid escalating every ticket automatically unless the workflow specifically requires it.
Structured Fields
Information collected by category forms can be treated as structured data.
For example:
| Visible Field | Semantic Key |
|---|---|
| Character Name | character_name |
| Payment Number | payment_number |
| Screenshot Proof | proof |
| Transaction Reference | transaction_reference |
Semantic keys allow integrations and workflows to understand what a field represents independently from the visible field label.
Shared Semantic Mapping
Different categories may use different field names while representing the same type of information.
For example:
Donation Purchase
GCash Number → payment_number
Event Reward
Reward Account → payment_number
Refund Request
Refund Account → payment_number
Although the visible field names are different, all three fields represent the same logical information.
Where supported, Novus can allow multiple physical fields to share the same semantic meaning.
This makes structured data easier to reuse across categories and integrations.
Category-Specific Integration Mapping
Categories may require different integration behavior.
For example:
Technical Support
→ Send structured issue information to a support tracking destination.
Event Reward
→ Record reward claim information in a configured Google Sheet.
Donation Support
→ Store relevant structured transaction information according to the configured workflow.
A category can provide the context required for Novus to determine which mappings or integration actions should apply.
Creating a category does not automatically activate an integration.
The corresponding integration, trigger, destination, and mappings must also be configured.
Category Conditions
Where supported, category configuration can work together with conditional forms and structured mappings.
For example:
Category: Event Reward
If:
Reward Type = Cash
Request:
- Payment Number
- Account Name
If:
Reward Type = In-Game Item
Request:
- Character Name
- Race
- Item Information
This allows the same category to support different data requirements without requiring separate categories for every variation.
Categories and In-House Ticketing
When using Novus In-House Ticketing, categories can be integrated directly into the native ticket creation workflow.
A typical flow may look like:
User Opens Ticket Panel
→ Selects Category
→ Required Form Opens
→ User Submits Information
→ Ticket Channel Is Created
→ Novus Begins the Configured Workflow
The selected category gives Novus context before AI support begins.
Categories and Third-Party Ticketing
When Novus operates alongside a Third-Party ticket provider, category behavior depends on the available configuration and information provided by the external ticket workflow.
Novus should not assume ownership of category or ticket lifecycle actions that belong to the external provider.
Instead, Novus uses the available ticket context and configured mappings to determine the appropriate AI and automation behavior.
Designing Good Categories
Categories should be specific enough to help Novus understand the concern but broad enough to avoid unnecessary complexity.
For example, instead of creating:
- Launcher Will Not Open
- Launcher Update Failed
- Launcher Download Failed
- Launcher Error
- Launcher Missing File
You may create:
Launcher Issues
Then use a form field such as:
Issue Type
with the appropriate options.
This keeps the ticket interface cleaner and easier to maintain.
Example Category Structure
Consider a Ticket Profile named Server Support.
It could contain:
Technical Support
Form:
- Issue Type
- Error Message
- Screenshot
- Description
Routing:
AI troubleshooting first, followed by staff escalation when manual assistance is required.
Account Support
Form:
- Character Name
- Account Concern
- Description
Routing:
AI provides documented account information and escalates requests requiring administrative action.
Event Claims
Form:
- Event Name
- Character Name
- Screenshot Proof
- Reward Type
Conditional fields:
If the reward requires external payment information, display the required payment fields.
Routing:
Collect required proof before staff verification.
These categories share the same overall Ticket Profile while maintaining different data requirements and support behavior.
Common Category Configuration Mistakes
Creating Too Many Categories
Do not create a new category for every minor variation.
Use form options and conditional fields when several concerns belong to the same support type.
Using Categories as Ticket Profiles
A category should represent a concern inside a workflow.
If the entire lifecycle, permissions, AI behavior, and purpose are different, consider creating another Ticket Profile instead.
Requesting Irrelevant Information
Do not attach large forms that ask every user for information that does not apply to their concern.
Use conditional fields where appropriate.
Duplicating the Same Form Fields
Use reusable forms and shared structured mappings when the same information is required across multiple categories.
Duplicating AI Instructions
Keep general behavior in the Ticket Profile and use category instructions only for behavior specific to that concern.
Assuming a Mapping Activates an Integration
Mappings describe structured information.
They do not automatically activate Google Sheets, Google Drive, or another integration.
The integration must also be configured and enabled.
Recommended Category Design
A well-designed Ticket Profile should follow a structure similar to:
Ticket Profile
→ Defines the overall support workflow
Category
→ Identifies the type of concern
Form
→ Collects the required information
Conditional Logic
→ Determines which additional information is needed
AI and Routing Instructions
→ Determine how the concern should be handled
Structured Mapping
→ Defines the logical meaning of collected information
Integration
→ Uses structured information when configured
This structure keeps complex support workflows organized without requiring unnecessary Ticket Profiles or duplicate configurations.
Before Going Live
Test every category before making the Ticket Profile available to members.
For each category, verify:
- The correct category can be selected
- The correct form is displayed
- Required fields work correctly
- Conditional fields appear correctly
- AI receives the correct category context
- Routing behaves correctly
- Staff escalation works when required
- Structured mappings contain the expected data
- Integration actions use the correct destination
- Closing and finalization still follow the Ticket Profile configuration
Testing each category independently helps prevent configuration problems from reaching production.
Once all categories have been tested successfully, the Ticket Profile is ready for use.