#16-Testing the Complete Ticket Workflow

A ticket panel successfully creating a Discord channel does not mean the entire ticket system is ready.

A complete Novus ticket workflow may involve:

Ticket Creation

↓

Form Submission

↓

Discord Permissions

↓

AI Assistance

↓

Knowledge Retrieval

↓

AI Routing

↓

Staff Takeover

↓

Resolution Detection

↓

Knowledge Review

↓

Transcript Processing

↓

Ticket Closing

Every important stage should be tested before members begin using the system.

Test Using a Normal Member Account

Whenever possible, perform final testing using a Discord account without Administrator permissions.

Administrator accounts can bypass many Discord permission restrictions.

A panel may appear to work perfectly for an administrator while normal members experience:

• Missing panels
• Inaccessible ticket channels
• Missing buttons
• Incorrect category permissions
• Inability to send messages

Always include a normal-member test.

Create a Simple Test Plan

Before testing, prepare several scenarios.

For example:

Test 1

Simple question AI should answer.

Test 2

Technical concern requiring troubleshooting.

Test 3

Concern requiring staff escalation.

Test 4

Successfully resolved ticket.

Test 5

Unresolved or inactive ticket.

Test 6

Wrong-category concern.

Test 7

Sensitive/private ticket.

Testing different outcomes is more useful than repeatedly opening identical tickets.

Part 1 — Verify Your Ticket Provider

First confirm which provider the server should use.

NOVUS

for Novus In-House Ticketing.

EXTERNAL

when another ticket system owns the ticket infrastructure.

Existing servers using third-party ticket systems remain on External by default rather than being automatically intercepted by native ticketing.

Testing NOVUS Provider

When testing Novus In-House Ticketing, verify the complete native flow.

Check:

• Ticket Category
• Panel
• Ticket Form
• Ticket creation
• Discord location
• Handler role
• Welcome message
• AI behavior
• Transcript configuration
• Closing behavior

Testing EXTERNAL Provider

When testing External Ticketing, verify that Novus enhances the existing system without breaking it.

Check:

• External panel still works
• External ticket creation still works
• Novus can access the ticket
• AI responds correctly
• Staff takeover works
• External close procedure still works
• External transcript still generates

Do not assume that successful AI replies mean the external integration is fully working.

Part 2 — Test Every Published Panel

Test every member-facing ticket panel individually.

For each panel:

1. Open the Discord panel channel.
2. Confirm the panel is visible.
3. Verify the title and description.
4. Check the button label and emoji.
5. Select the button.
6. Verify the expected Ticket Category is used.

The native panel implementation supports publishing and updating real Discord panel embeds/buttons.

Test for Incorrect Category Mapping

Suppose your panel says:

Payment Support

but creates:

Technical Support

This indicates an incorrect mapping.

Verify the complete chain:

Panel

→ Ticket Category

→ Ticket Form

→ Discord Category

→ Handler Role

Do not fix only the visible panel text if the underlying category mapping is wrong.

Part 3 — Test Ticket Forms

For every form, test:

• Required fields
• Optional fields
• Short Text
• Long Text
• Dropdowns
• Single Choice
• Multiple Choice

The native implementation supports up to five fields using these field concepts.

Test Required Fields

Try submitting the form without completing a required field.

For example:

Problem Description

Required: Yes

Attempt to continue without providing it.

The workflow should not silently accept incomplete required information.

Test Optional Fields

Optional fields should remain genuinely optional.

For example:

Exact Error Message

Required: No

A member who does not have an error message should still be able to continue.

Never force users to invent information simply to submit a ticket.

Test Choice Fields

If a dropdown contains:

• Launcher
• Client
• Login
• Website
• Other

select each relevant option during testing.

Make sure the resulting ticket context preserves the member's actual selection.

Part 4 — Test Discord Ticket Placement

After ticket creation, verify the channel appears under the correct Discord Category.

For example:

Technical Support

should create under:

TECHNICAL TICKETS

not:

PAYMENT TICKETS

Incorrect placement can also expose tickets to the wrong roles.

Part 5 — Test Member Permissions

Using the normal member account, confirm:

• Ticket owner can see their ticket.
• Ticket owner can send messages.
• Unrelated members cannot access it.
• Ticket owner cannot see other members' tickets.

This is one of the most important tests in the entire ticket setup.

Test With a Second Normal Member

If possible, use:

Member A

Creates Ticket A.

Then:

Member B

attempts to view Ticket A.

Member B should not receive unintended access.

This catches permission mistakes that an administrator account cannot reveal.

Part 6 — Test Handler Roles

Verify that the correct staff group can access each ticket.

For example:

Technical Support

→ @Technical Team

Payment Support

→ @Payment Team

Applications

→ @Community Team

Then confirm unrelated staff roles do not receive access when they should not.

Test Shared Handler Roles

If one role handles several categories, verify all intended mappings.

For example:

@Support Team

may handle:

• General Support
• Account Support
• Technical Support

Handler roles can be reused across native Ticket Categories.

Part 7 — Test Concurrent Ticket Limits

Try creating more simultaneous tickets than the configured member limit.

For example:

Configured Limit

1

Member already has:

support-0012

Then attempts to create another support ticket.

Verify the configured concurrent-ticket behavior is enforced appropriately.

The native foundation allows configurable limits within the supported plan boundaries.

Part 8 — Test the Welcome Message

After creating a native ticket, verify that the expected welcome information appears.

Check that it:

• Matches the Ticket Category
• Is understandable
• Does not contain outdated instructions
• Does not request sensitive credentials
• Explains what the member should do next

Part 9 — Test AI Assistance

Now send a question that Novus should know.

For example:

“How do I update the client?”

Verify that Novus:

1. Understands the concern.
2. Uses the correct AI behavior.
3. Retrieves relevant Knowledge.
4. Provides a useful answer.
5. Does not invent missing information.

Test a Known Knowledge Question

Choose something definitely present in your Knowledge Base.

If Novus fails to answer it correctly, investigate:

AI Route

↓

Route Instructions

↓

Knowledge Assignment

↓

Knowledge Content

Do not immediately assume the model itself is the problem.

Part 10 — Test Missing Knowledge

Ask something intentionally absent from the Knowledge Base.

Verify that Novus follows the configured fallback behavior.

It should not fabricate:

• Prices
• Policies
• Procedures
• Dates
• Account information
• Technical facts

when the support configuration requires verified Knowledge.

Part 11 — Test AI Routing

Test several clear concerns.

For example:

“The launcher won't start.”

Expected:

Technical Support

“My payment is still pending.”

Expected:

Payment Support

“How do I apply as a streamer?”

Expected:

Streamer/Application route

Verify that the correct instructions and Knowledge are used.

Test Ambiguous Routing

Also try:

“I need help with my account.”

This may require clarification.

Novus should not confidently select an unrelated specialized route when the intent is unclear.

Test Topic Changes

A ticket may change topic.

For example:

Member first asks:

“How do I install the client?”

Later:

“Also, where can I check my payment?”

Verify that Novus recognizes the new concern rather than remaining permanently locked to the first topic.

Part 12 — Test Cross-Profile Concerns

This is especially important for External Ticketing and multi-profile configurations.

For example:

Current Ticket

General Support

Member asks:

“My donation payment is pending.”

Test whether Novus can recognize the actual concern and retrieve the appropriate verified information instead of simply saying the member is in the wrong ticket.

Part 13 — Test Rerouting

If your configuration supports rerouting recommendations, test a concern that clearly belongs elsewhere.

Verify that Novus:

• Recognizes the correct destination
• Does not unnecessarily interrupt an answer it can safely provide
• Recommends the appropriate workflow
• Preserves conversation context

The member should not need to explain the entire concern again simply because routing changed.

Part 14 — Test Staff Escalation

Create a concern that AI should not complete alone.

Examples:

• Manual account verification
• Payment confirmation
• Backend changes
• Administrative approval
• Troubleshooting beyond verified procedures

Verify that Novus escalates to the correct staff destination.

Test Wrong Escalation

Also verify that normal questions do not escalate unnecessarily.

For example:

“Where can I download the client?”

should not require a staff member when the verified answer is already available.

Escalation should be meaningful.

Part 15 — Test Staff Takeover

Have a staff member begin handling the ticket.

For example:

Staff

“I'll check this manually.”

Then continue the conversation.

Verify that Novus does not repeatedly interrupt the staff member with unrelated automated troubleshooting.

Human and AI responses should not compete with each other.

Part 16 — Test AI-Resolved Tickets

Create a concern that Novus can resolve without staff.

Example:

Member reports a known configuration problem.

Novus provides the verified solution.

Member responds:

“That fixed it. It's working now.”

Verify that the ticket recognizes the strong resolution signal.

Test Weak Resolution Signals

Try:

“Okay, I'll try.”

or:

“Thanks.”

These should not necessarily mean the issue is resolved.

The system should distinguish between politeness and actual confirmation.

Part 17 — Test Staff-Resolved Tickets

Create a ticket where AI cannot finish the concern.

Then:

1. Escalate.
2. Have staff resolve it.
3. Have the member confirm success.
4. Continue through the closing workflow.

Verify that the final outcome reflects staff intervention.

Part 18 — Test Unresolved Tickets

Create a ticket where no solution is confirmed.

Do not allow your test user to confirm success.

The final outcome should not falsely become:

Resolved

A closed ticket and a resolved ticket are not always the same thing.

Part 19 — Test Inactivity

Create a ticket and stop responding.

If inactivity behavior is enabled, verify:

• Warning behavior
• Waiting period
• Final closure behavior
• Outcome classification

An inactive ticket should remain distinguishable from a confirmed resolution.

Part 20 — Test Knowledge Base Review

Create a test scenario where a genuinely new solution is discovered.

After resolution, verify the Knowledge analysis.

The existing resolution analysis can distinguish between existing similar Knowledge, related Knowledge, and potentially new reusable resolutions.

When a useful new candidate is found, staff may receive:

Add to Knowledge Base

and:

Ignore.

Test Duplicate Knowledge

Resolve a ticket using a solution already documented in your Knowledge Base.

Novus should not encourage staff to create unnecessary duplicate Knowledge.

The goal is to improve the Knowledge Base, not fill it with repeated copies.

Test Knowledge Privacy

Create a test resolution containing member-specific information.

For example:

Member

User123

Account Reference

TEST-123

The reusable Knowledge candidate should focus on the general verified solution rather than storing member-specific details.

Part 21 — Test Transcript Delivery

Close a native test ticket.

Verify that the transcript reaches the configured default transcript channel.

The native configuration uses the shared admin-only transcript destination selector.

Test Category Transcript Overrides

For Premium configurations using overrides, test at least two categories.

For example:

Technical Support

→ #technical-transcripts

Payment Support

→ #payment-transcripts

Verify that each transcript reaches the intended destination rather than always falling back to the global channel.

Test Global Transcript Fallback

Create a category without an override.

Verify that it uses:

Default Transcript Channel

instead.

This confirms the global fallback is functioning correctly.

Part 22 — Test Ticket Owner Transcript Behavior

If transcript delivery to the ticket owner is enabled, close a test ticket and verify the expected member-facing behavior.

Also test a category where member transcript delivery should not be used if your support policy requires stricter privacy.

Part 23 — Test Closing Delay

Verify the configured closed-ticket delete delay.

The native foundation enforces a minimum of five seconds.

The important behavior is:

Closing begins

↓

Required processing runs

↓

Delete delay expires

↓

Channel is removed

The ticket should not disappear before required closing operations can finish.

Part 24 — Test AI Summary

When AI Summary is enabled and available for your plan, verify that the summary accurately reflects the conversation.

A useful summary should distinguish:

Issue

What happened?

Actions

What troubleshooting or staff action occurred?

Resolution

What actually fixed the issue?

Outcome

Resolved, unresolved, inactive, or another applicable result.

Staff Intervention

Was human assistance required?

The native ticketing foundation includes Premium AI Summary configuration support.

Part 25 — Test External Ticket Closing

For EXTERNAL provider configurations, do not skip this test.

Create a ticket using the actual third-party provider.

Resolve it.

Then close it using the third-party provider's normal closing workflow.

Verify:

• External transcript generates
• Archive/log is created
• Close reason works
• Channel deletion works
• Novus does not interfere

Direct Discord channel closure can bypass some external providers' normal transcript workflow, which is why this must be tested carefully.

Part 26 — Test Google Sheets Mapping

If Google Sheets integration is enabled in your deployment, use a dedicated test spreadsheet first.

For example:

Spreadsheet

Novus Ticket Testing

Worksheet

Technical

Example mapping:

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

Then create one recognizable test ticket.

Verify Sheet Data

After the test workflow completes, confirm:

• Correct spreadsheet
• Correct worksheet
• Correct row
• Correct member
• Correct Ticket ID
• Correct category
• Correct form values
• Correct final status
• Correct resolution
• Correct timestamps

Also verify that closing the ticket does not unexpectedly create duplicate rows.

Test Updating an Existing Sheet Record

If your integration updates ticket records over time, test:

Ticket Created

Status → Open

then:

Staff Escalation

Status → Escalated

then:

Resolution

Status → Resolved

then:

Closing

Closed At → populated

The same ticket should remain associated with the same record when the integration is designed for updates.

Part 27 — Test Google Drive Mapping

If Google Drive ticket archiving is enabled, use a test folder.

For example:

/Novus Ticket Testing/

Map:

Technical Support

→ /Novus Ticket Testing/Technical/

Payment Support

→ /Novus Ticket Testing/Payment/

Then close one ticket from each category.

Verify Drive Archives

Confirm:

• Correct folder
• Correct ticket
• Correct filename
• Correct transcript content
• No unexpected duplicate
• Restricted tickets go to restricted locations
• File is created before required Discord data becomes unavailable

Test Category-Based Drive Mapping

Do not test only one category.

For example:

Technical Ticket

must go to:

/Technical/

while:

Payment Ticket

must go to:

/Payment/

This catches incorrect category-to-folder mappings.

Part 28 — Test Integration Failure

A connected service may eventually become temporarily unavailable.

For example:

• Google Sheets unavailable
• Google Drive unavailable
• Permission revoked
• Destination deleted
• Mapping invalid

Your ticket system should not falsely report that external storage succeeded when it did not.

Support operations should remain understandable even when an optional integration fails.

Part 29 — Test Sensitive Ticket Workflows

Create a private test category such as:

Payment Support

Verify:

• Only appropriate staff can access it.
• Transcript destination is restricted.
• Google Sheet permissions are appropriate.
• Drive destination is restricted.
• Member-specific data does not enter reusable Knowledge.
• No secret credentials are requested.

Discord privacy and external integration privacy should be tested together.

Part 30 — Test the Entire Workflow End-to-End

Finally, perform one complete realistic ticket.

For example:

Member

opens Technical Support

↓

Form

provides issue information

↓

Novus

retrieves Knowledge

↓

Troubleshooting

fails

↓

Novus

escalates

↓

Technical Staff

takes over

↓

Staff

finds a new solution

↓

Member

confirms success

↓

Novus

detects resolution

↓

Knowledge Analysis

identifies a reusable solution

↓

Staff

accepts the Knowledge candidate

↓

Transcript

is processed

↓

Google Sheets

receives structured ticket data when enabled

↓

Google Drive

receives the archive when enabled

↓

Ticket

closes successfully

This single test exercises almost every major part of the support lifecycle.

Create a Production Test Ticket

Before public launch, create one final ticket that looks like a real member ticket.

Do not use:

test test test

for every field.

Use realistic information so you can see how:

• Forms appear
• AI interprets context
• Summaries read
• Transcripts look
• Spreadsheet columns behave
• Drive filenames appear
• Knowledge candidates are generated

Realistic test data often exposes problems that placeholder text does not.

Final Launch Checklist

Before releasing your Ticket System publicly, verify:

• Correct Ticket Provider is selected.
• Every public panel works.
• Every panel maps to the correct Ticket Category.
• Forms display correctly.
• Required fields work.
• Discord ticket placement is correct.
• Member permissions are correct.
• Other members cannot access private tickets.
• Handler roles have appropriate access.
• Concurrent ticket limits work.
• Welcome messages are correct.
• AI responds using verified Knowledge.
• Missing Knowledge does not cause fabricated answers.
• AI Routes work.
• Topic changes work.
• Cross-profile concerns are handled appropriately.
• Staff escalation works.
• Staff takeover works.
• AI does not compete with active staff.
• Resolution detection works.
• Weak signals are not falsely considered resolved.
• Inactivity remains separate from resolution.
• Knowledge review works.
• Duplicate Knowledge is avoided.
• Sensitive information is excluded from Knowledge.
• Default transcript destination works.
• Premium transcript overrides work where configured.
• Ticket-owner transcript behavior is correct.
• Closing delay works.
• AI Summary reflects the real outcome.
• External provider closing remains functional when using EXTERNAL.
• Google Sheets mappings work when enabled.
• Google Drive mappings work when enabled.
• Integration failures are visible and do not silently pretend to succeed.
• Sensitive categories use appropriate permissions.
• One complete end-to-end production-style test has passed.

When Is Your Ticket System Ready?

Your system is ready when you can confidently follow a ticket from:

Member clicks the panel

all the way to:

Ticket safely closes

without needing to manually correct unexpected permissions, routing, transcript destinations, or support behavior.

Testing should focus on the entire lifecycle—not only whether the Create Ticket button works.

Next Step

The core Ticket System documentation is now essentially complete.

One optional final article remains: Ticket System Best Practices & Recommended Setups. It can serve as a shorter reference page with recommended configurations for small communities, large communities, gaming servers, SaaS/customer support, AI-first support, staff-first support, and privacy-sensitive workflows.