Ticket System

#11-Setting Up Novus In-House Ticketing

Learn how to enable Novus In-House Ticketing, configure global ticket settings, create native Ticket Categories, assign Discord locations and handler roles, configure transcript behavior, and prepare your server for publishing Novus ticket panels.

Updated 8/28/2026, 10:55:28 PM

Novus In-House Ticketing allows Novus to become the primary ticket provider for your Discord server.

Instead of depending on a separate ticket bot for ticket creation and lifecycle management, you can configure your native ticket structure directly through Novus.

The current native ticketing foundation supports provider selection, concurrent ticket limits, transcript configuration, Ticket Categories, handler roles, panel configuration, forms, and the foundation for AI-powered ticket processing.

Before You Start

Before enabling native ticketing, decide how you want your support system organized.

You should already have a basic idea of:

Which support categories you need
Which Discord Category will contain created tickets
Which roles handle each type of ticket
Where transcripts should be stored
Whether members should receive transcript copies
How many simultaneous tickets a member can create
Which categories need Ticket Forms
Which Discord channel will contain each ticket panel

Starting with a simple structure is usually easier than creating many categories immediately.

Step 1 — Select the NOVUS Ticket Provider

Open your server configuration and go to the Ticketing settings.

Choose:

Ticket Provider: NOVUS

The native implementation supports both:

EXTERNAL

and

NOVUS

Existing servers remain on External by default so that enabling new Novus features does not automatically take control of existing third-party ticket systems.

Selecting NOVUS means that your server is being configured to use Novus as the native ticket provider.

Switching From External Ticketing

If your server already uses another ticket bot, plan the transition carefully.

Do not immediately delete your existing:

Ticket panels
Transcript channels
Staff roles
Ticket categories
Archived ticket records

A safer migration is:

Configure Novus

↓

Create and test native categories

↓

Publish a test panel

↓

Create test tickets

↓

Verify permissions and transcripts

↓

Move members to the new panel

↓

Retire the old panel only when ready

This reduces the risk of disrupting your live support system.

Step 2 — Configure Concurrent Ticket Limits

Novus allows you to configure how many native tickets one member can keep open at the same time.

Current plan boundaries include:

Free

Up to 5 concurrent open tickets per user.

Premium

Up to 10 concurrent open tickets per user.

These are maximum configuration limits.

You do not need to set the maximum.

Recommended Concurrent Ticket Setting

For most support communities:

Concurrent Open Tickets Per User: 1

is a good starting point.

This prevents members from unnecessarily creating:

Multiple General Support tickets
Duplicate Technical tickets
Several tickets about the same concern

Increase the limit only when members genuinely need several independent active cases.

Use Case: Multiple Departments

A larger community may allow:

Concurrent Tickets: 3

For example, one member may simultaneously have:

1 Technical Support ticket
1 Payment ticket
1 Application ticket

This can be useful when these concerns are unrelated.

Step 3 — Configure the Default Transcript Channel

Choose a Discord channel where native ticket transcripts should be delivered.

For example:

Default Transcript Channel

#ticket-transcripts

The current implementation uses the same admin-only transcript channel selection logic already shared with other ticket configuration features.

Use a channel that normal members cannot access unless your support policy specifically requires otherwise.

Recommended Discord Structure

For example:

STAFF

#staff-chat
#ticket-transcripts
#support-logs

SUPPORT TICKETS

Native ticket channels created here

SUPPORT PANELS

#create-ticket

This keeps active member-facing support separate from internal support records.

Step 4 — Send Transcript to Ticket Owner

Novus includes a setting foundation for optionally sending the ticket transcript to the ticket owner.

Enable this when you want members to retain their own support history.

Possible use cases include:

Technical troubleshooting
Application records
General support history
Account-related instructions

Consider disabling member transcript delivery when the transcript could contain sensitive internal staff information.

Step 5 — Configure Closed-Ticket Delete Delay

Native Novus Ticketing includes a configurable delay before a closed ticket channel is deleted.

The implementation requires a minimum delay of 5 seconds.

The delay gives the system time to finish closing-related operations.

These may include:

Transcript processing
AI Summary processing
Final ticket metadata
Knowledge review workflow
Closing messages

Avoid setting an unnecessarily immediate deletion workflow when you still need final processing.

Example

A server may choose:

Delete Delay: 30 seconds

This provides a short window for final processing before the Discord ticket channel disappears.

The appropriate value depends on your workflow.

Step 6 — Create Your First Ticket Category

Native Ticket Categories define the different support options available to your members.

For example:

General Support
Technical Support
Payment Support
Account Support
Bug Report
Guild Application
Streamer Application

The native implementation provides Add, Edit, Delete, and Publish Panel functionality for Ticket Categories.

Example: General Support Category

A simple category could use:

Name

General Support

Discord Category

Support Tickets

Ticket Prefix

support

Handler Role

Support Team

Welcome Message

Welcome to General Support. Please describe your concern and Novus AI or a member of the support team will assist you.

Ticket Prefix

The Ticket Prefix helps identify the purpose of the created ticket.

For example:

General Support

Prefix: support

Technical Support

Prefix: tech

Payment Support

Prefix: payment

Bug Report

Prefix: bug

This makes active tickets easier for staff to identify.

Avoid Confusing Prefixes

Prefer:

tech

instead of:

Prefer:

payment

instead of:

A prefix should remain understandable when staff sees the ticket without additional context.

Step 7 — Map the Discord Category

Each native Ticket Category needs the appropriate Discord location for its generated tickets.

For example:

Novus Ticket Category

Technical Support

Discord Category

TECHNICAL TICKETS

This is a basic form of mapping.

You are telling Novus:

When this type of ticket is created → place it here.

Example Discord Category Mapping

A larger server could use:

General Support

→ GENERAL TICKETS

Technical Support

→ TECHNICAL TICKETS

Payment Support

→ TRANSACTION TICKETS

Guild / Streamer

→ COMMUNITY APPLICATIONS

This can simplify staff permissions and make ticket organization clearer.

One Discord Category for Multiple Ticket Types

You do not always need a separate Discord Category for every Ticket Category.

A smaller server can map:

General Support

→ SUPPORT TICKETS

Technical Support

→ SUPPORT TICKETS

Account Support

→ SUPPORT TICKETS

and use ticket prefixes plus handler roles to distinguish them.

This can be easier to maintain.

Step 8 — Assign a Handler Role

Each Ticket Category can use a handler role.

Handler roles are reusable across categories.

For example:

General Support

→ @Support Team

Technical Support

→ @Technical Team

Payment Support

→ @Transaction Team

Streamer Application

→ @Community Manager

This helps ensure the correct staff group can access and handle the ticket.

Example Small-Team Mapping

If you only have one support team:

General Support

→ @Support Staff

Technical Support

→ @Support Staff

Account Support

→ @Support Staff

Payment Support

→ @Administrators

There is no need to create unnecessary roles when the same team handles several concerns.

Step 9 — Configure a Welcome Message

Each category can have an optional welcome message.

Use it to explain what happens after the ticket opens.

For example:

Technical Support Welcome Message

Welcome to Technical Support.

Please provide any relevant error message, screenshot, or troubleshooting already attempted. Never share passwords, authentication codes, or other secret credentials.

Novus AI may assist you first, and staff can take over when manual assistance is required.

Keep Welcome Messages Short

Avoid placing your entire support policy in the welcome message.

It should tell the member:

What the ticket is for
What information may be useful
What happens next
Any important security warning

Detailed procedures should remain in your Knowledge Base or AI instructions.

Step 10 — Add a Ticket Form When Needed

Novus native Ticket Categories support optional forms.

Current implementation supports up to 5 form fields with concepts including:

Short Text
Long Text
Dropdown
Single Choice
Multiple Choice

Use forms when collecting information before ticket creation saves meaningful support time.

Technical Support Form Example

Field 1

Label: What problem are you experiencing?

Type: Long Text

Required: Yes

Field 2

Label: Issue Type

Type: Dropdown

Options:

Launcher
Game Client
Patch
Installation
Connection
Other

Required: Yes

Field 3

Label: Exact Error Message

Type: Short Text

Required: No

Field 4

Label: What have you already tried?

Type: Long Text

Required: No

Payment Support Form Example

Field 1

Label: Concern Type

Type: Single Choice

Options:

Payment Pending
Missing Purchase
Payment Verification
Other

Field 2

Label: Transaction Reference

Type: Short Text

Required: No

Field 3

Label: Describe your concern

Type: Long Text

Required: Yes

Do not ask members to submit secret payment credentials, passwords, verification codes, or other authentication information.

Bug Report Form Example

Field 1

Bug Title

Field 2

Description

Field 3

Steps to Reproduce

Field 4

Where Did It Happen?

Options:

Launcher
Login
Game
Website
Other

Field 5

Additional Notes

This uses the current five-field maximum efficiently.

Free vs Premium Forms

The native implementation currently defines:

Free

One active Ticket Form across categories.

Premium

Separate forms per category.

For a Free server, create a more general form that can work across several categories.

For Premium, each department can have a more specialized intake form.

Example Free Shared Form

A generic shared form could ask:

Concern

Long Text

Type

Dropdown:

General
Technical
Account
Payment
Other

Additional Information

Long Text

This avoids needing separate forms.

Step 11 — Configure the Ticket Panel

The native Panel Builder allows you to customize:

Title
Content
Button text
Button style
Optional emoji
Live preview

Example General Support Panel

Panel Title

Need Help?

Panel Content

Create a ticket if you need assistance with your account, game client, technical issue, or general concern.

Choose the appropriate support option so we can assist you faster.

Button Text

Create Support Ticket

Emoji

🎫

Example Application Panel

Panel Title

Community Applications

Panel Content

Interested in joining our Guild or Streamer programs? Create an application ticket and complete the required information.

Button Text

Apply Now

Emoji

📝

Step 12 — Choose the Panel Channel

A Ticket Category can have a configured panel destination.

For example:

General Support Panel

→ #support

Bug Report Panel

→ #report-a-bug

Applications Panel

→ #applications

This is another mapping relationship:

Novus Ticket Category → Discord Panel Channel

Single-Panel Strategy

Smaller servers may prefer one Discord channel:

#create-ticket

with several ticket panel messages.

For example:

Panel 1

General & Technical Support

Panel 2

Payment Support

Panel 3

Applications

This keeps the server navigation simple.

Multi-Panel Strategy

Larger communities may use:

#support-center

#payment-support

#applications

Each channel can contain the panel relevant to that department.

Use whichever structure is easiest for members to understand.

Step 13 — Publish the Panel

Once the category and panel settings are ready, publish the panel.

The native implementation can post the actual Discord embed/button and later update the published panel.

After publishing, test it using a normal Discord account.

Do not rely only on an Administrator account because Administrators can bypass many permission issues.

Step 14 — Create a Test Ticket

Select the published ticket button.

Verify that the expected workflow begins.

Check:

Correct panel
Correct category
Correct form
Correct handler role
Correct ticket location
Correct ticket naming
Correct welcome message
Correct member access
Correct staff access

If any of these are wrong, fix the configuration before releasing the panel publicly.

Complete Example — Gaming Community

Here is a practical starter configuration.

Global Ticket Settings

Provider

NOVUS

Concurrent Tickets

Default Transcript Channel

#ticket-transcripts

Send Transcript to Owner

Enabled

Delete Delay

30 seconds

Category 1 — General Support

Discord Category

SUPPORT TICKETS

Prefix

support

Handler

@Support Staff

Panel Channel

#create-ticket

Form

Shared General Support Form

Category 2 — Technical Support

Discord Category

SUPPORT TICKETS

Prefix

tech

Handler

@Technical Staff

Panel Channel

#create-ticket

Form

Technical Support Form

Category 3 — Payment Support

Discord Category

PRIVATE SUPPORT

Prefix

payment

Handler

@Transaction Staff

Panel Channel

#payment-support

Form

Payment Support Form

This provides clear separation without creating an unnecessarily complicated structure.

Complete Example — SaaS Community

Novus In-House Ticketing can also be used outside gaming communities.

For example:

Novus Source	Sheet Column
Ticket ID	Ticket ID
Ticket Owner	Member
Ticket Category	Category
Form: Issue Type	Issue Type
Created Date	Created At
Handler Role	Team
Final Status	Status
Resolution Summary	Resolution
Closed Date	Closed At

Next Step

After the global native ticket configuration is ready, the next step is building the actual member-facing entry point.

Continue to Creating & Publishing a Native Ticket Panel, where we'll cover panel design, category-to-panel mapping, button configuration, practical multi-panel setups, and real Discord use cases.