#9-Ticket Inactivity & Automatic Closing

Not every support ticket ends with a clear message such as:

"It's fixed, thank you."

Sometimes a member simply stops responding.

Without an inactivity workflow, these abandoned conversations can remain open indefinitely and make your support queue difficult to manage.

Novus AI can use Ticket Inactivity settings to identify inactive conversations and automatically move them toward closure according to your Ticket Profile configuration.

What Is Ticket Inactivity?

A ticket becomes inactive when no relevant conversation has occurred for the configured period.

For example:

Novus AI:
Please restart the launcher and let me know if the error continues.

The member does not respond.

After enough time passes, the ticket can be considered inactive.

This does not automatically mean the problem was resolved.

Inactivity Is Not Resolution

This distinction is important.

Resolution

The conversation provides evidence that the member's concern was successfully addressed.

Inactivity

The conversation has stopped for a configured amount of time.

A member may become inactive because:

• They went offline.
• They became busy.
• They forgot about the ticket.
• They decided to try again later.
• They no longer need assistance.
• They still have the problem but stopped responding.

Because the reason is unknown, Novus AI should not describe an inactive ticket as successfully resolved unless the conversation actually supports that conclusion.

Why Automatic Closing Is Useful

Inactive ticket handling helps prevent your support system from accumulating abandoned tickets.

It can help:

• Keep the active ticket queue organized
• Reduce abandoned conversations
• Free concurrent ticket limits
• Reduce unnecessary staff cleanup
• Keep ticket statistics more meaningful
• Automatically complete old support conversations

The goal is not to close tickets aggressively.

The goal is to prevent tickets from remaining open forever when no one is continuing the conversation.

Configure an Inactivity Period

Your Ticket Profile can define how long a ticket may remain inactive before the inactivity workflow begins.

Choose a period appropriate for the type of support being provided.

For example, a simple General Support workflow may tolerate a shorter inactivity period than a support process requiring the member to test something over a longer period.

Avoid making the inactivity period unnecessarily short.

Members need reasonable time to:

• Read instructions
• Download files
• Restart their device
• Test a solution
• Gather requested information
• Wait for an external process

When the Inactivity Timer Should Begin

The inactivity period should reflect when the conversation is genuinely waiting for additional activity.

For example:

Novus AI:
Please try the troubleshooting steps and let me know what happens.

The conversation is now waiting for the member.

If no response occurs, inactivity handling may eventually apply.

Member Activity

When the member sends a new relevant message, the ticket becomes active again.

For example:

Member:
Sorry for the delay. I tried it and I'm still getting the same error.

The ticket should return to the normal support flow.

Novus AI can continue troubleshooting or escalate according to the configured AI Route.

Staff Activity

Staff activity can also indicate that a ticket is still being handled.

For example:

Staff:
I'm reviewing this now and will update you shortly.

The ticket should not be treated as abandoned simply because the member has not responded yet.

Your inactivity workflow should work together with Staff Takeover and the actual ticket state.

Waiting for Staff Is Not Member Inactivity

Consider this situation:

Novus AI:
This concern requires manual verification.

The ticket is escalated.

The member is now waiting for staff.

The system should not penalize the member simply because they are not sending repeated messages while waiting.

The ticket's current support state matters.

Waiting for the Member

Compare that with:

Staff:
Please provide the requested information so I can continue checking the issue.

Now the conversation is waiting for the member.

If the member does not respond for the configured period, inactivity handling may be appropriate.

Inactivity Warning

Before automatically closing an inactive ticket, Novus AI can use the configured warning behavior to give the member another opportunity to respond.

For example:

"This ticket has been inactive for a while. If you still need assistance, please reply to keep the ticket active."

A warning helps prevent tickets from closing simply because the member forgot to respond.

Warning Period

After the inactivity warning is sent, the system can allow an additional period for the member to respond.

The flow may look like:

Active Ticket

↓

Inactive

↓

Inactivity Warning

↓

Waiting Period

↓

Member Responds → Active Again

or:

No Response → Automatic Closing

The exact timing should follow your Ticket Profile configuration.

Member Responds After Warning

If the member responds before automatic closure, the ticket should return to the active support state.

For example:

Novus AI:
This ticket is currently inactive. Reply if you still need assistance.

Member:
Yes, I still need help. The same problem is happening.

The automatic closing process should stop and support should continue.

Do Not Force the Member to Start Again

If the ticket is still open, the member should not need to recreate their support request simply because an inactivity warning was triggered.

Existing context should remain available, including:

• Ticket Form responses
• Previous member messages
• AI troubleshooting
• Staff messages
• Previous escalation
• Relevant support history

The conversation should continue from where it stopped.

Automatic Closing

If the member does not respond after the configured inactivity period and warning process, the ticket can proceed toward automatic closure.

The system should treat this as:

Closed due to inactivity

rather than:

Successfully resolved

unless the earlier conversation already confirmed resolution.

Closing Reason Matters

Keeping the closing reason accurate helps with:

• Ticket history
• Transcripts
• AI summaries
• Support statistics
• Knowledge review
• Future troubleshooting

For example:

Resolved

means the concern was successfully addressed.

Inactive

means the support conversation ended without further member activity.

These outcomes should not be treated as identical.

Resolved Tickets and Inactivity

A ticket may already contain a confirmed resolution but remain open because nobody manually closed it.

For example:

Member:
It's working now. Thanks!

If the ticket remains open afterward, automatic closing may eventually finalize it.

In this case, the ticket can still accurately reflect that it was resolved because resolution was already confirmed before inactivity occurred.

Unresolved Inactive Tickets

Consider:

Novus AI:
Did reinstalling the patch fix the issue?

No response occurs.

The ticket later closes due to inactivity.

The transcript or summary should not claim:

"Issue resolved by reinstalling the patch."

There is no confirmation that the proposed solution worked.

Instead, the outcome should reflect that the ticket closed without confirmation.

Inactivity After Staff Takeover

Inactive handling can also occur after staff becomes involved.

For example:

Staff:
Please test the account now and let me know if you can login.

The member never responds.

After the configured period, the ticket may enter the inactivity workflow.

Staff Takeover does not necessarily require the ticket to remain open forever.

Staff Can Still Close Manually

Automatic inactivity handling does not remove normal staff controls.

If staff determines that a ticket should be closed earlier according to your support policy, they can use the normal closing process.

Automatic closing primarily handles tickets that would otherwise remain abandoned.

Inactivity and Concurrent Ticket Limits

Inactive tickets may still count as active tickets until they are actually closed.

For example, if a category allows:

1 active ticket per member

a member with an abandoned ticket may be unable to create another ticket in that category.

Automatic inactivity closing helps release these old ticket slots.

Avoid Extremely Short Inactivity Periods

Closing tickets too quickly can create a frustrating support experience.

For example, a member may need time to:

• Reinstall a large client
• Download a patch
• Restart a computer
• Test the game
• Gather screenshots
• Wait until they can access another device

If the ticket closes before they can reasonably complete the requested action, they may need to start the entire process again.

Choose inactivity periods appropriate for your community.

Avoid Extremely Long Inactivity Periods

The opposite can also become a problem.

If abandoned tickets remain open for very long periods, your support system may accumulate:

• Old tickets
• Duplicate concerns
• Unused ticket channels
• Occupied concurrent ticket slots
• Difficult-to-manage support queues

Find a balance between giving members enough time and keeping the system organized.

Inactivity and Knowledge Base Review

An inactive ticket should not automatically generate new Knowledge simply because it is being closed.

Knowledge should be based on useful and sufficiently verified information.

For example:

AI:
Try replacing the configuration file.

The member never responds.

Because there is no confirmation that the solution worked, this should not automatically become verified Knowledge.

Previously Verified Information

An inactive ticket may still contain useful verified information if resolution occurred earlier.

For example:

Member:
That fixed it. Everything works now.

The ticket remains open and later becomes inactive.

The resolution was already confirmed.

Any Knowledge processing can consider the verified resolution according to the normal closing workflow.

Inactivity and AI Summary

When AI Summary is enabled, an inactive ticket summary should accurately describe what happened.

For example:

Concern: Launcher failed to start.

Troubleshooting: Member was instructed to reinstall the latest patch.

Outcome: Member did not confirm the result. Ticket closed after inactivity.

This is more accurate than claiming that the troubleshooting successfully resolved the issue.

Inactivity and Transcripts

Automatic closing should still respect your configured transcript behavior.

The transcript may contain:

• Ticket Form information
• AI responses
• Member messages
• Staff intervention
• Inactivity warning
• Closing information
• AI Summary when enabled

This preserves the history even when the ticket ends without confirmed resolution.

New Message Before Final Closure

If the member responds while the inactivity workflow is still waiting for closure, the ticket should return to active support when your configuration permits it.

For example:

Member:
Sorry, I'm back. The solution didn't work.

The ticket should no longer continue toward automatic closure as though nothing happened.

After the Ticket Is Closed

Once the ticket has completed final closure, future support should follow the normal ticket creation rules.

If the member still needs assistance later, they may create another ticket according to the available Ticket Profile and concurrent ticket limits.

The previous transcript can remain available according to your configured retention and transcript behavior.

Test Basic Inactivity

Create a test ticket and stop responding after Novus AI asks for additional information.

Verify that:

1. The ticket remains open during the configured inactivity period.
2. The inactivity workflow begins at the appropriate time.
3. The warning appears when configured.
4. The ticket closes only after the required waiting period.

Test Member Response After Warning

Allow the ticket to reach the inactivity warning.

Then respond:

"I'm still here. I still need help."

Verify that:

• Automatic closure is cancelled.
• The ticket becomes active again.
• Existing context remains available.
• Novus AI or staff can continue the conversation.

Test Waiting for Staff

Escalate a ticket and leave the member waiting for staff.

Verify that inactivity behavior does not incorrectly treat the member as responsible for responding when the next action belongs to staff.

Test Waiting for Member

Have staff ask the member for additional information.

Then stop responding as the member.

Verify that the inactivity workflow behaves according to your configured Ticket Profile.

Test Unresolved Automatic Closing

Create a ticket where a solution is proposed but never confirmed.

Allow it to close through inactivity.

Verify that:

• The ticket is not incorrectly marked as resolved.
• The AI Summary reflects the lack of confirmation.
• Unverified troubleshooting is not automatically saved as successful Knowledge.

Test Resolved Automatic Closing

Create another ticket where the member clearly says:

"It's fixed now."

Leave the resolved ticket open until the automatic closing workflow runs.

Verify that the ticket retains its resolved outcome even though final closure happened later through automation.

Inactivity Testing Checklist

Before enabling automatic inactivity closing, verify that:

• The inactivity period is reasonable.
• Active member messages reset or stop inactivity handling appropriately.
• Staff activity is considered correctly.
• Tickets waiting for staff are not incorrectly treated as abandoned by the member.
• Tickets waiting for members can become inactive.
• An inactivity warning appears when configured.
• Members can continue the ticket after a warning.
• Existing conversation context is preserved.
• Automatic closure occurs when no response is received.
• Inactive tickets are not automatically marked resolved.
• Previously confirmed resolutions remain resolved.
• Concurrent ticket slots are released after closure.
• AI Summary accurately describes inactive outcomes.
• Transcript behavior still works.
• Unverified solutions are not automatically converted into Knowledge.
• Resolved Knowledge can still follow the configured review process.
• Staff can still close tickets manually.

Ticket System Phase Complete

At this point, the core Ticket System documentation covers the complete ticket lifecycle:

Ticket Profile → Categories → Forms → AI Assistance → Staff Escalation → Resolution → Knowledge Review → Closing → Inactivity

The next major documentation phase should move away from ticket configuration and focus specifically on how Novus AI builds, organizes, and maintains the information used to answer members.

Next Category: Knowledge Base

Category Description:
Learn how to build and maintain the Knowledge Base used by Novus AI. Create reusable knowledge, organize support information, keep answers accurate and up to date, and understand how verified ticket resolutions can improve future AI responses.

Continue to Novus In-House vs External Ticketing.