SupportCandy Reports - WordPress Plugin

Guide to SupportCandy Reports: How to Read Support Reports and Turn Them into Action

SupportCandy Reports is not about pretty charts for the sake of reporting. It is meant for day-to-day support management inside WordPress. In this guide, we will look at what data the add-on shows, how to prepare your base SupportCandy setup, where to find report settings, how to use filters and date ranges, what to verify after installation, and how to avoid drawing the wrong conclusions from incomplete data.

This guide is intended for site owners, WordPress administrators, support managers, and specialists who already use SupportCandy as a ticketing system and want to understand their team’s workload: how many requests are coming in, how quickly agents respond, how long tickets take to close, where conversations get dragged out, and which categories demand the most attention.

You will also find a practical scenario for an online store or service-based site where reports help separate a real process issue from a normal spike in ticket volume. The guide also covers result validation, common mistakes, FAQ, comparable solutions, and careful recommendations for safe testing without modifying WordPress core, SupportCandy, or the add-on itself.

What the Reports Add-on in SupportCandy Actually Solves

A typical ticketing system has two layers. The first layer is what agents see: the list of requests, statuses, replies, attachments, notes, assigned staff, and conversation history. The second layer is what a manager needs: what is happening across the support process as a whole. SupportCandy Reports is built for that second layer. The add-on generates reports from ticket data and reveals trends that are hard to spot when you are only looking at individual requests.

According to the official add-on page and documentation, Reports includes several core report types: created and closed ticket statistics, first and average response delay, ticket closing delay, communication gap, satisfaction ratings, and reports based on applicable custom fields. That makes the add-on useful not just for counting how many tickets came in, but for analyzing process quality.

The main practical value of SupportCandy Reports is that it connects workload to team behavior. If ticket volume goes up, that does not automatically mean support is performing worse. If average closing time increases, that is not always an agent issue. The category mix may have changed, a new product may have launched, a form may have broken, the email flow may have shifted, or some tickets may be going to the wrong staff member. Reports help you test those kinds of hypotheses against actual data.

What Questions Reports Can Help Answer

The add-on becomes especially useful once support no longer fits the model of "we answer things as they come in." As soon as a site has multiple agents, different categories, priorities, products, integrations, or customer groups, the ticket list stops being enough as a management tool. You need slices of data by period, category, priority, status, rating, or custom field.

• How many tickets are created and closed during the selected period.
• Where the backlog is growing: in new requests, follow-up replies, or the closing stage.
• How quickly the team gives a first response and how often conversations continue after that.
• Which categories, priorities, or fields generate a disproportionate amount of work.
• Where there is a gap between the visible ticket count and the real support effort behind it.
• Whether it is time to change the contact form, knowledge base, agent assignment rules, or internal instructions.

One important nuance: Reports does not replace a sensible review of actual tickets. A chart shows a pattern, but the reason behind it still needs to be verified through the tickets themselves, field settings, notification rules, work schedules, and agent actions. A good reporting workflow looks like this: spot an anomaly, choose a filter, open several representative tickets, confirm the cause, and only then change the process.

Who SupportCandy Reports Is Best For and When It May Be Unnecessary

The add-on delivers the most value on sites where SupportCandy has already become the operational hub for support. That could include WooCommerce stores, digital product sites, learning platforms, WordPress-based SaaS services, agencies handling client work through tickets, or internal request portals. In all of those cases, reports help you do more than count requests. They help you understand what is actually slowing support down.

If a site only gets a handful of requests each month, Reports may be more than you need. In that case, the ticket list, saved filters, and manual review may be enough. The add-on starts paying off when there is repetition: recurring categories, predictable peak periods, multiple agents, complaints about response speed, or a regular need to explain to the project owner what is going on in support.

Good Use Cases

A very natural use case is when the team wants to track trends over time. For example, after a product update, requests in the "errors" category increase, but tickets are still getting closed quickly. That leads to one conclusion. Another example: the number of created tickets stays about the same, but average response time slows down. In that case, the issue is probably not marketing volume. You should look at agent schedules, notifications, assignment rules, and queue distribution instead.

Reports is also useful for sites where tickets include extra fields. The documentation states that reports can be generated for some custom field types: single select, multiple select, checkbox, and radio button, as well as category, priority, rating, and SLA. That matters most when a field like "Issue Type," "Product," "Plan," "Region," or "Request Source" helps drive management decisions.

When You Should Start Somewhere Else

If your basic SupportCandy setup still lacks properly configured pages, agent roles, notifications, categories, and required form fields, reports will mostly show noise. First, you need tickets to be created in a consistent way, agents to change statuses according to clear rules, closed statuses to actually mean finished, and categories to be intentional rather than random. Otherwise, a "closed" chart will reflect data entry habits, not support quality.

Practical rule: if the team has not agreed on when a ticket is truly closed, the Ticket Closing Delay report cannot be used as a performance metric. First define the process, then interpret the chart.

What to Check Before Installing and Running Reports for the First Time

SupportCandy Reports depends on the quality of the data in your base SupportCandy setup. That makes preparation more important than the ZIP installation itself. Before enabling the add-on, check not only your WordPress and PHP requirements, but also how the team handles tickets in practice. The official add-on page lists the minimum WordPress and PHP requirements, and the main plugin page on WordPress.org confirms that SupportCandy is a self-hosted ticketing system with agents, roles, filters, fields, notifications, shortcodes, and ticket data stored inside WordPress.

Basic Pre-Install Checklist

• The main SupportCandy plugin is installed, activated, and updated along with the add-ons you use.
• Your support page is created with [supportcandy], or separate pages are configured with [wpsc_create_ticket] and [wpsc_open_ticket].
• Agents and roles are configured under Support so it is clear who is responsible for which tickets.
• Categories, priorities, statuses, and custom fields do not duplicate each other and have clear names.
• Closed statuses are clearly separated from unfinished ones, otherwise the closing report will be misleading.
• Aggressive caching is disabled for SupportCandy pages if it interferes with forms, ticket lists, or dynamic data.
• You have a site backup and a way to test updates on a copy of the site, especially if the ticket database is large.

If your support workflow depends on email piping, WooCommerce, EDD, Gravity Forms, SLA, Satisfaction Survey, or Workflow/Automations, take those add-ons into account when checking reports. Reports can give you useful slices of data, but it will not fix bad routing rules, broken notifications, or a form that collects categories that are too vague.

What Data You Need for a Meaningful First Report

A new site with an empty ticket database should not expect useful analytics the moment Reports is enabled. At minimum, you need a set of tickets from a period that includes created, closed, and answered tickets. For rating reports, the rating mechanism must be configured and actually used. For custom field reports, the fields must not only exist, but also be filled in on real tickets.

If a field was added after most of your tickets were already created, the first reports for that field may look sparse. That does not necessarily mean the add-on is broken. Some older tickets simply do not contain the data needed for that slice. In that situation, it is better to choose a period after the field was introduced or explicitly separate old data from new.

Installation and the First Validation After Activation

The official SupportCandy documentation describes the standard installation path for the main plugin through the WordPress directory or by uploading a ZIP file. The logic for the Reports add-on is similar to any other WordPress plugin add-on: the base SupportCandy plugin must already be active, then the add-on is installed and enabled from the plugins area. We will not cover purchasing, billing, license keys, or the vendor account here. For this guide, what matters more is what to check after activation so you do not mistake an empty screen or stale data for normal behavior.

Your First Route Through the Admin Area

After activation, check the path Support -> Settings -> Reports. In the documentation, this screen is described as the place for general report settings. This is where you set the default duration and choose which custom fields should generate reports. Then go to Support -> Reports and open several basic reports: Ticket Statistics, Response Delay, Ticket Closing Delay, and Communication Gap.

What Counts as a Successful Installation

A successful installation is more than just seeing a new menu item. Make sure the selected period changes correctly, the report responds to filters, charts are built from real tickets, report printing is available where supported, and custom fields only appear after being added in Reports settings. If you see an empty chart, first verify the date range and the presence of data before assuming there is a conflict.

1. Open Support -> Reports and choose a period where you know tickets exist.
2. Compare the number of created tickets with a filter in Support -> Tickets for the same period.
3. Open tickets that should be closed and confirm that their status belongs to a closed group.
4. Check one report without a filter and one with a category or priority filter.
5. If you use custom fields, add only 1-2 of the most important ones and see whether they appear in Reports.

Do not enable every possible field just in case. The more slices you add, the harder it becomes to understand which ones actually help. Start with fields you are prepared to make decisions on: category, priority, product, request type, plan, or request source.

How to Configure Reports So the Charts Answer Real Questions

Configuration should start with a question, not with the interface. The wrong approach is to open every report and hope something interesting appears. The right approach is to define an operational hypothesis: "workload increased after launching a new product," "first response got slower," "some tickets are taking too long to close," or "one category requires too many follow-up clarifications." Then you choose the report, period, and filter that match that hypothesis.

Default Duration: Why the Default Period Matters

Reports settings include a default duration. It determines which period is used as the starting view. For daily monitoring, a short period is convenient: the current week or the last few days. For a management overview, a broader period that smooths out random spikes is usually better. The exact value matters less than whether it matches the team’s working rhythm.

If support runs on weekdays, comparing very short periods can be noisy: weekends, holidays, promotional emails, and product updates can all create sharp peaks. If ticket flow comes in waves, do not draw conclusions from a single short interval. Use a custom date range and compare matching periods. Otherwise, you may mistake seasonality for a process problem.

Generate Reports for Custom Fields: Choose Only Fields with Management Value

The documentation states that reports can be generated for certain custom field types, including single select, multiple select, checkbox, and radio button. That is a sensible limitation because those fields produce a finite set of values that can be aggregated cleanly. Text fields, long descriptions, and freeform comments are much less suitable for reporting because they cannot be turned into a clear chart without separate processing.

The best candidates for field-based reports are the ones where the user’s answer affects the process: product, issue category, plan, department, priority, customer type, or request source. The worst candidates are fields that are rarely filled out, frequently renamed, or cluttered with near-duplicate values like "error," "problem," "not working," and "broken."

How to Safely Add a New Field to Reports

1. Confirm that the field is already being used in the form or in tickets and that it has predictable values.
2. Add it under Support -> Settings -> Reports -> Generate reports for custom fields.
3. Open Support -> Reports and choose a period where that field is definitely populated.
4. Compare the chart with several real tickets to make sure the meaning of the field is being interpreted correctly.
5. If the field does not help you make decisions, remove it from reports and keep it in the form only as reference data.

Filters: Do Not Mix All Tickets into One Metric

The official Reports page says that applicable reports support filtering conditions similar to the filters used in the ticket list, and that filters can be saved with a custom name. This is one of the most important features in practice. An average across all support activity often hides a problem in a single category. If "technical issue" tickets take a long time to close while "billing question" tickets are handled quickly, the overall chart will smooth that difference out.

A filter should be narrow enough to answer a question, but not so narrow that you are left with two tickets and no meaningful conclusion. For example, a filter like "Category equals Pre-sale Questions" is useful if that category is actually used consistently. A filter like "Category equals Pre-sale Questions + Priority equals High + Agent equals John" may be too narrow for ongoing analytics if the data set is small.

How to Read the Main Reports Without Drawing False Conclusions

Reports shows several different metrics, and each of them answers a different question. A common beginner mistake is to treat them as if they all mean the same thing. The number of created tickets reflects incoming volume. The number of closed tickets reflects completion. First Response Delay measures the speed of the initial reply. Average Response Delay is closer to the overall pace of the conversation. Ticket Closing Delay shows how long it takes to close a ticket. Communication Gap describes the average number of messages exchanged before a ticket is closed.

Ticket Statistics: Incoming Volume and Closures

Ticket Statistics shows the trend for created and closed tickets over the selected period. This is the basic report for answering the question, "Is the backlog growing, or is the team keeping up?" If more tickets are being created than closed, that may be a warning sign, but not always. Some tickets may be waiting on the customer, some may belong to long-running tasks, and some may intentionally remain open until a larger project is complete.

The correct validation is straightforward: open a few of the tickets that remain open. If they are waiting on the customer, you need a waiting status and a clear closure policy. If they are waiting on an agent, the issue is workload distribution. If the tickets are effectively resolved but the status was never changed, then the problem is process discipline, not support quality.

Response Delay: First Reaction and Average Reply Time

The documentation distinguishes between First Response Delay and Average Response Delay. The first measures the time until the agent’s initial reply. The second measures the average reply time throughout the conversation. These metrics should not be mixed together. The first response matters because it affects whether the customer feels ignored. The average reply time matters because it reflects how the ticket is actually moving toward resolution.

If First Response Delay looks good but Average Response Delay looks weak, the team is picking up tickets quickly but losing momentum afterward. The reasons can vary: complicated clarifications, a weak knowledge base, ineffective reply templates, incorrect agent assignment, or a lack of decision-making authority. If the opposite is true and the first response is slow while the rest of the exchange moves normally, look at notifications, business hours, agent schedules, and assignment rules.

Ticket Closing Delay: Resolution Speed, Not Just Reply Speed

Ticket Closing Delay shows the average time until a ticket is closed. It is useful when you want to understand how long the customer remains inside the support process. But this report is highly sensitive to status rules. If an agent solves the issue but never closes the ticket, the metric rises. If tickets are auto-closed too early, the metric may look great while the actual customer experience is worse.

Do not use Ticket Closing Delay as the only quality metric for an agent. One staff member may handle complex categories while another handles simpler requests. First filter by category, priority, product, or request type, and only then compare outcomes.

Communication Gap: How Many Messages It Takes to Reach a Resolution

In the documentation, Communication Gap is described as the average number of threads exchanged between agent and customer before the ticket is closed. It is one of the most useful reports for improving the process. A large communication gap often means the customer has to clarify the same thing multiple times, the form does not collect enough data, the agent replies too broadly, or the instructions do not fully answer a common question.

If Communication Gap increases in one category, open 5-10 tickets from that slice and look at exactly where the extra messages appear. Common reasons include a missing required field, customers not attaching screenshots, agents requesting details one piece at a time, the absence of a standard diagnostic template, or outdated product documentation.

Ratings and Custom Fields: Quality Through the Customer Lens and Business-Level Slicing

Ratings are only useful when the rating mechanism is actually enabled and customers are using it. A low number of ratings should not be treated as a precise quality indicator. More often, it suggests that you should carefully check the rating request email, where the form is shown, how the message is worded, and whether the survey is being sent after closure.

Custom fields help translate support data into business terms. If most tickets come from one product, that is a signal for documentation or a product fix. If customers frequently assign high priority without real urgency, it may be time to revise the guidance in the form. If a specific plan produces more long back-and-forth conversations, new users may not be getting enough onboarding guidance.

Practical Scenario: Finding the Cause of Slower Responses After a New Feature Launch

Imagine a digital product site where SupportCandy handles customer requests. After a new feature launch, the manager starts hearing complaints that "support is taking longer to respond." Without Reports, the team argues from impressions. With Reports, you can take a short path from symptom to a verifiable cause.

Goal

You need to determine whether response delay really increased, which category it happened in, and what should be changed: the request form, assignment rules, reply templates, knowledge base, or the staffing of the support shift.

Preparation

Before you start, make sure tickets related to the new feature fall into a separate category or use a custom field such as "Product," "Module," or "Request Type." Without that, a report across all support activity will only show general noise. Also check that agents close tickets with the correct status, and that customers are not opening duplicate requests for the same issue instead of replying within the existing ticket.

Analysis Steps

1. Open Support -> Reports -> Ticket Statistics and select the period after the feature launch.
2. Compare the number of created and closed tickets without a filter to understand the overall flow.
3. Add a filter for the category or custom field related to the new feature.
4. Open Response Delay and review First Response Delay and Average Response Delay separately.
5. Check Communication Gap with the same filter: did the number of messages before closure increase?
6. Open several real tickets from that slice and note which details the agent has to request repeatedly.

Result Validation

If First Response Delay increased only in the new category, the cause may be routing: tickets are not being assigned to the right agent, or notifications are not arriving. If Average Response Delay and Communication Gap rise together, the issue is more often related to input quality or instruction complexity. If Ticket Closing Delay increased but replies are still fast, tickets may be getting stuck in a waiting-for-customer status or simply not being closed after resolution.

The Nuance That Often Breaks the Conclusion

If the new feature triggered many repeat questions, do not rush to blame support. The form may not be asking for the product version, a screenshot, the page URL, or exact reproduction steps. In that case, the best fix is not "reply faster at any cost," but improving the ticket form, the first-response template, and the documentation. In this scenario, Reports reveals not only team speed, but also the quality of the incoming process.

Result Validation: How to Tell Whether Reports Is Configured Correctly

After configuring Reports, you need to make sure the charts match reality. This is especially important on sites where SupportCandy has been in use for a long time, there are many statuses, custom fields have changed over time, and some tickets are created via forms, email, or integrations. The validation does not need to be complicated. It is enough to take one period, one filter, and several tickets you can open manually.

Cross-Checking Against Real Tickets

Choose a period tied to a clear event: a newsletter launch, product update, promotional campaign, site migration, or form change. Open Ticket Statistics and note the number of created and closed tickets. Then apply the same period and a similar filter in the ticket list. The numbers do not always have to match perfectly because of status logic and different views, but a large discrepancy should be investigated.

For Response Delay, take 3-5 tickets and manually check the creation time and the first agent reply. For Communication Gap, open the conversation thread and see whether a large number of messages is really being spent on follow-up clarification. For custom fields, confirm that the selected values are actually filled in on the tickets themselves and were not only added to the form after the fact.

Printing and Sharing the Report

The Reports documentation mentions the ability to print a report for a custom duration. Use that as a way to prepare a short summary for a meeting, but do not turn the printed version into your only source of truth. Before sharing it with a manager, add a short text note explaining which period was selected, which filters were applied, what was excluded from analysis, and what actions are being proposed.

Quick Summary After Setup

A well-configured Reports setup should answer specific questions rather than just display charts. A good outcome looks like this: the team knows which report to open, which period to choose, which filter to apply, where to verify the underlying tickets, and which process changes can be tested with the same report during the next working period.

Useful Working Habits for Ongoing Support Analytics

Reporting becomes useful when it is reviewed regularly and in a consistent way. If the period, filters, and closure criteria change every time, comparison stops being meaningful. That is why, after the initial setup, it helps to agree on a simple rhythm: a quick daily look at incoming flow, a weekly review of delays, and separate analysis after major releases or marketing campaigns.

Saved Filters as Operational Views

The official Reports page mentions the ability to save filters with a custom name. That is useful for recurring slices such as "product bugs," "high priority," "pre-sales questions," "WooCommerce tickets," or "VIP customer requests." The filter name should make sense not only to the person who created it, but also to another administrator who opens the report a month later.

Do not create dozens of filters right away. It is better to start with 3-5 working views and delete the ones nobody uses. If a filter is needed only for a one-time investigation, there is no reason to save it permanently. The fewer unnecessary views you have, the lower the risk of opening the wrong slice and drawing the wrong conclusion.

Keeping Reports Aligned with Ticket List Settings

The SupportCandy ticket list documentation describes default filters, filter items, and saved filters. This matters for Reports because reports and the ticket list should speak the same language. If agents are used to filtering the ticket list by category and priority, Reports should use similar conditions. That makes it easier for the team to connect a chart to specific requests.

What to Do with a Problem Once You Find It

Every report should end with an action, or with a conscious decision to change nothing. If Communication Gap increases, improve the form and add a required field. If First Response Delay increases, check notifications and staffing coverage. If Ticket Closing Delay increases, refine your status rules and automatic closing policy. If a custom field report shows one category is overloaded, add documentation or assign a dedicated agent.

Do not change everything at once. Make one clear change, wait for a meaningful period, then compare the same report with the same filter again. That is how Reports becomes an improvement tool rather than a gallery of attractive screenshots.

Product-Specific Scenarios: What Decisions to Make Based on Different Reports

The most common mistake in support analytics is treating reports like a scorecard for agents. In practice, SupportCandy Reports is more useful as an early warning system for problems in the product, documentation, request form, and routing logic. The same metric can mean different things in different contexts. That is why the scenarios below matter. They cannot be replaced with generic advice like "just check the chart."

When Created Tickets Increase but Closures Keep Pace

If Ticket Statistics shows more created tickets and the number of closed requests is growing at roughly the same rate, the situation is not necessarily bad. The site may have grown, marketing may have brought in new customers, there may have been a newsletter, or a product update may have triggered more interest. In that case, Reports helps prevent panic: the team is coping, but you still need to understand whether the structure of requests is changing.

The next step is to apply a category or custom field filter. If the increase is spread evenly across all categories, you can plan staffing and improve the knowledge base. If the increase comes from one category, that is already a product clue. For example, a new setting may be confusing users, a help page may not answer the real question, or the order form may be creating expectations that support has to explain manually.

What Counts as a Useful Conclusion

A useful conclusion should sound like an action: "add guidance to the form," "update the knowledge base article," "assign an agent to this category," "check the post-purchase email copy," or "change the status after resolution." A statement like "ticket volume increased" is useless on its own until you connect it to a source and a follow-up check.

When First Response Is Fast but Closure Takes Too Long

This scenario is especially important in SupportCandy Reports because it highlights the difference between Response Delay and Ticket Closing Delay. A fast first reply can hide a slow resolution. The agent sees the ticket and responds, but the conversation keeps dragging on. The cause may be a complex category, limited agent permissions, a wait for a developer, the lack of a diagnostic template, or the fact that the customer has to send details in multiple steps.

Here you need to look at Communication Gap and real tickets. If the thread contains many clarifications, improve the form and the first reply. If there are only a few messages but the ticket stays open for a long time, review statuses and internal expectations. If the agent quickly says "we passed this to a specialist" but the solution never appears, the problem is not first-line support. It is escalation.

When Communication Gap Increases in Only One Category

Communication Gap is especially good at showing where the customer and agent fail to understand each other on the first try. If the metric is high across all categories, support may not have a consistent diagnostic style. But if it rises in only one category, that is almost always a subject-matter problem: a missing field, unclear instructions, a missing screenshot, an imprecise product choice, a missing version number, a missing URL, or missing order context.

For a category like that, it is useful to open several closed tickets and create a small map of recurring clarifications. For example, the agent may ask for the page URL, browser type, and reproduction steps every time. In that case, there is no need to coach the agent to "be more attentive." You need to change the request form or the first-response template. In the next period, the same filter will show whether the number of messages before closure went down.

When Custom Field Reports Conflict with the Team’s Intuition

Sometimes the team is convinced that one product or department causes most of the trouble, but the custom field report shows something else. Do not argue with the data too quickly, and do not trust it blindly either. First check how the field is being filled out. If the agent chooses the category after reading the ticket, the metric depends on agent discipline. If the customer selects the value, the metric depends on how clear the options are. If some requests come in through email or an integration, the field may be populated differently.

A good practice is to do a brief audit of field values. Remove duplicates, rename unclear options, and do not mix technical and commercial categories in the same field. For reporting, 6-8 clear values are usually better than 30 options that nobody uses consistently. Reports will not fix a bad taxonomy, but it will quickly show where that taxonomy is getting in the way of decision-making.

How to Use Reports in a Team Meeting

A regular support review should not turn into reading every chart one by one. Choose 2-3 metrics that match the current goal. For example, if the team is trying to improve first-response speed, look at First Response Delay for key categories. If the goal is to reduce repeated follow-up questions, look at Communication Gap. If the goal is to reduce pressure on a difficult category, look at Ticket Statistics and the custom field report for that category.

After the meeting, record not only the number itself, but also the filter that was used. Repeat the same slice during the next period. If you change the filter or date range, the team will not know whether the adjustment actually helped. That is why saved filters in Reports are useful not only for convenience, but also for measurement discipline.

Common SupportCandy Reports Issues and How to Diagnose Them

Problems with reports are usually caused not by the chart itself, but by the data, date range, filters, caching, interface conflicts, or outdated add-ons. The Reports changelog includes fixes related to Ticket Statistics loading, filters, large data sets, report printing, date localization, and the display of certain reports. That is a good reason to always start troubleshooting with basic checks and updates on a site copy.

The report is empty even though tickets exist

Symptom: you select a report in Support -> Reports, but the chart is empty or shows zeros. Possible causes include a date range with no matching tickets, a filter that is too narrow, tickets that do not have a closed status, a custom field that was added to reports after the tickets were created, or data tied to an unsupported field type.

What to check: remove the filter, choose a wider period, open several tickets manually, and verify their dates, statuses, and populated fields. If the issue involves custom fields, make sure the field is a supported type and has been added in Reports settings. If the report still does not appear after that, update the main SupportCandy plugin and all add-ons on a test copy.

The report filter gives a strange result

Symptom: a category, priority, or field filter shows clearly fewer or more tickets than expected. Possible causes include inconsistent category names, old tickets with an empty field, overly complex conditions, or a mismatch between the ticket-list filter and the report filter.

Start the fix with a simple one-condition filter. Then add the second condition and compare the result. If the field was renamed or its response options changed, do not merge old and new data without checking them first. When in doubt, open the ticket list and manually inspect several items from the selected slice.

The chart loads, but the numbers do not match the team’s expectations

Symptom: the team believes there are more or fewer closed tickets than the report shows. A common cause is misunderstanding statuses. SupportCandy allows custom status configuration, and the closing report depends on which tickets are truly treated as closed in the workflow.

Check which statuses the team uses for completed requests and whether something like "resolved, waiting on customer" is sitting inside the closed group. If the process changed over time, compare only periods after the change. For earlier periods, add a note to the report summary. Otherwise, the chart may look like an error when it is really reflecting an older process.

The reports page is slow or cannot build a large date range

Symptom: reports open slowly, especially across a long period or in a large ticket database. The Reports changelog has previously mentioned fixes for large data sets and performance. Even so, large databases still require a careful approach.

What to do: check the report over a smaller period, narrow the filter, avoid enabling unnecessary custom field reports, update add-ons on a staging copy, and do not run heavy checks during peak hours. If the site has a very large database, talk to a developer or hosting provider about indexes, cron, object caching, and overall WordPress load. Do not delete old tickets just to make reports faster if you still need them for history or customer obligations.

After an update, part of the Reports interface looks wrong

Symptom: buttons, charts, tabs, or tables look broken, cannot be clicked, or conflict with another plugin. The main SupportCandy changelog has mentioned DataTables conflict fixes, and forum discussions often recommend checking plugin and theme conflicts.

Safe troubleshooting: create a copy of the site, update SupportCandy and its add-ons, temporarily disable caching and script optimization for SupportCandy pages, then test for conflicts with other plugins and the theme. On a live site, do not switch themes just to experiment unless you have a rollback plan. If the problem disappears when a specific optimizer is disabled, exclude support pages from script merging and deferred loading.

The Response Delay metric looks worse after notification changes

Symptom: after changes to notifications or assignment rules, first response appears slower. This may not be a Reports issue at all. It may reflect a real process change. SupportCandy forum discussions about email notifications show a typical troubleshooting chain: check the sender, SMTP, test emails, notification recipients, agent roles, and template conditions.

Fix: verify notifications for new tickets and assignee changes, make sure agents are included as recipients, and confirm that template conditions are not excluding the relevant category. Then create a test ticket during a non-peak period and make sure the notification arrives, the agent sees the ticket, and the first reply appears in the report.

Safe Process Improvements Without Editing Plugin Code

With SupportCandy Reports, there is no reason to invent PHP hooks or JavaScript modifications unless they are directly supported by the documentation. It is more reliable to improve the process through SupportCandy settings, field structure, team rules, and cache exclusions. That approach is safer, reversible, and update-friendly.

Improve the Form if Communication Gap Is Too High

If the report shows too many messages before closure, do not start with the chart. Start with the ticket creation form. The customer may not be specifying the product, version, URL, screenshot, reproduction steps, or urgency. Add one required field with fixed options instead of forcing a long text explanation. Then compare Communication Gap for the same category in the next period.

Refine Statuses if Ticket Closing Delay Is Distorted

The team should clearly distinguish between "waiting on customer," "in progress," "resolved," and "closed." If all of those states are mixed together, the closing report will be too blunt to trust. Do not add statuses just to make the workflow look sophisticated. Add only the ones that change agent action or customer expectations. After changing statuses, record the date in the team’s working notes so you do not compare the old and new process as if they were the same.

Exclude Support Pages from Aggressive Cache Rules

In support-related discussions, the SupportCandy developer recommends excluding support pages from caching if the ticket creation form hangs or the dynamic interface behaves inconsistently. This is not a Reports-specific tweak, but it matters for data accuracy: if a customer cannot create a ticket or the form spins forever, the incoming volume report will reflect a technical issue rather than real support demand.

Validation is simple: create a test ticket as a regular user, open it through the public page, reply as an agent, and confirm that it appears in the list and in reports for the selected period. If the issue disappears after disabling cache, configure an exception in the caching plugin instead of turning off optimization site-wide.

When SupportCandy Reports Is Worth Using

SupportCandy Reports is a strong choice if tickets are already part of your operating workflow and the team wants to see not only individual requests, but the full support picture. The add-on helps you understand incoming volume, first-response speed, conversation pace, closing time, category quality, and the practical value of custom fields.

Before rolling it out, do not try to solve everything with charts. First verify your base SupportCandy setup: pages, shortcodes, roles, notifications, statuses, categories, fields, cache rules, and a test ticket. Then enable Reports, set a default duration, add only the important custom fields, save a few working filters, and agree on how the team will read the metrics.

If you can see that the reports are helping you identify real bottlenecks, you can download the SupportCandy Reports package and test the add-on on your live site or a staging copy. The safest path is to start with one scenario, for example measuring response delay in an important category, improving the form or routing, and then running the same report again to see whether the result changed.

The core takeaway is simple: Reports is valuable not because it shows a lot of numbers, but because it brings discipline to support operations. It forces you to define a question, choose the right slice, verify real tickets, and change only what truly affects service speed and quality.