SupportCandy

SupportCandy – Automatic Close Ticket adds an inactivity rule to the SupportCandy ticketing system. It closes tickets after a defined period without activity, while giving administrators control over the warning email and the number of days before closure. That makes it a focused tool for keeping old conversations from remaining in the active queue indefinitely.

What it handles

The central job is straightforward: identify tickets that have been inactive for a configured timeframe and close them automatically. Before that happens, the plugin can notify the user by email. This creates a clear final prompt for a customer who has stopped responding, rather than leaving every quiet ticket open for a support agent to review manually.

The add-on is built around SupportCandy rather than functioning as a separate ticketing system. Its role is to add an automatic-closure layer to an existing support workflow, with settings intended to fit the way a team already sorts and manages tickets.

Useful controls

The feature list gives administrators several points of control instead of one fixed timeout. The available functions include:

• Setting an inactivity timeframe before a ticket closes.
• Sending a warning email before the closure takes place.
• Choosing different closure rules for different ticket statuses.
• Keeping a log of tickets that have been closed.
• Managing the behaviour through a user-facing settings interface.

Status-specific rules are particularly relevant for teams whose queues contain more than one kind of waiting ticket. A pending customer reply, an internal follow-up and another status can follow different closure policies, rather than being forced into one global timer. The warning email also gives the process a visible checkpoint before the ticket leaves the active workload.

Records and maintenance

Logging closed tickets helps preserve a record of what the automation has done. That is useful when an agent needs to confirm whether a conversation was closed by policy or when a team reviews its support history. The vendor also lists compatibility with current WordPress versions and themes, along with regular updates for compatibility and security. Those statements describe the intended maintenance position, but the actual fit still belongs in the wider SupportCandy and WordPress setup.

Where it falls short

Automatic closure treats inactivity as the trigger, not as proof that the customer’s issue is resolved. A user who misses the warning email or cannot reply within the configured period faces closure even when the underlying problem remains open. That makes the warning message and timeframe important operational decisions rather than settings to choose once and forget.

The add-on also relies on SupportCandy, so it has limited value without that ticketing system in place. Status-specific rules provide flexibility, but they also introduce more policy choices: administrators need to decide which statuses should close, how long each should wait and which customer messages are appropriate. The closed-ticket log documents the result, but the supplied feature list does not describe a separate recovery or reopening workflow.

Who should use it

SupportCandy users with a growing backlog of quiet tickets are the clearest audience. It suits teams that want a defined end to conversations after a customer stops engaging, while still sending a warning and retaining a closure record. It is less suited to workflows where inactivity is not a reliable signal or where every ticket needs manual resolution before it leaves the queue. For the right SupportCandy installation, this is a narrow but practical housekeeping add-on: its value comes from turning an agreed support policy into a repeatable ticket rule.