#10-Novus In-House vs External Ticketing

Novus AI can support different Discord ticket environments.

You may already have an existing third-party ticket bot that your community depends on, or you may want Novus to provide the complete ticket system itself.

For this reason, Novus separates ticketing into two provider types:

Novus In-House Ticketing

Novus manages the native ticket workflow.

External Ticketing

Your existing ticket system creates and manages the tickets while Novus provides AI-powered assistance inside those conversations.

Existing servers using external ticket systems are not automatically migrated when native Novus Ticketing is introduced.

Novus In-House Ticketing

With Novus In-House Ticketing, Novus becomes the primary ticket system for your Discord server.

Instead of requiring another ticket bot to create the support channels, Novus can provide the ticket configuration and native workflow.

The native ticketing foundation includes configuration for:

• Ticket Categories
• Discord ticket locations
• Ticket panel channels
• Ticket prefixes
• Handler roles
• Concurrent ticket limits
• Transcript destinations
• Ticket owner transcripts
• Closed-ticket deletion delay
• AI Summary support
• Ticket lifecycle integration

This provides tighter integration between your ticket system and Novus AI.

External Ticketing

External Ticketing is designed for communities that already use another Discord ticket system.

For example, your server may already have:

• An established ticket panel
• Existing support channels
• Staff roles
• Ticket permissions
• Transcript handling
• Closing procedures

You do not necessarily need to replace that system just to use Novus AI.

Novus can provide the AI support layer while the external ticket provider remains responsible for the actual ticket lifecycle.

The Main Difference

The easiest way to understand the difference is:

Novus In-House

Novus owns the ticket workflow.

External

Novus participates in somebody else's ticket workflow.

This distinction becomes important for features such as:

• Ticket creation
• Closing
• Channel deletion
• Permissions
• Transcripts
• AI summaries
• Knowledge review
• Staff takeover

Example: Novus In-House Support Server

Imagine your Discord server needs these support options:

Support

• General Support
• Technical Support
• Account Support

Transactions

• Payment Support
• Purchase Support

You can configure Novus Ticket Categories and publish the appropriate ticket panels directly to Discord.

Members use the Novus panel to create their tickets.

Novus can then participate throughout the complete support lifecycle.

Example: Existing Ticket Bot

Another server may already have a mature ticket system.

Its workflow might be:

Existing Ticket Bot

↓

Creates ticket-0012

↓

Configures member/staff permissions

↓

Novus AI assists inside the ticket

↓

Staff takes over when necessary

↓

Existing Ticket Bot closes the ticket

↓

Existing Ticket Bot generates the transcript

In this situation, replacing the existing system may be unnecessary.

External Ticketing allows Novus to enhance the workflow instead.

Choosing Your Ticket Provider

When configuring ticketing, choose the provider that matches your current environment.

Choose NOVUS when you want Novus to manage the native ticket system.

Choose EXTERNAL when another system already owns the ticket lifecycle.

Existing servers default to the external provider so introducing native ticketing does not unexpectedly intercept existing ticket systems.

When to Use Novus In-House

Novus In-House Ticketing is useful when:

• You are building a new Discord support system.
• You want fewer separate Discord bots.
• You want ticket creation integrated with Novus.
• You want native Novus panels.
• You want Novus Ticket Forms.
• You want centralized ticket configuration.
• You want native transcript configuration.
• You want the ticket lifecycle integrated with AI.
• You want AI summaries integrated into the native workflow.
• You want future Novus ticket features without depending on another ticket provider.

When to Use External Ticketing

External Ticketing may be better when:

• Your server already has a working ticket system.
• Staff already knows the existing workflow.
• Existing transcripts are important.
• You depend on ticket-provider-specific features.
• You do not want to migrate existing ticket panels.
• You only need Novus for AI assistance.
• Another system must remain responsible for ticket creation and closure.

There is no requirement to migrate simply because Novus In-House Ticketing is available.

Native Ticket Categories

Novus In-House Ticketing allows administrators to create Ticket Categories.

A category can define information such as:

• Name
• Discord Category
• Panel configuration
• Ticket prefix
• Handler role
• Transcript behavior
• Welcome message
• Ticket Form

The current implementation also provides management actions for creating, editing, deleting, and publishing Ticket Categories.

Example Category Configuration

Suppose you create:

Category Name

Technical Support

Discord Category

Support Tickets

Ticket Prefix

tech

Handler Role

Technical Support

Welcome Message

Welcome to Technical Support. Please provide the requested information and describe the problem you are experiencing.

Tickets created from this category might follow a naming structure such as:

tech-0001

The exact resulting channel naming follows your configured ticket workflow.

Native Ticket Panels

Novus can publish a real Discord ticket panel for a Ticket Category.

The panel builder supports configuration for:

• Panel title
• Panel content
• Button text
• Discord button style
• Optional emoji
• Live preview

Novus can publish or update the actual Discord embed and button rather than requiring administrators to manually construct the panel.

Example Ticket Panel

A Technical Support panel might use:

Title

Technical Support

Content

Having problems with the client, launcher, installation, patching, or connection? Create a Technical Support ticket and provide the requested information.

Button

Create Ticket

Emoji

🎫

A member selects the button to begin the configured ticket workflow.

Native Ticket Forms

Novus In-House Ticketing can also collect information before the support conversation begins.

The current Ticket Form implementation supports up to 5 fields and includes these field concepts:

• Short Text
• Long Text
• Dropdown
• Single Choice
• Multiple Choice

Example Technical Support Form

A Technical Support category could use:

Field 1 — Long Text

Problem Description

Required: Yes

Field 2 — Short Text

Error Message

Required: No

Field 3 — Dropdown

Issue Type

Options:

• Launcher
• Client
• Installation
• Patch
• Connection
• Other

Field 4 — Long Text

Troubleshooting Attempted

Required: No

This gives Novus useful context immediately when the ticket begins.

Example Application Form

Forms are not limited to troubleshooting.

For example:

Category

Streamer Application

Fields

Streamer Name — Short Text

Streaming Platform — Dropdown

• Facebook
• YouTube
• Twitch
• TikTok
• Other

Channel URL — Short Text

Streaming Schedule — Long Text

Programs Interested In — Multiple Choice

This allows Novus In-House Ticketing to support structured workflows beyond normal technical support.

Free and Premium Form Behavior

The current native implementation applies different form capabilities depending on the plan.

For Free servers, one active Ticket Form can be used across categories.

Premium allows separate forms per category.

This should be considered when planning a large ticket structure.

Handler Roles

Each Ticket Category can be associated with the appropriate handler role. The implementation allows handler roles to be reused across categories.

For example:

General Support

Handler: Support Team

Technical Support

Handler: Technical Team

Payment Support

Handler: Payment Team

Streamer Application

Handler: Community Manager

This prevents every support concern from being directed to the same staff group.

Example Small Server Configuration

A smaller Discord community could start with:

General Support

Handler: Support Staff

Technical Support

Handler: Support Staff

Payment Support

Handler: Administrators

This provides useful separation without creating too many categories.

Example Large Server Configuration

A larger community might use:

General Support

Handler: Support Team

Technical Support

Handler: Technical Support

Account Support

Handler: Account Team

Payment Support

Handler: Transaction Team

Bug Reports

Handler: Development Team

Guild Applications

Handler: Community Team

Streamer Applications

Handler: Community Team

The correct structure depends on how responsibilities are divided inside your server.

Concurrent Ticket Limits

Novus In-House Ticketing includes global concurrent-ticket controls.

The current implementation provides:

Free

Up to 5 concurrent open tickets per user.

Premium

Up to 10 concurrent open tickets per user.

This represents the configurable maximum capability of the plan; administrators can choose a lower limit when appropriate.

Example Concurrent Ticket Configuration

For a normal support community, you might configure:

Concurrent Tickets Per User: 1

This prevents members from creating multiple active tickets unnecessarily.

A community handling independent reports may choose a higher value.

The correct limit depends on your workflow.

Transcript Destination

Native Novus Ticketing provides a default transcript destination.

The transcript destination uses the same admin-only Discord channel selector behavior already used elsewhere in the ticket configuration.

For example:

Default Transcript Channel

#ticket-transcripts

All native ticket transcripts can use this destination unless another supported configuration overrides it.

Premium Per-Category Transcript Mapping

Premium configuration can provide a category-specific transcript destination instead of using only the global destination.

This is useful for servers with multiple departments.

For example:

General Support

→ #support-transcripts

Technical Support

→ #technical-transcripts

Payment Support

→ #payment-transcripts

Applications

→ #application-transcripts

This keeps sensitive or specialized ticket histories separated.

What Is Mapping?

As Novus expands beyond simple Discord configuration, you may encounter mapping.

Mapping means connecting one piece of ticket information to another destination or field.

For example:

Novus Field

Ticket Owner

↓

Google Sheet Column

Discord User

Or:

Ticket Category

Payment Support

↓

Google Drive Folder

/Support/Payment Tickets/

Mapping tells Novus where specific information should go.

Example Google Sheets Use Case

Suppose you want resolved support tickets recorded in a spreadsheet.

Your Google Sheet might contain:

Sheet Column	Novus Data
Ticket ID	Ticket ID
Created At	Ticket Created Date
Closed At	Ticket Closed Date
Member	Ticket Owner
Category	Ticket Category
Status	Final Ticket Status
Assigned Team	Handler Role
Resolution	Resolution Summary
AI Assisted	AI Participation
Escalated	Staff Escalation Status

This allows your team to create support reports without manually entering every completed ticket.

Example Support Analytics Sheet

A server owner could maintain:

Google Sheet

Support History

with rows such as:

Ticket	Category	Status	AI	Escalated
#1021	Technical	Resolved	Yes	No
#1022	Payment	Resolved	Yes	Yes
#1023	General	Inactive	Yes	No

This data can later help answer questions such as:

• Which category receives the most tickets?
• How many tickets are resolved by AI?
• Which concerns frequently require staff?
• How many tickets close due to inactivity?
• Which support team handles the largest workload?

Note: Google Sheets mapping should only be documented as an available workflow once the corresponding integration is enabled in your Novus implementation. The example above illustrates how field mapping should be configured rather than claiming that every mapping action is currently active.

Example Google Drive Use Case

Google Drive can serve a different purpose.

Instead of structured rows, Drive is better suited for storing files such as:

• Ticket transcripts
• Generated reports
• Exported summaries
• Attachments
• Archived support records

For example:

Google Drive

Novus Support Archive

↓

Technical Support

↓

2026

↓

August

↓

ticket-1021.html

This creates an organized external archive.

Google Drive Folder Mapping

A useful mapping configuration could look like:

Technical Support

→ /Novus Support Archive/Technical/

Payment Support

→ /Novus Support Archive/Payment/

Account Support

→ /Novus Support Archive/Account/

Applications

→ /Novus Support Archive/Applications/

This allows each ticket type to be archived separately.

Again, treat this as a configuration/use-case example unless the Google Drive export connector has already been implemented and enabled.

Sheets vs. Drive

Google Sheets and Google Drive solve different problems.

Google Sheets

Best for structured information:

• Ticket IDs
• Dates
• Categories
• Status
• Staff assignment
• Resolution statistics
• AI usage
• Escalation data

Google Drive

Best for files:

• Full transcripts
• Reports
• Exports
• Attachments
• Long-term archives

A complete support workflow can eventually use both.

Example Combined Mapping

A completed Technical Support ticket could produce:

Google Sheets

One new row:

#1021 | Technical | Resolved | AI | No Escalation | Aug 29

and:

Google Drive

One transcript:

/Technical/2026/August/ticket-1021.html

The Sheet becomes your searchable support index.

Drive stores the detailed record.

Mapping Ticket Forms to Google Sheets

Forms provide another useful mapping opportunity.

Suppose your Streamer Application form contains:

• Streamer Name
• Platform
• Channel URL
• Schedule

These could map directly to:

Google Sheet Column	Ticket Form Field
Discord User	Ticket Owner
Streamer Name	Streamer Name
Platform	Streaming Platform
Channel	Channel URL
Schedule	Streaming Schedule
Status	Ticket/Application Status

This can remove the need for staff to manually copy application information from Discord into a spreadsheet.

Mapping Different Categories to Different Sheets

Larger communities may want separate destinations.

For example:

Streamer Applications

→ Google Sheet: Streamer Applications

Guild Applications

→ Google Sheet: Guild Applications

Bug Reports

→ Google Sheet: Bug Reports

Payment Support

→ Google Sheet: Transaction Reviews

This is more useful than forcing unrelated information into one large spreadsheet.

Example Bug Report Mapping

A Bug Report form could collect:

• Bug Title
• Description
• Reproduction Steps
• Character/Class
• Additional Notes

Then map it to:

Sheet Column	Source
Report ID	Ticket ID
Reporter	Ticket Owner
Bug	Bug Title
Description	Description
Steps	Reproduction Steps
Status	Ticket Status
Resolution	Resolution Summary

This could provide a lightweight issue-tracking workflow directly from Discord tickets.

External Ticketing and Mapping

When using an external ticket provider, Novus may not own every piece of the ticket lifecycle.

This means certain data may depend on what Novus can reliably detect from the external ticket.

For example, Novus may know:

• Conversation content
• Active Ticket Profile
• AI Route
• Resolution analysis

but another bot may own:

• Original panel interaction
• Internal ticket ID
• Transcript generation
• Channel deletion
• Close reason

This is one of the reasons native Novus Ticketing can provide deeper integrations.

External Closing Limitations

With external systems, Novus must avoid interfering with the third-party provider's normal closing lifecycle.

Existing implementation specifically warns that directly closing a Discord channel can bypass the third-party system's transcript workflow.

For important external tickets, Staff Review can therefore be safer.

Novus can determine that the member is finished, restrict further member messages when configured, and allow staff to complete closure using the original ticket system.

Knowledge Base Review Works Across the Support Flow

Whether AI or staff resolves the concern, Novus can analyze the resolution before closure.

The existing resolution analysis distinguishes between:

• Similar verified Knowledge already exists
• Related Knowledge exists
• No sufficiently similar resolution exists

When a useful new resolution is found, staff can receive:

Add to Knowledge Base

or:

Ignore

This prevents every ticket from automatically becoming Knowledge.

Recommended Starting Configuration

For a new community that wants Novus to manage support from beginning to end:

Provider

NOVUS

Concurrent Tickets

1 per member

Categories

• General Support
• Technical Support
• Account Support
• Payment Support

Default Transcript Channel

#ticket-transcripts

Send Transcript to Owner

Enabled when appropriate for your community

Closed Ticket Delete Delay

Allow enough time for final processing before channel deletion.

AI Assistance

Enabled for documented support categories.

Knowledge Review

Use staff review for genuinely new reusable solutions.

This provides a simple foundation that can be expanded later.

Recommended Existing-Server Configuration

For a community already using a reliable ticket bot:

Provider

EXTERNAL

Existing Ticket Bot

Continue handling:

• Ticket creation
• Permissions
• Closing
• Transcripts
• Archiving

Novus

Handle:

• AI assistance
• Knowledge retrieval
• AI Routing
• Troubleshooting
• Resolution detection
• Knowledge analysis
• Staff escalation

This allows the community to adopt Novus gradually instead of replacing its entire support workflow immediately.

Which Provider Should You Choose?

Choose Novus In-House Ticketing when you want the most integrated Novus experience.

Choose External Ticketing when preserving your current ticket infrastructure is more important.

Neither option is universally better.

The correct choice depends on who you want to own the ticket lifecycle:

Novus

or:

Your existing ticket provider.

Next Step

Now that you understand the difference between native and external ticket providers, the next step is configuring Novus as your server's primary ticket system.

Continue to Setting Up Novus In-House Ticketing, where we'll cover a complete example configuration including provider setup, global settings, ticket categories, Discord mapping, handler roles, transcript destinations, panel publishing, forms, and practical configuration examples.