Ticket Forms allow you to collect important information from members before their support ticket is created.
Instead of opening an empty ticket and repeatedly asking the same initial questions, you can create a structured form that asks members for the details your AI or support team needs.
Novus AI supports reusable forms, allowing the same form to be used across multiple Ticket Categories when those categories require the same information.
What Is a Ticket Form?
A Ticket Form is a collection of fields presented to a member during the ticket creation process.
For example, a Technical Support form might ask:
- What problem are you experiencing?
- What error message are you receiving?
- When did the problem begin?
- What troubleshooting have you already attempted?
After the member submits the form, the information becomes part of the ticket's initial context.
Why Use Ticket Forms?
Ticket Forms help collect useful information before the support conversation begins.
They can help:
- Reduce repetitive questions
- Improve ticket quality
- Give Novus AI better initial context
- Give staff useful information immediately
- Standardize support submissions
- Reduce incomplete tickets
- Speed up troubleshooting
- Improve ticket routing
A well-designed form can significantly reduce the amount of back-and-forth required at the beginning of a ticket.
Reusable Forms
Ticket Forms in Novus AI can be designed for reuse.
Instead of recreating the same fields for every Ticket Category, you can create a form once and assign it wherever the same information is required.
For example, a form named:
Basic Support Information
could potentially be used by several support categories that require the same initial details.
This makes your configuration easier to maintain.
When to Create Separate Forms
Create a separate form when a ticket type requires substantially different information.
For example:
Technical Support Form
May ask for:
- Problem description
- Error message
- Troubleshooting attempted
Payment Support Form
May ask for:
- Purchase or service
- Transaction concern
- Payment-related details
These concerns require different information, so separate forms are usually more appropriate.
Avoid Creating Duplicate Forms
Before creating a new form, check whether an existing form already collects the information you need.
For example, if both General Support and Account Support only require:
Describe your concern
you may be able to reuse the same basic form instead of creating two identical forms.
Reusable forms keep your Ticket System easier to manage.
Step 1: Create a Ticket Form
Open your Ticket System configuration and navigate to the area where Ticket Forms are managed.
Create a new form and give it a descriptive name.
Examples:
- Technical Support Form
- General Support Form
- Payment Assistance Form
- Account Support Form
- Bug Report Form
- Application Form
The form name should help administrators understand its purpose.
Step 2: Add a Description
When available, use the form description to explain what information the form is intended to collect.
For example:
Collects the initial troubleshooting information required for Technical Support tickets.
Keep administrative descriptions short and easy to understand.
Step 3: Add Form Fields
A Ticket Form contains one or more fields.
Each field represents a piece of information you want the member to provide.
For example:
Field 1
Problem Description
Field 2
Error Message
Field 3
Troubleshooting Attempted
Each field should have a clear purpose.
Field Labels
The field label tells the member what information is being requested.
Use labels that are short and understandable.
Good examples:
- Problem Description
- Error Message
- Account Name
- Transaction Reference
- Application Details
- Additional Information
Avoid vague labels such as:
- Info
- Details 1
- Data
- Other
unless the surrounding context makes their purpose obvious.
Field Descriptions
When a field may not be self-explanatory, provide a short description.
For example:
Field: Error Message
Description:
Enter the exact error message displayed by the launcher or client.
Another example:
Field: Troubleshooting Attempted
Description:
Tell us what steps you have already tried to resolve the problem.
Descriptions help members provide more useful answers.
Placeholders
When supported by the field type, a placeholder can show an example of the expected response.
For example:
Problem Description
Placeholder:
Example: The launcher closes after I click Start.
A good placeholder demonstrates the expected format without forcing the member to copy a specific answer.
Required Fields
Fields can be configured as required when the information is necessary to process the ticket.
For example, a Technical Support ticket may require:
Problem Description
because the support conversation cannot meaningfully begin without knowing the problem.
Use required fields only when the information is genuinely necessary.
Optional Fields
Some information may be helpful but not required.
For example:
Additional Information
can usually remain optional.
Members who have useful extra details can provide them, while others can continue without being blocked.
Don't Make Everything Required
Making every field required can create unnecessary friction.
For example, a member may not have an error message.
If Error Message is required, they may be forced to enter meaningless text simply to submit the ticket.
If a field does not apply to every member, consider making it optional.
Short Text Fields
Short text fields are useful for concise information.
Examples may include:
- Username
- Character name
- Short reference number
- Application name
- Brief subject
Use short fields when the expected answer should fit comfortably on one line.
Long Text Fields
Long text fields are useful when members need to explain something in detail.
Examples include:
- Problem Description
- Bug Description
- Troubleshooting Attempted
- Report Details
- Application Information
For support concerns, long text fields are often more appropriate than forcing a detailed explanation into a short field.
Selection Fields
When available, selection fields can be useful when members should choose from predefined options.
For example:
Issue Type
- Installation
- Launcher
- Connection
- Crash
- Other
Predefined choices can make submissions more consistent.
However, avoid using a selection field when the possible answers cannot be reasonably predicted.
Form Field Order
Arrange fields in a logical order.
For example, a Technical Support form might use:
- Problem Description
- Error Message
- When the Problem Started
- Troubleshooting Attempted
- Additional Information
Members should be able to complete the form naturally from top to bottom.
Ask the Most Important Question First
The first field should usually capture the primary concern.
For example:
Describe the problem you are experiencing.
This immediately gives Novus AI and staff the most important context.
Additional fields can then collect supporting information.
Keep Forms Short
Long forms can discourage members from creating tickets.
Avoid collecting information simply because it might be useful someday.
Ask only what is needed to begin support.
Novus AI or staff can request additional details during the conversation when necessary.
Avoid Questions AI Can Ask Later
Not every possible troubleshooting question needs to be part of the initial form.
For example, you may not need to ask:
- Every device specification
- Every troubleshooting step
- Every possible error condition
- Every account detail
If the information is only relevant in certain situations, Novus AI can ask for it later when needed.
Don't Ask the Same Question Twice
Review your form together with your ticket welcome message and AI behavior.
If the form already asks:
What problem are you experiencing?
Novus AI should not unnecessarily begin the ticket by asking the member to describe the problem again.
The submitted form information should provide useful initial context.
Use Forms to Improve AI Context
Form submissions can help Novus AI understand the concern before generating its first support response.
For example:
Problem Description:
Launcher closes after clicking Start.
Error Message:
No error appears.
Troubleshooting Attempted:
Restarted PC and reinstalled the launcher.
Novus AI now has more useful information than it would receive from a message such as:
"help launcher."
This can improve the relevance of the initial response.
Forms Do Not Replace Conversation
A Ticket Form provides initial information, but support may still require follow-up questions.
Novus AI or staff may need clarification when:
- The information is incomplete
- The concern changes
- A troubleshooting step produces a new result
- Additional verification is required
- The member provides conflicting information
Forms should help start the conversation, not attempt to replace the entire support process.
Forms Do Not Replace AI Routing
A form may provide hints about the ticket's purpose, but AI Routing should still consider the member's actual concern.
For example, a member opens Technical Support but writes:
"I actually need help with a pending payment."
The conversation may need to follow the appropriate Payment Support behavior or be rerouted.
The selected form should not permanently determine the AI Route.
Never Request Passwords
Ticket Forms should never ask members to provide their password.
This applies even if the ticket is private.
Do not request:
- Account passwords
- Email passwords
- Discord passwords
- Database passwords
- Other login credentials
Support should never require a member to disclose their password.
Never Request Authentication Codes
Also avoid requesting:
- OTPs
- Two-factor authentication codes
- Backup codes
- Recovery codes
- Security PINs
- Verification codes intended for authentication
These values are designed to remain private.
Be Careful With Personal Information
Only collect information that is actually necessary for the support process.
Avoid requesting unnecessary personal information.
A support form should focus on the information required to understand and resolve the member's concern.
Payment Forms
Payment-related tickets may require transaction information.
Only request the minimum information required for your support workflow.
For example, you may need:
- Purchase or service involved
- Transaction reference
- Approximate transaction time
- Description of the payment concern
Do not request full payment credentials or other sensitive financial authentication information.
Account Support Forms
Account-related tickets should also avoid secret information.
For example, you may ask for an account identifier when your support process requires it.
However, do not ask for the member's password or authentication codes.
Your form should collect information needed to identify the concern, not credentials that could be used to access the account.
Technical Support Form Example
A simple Technical Support form could contain:
Problem Description — Required
Describe the technical problem you are experiencing.
Error Message — Optional
Enter the exact error message if one appears.
Troubleshooting Attempted — Optional
Tell us what troubleshooting steps you have already tried.
Additional Information — Optional
Provide any other information that may help us understand the issue.
This provides useful initial context without overwhelming the member.
General Support Form Example
General Support may require only:
Concern — Required
Describe what you need help with.
Additional Information — Optional
Provide any additional details that may help us assist you.
A simple concern does not need a complicated form.
Payment Support Form Example
A Payment Support form might contain:
Purchase or Service — Required
What purchase or service is your concern related to?
Transaction Concern — Required
Describe the issue you are experiencing.
Transaction Reference — Optional
Provide the relevant reference when available and safe to share.
Additional Information — Optional
Provide any other details that may help staff review the concern.
Application Form Example
An application workflow may use fields such as:
Application Type — Required
Select the program you are applying for.
Application Details — Required
Provide the requested application information.
Additional Information — Optional
Include anything else relevant to your application.
The exact fields should match the requirements of your community program.
Reusing a Form Across Categories
When several Ticket Categories need the same information, assign the same reusable form instead of maintaining multiple copies.
For example:
General Support
and:
Community Support
may both use:
Basic Support Form
if both only require a concern description and optional additional information.
If you later improve the reusable form, you can maintain a more consistent support experience.
Be Careful When Editing Reusable Forms
Because a reusable form may be assigned to multiple Ticket Categories, changes can affect more than one support workflow.
Before modifying a shared form, review where it is currently being used.
For example, adding a new required field to a shared form may suddenly require that information from members opening several different ticket types.
Consider creating a separate form when the new requirement applies to only one category.
Removing Fields
If a field is no longer useful, remove it from the form.
Before removing an important field, consider whether your AI or staff workflow still depends on that information.
Your form should evolve with your actual support requirements.
Reordering Fields
If members frequently misunderstand the form, changing the order may improve the experience.
Place:
- Primary concern first
- Important supporting information next
- Optional details last
A logical form structure makes submissions easier to complete.
Test the Form as a Member
After creating or editing a Ticket Form, test it through the actual Discord ticket creation process.
Verify:
- The correct form appears.
- Field labels are understandable.
- Descriptions are clear.
- Placeholders display correctly.
- Required fields behave correctly.
- Optional fields can be skipped.
- Long answers can be entered where appropriate.
- The form can be submitted successfully.
- Submitted information appears correctly in the ticket.
Do not rely only on how the form looks in the dashboard.
Test Form Information With Novus AI
After submitting the form, verify that Novus AI can use the information appropriately.
For example, if the member already provided:
Troubleshooting Attempted:
Reinstalled the launcher.
Novus AI should avoid unnecessarily asking whether they have already reinstalled the launcher unless clarification is genuinely required.
This helps confirm that form data is providing useful support context.
Review Forms Over Time
Real tickets can reveal which form fields are useful.
You may discover that:
- Members frequently leave a field empty
- A required field should be optional
- Staff repeatedly asks for information that should be collected initially
- Two fields collect the same information
- A form is too long
- Several categories could share one reusable form
Use these patterns to improve your forms.
Ticket Form Checklist
Before using a Ticket Form, verify:
- The form has a clear purpose.
- Fields are relevant to the ticket type.
- The primary concern is collected.
- Labels are understandable.
- Descriptions are concise.
- Required fields are genuinely necessary.
- Optional fields can be skipped.
- No passwords or authentication codes are requested.
- Unnecessary personal information is not collected.
- Fields appear in a logical order.
- The form is not unnecessarily long.
- Reusable forms are used where appropriate.
- Shared forms have been reviewed before editing.
- The form has been tested through Discord.
- Novus AI can use the submitted information appropriately.
Next Step
Once your Ticket Forms collect the necessary initial information, the next step is configuring how Novus AI should behave after the ticket has been created.
Continue to Configuring AI Assistance in Tickets.