SupportCandy Automatic Close Tickets - WordPress Plugin

SupportCandy Automatic Close Tickets Setup Guide for Controlled Ticket Closure

SupportCandy Automatic Close Tickets is not about "speeding up support" with a single click. It is about managing the ticket lifecycle in WordPress in a calmer, more predictable way. In this guide, we will walk through how to prepare your base SupportCandy setup, choose which statuses should be eligible for auto-close, define the inactivity window, make the warning emails clear to customers, and verify that a ticket closes at exactly the right point.

This guide is written for a site owner, support administrator, or webmaster who already uses SupportCandy as a ticketing system and wants to clear stalled requests without manually cleaning up the queue. We will not repeat the short product description from the top of the page. Instead, we will follow the full working flow, from preparing statuses to diagnosing cases where the reminder email never went out or the ticket stayed open.

The core idea is simple: automatic closure should be predictable and reversible. If you configure it too aggressively, customers may feel like support was closed without a real answer. If you configure it too loosely, your queue will still be clogged with old tickets. That is why the guide below includes a lot of practical checks, solution tables, and wording examples for warning notifications.

What problem automatic ticket closure actually solves

In support workflows, there are almost always tickets that stop moving not because of the agent, but because the customer never replies. A user asks about a problem, gets a follow-up question, never comes back, and the ticket keeps sitting in the active queue. After a few cases like that, it becomes harder for the agent to separate truly urgent requests from old threads that have already lost relevance.

SupportCandy Automatic Close Tickets handles exactly this part of the process. The administrator chooses which statuses are treated as auto-close candidates, sets the number of inactive days, and specifies which status should be assigned after the waiting period ends. The add-on also lets you configure one or more warning emails before closure. If the customer replies after the warning, the ticket should no longer be treated as inactive for that current auto-close cycle.

The practical value shows up in three places. First, the list of active tickets becomes cleaner, so agents see the requests that actually need the next step. Second, the customer gets a warning instead of a sudden closure with no context. Third, the closed ticket can still be handled through standard SupportCandy tools: reports, filters, closed-ticket archiving, and other related settings if they are enabled in your configuration.

Where auto-close makes sense

This add-on works best in workflows where support often waits on the customer for information: access to a staging site, screenshots, order confirmation, a reply to a clarification question, or a preferred time for testing. In those cases, a status such as Awaiting Customer Reply or a similar custom status clearly shows that the support team has already taken the next step and is now waiting on the other side.

For stores, educational projects, and service-based websites, auto-close helps avoid keeping tickets open that are effectively finished. For example, an agent asks the customer to confirm that a file access issue has been resolved. If the customer does not reply for several days, the system first sends a reminder and then moves the ticket to a closed status. That is better than manually reviewing dozens of similar threads.

Where the feature can do harm

You should not enable auto-close across every open status without thinking it through. If you include a status where the next step still belongs to the agent, the system may close unfinished requests. This is especially risky for statuses like Open, In Progress, or custom statuses that represent internal team work.

Another risk is using a short waiting period for more complex issues. The customer may be collecting logs, coordinating access with coworkers, or waiting on a hosting provider. If the inactivity window is too short, the warning will arrive too early, and the closure will feel like pressure. That is why this setting should be based not on the urge to "clean up the queue," but on the real customer response cycle on your site.

What to check before installing the add-on

Before installation, make sure your core ticketing system is already working reliably. Automatic Close Tickets depends on statuses, emails, and ticket activity history. If your base SupportCandy setup does not yet have support pages, email notifications, agents, and statuses configured, auto-close will be hard to test because it will be unclear whether the issue is in the add-on or in the underlying setup.

Start with a simple test. Create a regular ticket from a test customer, reply to it as an agent, change the status, verify that the standard email notification is sent, and confirm that the customer can see the ticket in the customer portal. Only after that does it make sense to add automatic closure.

Minimum SupportCandy readiness

• The SupportCandy plugin is installed and activated. The base plugin can be installed through the WordPress plugin directory or by uploading a ZIP file through the plugins screen.
• Your support pages are created and loading correctly. Customers should have a clear path to both the ticket list and the ticket submission form.
• SupportCandy notifications are already being sent. At minimum, test ticket creation and an agent reply before you start testing auto-close warnings.
• Your ticket statuses reflect the real workflow. You need a separate status for waiting on the customer, otherwise auto-close will be difficult to configure safely.
• A closed status is already defined. The add-on needs to know which status to assign after the inactivity period ends.

Why a dedicated waiting-for-customer status is better than a generic one

The most common mistake in automations like this is treating every unresolved ticket as the same thing. In practice, Open may mean a new request, In Progress may mean the agent is working on it, and Awaiting Customer Reply may mean the team is waiting on the customer. Auto-close only makes sense for the last group.

If you do not yet have a dedicated waiting-for-customer status, create one in SupportCandy's status settings before enabling Automatic Close Tickets. The administrator can manage statuses, assign a name, and define a color label. This helps agents quickly distinguish threads where the next step belongs to the customer from tickets where the team still needs to act.

Practical check: if an agent cannot explain within five seconds why a specific ticket is in the selected status, that status should not be used as an auto-close condition.

Installation and the first check in WordPress

How you install the add-on depends on how you receive the product archive, but the general path in WordPress is standard: upload the ZIP file, activate the add-on, and make sure the Automatic Close Tickets settings section appears in the admin panel. This article does not cover purchasing, key entry, or licensing workarounds. We are focused on the add-on file you already have and on safely verifying how it works on the site.

Before installing on a live site, it is smart to create a backup and run your first test on a site copy or during off-peak hours. The add-on changes ticket statuses automatically, so a setup mistake can affect real support requests. Even if a closure can be corrected manually, it is better not to create unnecessary confusion for customers and agents.

General installation flow

1. Open the WordPress admin panel and go to Plugins - Add New.
2. Select plugin upload through Upload Plugin if you have the add-on ZIP archive.
3. Upload the archive and activate the add-on after installation.
4. Make sure base SupportCandy is active. Without it, the add-on has no working context.
5. Open Support - Settings - Automatic Close Tickets and confirm that the settings are available.

A low-risk first test

Do not start with real customer tickets. Create a test ticket from a separate user account or from a guest customer if guest tickets are enabled in your configuration. Reply as an agent, change the status to the waiting-for-customer state, and make sure the ticket actually landed in the status you plan to use for auto-close.

For the first test, you do not need perfect timing values. What matters is confirming that the settings screen is available, the status list loads correctly, the closed status is chosen intentionally, and a warning email can be created in the email notification section. After that, you can move on to timing rules and real-world settings.

Configuring statuses, the inactivity window, and the closure result

The main Automatic Close Tickets screen is located at Support - Settings - Automatic Close Tickets. In the official documentation for this screen, three key settings are described: the statuses that should be checked for auto-close, the ticket age in days, and the status that will be assigned after closure. Those three fields define the entire workflow.

You should not treat the age field as a simple delay "after ticket creation." The product logic is based on inactivity, meaning the absence of activity within the selected ticket. That is why proper configuration starts with a different question: "In which statuses does the lack of a customer reply actually mean the ticket can be closed after a warning?"

Ticket status to check for auto-close

Only add the statuses in which the system should look for closure candidates. For most sites, that means one or two waiting-for-customer statuses. For example, Awaiting Customer Reply and, if needed, a separate status for waiting on documents or confirmation. Do not add all open statuses here just for convenience, because that breaks the logic of the automation.

A good practice is to start with a single status. That makes it easier to see how the rule behaves on real tickets and avoids mixing different scenarios together. If, after a few weeks, it becomes clear that the same behavior is needed for another status, you can add it separately and test again.

How to choose a candidate status

• The status should mean that the agent has already replied and is waiting on the customer.
• The status should not be used for the agent's internal tasks.
• Agents should have a clear rule for when to move a ticket into this status.
• The status color in the ticket list should be visually distinct from new and active requests.
• The status should make sense in reports and filters, otherwise the team will miss broken logic.

Age (days)

The Age (days) field sets the number of inactive days after which the ticket will be closed. There is no universal value. One timeframe may work for simple requests, while complex technical support may need a very different one. A period that is too short creates frustration, while a period that is too long leaves the queue cluttered.

For a typical site, start with a moderate value and review actual customer response patterns. If most customers reply within two or three business days, you can make the window slightly longer so the conversation is not closed right after the first silence. If tickets often require external verification, give the customer more time and use the warning as a gentle reminder.

How not to confuse calendar days with your actual business rhythm

SupportCandy also includes working hours, holiday, and exception settings for cases where team availability matters. But the Automatic Close Tickets documentation describes age specifically as days of inactivity. So do not assume that a short window will automatically feel "softer" because of weekends. If weekends matter for your support flow, build that cushion into the timeframe itself and into the wording of the email.

Close status

The Close status field determines which status the ticket will receive after auto-close. In most cases, that will be your standard closed status. If your team needs to distinguish between manual closure and automatic closure, you can use a separate closed status, but only if your status system and reporting really support that distinction without creating confusion.

SupportCandy's documentation notes that closed status options are added through the ticket list settings and advanced options. Before choosing a separate status, verify how it appears in the list view, filters, reports, emails, and archive rules. In many cases, one clear closed status is better than several similar options that no one actually analyzes.

Quick takeaway: safe configuration does not start with the number of days. It starts with the right waiting-for-customer status. If the status is wrong, any timing value will work against your support process.

Warning emails before closure: how to make them useful

The second important part of SupportCandy Automatic Close Tickets is pre-close notifications. The documentation points to Support - Email Notifications - Automatic Close Tickets. There, you can create an email notification that reminds the customer about an inactive ticket. If needed, you can create more than one of these notifications.

The purpose of the warning is not just to formally say "your ticket will be closed soon." A good email helps the customer quickly understand what is expected from them, where to reopen the ticket, and what will happen if they do not reply. If the email sounds dry or threatening, it damages the support experience even if the automation is technically correct.

Title, Days Before Closing, Subject, and Body

The template settings include several fields. Title is for the internal name of the notification. Days Before Closing defines how many days before closure the email should be sent. Subject controls the email subject line, and Body is the message itself. In the body, you can use SupportCandy macros that insert ticket and customer data.

Plan your warnings relative to the total closure window. If the ticket closes after ten days of inactivity, one warning sent two or three days before closure is often enough. If your support team handles complex B2B tickets, you may want two reminders: an early gentle one and a short final notice. But do not turn the system into a stream of daily reminders.

Example logic for a single warning

1. The ticket is in a waiting-for-customer status.
2. The customer does not reply for most of the selected period.
3. The system sends a warning a few days before closure.
4. If the customer replies, the ticket exits the current auto-close flow.
5. If there is no reply, the ticket receives the closed status after the full inactivity period.

Which macros to use carefully

SupportCandy supports email-template macros for the ticket ID, customer name, email, recent replies, ticket history, and other fields. For an auto-close warning, a personal greeting, the ticket subject, and a link or piece of information that helps the customer return quickly are usually enough. You do not need to include the full conversation history in every reminder if it makes the email too long.

If you use a history macro, test the email on a real sample ticket. A long thread can feel heavy in an email client, especially on mobile. For a warning message, a short structure works better: why the email was sent, what the customer needs to do, what event this relates to, and how to reply.

Example email body text

The example below is not a universal ready-made template. It is a structure worth adapting to your support tone. Use the exact macros from the SupportCandy list and verify the final email after saving.

Hello, {{customer_first_name}}.

We are waiting for your reply on ticket {{ticket_id}}. If the issue has already been resolved, no further action is needed.
If you still need help, please reply in the ticket before it is automatically closed.

Ticket subject: {{ticket_subject}}

After inserting the template, send a test warning to an address you can check manually. Review the subject, body, macro replacement, and ticket link if you add one. If the message lands in spam, the issue may not be in Automatic Close Tickets at all, but in overall WordPress email deliverability.

Safe rollback: if customers start complaining about overly frequent emails after warnings are enabled, first disable the extra template or increase the closure window. Do not delete statuses or rush into changing the entire support process.

Practical scenario: closing stalled tickets after waiting for the customer

Let us look at a concrete example. Suppose the site sells digital products and uses SupportCandy for customer support. The agent replies to a ticket, asks the customer to confirm that the issue is resolved, and moves the ticket into a waiting-for-customer status. If the customer does not respond, the system should send a reminder and then close the ticket. At the same time, new and active tickets should not be pulled into this rule.

Goal

The goal is to keep a clean active ticket list where stalled requests are closed automatically, but only after the customer has been warned. We are not closing tickets where the agent is still working, and we are not touching new requests that have not yet received a support reply.

Preparation

• A waiting-for-customer status has been created or selected, for example Awaiting Customer Reply.
• A closed status exists and is already used by the team for completed requests.
• Standard SupportCandy email notifications are delivered to a test address.
• Agents understand that moving a ticket into the waiting-for-customer status means "the next step belongs to the customer."

Configuration steps

1. Open Support - Settings - Automatic Close Tickets.
2. In Ticket status to check for auto-close, select only the waiting-for-customer status.
3. In Age (days), set a timeframe that matches the real response expectations on your site.
4. In Close status, choose the closed status.
5. Save the settings and go to Support - Email Notifications - Automatic Close Tickets.
6. Create a warning: internal name, number of days before closing, email subject, and a short body with macros.
7. Create a test ticket, reply as an agent, and move it to the waiting-for-customer status.

Checking the result

Verification should not stop at looking at the settings page. Open the ticket list and confirm that the test ticket is truly in the correct status. Check that other test tickets with active statuses do not match the rule. Then wait for the warning to be sent in your test scenario, or use a shorter test window on a site copy if the live timeframe is too long.

After the ticket closes, verify three things: the status changed to the selected closed value, the customer received the expected warning before closure, and the ticket history still contains the important replies. If automatic archiving of closed tickets is enabled, separately confirm that the closed ticket does not disappear from the active list earlier than your team needs.

An easy detail to miss

Auto-close is only useful if agents consistently update the status after they reply. If an agent leaves the ticket in Open while the rule only targets the waiting-for-customer status, the ticket will never close automatically. But if you add Open to the rule, you will start closing requests where the customer never received a proper answer at all. So it is better to fix the team's status habits than to expand the rule to cover the wrong states.

How to connect auto-close with reports, archiving, and support quality

Automatic closure is not a standalone cleanup button. It is part of the broader support process. Once it is configured, think about how closed tickets will appear in reports, whether they will be archived, and how the team will distinguish genuinely resolved requests from tickets that were closed because the customer went silent.

SupportCandy includes settings for archiving closed tickets and deleting archived tickets. The documentation emphasizes an important point: deleting archived tickets is irreversible. That means auto-close should not automatically lead to fast deletion. There should be a sensible gap between closure and any data cleanup actions, especially if tickets may be needed for communication history, warranty issues, or internal quality review.

Closed does not mean deleted

A closed ticket usually remains part of the support history. It can still be found, reviewed, restored into the context of a new request, or used for analysis. Archiving helps remove closed tickets from the active workspace, but it should not be treated as immediate destruction of data. Archived ticket deletion should only be enabled after you verify your data retention policy and business requirements.

Do you need a separate auto-close status

Some teams like to have a status such as Auto Closed so they can quickly see which requests were closed without a customer reply. But that approach adds one more status to the system and requires reporting discipline. If the team is small and no one plans to analyze the closure reason separately, a dedicated status may only make the list harder to manage.

If you do introduce a separate status, agree on the rules first: which filters agents will use, who reviews those tickets, how quickly they should be archived, and what to do if the customer replies after closure. Do not create the status just because it looks nice in the dashboard.

How to evaluate the setup after a few cycles

• Check how many tickets are closed automatically and how many of those customers later try to continue.
• Compare customer complaints before and after enabling warnings.
• See whether tickets on more complex issues are being closed too quickly.
• Make sure agents are not using the waiting-for-customer status as a way to hide a difficult ticket from the queue.
• Assess whether the active ticket list has become easier to work with.

If the team is losing fewer important requests after enabling auto-close, and customers are not complaining about unexpected closures, the setup is probably working well. If disputes appear, adjust the statuses and timeframes first rather than turning everything off immediately.

Best settings for different types of support

The question "best SupportCandy Automatic Close Tickets settings" makes sense, but there is no single preset. The best setup depends on how quickly customers typically reply and how critical it is to avoid closing a request too early. Below are practical scenarios you can use as a starting point, without treating them as universal rules.

Small store or service website

For a small store, one waiting-for-customer status and one warning before closure are usually enough. Customers typically reply within a few days, and there are not many complex approval chains. What matters most is that the email subject is clear, so the customer immediately sees that it is about a specific ticket rather than a marketing message.

In this kind of setup, a separate auto-close status is not always necessary. It is often simpler to use the regular closed status and identify the closure reason through the history and the warning email template. If ticket volume grows and reporting becomes more important, you can add a separate status later.

Technical support with longer diagnosis cycles

For technical issues, the waiting period should be longer. The customer may be collecting logs, testing recommendations on a staging copy, waiting on their hosting provider, or coordinating with a developer. In this case, two warnings can help: the first as a gentle reminder, the second as a final notice before closure. But each email should stay short and give a clear path back into the conversation.

In teams like this, it is especially important not to include internal diagnosis statuses in auto-close. If the agent has taken ownership of the issue and is waiting for a result from a coworker, that is not customer inactivity. For those states, use separate internal statuses and filters.

Support tied to WooCommerce or digital orders

If SupportCandy is connected to sales, orders, or digital products, auto-close needs to account for the customer experience. For example, a buyer may open a ticket about file access, receive a reply with instructions, and never confirm the outcome. A closure after warning is useful here, but the email should say clearly: if the issue is still there, replying in the ticket is enough.

Do not use automatic closure as a replacement for oversight on problem orders. If a ticket is tied to payment, product access, or a critical error, the agent should confirm that the customer actually received a solution before moving the ticket into a waiting status.

When it is better to disable or postpone auto-close

There are cases where this feature can wait. If the team is just rolling out SupportCandy and has not yet agreed on statuses, auto-close adds another variable too early. If WordPress email delivery is unstable, warnings may never arrive, making closure feel sudden. And if tickets are legally sensitive or tied to long-term obligations, you should first define your retention and closure policy.

Temporarily disabling a questionable automation is a normal operational decision. It is better to postpone the rule for a week and clean up the status process than to enable it on top of a chaotic queue.

A working status policy for the support team

Even a correctly configured plugin will not fix the process if agents use statuses differently. One agent marks waiting-for-customer only after a specific follow-up question, another does it after any reply, and a third leaves the ticket open until the final resolution. For manual work, that is inconvenient but manageable. For auto-close, it becomes a direct source of errors: the system does not understand the agent's intent, it only sees a status and an inactivity period.

That is why it helps to create a short internal status policy before launch. This does not need to be a long bureaucratic document. It just needs to explain when a ticket enters the scope of Automatic Close Tickets. The simpler the rule, the lower the chance that an agent will work around the process or use the status as a personal note.

The rule: "the next step belongs to the customer"

The waiting-for-customer status should be applied only after the agent has already replied and a specific answer from the user is required to continue. That may be confirmation of the result, a file, a screenshot, access to a staging environment, a product version detail, a choice between two solutions, or approval for the next step. If the agent simply has not had time to investigate the issue yet, this status should not be used.

A good internal instruction sounds like this: "We move a ticket to waiting for customer only after sending a message that clearly states what the customer needs to do next." In that case, automatic closure works as a continuation of a clear conversation, not as a filter for agent fatigue.

Examples of correct use of waiting-for-customer

• The agent asked for a screenshot of the error and explained how to take it.
• The agent provided instructions and asked whether they solved the issue.
• The agent requested temporary access to a staging copy of the site.
• The agent asked the customer to choose one of two possible fixes.
• The agent stated that the issue should now be resolved and is waiting for final confirmation.

Examples where waiting-for-customer should not be used

• The agent has not yet reviewed the ticket and just wants to remove it from the active list.
• The team is waiting on a developer, hosting provider, or another staff member.
• The ticket involves payment, access, or a critical error, and the resolution has not been confirmed.
• The user has already sent the requested data, but the agent has not processed it yet.
• The ticket is being used as an internal reminder or a task for the team.

How to train agents without writing long documentation

The best way to introduce the rule is to show agents two or three real examples from your queue. Take one ticket where the customer truly went silent after a question, and another where the team still owes the next reply. Walk through which status fits each case. After that, it becomes easier for agents to understand that auto-close does not replace responsibility for giving a response.

You can also add a short internal note to the agent reply template. For example: "If the issue is resolved, you do not need to reply. If you still need help, just respond in this ticket." That helps the customer and also makes the reason for using the waiting-for-customer status more transparent. When the Automatic Close Tickets warning arrives a few days later, it will not feel abrupt.

How to handle a reply after automatic closure

Sooner or later, a customer will come back after the ticket has been closed. That is a normal scenario, not a configuration failure. Your internal rule should explain what the agent does next: reopen the old ticket, create a new one, change the status, or ask the customer to continue in a new request. The right choice depends on your site policy and on the current SupportCandy configuration.

For most teams, the easiest approach is to find the old closed ticket first and review the context. If the issue is the same and the history matters, continuing the old ticket makes sense if your process allows it. If it is already a different issue, opening a new request and referencing the previous history is usually cleaner. The main thing is not to leave the customer in a situation where the system closed the ticket and the team has no idea how to bring it back into the workflow.

Working rule: auto-close should end a stalled conversation, but it should not cut the customer off from support. Every warning and every internal instruction should leave a clear path forward.

Use cases where the add-on delivers the most value

Automatic Close Tickets is especially useful when stalled tickets appear as a repeating pattern. If your site receives only one or two requests a week, manual closure may be simpler. But when ticket volume grows, old threads start to distort the picture of workload: the agent sees dozens of open tickets even though some of them have been waiting on the customer for a long time and do not need immediate action.

Below are a few scenarios where auto-close helps not only "clean up old tickets," but also make support clearer for the customer, the agent, and the administrator.

Confirming a fix after instructions were provided

This is the simplest and safest scenario. The agent gives instructions, for example asking the customer to refresh the page, check access, re-download a file, or clear the browser cache. After replying, the agent moves the ticket into waiting-for-customer. If the customer does not come back, the system sends a warning and closes the request after the selected timeframe.

The strength of this scenario is that the customer has already received a useful answer. The closure does not feel like a refusal to help, because the email can say: "If the issue is still there, just reply in the ticket." For the team, it is also a good way to avoid keeping open the requests that are likely already resolved but never explicitly confirmed.

Waiting for additional data

In technical support, it is often impossible to continue without customer data: logs, screenshots, access details, the error text, a page URL, browser information, or a list of steps that caused the issue. In that case, auto-close works as a gentle control layer for an incomplete request.

But there is an important nuance here. The warning email should repeat what data is still needed. If the customer only gets a generic message saying "your ticket will be closed," they may not remember what exactly you asked for. That is why the agent reply before switching to waiting-for-customer should clearly list the request, and the warning template should include a link or prompt that helps the customer return to the agent's last message.

Cleaning up seasonal or temporary requests

Stores and educational projects often receive requests that matter only for a short period: webinar access, a temporary promotion, file download issues, scheduling questions, or last-minute clarifications before an event. If the customer does not reply after the issue is addressed, there is little value in keeping that ticket open for long. Auto-close helps finish those threads without manual review.

In those cases, it is important not to confuse auto-close with deleting history. Even if the issue is temporary, the conversation history may still matter later for repeat contact, reporting, or analysis of common problems. So closure is fine, but fast cleanup without a trace should only happen after a separate decision about data retention.

Separating customer silence from internal waiting

Sometimes a ticket is stalled, but not because of the customer. The agent may be waiting for a bug fix release, a developer response, a manager decision, or information from an external service. Those requests should not be closed by a waiting-for-customer rule. They are better handled with a separate internal status that is not included in Ticket status to check for auto-close.

This separation makes the queue more honest. The waiting-for-customer status contains only the tickets where the customer can actually move the process forward. Internal waiting contains team tasks. Automatic Close Tickets works only with the first group, while the support manager can monitor the second group separately.

How not to damage the customer experience with automation

Automatic closure is technically easy to set up, but much harder to make feel right from the customer's perspective. The user does not see your admin panel, status list, or internal rules. They see the email and the closure. If the email sounds cold, the timeframe is too short, and the path to continue is unclear, even a useful automation will come across as carelessness.

Write the warning as part of support, not as a system punishment

The email subject should be calm and specific. "We need your reply on this ticket" or "Please confirm whether your issue is still active" works better than a blunt "Your ticket will be closed." In the body, explain that the ticket is waiting for a response and that the customer can simply reply if help is still needed.

Avoid wording that makes the customer sound at fault. Support can be strict about timelines, but the tone of the message should still preserve trust. If you use several warnings, the first should be gentle, and the final one should be more direct while still remaining clear and respectful.

Do not bury the closure message inside complicated templates

Sometimes an administrator wants to create a polished email with a long explanation, multiple links, a signature, a conversation history, and several content blocks. For auto-close, that is usually unnecessary. The customer needs to understand three things quickly: which ticket the email is about, what is expected from them, and what happens if they do not reply.

If the email is too long, the main point gets lost. Use macros selectively: the customer name, ticket number or subject, and a link to the request if it works correctly in your configuration. Everything else is usually better left in the ticket history itself.

Align your timing with your public support promises

If your website says that support replies within a few business days, but auto-close happens almost immediately after the agent's response, the process feels inconsistent. The customer may reasonably assume they should have more time. The closure timeframe should reflect not only your internal desire to clean up the queue, but also the public tone of your support.

For premium or B2B support, a gentler model usually works better. For high-volume simple questions, the window can be shorter, but the warning still needs to be clear. In any case, do not just verify settings. Review actual user reactions after launch as well.

Think separately about reopening

The customer experience breaks down when someone replies after closure and has no idea what happens next. If your configuration allows a closed ticket to continue, document that in your support process. If a new ticket is required instead, make that path obvious. In the email, you can carefully say: "If this ticket has already been closed, please open a new request and include your previous ticket number."

This message matters even more on sites that use guest tickets, email piping, or several contact channels. The user may reply from email instead of from the customer portal. Make sure you test how your configuration actually handles replies to closed requests.

Verifying the result after enabling it on a live site

After saving the settings, you need to verify more than the technical fact of closure. The customer should understand the email, the agent should see the status change, and the administrator should be able to find the closed ticket and continue working with it if needed.

Administrator checklist

• A test ticket has been created in the selected waiting-for-customer status.
• A second test ticket has been created with an active status that should not be closed.
• The warning email has a clear subject, correct macros, and does not read like a promotional message.
• After the customer replies, the ticket should not keep moving through the closure flow as inactive.
• After automatic closure, the status matches the selected value.
• The closed ticket can be found through a filter or through the customer's history.
• If archiving is enabled, it does not remove the ticket too quickly.

Verification from the agent's point of view

Ask an agent to complete one full test scenario. They should reply to the customer, move the ticket into the waiting status, see it in the list, and understand what is supposed to happen next. If the agent has to guess which status to choose after replying, automatic closure will behave inconsistently.

It also helps to add a short internal instruction: "After replying with a clarification question, set the ticket to waiting for customer. Do not use this status if the next step belongs to the agent." That kind of rule is often more effective than trying to build overly complex automation logic.

Verification from the customer's point of view

Send a test warning to a normal inbox and evaluate it without relying on your internal knowledge of the setup. Is it obvious which ticket the message refers to? Is it clear what the customer needs to do? Does it feel like support is closing the request without warning? If the email sounds too harsh, rewrite it before using it with real customers.

Sign of a good setup: the customer understands that the ticket is being closed because there was no reply, but can continue the conversation with a normal response if needed.

Safe improvements without editing plugin code

For Automatic Close Tickets, do not invent PHP hooks or modify add-on files unless the documentation confirms a specific programming interface. It is much safer to improve the process through statuses, email templates, mail verification, and agent instructions. That reduces the risk of breakage after updates and keeps the product maintainable.

Improvement 1: add a short note to the email template

The most useful improvement is to add one short human sentence to the warning body. It should explain that closure does not mean support is refusing to help. For example: if the issue is still relevant, reply to this email or open the ticket in your account. Wording like that increases the chance that the customer returns to the same conversation instead of creating a new ticket.

Improvement 2: create a short internal rule for agents

Create a short team rule and keep it next to your regular support instructions. You do not need a separate extension or any code. Three points are enough: when to apply the waiting-for-customer status, when not to apply it, and what to do if the customer replies after closure. This directly affects how well Automatic Close Tickets performs.

Improvement 3: check deliverability through an SMTP plugin

If warnings are not arriving, first test general WordPress email delivery. In practice, that usually means SMTP configuration or a sent-mail log. Choose the specific tool that matches your site's policy. The important part is not to change your auto-close rules prematurely if the real issue is email delivery.

This guide intentionally does not include code snippets. For this add-on, it is safer to rely on documented SupportCandy settings, email templates, and statuses than to suggest unverified hooks or file edits. If you need a programmatic integration, first review the developer's current documentation or contact product support.

Why auto-close or warnings may behave incorrectly

It is best to troubleshoot this in order: ticket status, inactivity window, email template, mail delivery, closed status, and related archive settings. Do not start by reinstalling the add-on. In most cases, the problem turns out to be the selected status, the wrong expectations around timing, or the site's overall WordPress mail configuration.

The ticket did not close after the selected period

Symptom: the test ticket stays in the queue longer than expected, but the status does not change to closed. A likely reason is that the ticket is not in one of the statuses listed in Ticket status to check for auto-close, or the ticket had recent activity that restarted the inactivity period.

Check the ticket's current status, reply history, and the date of the last action. Then make sure the selected status is actually included in the rule. If your test is extremely time-sensitive, do not project those conclusions onto the live site too quickly: automated processes may run on the WordPress schedule rather than instantly.

The wrong tickets are being closed

Symptom: requests that still need an agent reply are being moved to the closed status. In almost every case, this means the rule includes a status that is too broad, or the team is using the waiting-for-customer status incorrectly.

The fix starts with removing unsuitable statuses from the rule. After that, review your agent instructions. If the waiting-for-customer status is being used as a generic way to "get a ticket out of sight," the automation will keep making the same mistake.

The warning is not reaching the customer

Symptom: the ticket matches the rule, but the customer does not receive the email before closure. Check whether the template was created in Support - Email Notifications - Automatic Close Tickets, whether the right notification is enabled, and whether Days Before Closing is set correctly.

If the template looks correct, test your site's overall WordPress email delivery. Standard notifications for ticket creation and agent replies should already be working before you test auto-close. If no emails are arriving at all, the problem is not specific to this add-on.

Macros in the email are not being replaced

Symptom: the customer sees a technical token instead of a name, subject, or ticket data. A likely cause is an incorrect macro name or the use of a macro that is not in the current SupportCandy macro list. Open the documented macro list and replace any questionable tokens with confirmed ones.

After fixing the template, send a test email on a separate ticket. Do not judge macros only by how they look inside the template editor, because the final result depends on real ticket data.

The customer replied, but the ticket still closed

Symptom: the ticket still received the closed status even after the customer responded. Check whether the reply was added to the correct ticket, or whether it arrived as a separate email without being linked back to the request. If you use email piping or mail-based replies, verify that your base reply handling is working correctly.

Also verify whether the ticket remained in the waiting-for-customer status after the reply. In some workflows, the agent must manually move the ticket back to an active status. If the team wants more advanced behavior than that, it may be better to look at separate automation rules rather than stretching auto-close beyond its core purpose.

Closed tickets disappear from the list too quickly

Symptom: after auto-close, the ticket becomes hard to find. A likely reason is enabled archiving for closed tickets or a list filter that hides closed statuses. Check your archive settings and ticket-list filters.

If automatic deletion of archived tickets is enabled, proceed carefully. SupportCandy documentation warns that deleted archived tickets cannot be restored. For support teams, this is a sensitive area: define your retention policy first, then enable cleanup.

Quick diagnostics for Automatic Close Tickets

Problem	What to check first	Safe fix
The ticket does not close.	The ticket status and the latest activity.	Keep only the correct waiting-for-customer status in the rule and rerun the test.
Active requests are being closed.	The list of candidate statuses.	Remove broad statuses such as new or in-progress tickets from the rule.
The warning is not sent.	The Automatic Close Tickets template and overall mail delivery.	Check standard notifications and SMTP delivery.
Macros appear as plain text.	The exact macro name in the current list.	Replace the unconfirmed token and send a test email.
The ticket disappeared after closure.	List filters, archiving, and archive deletion.	Disable risky deletion and set up a clear filter for closed tickets.

When SupportCandy Automatic Close Tickets is the right choice

SupportCandy Automatic Close Tickets is worth using if you already have a working SupportCandy setup, a dedicated waiting-for-customer status, and a clear policy for closing inactive requests. In that case, the add-on fills a specific gap: it removes stalled tickets from the active queue, warns the customer in advance, and helps agents avoid spending time manually reviewing old threads.

The product may not be the right fit if you need complex multi-step automation with different conditions, agent assignment, internal actions, and branching logic. In that case, it makes sense to look for a broader workflow module or an alternative support system. But for the task of "close tickets after no customer reply and send a warning first," this is a logical extension for SupportCandy.

Before launching on the live site, walk through one short final checklist: one waiting-for-customer status, a sensible timeframe, a clear closed status, one warning, a test ticket, and a verified email delivery path. If everything behaves as expected, you can download the SupportCandy Automatic Close Tickets archive and roll out the rule gradually, starting with a small group of tickets.

The best result does not come from the strictest automation. It comes from a clear process. The agent understands when to use the waiting status. The customer receives a human warning. The administrator can see closed tickets and verify that the rule is working correctly. That is the scenario that makes automatic closure useful rather than risky.