Ticket Profiles are the foundation of the Novus AI ticket system. A Ticket Profile defines how a support workflow behaves—from ticket creation and data collection to AI handling, staff intervention, resolution, transcripts, integrations, and closing.
Instead of configuring each ticket workflow separately, Ticket Profiles allow administrators to manage related ticket behavior from a centralized configuration.
What Is a Ticket Profile?
A Ticket Profile is a configurable support workflow that determines how Novus AI should handle tickets associated with that profile.
A Ticket Profile can define:
- Ticket provider and ticketing mode
- Ticket categories
- Reusable forms and fields
- Conditional field behavior
- AI support behavior
- Staff takeover and escalation
- Resolution detection
- Inactivity handling
- Ticket closing behavior
- Transcript handling
- Knowledge review
- Concurrent ticket controls
- Structured data and integration mappings
This allows different support workflows to operate independently while using the same Novus AI installation.
For example, you can create separate profiles for:
- General Support
- Technical Support
- Billing and Payments
- Donation Support
- Event Claims
- Account Assistance
- Guild Applications
Each profile can have its own categories, forms, AI instructions, ticket behavior, and integration configuration.
In-House vs Third-Party Ticketing
Ticket Profiles can be used with different ticketing environments.
Novus In-House Ticketing
With Novus In-House Ticketing, Novus manages the ticket lifecycle directly.
Depending on the profile configuration, Novus can handle:
- Ticket creation
- Ticket panels
- Category selection
- Forms and structured information
- Native ticket controls
- AI support
- Staff takeover
- Resolution confirmation
- Inactivity handling
- Ticket closing
- Transcript processing
- Channel finalization and deletion
This provides a complete ticketing workflow without requiring a separate ticket bot.
Third-Party Ticketing
Novus can also operate alongside an external ticket system.
In this configuration, the external ticket provider remains responsible for its native ticket lifecycle and channel management.
Novus can provide AI support, routing, structured data processing, integrations, and other configured automation without unnecessarily replacing actions that belong to the external ticket provider.
This distinction is important because closing, transcript, and channel-management behavior may differ between In-House and Third-Party ticket workflows.
Categories and Routing
A Ticket Profile can contain multiple ticket categories.
Categories allow administrators to separate different types of concerns within the same support workflow.
For example:
General Support
- Client Issues
- Launcher Issues
- Login Problems
- Connection Problems
Donation Support
- Donation Inquiry
- Purchase Request
- Payment Concern
Each category can have its own instructions, forms, mappings, integrations, and AI behavior where supported.
This allows Novus to understand what type of assistance is required before processing the ticket.
Reusable Forms
Novus supports reusable ticket forms.
Instead of recreating the same fields for multiple ticket workflows, administrators can configure forms and reuse them where appropriate.
For example, a Payment Information form may contain:
- Account Name
- Payment Number
- Amount
- Reference Number
The same structured form can then be used by multiple supported categories or workflows.
Reusable forms help keep configurations consistent and reduce duplicate administration work.
Conditional Forms and Fields
Ticket forms can support conditional behavior.
This allows Novus to display or process fields based on information previously selected or provided by the user.
For example:
Concern Type: Donation
- Item
- Transaction Details
- Payment Information
Concern Type: Event Reward
- Event Name
- Screenshot Proof
- Payment Information
Users only need to provide information relevant to their selected concern.
Conditional forms are especially useful when one Ticket Profile handles several related workflows that require different information.
AI Handling and Staff Takeover
Novus AI can provide automated support inside configured ticket channels using the profile's instructions, knowledge sources, and routing configuration.
However, AI handling does not prevent staff from taking control.
When human assistance is required, the ticket can move into a staff-controlled workflow according to the profile configuration.
This allows Novus to handle repetitive support requests while keeping administrators and support staff available for situations that require manual review or action.
Resolution Detection
Novus can detect when a support conversation appears to have reached a resolution.
Resolution detection can be used to initiate a configured confirmation or closing workflow.
For example:
Issue appears resolved
→ Novus requests confirmation
→ Ticket owner confirms resolution
→ Configured closing workflow continues
Resolution detection is separate from a manual Staff Close.
A staff member may close a ticket administratively, while resolution detection is designed to recognize when the conversation itself appears complete.
Inactivity Handling
Ticket Profiles can define how inactive tickets should be handled.
A typical inactivity lifecycle may include:
Inactivity Detected
→ Inactivity Notice
→ Final Warning
→ Configured Closing or Finalization
The exact timing and final action depend on the profile configuration.
Behavior may also differ between Novus In-House tickets and tickets managed by a Third-Party provider.
This prevents abandoned tickets from remaining open indefinitely while still giving users an opportunity to continue their support request.
Ticket Closing Behavior
Ticket closing is controlled by the ticketing environment and Ticket Profile configuration.
For Novus In-House tickets, Novus can manage the native closing and finalization workflow.
For Third-Party ticket systems, Novus respects the responsibilities of the external ticket provider and avoids unnecessarily taking over provider-owned lifecycle actions.
Closing behavior may also depend on how the ticket was closed, such as through:
- Resolution confirmation
- Staff action
- Inactivity handling
- Native ticket controls
- Other configured workflow actions
This allows different closing scenarios to be handled appropriately.
Transcript Handling
Transcript handling is a separate part of the ticket lifecycle.
Depending on the configured workflow, transcript processing can determine whether ticket conversation data should be saved or ignored during finalization.
Transcript behavior may also interact with configured integrations or archival destinations.
Administrators should configure transcript behavior according to their support, privacy, and record-keeping requirements.
Transcript handling should not be confused with Knowledge Review. Saving a transcript and adding information to the Knowledge Base are separate actions.
Knowledge Review
Novus can provide a Knowledge Review workflow for eligible ticket conversations.
This allows authorized staff to determine whether useful information from a completed support interaction should be added to the Novus Knowledge Base or ignored.
For example:
Ticket Completed
→ Knowledge Review
→ Save/Add to Knowledge Base or Ignore
This helps administrators improve Novus over time without automatically treating every completed ticket as reusable knowledge.
Sensitive, temporary, user-specific, or irrelevant information should not be added to the Knowledge Base.
Concurrent Ticket Controls
Novus can apply concurrent ticket controls to help prevent excessive simultaneous tickets from the same user.
These controls help:
- Reduce duplicate tickets
- Prevent ticket spam
- Keep support queues manageable
- Improve resource allocation
Available limits may depend on the Novus plan and ticket configuration.
Administrators should configure ticket workflows according to the expected size and activity of their Discord community.
Structured Data and Integrations
Information collected through ticket forms can be used as structured data.
This allows Novus integrations to work with specific pieces of information instead of relying only on raw conversation text.
For example:
| Physical Field | Semantic Meaning |
|---|---|
| GCash Number | payment_number |
| Refund Account | payment_number |
| Payment Number | payment_number |
Different physical fields may represent the same semantic information where supported.
This allows multiple forms or categories to provide consistent structured data to integrations even when the visible field names are different.
Structured data can be used by supported integrations such as Google Sheets, Google Drive, and other configured workflows.
Example Ticket Profile
Consider a Ticket Profile named Server Support.
The profile could contain:
Categories
- Technical Support
- Account Support
- Event Claims
Forms
- Technical Issue Form
- Account Information Form
- Event Claim Form
AI
- Uses the Server Support knowledge and routing instructions.
Staff Workflow
- Staff can take over when manual intervention is required.
Resolution
- Novus can detect when an issue appears resolved and request confirmation.
Inactivity
- Inactive tickets follow the configured warning and finalization workflow.
Transcripts
- Transcript behavior follows the profile's configured handling rules.
Integrations
- Structured ticket information can be mapped to supported external integrations.
One Ticket Profile can therefore coordinate the complete support workflow without requiring administrators to configure every component independently.
Best Practices
Keep each Ticket Profile focused on a related group of support concerns.
Use categories when different concerns belong to the same overall support workflow, and create separate Ticket Profiles when workflows require significantly different behavior.
Reuse forms whenever multiple categories require the same information.
Use conditional fields to avoid asking users for information that does not apply to their concern.
Keep AI instructions specific to the responsibilities of the profile.
Configure staff takeover for situations where manual action may be required.
Review inactivity, closing, transcript, and Knowledge Review settings carefully before enabling automatic ticket finalization.
Use structured mappings when integrations need consistent data across different forms or categories.
Finally, test the complete Ticket Profile workflow before deploying it to a live Discord server.
A proper test should include:
Ticket Creation → Form Submission → AI Handling → Staff Takeover → Resolution → Inactivity → Closing → Transcript Handling → Knowledge Review → Integrations
This helps ensure that every part of the profile behaves correctly before it is used by your community.