SupportCandy Productivity Suite - WordPress Plugin

A Practical Guide to Configuring and Using SupportCandy Productivity Suite

SupportCandy Productivity Suite is a set of workflow tools for support teams inside WordPress that extends an already configured SupportCandy help desk. This guide focuses on practical usage rather than product marketing: what to enable after installation, which permissions to review, how to build templates, checklists, and personal tasks around a real ticket-handling process, how to use AI Assistant carefully, and how to verify that the team is actually working faster instead of just getting a few more buttons in the interface.

This article is written for a site owner, WordPress administrator, support manager, or technical specialist who already understands why the site needs a ticketing system. If your site does not yet have the basic SupportCandy pages, agent roles, and a test ticket in place, start there first. Productivity Suite is most useful once you already have an active stream of requests that needs structure: removing duplicates, preventing important tickets from getting lost, standardizing recurring request types, closing internal service tickets without unnecessary notifications, and helping agents work through long conversations more efficiently.

This guide uses careful wording around AI features. The official documentation states that AI Assistant connects to an external provider through an API key and uses settings such as Max Tokens, logs, custom prompt, Ticket Summary, and Polish Reply. That means your workflow should define in advance what data can be sent to AI, who is allowed to use those features, and how agents must review the result before sending anything to the customer.

What Productivity Suite Actually Solves in a Ticketing System

The suite is not meant to replace the entire help desk. Its job is to add a layer of operational discipline on top of it. Core SupportCandy creates tickets, stores conversations, shows the ticket list, provides agent roles, notifications, support pages, and custom fields. Productivity Suite builds on that foundation: it helps an agent understand more quickly what needs to happen with a specific request, which steps cannot be skipped, which template to apply, which tickets need to stay visible, and when a task can be closed without sending another email to the customer.

According to the official product page, the suite includes AI Assistant, Merge Tickets, Checklist, Ticket Templates, To-Do List, Pin Tickets, and Close Ticket Silently. SupportCandy documentation separately covers Checklist, Ticket Templates, To-Do List, Pin Tickets, and Close Ticket Silently under Support > Settings > Productivity Suite. AI Assistant has its own settings section, but it is listed on the Productivity Suite page as part of the bundle, so it makes sense to evaluate it alongside the other productivity tools.

In practical terms, these features improve different layers of the workflow:

• Order inside the ticket. Checklist records mandatory steps, while To-Do List helps the agent manage personal tasks tied to a specific request.
• Order when creating a request. Ticket Templates let you prefill part of the form so agents do not have to build the same structure manually every time.
• Order in the ticket list. Pin Tickets keeps important requests above the usual sorting order, while still respecting the active filter.
• Order in communication. Close Ticket Silently closes a ticket without sending a notification and, according to the documentation, does not trigger a satisfaction survey for that closure.
• Order in long conversations. AI Assistant can summarize ticket context and improve a draft reply, but it requires an external AI provider and a careful data policy.

The key is not to enable everything at once without a process behind it. If the team has no clear rule for when a ticket is ready to close, the checklist will turn into a formality. If ticket categories are not thought through, templates will multiply without structure. If agents have overly broad permissions, Productivity Suite can amplify not only speed but also the risk of mistakes. That is why setup should begin with the ticket journey itself, not with mechanically flipping every switch.

Who This Suite Fits Best, and When It May Be Overkill

SupportCandy Productivity Suite works best for sites where support has already become a regular operational function. That could be a WooCommerce store, an e-learning site, a member-based service, a portal with paid content, an agency that handles clients through tickets, or an internal support desk for a team. The more recurring requests, agent handoffs, internal checks, and "verify first, respond second" situations you have, the more useful checklists, templates, and personal task lists become.

The suite is especially useful when the team includes multiple roles. For example, first-line support receives the ticket and gathers the data, a technical specialist investigates the cause, a manager sends the final response to the customer, and a team lead wants visibility into which requests must not be missed. In that kind of workflow, Checklist sets the shared standard, To-Do List helps a specific agent keep track of their own actions, Pin Tickets highlights critical requests, and Ticket Templates speed up the creation of standard ticket types by category.

The product may be unnecessary for a site where tickets appear rarely and are handled by one person with no repeatable procedure. If the site owner gets one request a week and simply replies by email, the extra layer of Productivity Suite may create more administrative overhead than value. In that case, it is more reasonable to first configure the core SupportCandy pages, notifications, statuses, priorities, and roles, then come back to the extension once repeatable scenarios start to appear.

AI Assistant should be evaluated separately. It is useful for long conversations, agent handoffs, and keeping a consistent tone in replies. But if company policy forbids sending ticket content to external AI services, or if tickets regularly include personal, medical, financial, or other sensitive information, AI features should either remain disabled or be used only after internal approval. The official documentation explicitly states that an external provider API key is required, so this is not a local feature that works without sending data to a provider.

What to Check Before Installing and Enabling Productivity Suite

Before installation, make sure the core SupportCandy system is already working. Productivity Suite should not be your first step in setting up support. You need a working foundation first: SupportCandy installed, support pages created, a clear structure for statuses, categories, and priorities, agent roles configured, test notifications verified, and at least one test ticket created.

Core SupportCandy Pages

SupportCandy documentation describes the support page built with the [supportcandy] shortcode, a separate ticket creation page with [wpsc_create_ticket], and a page for opening an existing ticket with [wpsc_open_ticket]. This matters for Productivity Suite for a simple reason: some features are visible only in the context of the ticket list, the new ticket form, or an individual ticket view. If those pages are not assigned under Support > Settings > General Settings > Page Settings, an agent may enable a feature but still not see the expected result on the public-facing side or in the working interface.

Before enabling the suite, open a test ticket as both a customer and an agent. Verify that the ticket is created, can be opened, replied to, moved to another status, and triggers a notification. This is not a Productivity Suite test. It is a checkpoint that protects you from false troubleshooting. Otherwise, it is easy to assume that Checklist or Ticket Template is broken when the real issue is that the ticket page is not assigned or the agent does not have permission to perform the required action.

Agent Roles and Permissions

In SupportCandy, roles determine what an agent can see and change. The documentation lists core roles such as Administrator and Agent, along with capabilities such as viewing tickets, replying, using private notes, assigning agents, changing status, editing fields, viewing logs, and Modify Checklist. This is critical for Productivity Suite: checklists, pinning tickets, silent closure, and AI tools should not be available to everyone by default. They should be available only to the roles that actually need them.

Practical rule: start by giving the role the minimum permissions it needs, then enable suite features one at a time and test them under a dedicated agent account. An administrator can almost always see more than a regular agent, so testing only as an administrator creates a false sense of readiness.

Email, Notifications, and Surveys

Close Ticket Silently is especially sensitive because of notifications. The documentation states that a silent closure does not send notifications and does not trigger a satisfaction survey for that ticket. That means you need to understand your current notification flow before rolling it out: which emails are sent when someone replies, changes status, closes a ticket, or triggers the satisfaction survey. Otherwise, the team may accidentally close customer requests without the necessary final message, or expect a survey to appear where it should not.

Quick pre-launch check: create a test ticket, reply as an agent, close it the normal way, review the notifications, then repeat the scenario with silent closure after enabling the feature. The difference should be clear before the tool becomes part of your live workflow.

Installation, Activation, and the First Verification Pass

Core SupportCandy is installed like a standard WordPress plugin: through the plugin directory in the admin panel or manually by uploading a ZIP archive. Productivity Suite is an add-on for SupportCandy, so your internal setup instructions should clearly separate installing the main help desk from enabling the extension. This guide does not cover purchasing, licensing steps, or key entry. Those belong to your account workflow and the developer's documentation. What matters here is the safest way to configure a product you already have.

A Safe Activation Sequence

1. Make sure core SupportCandy is active and the basic pages are assigned.
2. Install and activate the Productivity Suite add-on using the standard WordPress plugin workflow.
3. Open Support > Settings > Productivity Suite.
4. Enable only one feature first, such as Checklist, and save the changes.
5. Test it on a sample ticket using both the administrator role and a regular agent role.
6. Only after that test passes should you enable the next feature.

This sequence may feel slow, but it pays off quickly. When a team enables everything at once, problems get mixed together: it becomes unclear why a widget did not appear in the ticket, why the agent cannot assign a checklist, why a pinned ticket disappeared from the current filter, or why silent closure behaves differently from a normal closure. A step-by-step rollout preserves a clean cause-and-effect relationship.

What Counts as a Successful Initial Check

After enabling the first feature, confirm not just that the toggle exists, but that the feature actually works. For Checklist, a successful test means the administrator can create a checklist template, the checklist widget is enabled in Ticket Widgets, the agent can see it in the ticket view, assign a checklist, and mark tasks as complete. For Ticket Templates, it means the template is available when creating a new ticket and fills only the fields you intentionally preconfigured. For To-Do List, it means the agent can see their personal list inside the ticket and understands that those tasks belong to that specific ticket rather than carrying over between requests.

If something is missing at this stage, do not rush to reinstall the add-on. First check the agent role, whether the required widget is enabled, whether you are viewing the correct ticket screen, and whether the current filter is hiding the request. Most issues here are caused not by installation but by interface context and permissions.

Feature Map After Installation: What to Enable First

Once the add-on is installed, the next decision is which features will deliver value fastest for your team. Not every tool matters equally at the beginning. If the team is drowning in recurring requests, start with Ticket Templates. If tickets are being closed with missed verification steps, implement Checklist first. If important requests disappear into ordinary sorting, add Pin Tickets. If agents keep forgetting small internal actions tied to a ticket, enable To-Do List. If the real pain point is long conversations and inconsistent reply quality, test AI Assistant carefully.

A practical rollout strategy is not to turn on the entire suite in a single day. Start with the feature that addresses the most expensive process failure. After a few working days, review whether the number of manual repeats, missed steps, and bounced tickets has gone down. Then add the next capability. Productivity Suite works well as a connected set of tools, but it is best implemented in small, testable steps.

Checklists: Turning Mandatory Verification Into a Working Standard

Checklist is one of the most practical features in the suite because it turns the team's verbal agreements into visible steps inside the ticket. The documentation describes enabling it via Support > Settings > Productivity Suite > Checklist, managing templates through Support > Settings > Checklist Templates, enabling the widget under Support > Settings > Ticket Widgets > Checklist, and granting permissions via Support > Support Agents > Agent Roles > Edit > Modify Checklist.

What a Good Checklist Looks Like

A good checklist does not repeat obvious actions such as "read the ticket" or "reply to the customer." It captures the steps the team actually forgets or performs inconsistently. For technical support for a WordPress plugin, that might include checking the PHP version, theme, conflicting plugins, the exact error text, a screenshot, temporary access, and the result after the fix. For a store, it might include the order number, payment method, shipping status, address, email history, and customer confirmation.

Do not build one giant checklist for everything. It is better to create several templates for different request types: "Login issue," "Payment error," "Plugin conflict," "Data change request," "Order question." That way, the agent chooses the relevant template and sees only the steps that actually apply.

Permissions for Editing Checklists

The documentation lists the Modify Checklist permission for agent roles. This is not a minor technical detail. It is part of quality control. If every agent can freely change the shared checklist, the standard will quickly drift. A practical model looks like this: the administrator or support manager creates and edits templates, experienced agents can assign approved checklists, and new agents only mark completed steps within the checklist assigned to the ticket.

How to Verify the Result

After enabling Checklist, create a test template with 4 to 6 items, assign it to a test ticket, and run through the full scenario using an agent account. Check three things: whether the agent can see the widget, whether they can assign the template, and whether the checked items remain saved after refreshing the page. If any of those checks fail, go back to Ticket Widgets and the role permissions. If the checklist is visible to the administrator but not to the agent, the cause is almost always the role or access to that ticket.

Ticket Templates: Speeding Up Repetitive Requests Without Creating Field Chaos

Ticket Templates are not only about speed. Their main value is consistent data structure. The documentation explains that an administrator can create multiple templates for different request types, group them into categories, fill some or all fields, and leave others blank. Once created, the template becomes available on the new ticket form, allowing the agent to quickly apply predefined values.

When a Template Is Actually Worth Creating

Create a template when a request happens repeatedly and requires the same set of fields. Examples include "Authorization error," "Order refund," "Customer license verification," "Payment failure," "Email change request," or "Course question." If a scenario appears only once a month and has no stable structure, the template may cause more friction than value. The more templates you create without a system, the harder it becomes for the agent to choose the right one.

A good template library depends heavily on categories. The documentation points to category settings under Support > Settings > Ticket Template > Categories. Organize templates not by internal staff naming habits, but by task types the whole team understands: "Account," "Payment," "Technical issue," "Shipping," "Content access." That way, the template becomes part of navigation rather than a personal reminder created by one administrator.

Which Fields to Prefill

Prefill only the fields that are truly predictable. Category, priority, subject, an agent-only field describing the type of verification, or the starting status often work well in a template. Fields containing personal data, order numbers, addresses, detailed issue descriptions, and attachments should usually be filled in by a person. The documentation explicitly states that not every field has to be filled. That detail matters: the template should speed up the start of the process, not inject inaccurate data.

Safe setup: for each template, add a short internal instruction in an agent-only field if your SupportCandy configuration uses that field type. Do not replace it with a customer-facing reply that an agent might send without review.

How to Test a Template

Create a ticket from the template, save it, open it as an agent, and verify that the prefilled values do not conflict with required fields. Then create a second ticket without a template and compare both the time spent and the quality of the data entered. If the template saves 10 seconds but increases the risk of selecting the wrong category, it should be simplified. If it removes 5 to 8 repetitive manual actions and produces a consistent structure, it is doing its job.

To-Do List, Pin Tickets, and Silent Closure: Day-to-Day Discipline

These three features may seem small, but they directly change how an agent works throughout the day. To-Do List helps the agent avoid forgetting personal actions tied to a specific ticket. Pin Tickets keeps high-priority requests in view. Close Ticket Silently closes internal or technically resolved tickets without sending an unnecessary customer notification. The key is not to blur their roles.

To-Do List Does Not Replace Checklist

The documentation emphasizes that to-do lists are specific to an individual ticket and do not carry over to other tickets. This makes them a personal working note for the agent, not a shared processing standard. For example, a checklist might say "check plugin conflicts, request the log, confirm the fix." The individual agent's To-Do List might instead include "wait for the developer's reply," "return after the staging update," or "review the customer's attachment."

To enable it, the documentation points to Support > Settings > Productivity Suite > To-Do List, followed by a separate widget setting at Support > Settings > Ticket Widgets > My To-Do. If the agent cannot see the task list, check the widget first rather than the add-on installation.

Pin Tickets and Filter Limits

Pin Tickets is meant for situations where a ticket needs to stay at the top of the list. The documentation states that a pinned ticket remains at the top regardless of sorting, but if it does not match the current filter, it will not appear in the filtered list. That detail matters when troubleshooting. If an agent pins a "High priority" ticket and then opens the "Assigned to me" or "Awaiting customer" filter, the pinned ticket may be hidden not because the feature failed, but because the ticket does not match the filter.

Pinning permissions are configured through Support > Support Agents > Agent Roles > Edit > Pin Ticket Access. Do not grant that permission to everyone automatically. If every agent pins everything, the top of the list becomes just another cluttered list. It is better to agree that pinning is reserved for incident-level requests, VIP clients, expected deadlines, payment-related incidents, or tickets where delay directly affects the business.

Using Close Ticket Silently Without Surprises

Close Ticket Silently works well for internal service cases: a duplicate already handled in another ticket, a customer who has already received a reply in the main thread, a ticket created for internal verification, or a task that is technically complete and does not require another email. The documentation states that silent closure sends no notifications, does not trigger a satisfaction survey, and if the ticket is reopened, the next closure must use Close Silently again. Otherwise, a normal closure will notify the customer.

The risk is that an agent could close a real customer issue without sending a final answer. That is why this feature should be paired with a simple internal rule: when silent closure is allowed, who may use it, how the reason should be documented in a private note, and when it is better to close the ticket normally with a proper closing message.

How to Build Practical Workflows for Different Support Models

Productivity Suite becomes especially useful when you configure it around request types rather than around the feature list itself. One team may struggle most with technical tickets after updates, another with orders and refunds, and a third with course access or member accounts. The toolkit is the same, but the combinations will differ. That is normal. A good help desk process does not have to look the same for a store, an e-learning site, and an agency.

Workflow for Technical Support of Plugins and Themes

For technical tickets, the most important thing is gathering enough context before the agent starts giving instructions. A strong combination here is Ticket Template + Checklist + To-Do List. The new ticket template can immediately set the category to "Technical issue," assign an initial priority, and populate an agent-only field with guidance on what information to request. The checklist captures required verification: WordPress environment, active theme, list of conflicting plugins, error text, screenshot, reproduction steps, and the result after the fix. The To-Do List remains the agent's private list: "review the log after the customer replies," "escalate to the developer," "return to the ticket after the update."

In this scenario, Pin Tickets should not be used for every bug, only for cases where downtime or broken checkout creates direct business impact. If every technical question gets pinned, the feature loses its purpose. Close Ticket Silently can be used for an internal duplicate created during escalation, but the main customer-facing ticket is usually better closed with a normal reply so the customer can see the outcome.

Workflow for an Online Store or Paid Service

Stores and subscription services repeat a different set of data points: order number, customer email, payment status, shipping method, product, file access, notification history. Ticket Templates help preserve structure, but in these scenarios it is especially risky to prefill personal fields. It is better to preconfigure the category, request type, and an internal instruction field while leaving the specific data blank. The checklist can require verification of the order, payment, mail logs, file access, and final customer confirmation.

Silent closure requires extra care here. If the customer asked about an order, they almost always need a final reply. Close Ticket Silently fits a duplicate, an automatic internal service ticket, or a back-office verification step, but not the closure of a real customer request without a message. If satisfaction surveys are enabled, make sure agents understand in advance that a silent closure will not trigger the survey, and that this is expected behavior rather than an error.

Workflow for an Internal Team or Agency

An internal help desk often deals not only with customers, but also with team tasks: checking access, updating a site, preparing a response, collecting data, or approving an action. In that context, To-Do List may be more valuable than it first appears. It does not replace a project system, but it works well for small actions tied to a specific ticket. For example, an agency receives a ticket saying "update the form on the client's site." The shared checklist captures required steps: backup, staging, form test, email test, note to the customer. The agent's personal to-do list holds today's specific actions: "request access," "check SMTP," "send the customer a screenshot."

For agencies, Ticket Templates by client type or service type are also useful, but they need oversight so they do not end up containing outdated internal instructions. Assign someone to review templates regularly. If the team changes its process often, a template that is never reviewed quickly becomes a source of mistakes.

A Safe Policy for AI, Notifications, and Access Rights

Productivity Suite includes features that affect not only convenience, but also responsibility boundaries: AI Assistant, Close Ticket Silently, permissions for editing checklists, and permissions for pinning tickets. These features should not be rolled out as a purely technical change. You need a short internal policy that explains who may use each tool and what must be checked before the result is saved.

AI Assistant and Ticket Data

AI Assistant documentation states that it connects to external AI services through an API key, and that features such as Ticket Summary and Polish Reply use the contents of the ticket and the draft response. That means the first question is not technical but organizational: what data may be sent to the provider. If tickets can include passwords, keys, medical details, financial documents, or personal data, agents need to know that such information must be removed or generalized before using AI, or that AI should not be used for those tickets at all.

Custom Prompt is useful as a shared company style rule: respond calmly, do not promise timelines without confirmation, do not invent the cause of the problem, ask for extra information only when necessary, and do not mention internal notes. But the custom prompt should not contain secrets, private access instructions, or customer data. Auto Delete AI Logs helps control log retention, but it does not eliminate the need to handle ticket content carefully.

Silent Closure and Communication Control

Close Ticket Silently should come with a clear list of allowed scenarios. For example: close a duplicate, close an internal technical ticket, complete a service-side verification task, or close a ticket where the customer already received the answer in the main thread. It is just as useful to define what is not allowed: the customer asked a question and is waiting for the outcome, there is an unresolved complaint, a refund confirmation is still required, or the agent is not sure the main thread truly resolves the issue. A short list like this prevents unpleasant situations more effectively than trying to explain mistakes afterward.

Permissions as Part of Quality Control

Not every agent should have the same capabilities. A new agent may only need to view tickets, reply, work with an assigned checklist, and manage a personal To-Do List. An experienced agent may be allowed to assign checklists and pin important tickets. A manager or administrator should usually retain control over template creation, template category changes, bulk checklist review, and AI configuration. That approach reduces the risk of accidental changes to the team's support standard.

The policy check is simple: ask an agent to explain when they use Checklist, when they use To-Do, when they use Pin Ticket, when they use Close Silently, and what they must verify after Polish Reply. If the answer takes less than a minute and does not trigger debate, the process is ready. If each person interprets the features differently, you need alignment before expanding the toolkit.

AI Assistant: Where It Helps and Where Oversight Is Necessary

Within the SupportCandy ecosystem, AI Assistant addresses a specific class of tasks: quickly understanding a long ticket, improving a draft response, and keeping communication tone consistent. The official AI Assistant page describes Ticket Summary, Polish Reply, usage reports, and custom prompts. The General Settings documentation points to Support > Settings > AI Assistant > General, where you choose the AI Service Provider, API Key, Max Tokens, Auto Delete AI Logs, and Custom Prompt. The Ticket Summary documentation explains that the summary is generated inside an open ticket and may include the main issue, important replies, actions taken, and sentiment. The Polish Reply documentation describes improving text through Polish (AI), reviewing the result in a popup, and choosing either Append or Replace.

Settings You Should Not Skip

The first decision is the provider and key. If AI features do not work, the documentation recommends checking whether the API key matches the selected provider. The second is Max Tokens. If the value is too low, responses may be cut off. If it is too high, the cost of the external AI request may increase. The third is Auto Delete AI Logs. If your company has data retention requirements, logs should never be left without a deletion policy. The fourth is Custom Prompt. It should define style and guardrails, not attempt to replace agent training.

How to Use Ticket Summary

Ticket Summary is useful during agent handoffs, after a long pause, or when a manager needs to evaluate the situation quickly. The agent opens the ticket, goes to the AI Overview area, and generates a summary. That summary should not be used as the sole basis for the next response. It needs to be cross-checked against the latest messages, attachments, and private notes. This matters even more in sensitive or emotional tickets: sentiment can help with orientation, but it does not replace reading the critical details.

How to Use Polish Reply

Polish Reply works best when the agent already has a meaningful draft. The documentation says the agent writes the reply, clicks Polish (AI), reviews the improved version, and chooses Append or Replace. For most teams, it is safer to start with Append: the agent can see the original and improved versions side by side, compare the meaning, and avoid losing an important technical detail. Replace makes sense only when the agent is confident the reply is accurate and nothing important has been removed.

Do not send an AI-generated reply without review. Even if the wording sounds polished, the agent still needs to verify the facts, links, timelines, promises, and instructions. AI can improve the form of a response, but responsibility for support remains with the team.

Practical Scenario: Handling a Repeat Technical Request

Here is a realistic example of several Productivity Suite features working together. Imagine a site selling a digital product, and a customer writes in saying the same login error has returned after an update. A similar ticket already existed last week, the agent sees a long history, the team needs to keep the context intact, follow the technical checks, avoid duplicate work, and send a careful response.

Goal

The goal is to process a repeat technical request so the agent can quickly understand the prior context, gather the required data, keep track of internal actions, and close the duplicate thread without unnecessary notifications if it truly duplicates the main conversation.

Preparation

• The SupportCandy support page is already in place and notifications have been verified.
• Checklist, Ticket Templates, To-Do List, Pin Tickets, and Close Ticket Silently are enabled.
• The agent has permissions to view the ticket, reply, use private notes, assign checklists, pin tickets, and change status.
• If AI Assistant is used, the provider, API key, response limit, log deletion policy, and custom prompt are already configured.

Handling Steps

1. The agent opens the new ticket and checks whether it is a repeat of an earlier request.
2. If the ticket is long or was handed off by another agent, the agent generates a Ticket Summary and compares it against the latest messages.
3. The agent assigns the checklist "Login issue after update": verify the user, environment, plugin conflict, error screenshot, and outcome after the fix.
4. In To-Do List, the agent adds personal tasks: request the log, return after the customer replies, check staging, update the private note.
5. If the request is business-critical for the customer, the agent pins the ticket so it remains at the top of the relevant working list.
6. If an internal ticket needs to be created for a technical specialist, the agent uses a Ticket Template with the category already selected and the required agent-only fields in place.
7. After the issue is resolved, the agent writes a draft response and, if needed, uses Polish (AI), choosing Append to compare versions.
8. If the second ticket turns out to be a duplicate and the customer has already received an answer in the main thread, the agent adds a private note with the reason and closes the duplicate using Close Silently.

Verification

The final outcome should be visible in several places: the main ticket contains a clear conversation history, the checklist is completed based on real steps, the agent's personal tasks are finished or removed, the pin is removed after resolution, the internal duplicate is closed without an extra notification, and the customer-facing reply contains no unverified promises. If AI Assistant is used, the final text must be reviewed by a human for factual accuracy.

Important Detail

Close Ticket Silently should not become a way to bury inconvenient tickets. If the customer is waiting for an outcome, close the ticket normally with a reply. Silent closure is justified only when the extra notification truly adds no value: a duplicate, an internal task, a technical back-office thread, or a repeated verification step that does not require a customer message.

Verifying Results and Creating a Team Workflow Policy

Once Productivity Suite is configured, the team needs a short working policy. It does not have to be a long document, but it should answer a few basic questions: who creates templates, who edits checklists, who is allowed to pin tickets, when silent closure is acceptable, who reviews AI-generated responses, and how the team updates the process after mistakes.

Simple Metrics Without Heavy Analytics

Even without a dedicated reporting system, you can still assess the result. Compare the number of tickets that came back because data was missing, the number of follow-up questions sent to customers, average first-response time, the number of duplicates that had to be handled manually, and the number of times an agent had to ask a teammate to explain a long ticket history. If those situations become less frequent after rolling out checklists and templates, the configuration is working.

Verification After Every Change

After changing a ticket template, create a test ticket. After editing a checklist, assign it to a test ticket and mark the steps. After changing a role, log in as a test agent. After configuring AI Assistant, generate a test summary and a polish reply using a safe demonstration ticket. Do not use a real customer request as the first test for a questionable change.

If the team is small, a simple table in the company's internal documentation is enough: feature, where it is enabled, who can use it, when to use it, how to verify it, and when to disable it. A lightweight policy like that is more useful than a long instruction nobody reads. Productivity Suite works best when each feature is tied to a specific behavior rule.

Common Issues and Troubleshooting

Most Productivity Suite issues are not caused by the add-on itself, but by the underlying SupportCandy configuration: roles, widgets, filters, pages, notifications, and AI settings. Below is a practical symptom-based troubleshooting guide.

The feature is enabled, but the agent cannot see it

Symptom: the administrator can see Checklist, To-Do, or Pin Ticket, but a regular agent cannot. A likely cause is that the agent role lacks the required permission, the widget is not enabled, the agent does not have access to that type of ticket, or the test is being done on the wrong screen. Review the role under Support > Support Agents > Agent Roles, then check Ticket Widgets and the agent's access to the specific ticket. If everything works under the administrator account, do not reinstall the plugin before checking the role.

Checklist will not assign or does not save correctly

Symptom: the checklist template exists, but the agent cannot assign it to the ticket, or the checkmarks disappear. Verify that Checklist is enabled in Productivity Suite, that a template exists in Checklist Templates, that the Checklist Widget is enabled, and that the role has the Modify Checklist permission. If the issue started after an update, it is worth checking the changelog: the Productivity Suite history has mentioned fixes for screen freezes during automatic checklist assignment and fixes related to the Todo widget.

Ticket Template fills too many fields

Symptom: the agent selects a template, and the ticket receives the wrong priority, category, or text. The usual cause is an overly aggressive template. Go back to Support > Settings > Ticket Templates and leave blank any fields that should not be universal. The documentation allows you to fill only some fields, so it is better to keep the template shorter than to insert unreliable data.

A pinned ticket does not appear at the top

Symptom: the agent pinned the ticket, but it is not visible in the current list. The Pin Tickets documentation includes an important detail: a pinned ticket remains at the top regardless of sorting, but it will not appear in a list if it does not match the current filter. Check the active filter, ticket assignment, status, category, and the agent's permissions. If you need critical requests to stay visible at all times, create a saved filter for those conditions and train the team to use it.

Silent closure did not behave the way the team expected

Symptom: the customer did not receive an email, the survey did not arrive, or after reopening the ticket a normal closure sent a notification. That matches the documented logic of Close Ticket Silently: silent closure sends no notifications and does not trigger the survey, while a reopened ticket behaves like a normal ticket again on the next ordinary closure. The fix is not technical but procedural: add a private note explaining the reason for the silent closure and define who is allowed to use the feature.

AI Summary or Polish Reply does not work

Symptom: the button is visible, but the summary or reply improvement is not generated. According to the AI Assistant documentation, you should check the selected AI Service Provider, API Key, Max Tokens, and whether the agent has the required permission to read or reply within the ticket. Also make sure the test ticket contains enough content to summarize or improve. If company policy does not allow ticket content to be sent to an external AI provider, the feature should be disabled rather than worked around.

When SupportCandy Productivity Suite Is the Right Choice

SupportCandy Productivity Suite is worth using if you are already working inside SupportCandy and want to make support more predictable: keep important tickets pinned, close internal service requests without unnecessary notifications, assign checklists, standardize ticket creation, track personal agent tasks, and carefully introduce an AI assistant for summaries and reply refinement. It is not a magic speed button. It is a toolkit for a team that already has a clear flow of incoming requests.

The best results come when the administrator first maps the workflow, then enables features to support that workflow, verifies roles and widgets, creates compact templates, and trains agents on the rules for using them. If everything is enabled without a policy, the suite can become just another layer of interface that the team works around. Start with one scenario, measure the result, remove what is unnecessary, and gradually turn Productivity Suite into a practical knowledge layer built directly into your tickets.