SupportCandy - WordPress Plugin

How to Set Up SupportCandy for Customer Support on WordPress

SupportCandy is best viewed not as a simple contact form, but as a support team workspace inside WordPress. This guide walks through installation, the first support pages, agent roles, ticket fields, notifications, email handling, a WooCommerce store scenario, result verification, and troubleshooting common issues.

This article does not repeat the product's short description. The goal here is different - to show how to turn the plugin into a clear support workflow: a visitor submits a request, an agent sees the right context, the email goes out from the correct address, the status changes predictably, and a manager can see where support is getting delayed.

The guide uses careful wording for features that depend on the version and the extension set. The free version covers a basic ticketing system, while paid add-ons expand it with mailbox-based email handling, SLA, automation, reporting, WooCommerce integration, AI Assistant, and other capabilities. That is why it is important to separate the required baseline from the features only certain teams actually need before you roll it out.

What a Ticket System Inside WordPress Actually Solves

A regular contact form works fine as long as there are only a few requests and one person handling them. As soon as you have repeated questions, attachments, multiple statuses, several team members, and a need to see history, the form starts getting in the way. Emails get lost in personal inboxes, customers keep asking for status updates, and a new team member has no idea what has already been done.

SupportCandy solves this through a ticket model. Each request has an author, subject, message, status, priority, category, reply history, attachments, internal notes, access permissions, and, when needed, a connection to an order, course, user, or external system. That makes support feel more like a small internal CRM, but without moving the workflow outside WordPress.

The main practical value of SupportCandy is not the fact that it creates tickets, but that each ticket becomes a manageable unit of work. You can find it, filter it, assign it to an agent, close it, reopen it, add an internal note, export it, or use it as a source of reporting data. This is especially useful for site owners if WordPress is already the center of sales, training, the member area, or a client portal.

The plugin is useful in several common situations:

• You need to replace scattered emails with a single customer support portal.
• Your support team works directly inside the WordPress admin area and does not want to maintain a separate SaaS service.
• The site accepts attachments, screenshots, technical details, or confidential follow-up information that should stay attached to the ticket.
• Requests have different categories, statuses, priorities, and assigned team members.
• An online store needs to connect a customer question to an order or product when the relevant integration is enabled.
• The team wants to verify and manage its own data because tickets are stored in its own WordPress environment.

That said, SupportCandy will not always be the best fit. If your support operation already runs through an external service desk with telephony, complex routing, omnichannel chat, and separate analytics, moving it into WordPress may be unnecessary. If the site is hosted on a weak server and receives a high volume of requests, you need to assess the load on the database, email delivery, and background jobs before rollout. If support happens entirely in a messaging app, a ticket system may become an extra step rather than an improvement.

The best candidate for rollout is a site where WordPress already knows the customer: a store, learning portal, service dashboard, agency site, partner-only area, or knowledge base. In that kind of environment, SupportCandy helps you do more than answer questions - it helps you connect each question to the user, the context, and the history.

What to Check Before Installing It on a Live Site

Before installation, it is worth deciding what kind of support workflow you actually want. A common rollout mistake is activating the plugin on a live site right away, leaving the default fields in place, and only later noticing that customers do not understand where to write, emails are not being delivered, agents see unnecessary data, or the support page conflicts with the theme.

Do not start with the Install Now button. Start with a short map of the future ticket flow. Who is allowed to create requests: registered users only, guests, agents, or all of those groups? Where will the customer see their list of tickets: on a full support page or on a separate page for submitting a ticket? Do you need registration, built-in login, standard WordPress login, or a one-time code by email? These decisions determine how you configure pages, permissions, and notifications.

Technical Site Readiness

Check the basics. The site should be running a current WordPress environment, PHP should meet at least the WordPress.org listing requirements for the current plugin version, email sending should be enabled through an SMTP plugin or a reliable mail service, and the administrator should have access to pages, roles, and plugin settings. The WordPress.org listing shows WordPress and PHP requirements, but you should always compare them with the current plugin page before updating because those numbers can change.

If the site uses aggressive caching, script optimization, or strict security rules, prepare exclusions for the support page. SupportCandy outputs the portal through shortcodes and loads its own scripts on selected pages. The page settings include a Load Scripts option that helps limit script loading to the required pages. But if an optimization plugin combines or defers JavaScript without accounting for those pages, the portal may not work correctly.

Team Readiness

For a small site, one administrator and basic statuses may be enough. For a team, it is better to define roles in advance: who handles new tickets, who replies to the customer, who closes requests, who can see email addresses in conversations, who can change statuses, and who has access to internal notes. In SupportCandy, the site administrator is added as an agent by default, but other staff members must be added as agents with the appropriate role.

You should also define the minimum form fields. The more fields you add to the first screen, the more likely the customer is to abandon the request. But if there are too few fields, the agent will have to ask for basic details later. For technical support, category, subject, description, attachment, and one clarifying field such as issue type are usually useful. For a store, use the order or product if the WooCommerce integration is available. For a B2B portal, company or department makes sense if you work with user groups.

A Safe Launch Plan

It is better to configure SupportCandy first on a test page hidden from the menu. Create a test user, a test agent, and a test ticket, verify the notifications, and only then add a link in the header, account area, or menu. If the site already accepts requests through a contact form, do not turn it off immediately. Leave a transition period so you can confirm that the new ticketing system handles every type of request and does not lose emails.

Quick pre-launch check: the customer can create a ticket, the agent can see it in the list, the notification is sent from a domain-based address, the link in the email opens the correct page, and the attachment does not exceed the allowed file size.

Installation and Your First Support Pages

SupportCandy can be installed from the WordPress plugin directory or uploaded manually as a ZIP file. For a typical site, the easiest path is Plugins -> Add New, search for SupportCandy, click Install Now, then Activate. Manual upload through Upload Plugin is useful if you are installing a file from a local archive or working in an environment without plugin directory search.

After activation, do not send customers to the support page right away. First create the pages that will handle the portal and separate workflows. The SupportCandy documentation describes three key shortcodes: [supportcandy] for the full portal, [wpsc_create_ticket] for a standalone new ticket form, and [wpsc_open_ticket] for opening an existing ticket. This is an important difference from a normal contact form: you can show a full self-service area or give the user only a submission entry point.

Full Support Portal

The full portal is the right choice if customers need to log in, view their tickets, create new ones, open existing ones, use registration, and reset passwords through one interface. To set this up, create a page such as "Support," insert [supportcandy], then select that page as the Support Page in the plugin settings.

This option works well for a member area, service portal, or private support environment. It gives customers a sense of continuity: their requests do not disappear after form submission but stay visible in a list. It also works better for agents because each customer message remains attached to a ticket instead of becoming a separate email thread.

Standalone New Ticket Form

If you want to use SupportCandy as a replacement for a contact form, you can create a page with [wpsc_create_ticket]. This option does not show the customer a full ticket list. It works well for a public "Create a Request" page where the goal is to submit a request quickly without a full support dashboard.

In the page settings, specify that the new ticket link should point to a custom page. It is important to test not just the form submission itself, but the next step as well: where the customer lands after submission, which email they receive, how they open the agent's reply, and whether they can return to the request without confusion.

Ticket Open Page

The [wpsc_open_ticket] shortcode is useful when you do not want to show the full portal but still want to give customers a way to open a specific request by link or identifier. This page can be used as the destination for links in notifications. If it is configured incorrectly, the email may be sent, but the customer will land on the wrong page or see a blank screen.

After saving the pages, check the Load Scripts option. If you use custom pages with shortcodes, those pages must be selected for SupportCandy script loading. This is one of the practical details people often miss: the shortcode is on the page, but interactive elements behave strangely because the required scripts were not loaded or were deferred by an optimization plugin.

Post-Install Check

1. Open the support page as a guest and as a logged-in user.
2. Create a test request with a short subject, description, and a safely sized attachment.
3. Log into the admin area as an agent and make sure the ticket appears in the list.
4. Reply to the ticket and verify that the status changes according to your general settings.
5. Open the link from the notification email and confirm that it takes you to the correct ticket page.

If those five steps work without errors, the basic installation is in place. From there, it makes sense to move on to statuses, roles, form fields, and notifications.

Configuring Statuses, Roles, and Permissions

A ticketing system becomes risky at either extreme. One extreme is leaving everything too open: any user can create tickets, agents can see unnecessary email addresses, customers can close requests, and statuses change without a clear logic. The other extreme is locking everything down so tightly that the customer cannot create a ticket, the agent cannot see the needed request, and email becomes a dead end. SupportCandy configuration should land in the middle.

Statuses After Customer and Agent Replies

Under Support -> Settings -> General Settings -> General, there are settings that define the status after a customer reply and after an agent reply. This may seem minor, but it shapes the working rhythm of the support team. If the customer replies, the request should move back into a state that gets the agent's attention. If the agent replies, the ticket can move into a waiting-for-customer state or remain unchanged if your team uses its own status logic.

For a small team, it is usually helpful to define at least four states: new request, in progress, waiting for customer, and closed. They do not have to be named exactly that, but the meaning should be obvious. Customers do not need to see internal bureaucracy, while agents need to quickly tell apart tickets that require team action from tickets that are waiting on the customer.

Who Can Close and Create Tickets

The Allow Close Ticket setting defines who can close a ticket: customers, administrators, or agents. If you allow customers to close tickets, they can mark an issue as resolved on their own. That is convenient for simple requests, but it may get in the way if closure is used as a formal quality-control step. In that case, keep closure rights with agents or administrators.

The Allow Create New Ticket setting defines who can create requests. Allowing guests lowers the barrier to entry, but it also raises the bar for anti-spam protection, form design, and moderation. Limiting ticket creation to registered users works better for member areas, paid services, stores, or courses. An agents-only option is useful when a team member creates a ticket on behalf of a customer after a phone call or external email.

Agent Roles and Data Visibility

You add an agent through Support -> Support Agents -> Agents -> Add New. You select an existing WordPress user and assign a role. If several people work on the site, do not give all of them WordPress administrator rights just to access tickets. Create roles with only the permissions they actually need.

You should also review Thread Email Visibility. This setting controls which agent roles can see email addresses inside conversations. For a support team, this is a sensitive setting: an agent may be able to do their job by replying in the ticket without seeing unnecessary personal data. The fewer people who can see email addresses and attachments, the easier it is to follow internal security rules.

Search and Filters

The Select Allowed Search Fields setting controls which fields can be searched. Enable only the fields that genuinely help agents: ID, customer, subject, conversation text, and the custom fields that matter. If the form contains sensitive data, do not turn it into a shared searchable index unless there is a real need.

Saved filters matter for teams that work from queues: "my tickets," "unassigned," "waiting for customer," "high priority," or "specific category." It is better to create a few practical filters and train agents to use them than to expect everyone to find the right requests manually every time.

Ticket Form: Fields, Required Rules, and Display Conditions

The ticket form is where the user either gives the agent helpful context or sends a short "it doesn't work." SupportCandy lets you configure form fields and additional ticket fields, but the real value only shows up when the structure is carefully planned. The more precisely you ask the right questions, the fewer follow-up messages you will need later.

In the documentation, the Ticket Form Fields section describes the form as the set of fields shown to the user when creating a request. New fields themselves are created under Ticket Fields or Customer Fields, and inside the form you decide which ones to show, which ones are required, how wide they are, and in what order they appear. The Name and Email fields are required and cannot be removed from the form.

A Minimal Form for Launch

Do not make the form too long at launch. In most cases, name, email, subject, description, category, and attachment are enough. If this is technical support, add an "Issue Type" field. If it is a store, add an order link through the integration if available. If it is a learning project, add the course or module, but only if that relationship actually exists in your workflow.

Use required fields carefully. A field should be required only when the agent would almost always need to ask for that information anyway. Category can be required if it affects ticket routing. Priority is often better kept away from the customer because users tend to pick the highest priority if they do not understand the criteria.

Width, Order, and Readability

SupportCandy gives you field width options such as one-third row, half row, and full width. This is not just visual polish. Short fields such as category or request type can sit on half a row. A long description should usually stay full width. The attachment field should also be easy to spot if you often ask for a screenshot or file.

The field order should match the way a customer thinks. Start with who is contacting you, then the subject and category, then the details, then the attachment and any extra information. Do not place complex internal fields before the problem description. The user came to explain an issue, not to fill out a questionnaire.

Visibility Conditions

Display conditions help remove unnecessary fields. For example, if the customer selects the "Technical Error" category, you can show a "Page URL" or "Error Text" field. If they select "Order Question," you can show the order or product field. In SupportCandy, conditions can use AND or OR logic: either all conditions must be met, or one condition is enough.

Do not turn conditions into a complicated puzzle. If the agent later has trouble understanding why a field did or did not appear, the setup will work against you. Start with one or two high-value conditions and test them with a test user. A good outcome is that the user sees only relevant fields while the agent gets enough information for the first reply.

Attachments and Private Data

Attachments are useful for screenshots, logs, and documents, but they need limits. Configure the allowed file types, maximum size, and how attachments behave in email notifications. Notifications can send actual files, links, or no attachments at all. For large files and sensitive data, sending links or keeping the attachments inside the ticket is often safer than attaching them to every email.

If customers need to send passwords, access keys, or other sensitive information, do not ask them to put that in a regular description field. SupportCandy has a Private Credentials extension designed for more controlled handling of that kind of data. If you are not using it, the safer approach is to instruct customers not to send secrets through a regular ticket and to use a separate secure channel instead.

Email Notifications and Email Piping Without Losing Replies

Email is the most common trouble area in any WordPress ticketing system. The plugin itself can generate a notification, but WordPress and your SMTP plugin usually handle delivery. The official SupportCandy documentation clearly states that email notifications are not enabled by default and that you need an active SMTP plugin for real delivery. That means email setup must be tested separately from ticket creation.

Basic Notifications

In the email notification settings, review From Name, From Email, and Reply-To Email. The sender name should be recognizable: the site name or the support team name. The sender address should ideally use the site's domain and be verified in your mail service. That lowers the chance of notifications landing in spam and helps the customer understand where the email came from.

The Reply-To Email field matters if users reply to notifications. If Email Piping is not in use, the reply may go to a regular mailbox and never make it into the ticket. If Email Piping is enabled, Reply-To Email should use the address connected to inbound processing; otherwise, customer replies will drift away from the ticket history.

The Number of Emails Per Cron Job setting helps limit how many emails are processed in a single background run. On a small site, a moderate value is usually fine. On a high-volume site, it should be aligned with your hosting and SMTP service capacity so you do not create delays or trigger sending limits.

Email Piping: When You Actually Need It

Email Piping is useful if customers and agents need to create tickets and reply directly from their email client. That works well for teams where email remains the main communication channel. In SupportCandy, this is part of the extension set and supports IMAP, Gmail, and Microsoft Exchange. In the basic setup, you choose the connection, inbound email rules, allowed senders, whether to prefer HTML or plain-text message bodies, and how often to check for incoming mail.

There are three practical inbound mail modes: accept all emails, accept only new emails as new tickets, or accept only replies to existing tickets. The last mode looks for the ticket ID in the email subject and adds the message to the correct thread. If there is no ID, the email is blocked and the sender can be shown a warning. That protects the system from chaos, but it also requires your notification templates to preserve a clear ticket identifier in the subject line.

What to Test in Email

1. Create a ticket as a customer and make sure the email reaches both the customer and the agent.
2. Reply to the customer's email if Email Piping is enabled and verify that the reply appears in the correct ticket.
3. Send an email from an unauthorized address if you restrict access to registered users and check the warning behavior.
4. Add an attachment and confirm that it is handled according to the selected policy.
5. Check whether notifications go to spam and whether the sender domain matches your email service configuration.

Troubleshooting detail: if the ticket is created but the email never arrives, start with the SMTP log and the mail service. If the email arrives but the reply does not return to the ticket, check Reply-To Email, the Email Piping mode, the subject line, and the inbound polling frequency.

Practical Scenario: A Support Portal for a WooCommerce Store

Let us look at a concrete example. You have a WordPress store, and customers are writing about shipping, digital product access, refunds, payment errors, or questions tied to a specific order. The goal is to let the customer create a request on the site, let the agent see the order context, make sure replies are not lost, and use the ticket status to show who needs to act next.

This scenario does not require describing how to buy the plugin or enter a license key. It shows how to configure an existing tool around a real support workflow. If WooCommerce integration is available in your version, it can connect requests to orders and products. If that integration is not available, use a standard "Order Number" field and verify it manually.

Goal

The customer should open the support page, choose the issue type, specify the order or product, describe the problem, attach a screenshot if needed, and receive a confirmation email. The agent should see the ticket in the queue, understand the context, reply, and either move the request to waiting for customer or close it once resolved.

Preparation

Before configuring anything, make sure WooCommerce is working, orders are being created correctly, the SMTP plugin can send test emails, and the support page is not being hidden by caching or redirects. Create a test order or use a separate customer test account. Do not test the process as an administrator: administrators often see more than a normal customer and may miss a permissions issue.

Setup Steps

1. Create a "Support" page with the [supportcandy] shortcode or a standalone form page with [wpsc_create_ticket].
2. Under Page Settings, select the needed page as the support page or as the custom new ticket page.
3. Under General Settings, decide whether tickets can be created by guests or only by logged-in customers.
4. Create categories: "Shipping," "Payment," "Product Access," "Refund," and "Technical Error."
5. Configure the order field through the WooCommerce integration if available, or add a standard order number field.
6. Make the category field required, and make the order field required only for the categories that actually need it.
7. Add agents and assign responsibilities: one handles new requests, another handles orders, and a third steps in for technical issues.
8. Configure notifications for new tickets, agent replies, and customer replies.
9. Create a saved filter for tickets in the "Shipping" or "Technical Error" category if request volume is high.

Expected Result

The customer sees a clear form and does not send a vague message without context. The agent opens the ticket and immediately understands which order, product, or issue it is about. Internal notes make it easy to hand the request to another team member without moving the conversation outside the system. The status after a customer reply sends the ticket back into the active queue, and the status after an agent reply shows that the team is waiting for the buyer.

Verification and One Important Detail

After setup, create a test request as a customer. Verify that the order field appears only where it should, that the email comes from the correct sender, that the agent can see the ticket, and that the email link opens the ticket page. Then reply as the customer and make sure the status changes according to your workflow.

The key nuance is roles and the customer account area. If the customer should see their requests inside the WooCommerce account, verify that you have the required integration and that the related output is enabled. If that connection is not available, do not promise support access from the orders section. Give the customer a separate link to the support page and explain where to view ticket history.

Filters, Internal Notes, and How Agents Work the Queue

Once the system is live, most of SupportCandy's value shows up not in the customer form but in the agent's daily workflow. A well-organized queue reduces response time: the agent sees assigned tickets, urgent topics, new customer replies, the right categories, and internal notes. A bad queue turns the ticket system into just another overloaded list.

Saved Filters

SupportCandy includes standard filters such as all tickets, unresolved, mine, and deleted, along with the ability to save custom filters. For a support team, this is one of the most useful tools in the plugin. Configure filters around real actions, not around pretty reporting.

Examples of practical filters:

• New requests without an assigned agent.
• My tickets where the customer has replied.
• High-priority tickets with an open status.
• WooCommerce order-related requests, if the integration is enabled.
• Tickets with attachments that require checking a file or screenshot.
• Tickets waiting on a customer reply longer than the usual work cycle.

Do not create too many filters at once. It is better to start with three working views and expand after the first week of use. If nobody opens a filter, you do not need it.

Internal Notes

Private notes help the team communicate inside the ticket without sending a message to the customer. This is useful when one agent asks another to review an order, a developer adds a technical comment, or a manager records the reason for a delay. Internal notes become especially important when a ticket is handed off between team members: the new agent sees not only the public thread but also the internal context.

The rule is simple: internal notes should explain the next step. A weak note is "check later." A good note is "Check the payment in WooCommerce; the customer referenced order 1234, and the error appears after shipping is selected." That kind of note saves time and reduces the chance that the customer will be asked the same question again.

Agent Collision and Duplicate Replies

The current WordPress.org changelog for SupportCandy mentions the addition of an Agent Collision widget. The point of a feature like this is to warn the team that multiple agents may be working on the same ticket at the same time. For support, this is not cosmetic: two identical replies, or two different solutions in the same request, look unprofessional and can confuse the customer.

If that widget is available in your version, test it on a sample ticket with two agents. If the feature is not available, agree on a simple manual rule: an agent should take ownership of the ticket, change the status, or assign it to themselves before replying. The technical tool helps, but it does not replace queue discipline.

Reports and Measuring Results

Reports, response delay, closing delay, and similar metrics belong to the more advanced feature set. Not every team needs them, but they can be useful for a support manager. The important part is not to turn reporting into an end in itself. If your team is small, start with a manual review: how many new tickets arrive each day, how many are still unanswered by the end of the workday, and which categories repeat most often.

As volume grows, reports help reveal bottlenecks. If a large share of requests belongs to one category, your site may need better instructions. If closures are delayed, review your statuses and waiting-for-customer logic. If one agent is overloaded, adjust assignment rules or agent groups.

Privacy, Localization, and the Portal's Visual Experience

A ticket system works with data that a regular contact form often does not store in the same volume: conversation history, email addresses, attachments, internal notes, categories, user details, and sometimes an order number or a link to a restricted area of the site. That is why SupportCandy setup should cover not only agent convenience but also careful handling of customer data.

What You Should Not Collect Unless You Truly Need It

A good support form asks only the questions that actually help resolve the request. Do not ask for passport information, passwords, full payment details, private keys, hosting control panel access, or other secrets through a standard description field. If the team genuinely needs sensitive information, use a separate secure process or a specialized extension such as Private Credentials, if it is available in your setup and fits your internal rules.

In a normal workflow, it is enough to tell the customer which details are safe to provide: a screenshot of the error, a page link, an order number, a product name, or a description of the step after which the issue occurred. The clearer the hint next to the field, the lower the risk that the user will send too much. If that hint cannot be placed exactly where you want it, add a short explanatory text before the form on the support page.

GDPR, Retention, and Deleting Old Requests

The WordPress.org listing for SupportCandy mentions features related to GDPR, data retention, and deletion. The article should not promise universal legal compliance because legal responsibility depends on the site, the country, the retention policy, and the real data-handling process. In practical terms, this means something simpler: the administrator should understand what data enters tickets, who can see it, how long it is stored, and how it is removed after support is complete.

For a small site, an internal rule is often enough: closed requests are kept for a defined period and then archived or deleted according to the agreed policy. If automatic archiving, automatic deletion, or automatic closing is enabled, test those features first on sample tickets. A mistake in the timing can remove useful history before the team has fully resolved a repeat customer question.

Translation and Clear Labels

On a Russian-language site, the customer-facing support area should sound natural. If some strings still appear in English, check the plugin translation, available WordPress.org locales, and the standard WordPress translation workflow. Do not fix strings by editing plugin files directly: those changes will be lost after the next update. It is safer to use WordPress localization tools or text settings if the specific string is output by SupportCandy through a configurable template.

Pay special attention to the words a customer sees at the moment of an error: required field, invalid email, access denied, ticket closed, reply unavailable, file too large. If those messages are unclear, users will create duplicate requests or switch to another contact channel. Before going live, walk through the form as a regular user and intentionally make a few mistakes: leave a required field empty, upload an unsupported file, and open the page without logging in. That quickly shows where the text needs improvement.

Visual Design and Theme Compatibility

SupportCandy renders the portal inside a WordPress page, so the final appearance depends not only on the plugin but also on the theme, page builder, site CSS, container width, and caching rules. If the portal looks too narrow, the buttons bunch together, the ticket table is hard to read, or the form breaks on mobile, first check the normal page setup: use a template without a sidebar, make sure the content area is wide enough, and remove unnecessary blocks around the shortcode.

Do not start with CSS tweaks until you have ruled out the obvious causes. In many cases, the fix is simply a dedicated support page with a clean template, no sidebar, and an exclusion from aggressive script optimization. CSS only makes sense once you understand exactly which theme element is conflicting with the portal. Without confirmed stable plugin classes, it is better not to publish a generic snippet because it may break after an update or fail on another theme.

A practical approach: first make sure the portal works correctly without custom code, then improve the styling with small, reversible theme-level or child-theme changes. If a change does not affect ticket creation, agent replies, and opening the email link, it is secondary.

Integrations, Automation, and Extensions: What Not to Turn On Right Away

SupportCandy comes with a large set of extensions and integrations. That is a strength, but it can also create an overloaded launch. If you enable Email Piping, SLA, Workflows, WooCommerce, AI Assistant, Satisfaction Survey, Reports, and automatic closing all in one day, it becomes hard to tell which setting caused the problem. A more practical approach is to roll features out in layers.

Baseline Layer

Start with pages, the form, statuses, roles, notifications, and a tested ticket flow. That is the core workflow, and automation will not rescue the process without it. If the baseline form collects the wrong data, Workflows will route the wrong tickets. If notifications do not arrive, SLA will only show that the team is behind; it will not fix email delivery.

Email Piping and Mail Channels

Email Piping should be enabled only after basic notifications work reliably through SMTP. This feature changes the normal communication path: a customer reply from email should return to an existing ticket, and a new email may create a new request. A mistake in the address, subject line, or inbound mail rules creates duplicates and lost replies. Before going live, test the scenarios for "new email," "ticket reply," "guest email," "email from an unregistered user," and "reply to a closed ticket."

SLA and Business Hours

SLA makes sense when support has promised response or resolution times. If you enable SLA, first configure business hours, exceptions, and holidays; otherwise, the system may count time when the team is not working. It is also important to explain to agents that SLA is not just a colored indicator but a prioritization rule. Tickets approaching their deadline should rise to the top in priority filters.

Workflows and Agent Assignment

Automation is useful when you already have clear conditions: the "Payment" category goes to billing, "Technical Error" goes to the technical group, and WooCommerce-related questions go to the store agent. If you do not have those conditions, automation only hides the chaos. Start with one simple rule, test it on sample tickets, and only then add more conditions.

AI Assistant

AI Assistant belongs to the Pro feature set and, according to the official description, helps summarize tickets, improve replies, use knowledge materials, and prepare drafts. It should be treated as an agent assistant, not as a stand-alone support team. Before enabling it, decide what data may flow into AI features, who approves replies, and how tone of voice is reviewed. For sensitive requests, manual review and internal rules are still the safer path.

Automatic Closing and Satisfaction Surveys

Automatic Close Tickets helps close inactive requests after a set period and can send a warning beforehand. Satisfaction Survey gathers feedback after closure. These features are best enabled only after the team is comfortable with statuses. If automatic closing is configured too aggressively, the customer may feel that the issue was closed without being resolved. If every minor request triggers a survey, it quickly becomes annoying.

How to Verify the Setup After Configuration

SupportCandy verification should simulate real usage, not just one successful form submission. You need to walk through the customer path, the agent path, the administrator path, and the email channel. This matters even more on sites with caching, account areas, WooCommerce, access restrictions, or a custom theme.

Customer Path

Open the site in a private browser window. If guest tickets are enabled, create a request without logging in. If support is limited to registered users, log in as a test customer. Check that the support page is clear, the form works on mobile, required fields are highlighted, and the user receives confirmation after submission.

Then open the customer's email. The link should take them to the place where the ticket can be read and answered. If OTP Login is used, verify that the one-time code arrives and that the user returns to the correct request. If standard WordPress login is used, make sure the user is not redirected to an unexpected page after authentication.

Agent Path

Log in as a test agent who does not have administrator rights. Check whether that user can see the right tickets and cannot see the wrong ones. Open a ticket, add a public reply, then add an internal note. Make sure the public reply is visible to the customer and that the internal note is not.

Check status changes as well. After the agent replies, the ticket should move into the state that matches your process. After the customer replies, the ticket should return to the agent's queue. If statuses do not change, open the general settings and review the status-after-customer-reply and status-after-agent-reply options.

Administrator Path

An administrator checks more than a single ticket; they check whether the overall process is stable. Review the filters, categories, agent list, page settings, notifications, attachments, roles, and change log if one is available. Make sure deleting or archiving tickets is not being used as a way to hide unfinished work. For older closed requests, a clear retention policy is the better approach.

Email and Background Job Path

Create a ticket, reply to the notification, add an attachment, send an email from an unregistered address, and review cron timing and the SMTP log. If the site uses an external SMTP service, check for domain verification errors, sending limits, or rejections. If emails arrive late, SupportCandy is not always the cause: the delay may come from cron, hosting, the SMTP provider, or the domain's DNS settings.

A good verification outcome: the ticket completes the full cycle from creation to closure, the agent sees only the needed data, the customer gets the correct emails, and the administrator knows where to review both the queue and the errors.

Common SupportCandy Issues and How to Diagnose Them

Most ticket system problems do not show up as one obvious error. They appear as a broken route: the page opens, but the form will not submit; the ticket is created, but the email never arrives; the agent replies, but the customer cannot see the reply; the field exists in settings, but never appears in the form. The easiest way to troubleshoot is symptom by symptom.

The Support Page Is Blank or the Shortcode Does Not Work

Symptom: the page exists, but the portal does not appear, elements look incomplete, or buttons do not respond. In some cases, the customer only sees the shortcode text.

Possible causes: the shortcode was inserted in the wrong place, the page was not selected in Page Settings, SupportCandy scripts are not loading on the custom page, cache or an optimization plugin is breaking JavaScript, or the theme is interfering with form output.

What to check: confirm that [supportcandy], [wpsc_create_ticket], or [wpsc_open_ticket] is present on the correct page; confirm the page selection in settings; review Load Scripts; disable script combination and defer rules for the support page.

How to fix it: save the page again, select it in SupportCandy settings, clear the cache, and temporarily disable JavaScript optimization for that page. If the problem disappears, add a permanent exclusion in the cache plugin. If it does not, test for a theme conflict using a default theme on a staging copy.

The Ticket Is Created, but Emails Never Arrive

Symptom: the request appears in the admin area, but the customer or agent does not receive the notification.

Possible causes: email notifications are not enabled, there is no SMTP plugin, From Email does not belong to the domain, the mail service rejects the message, the notification template is disabled, or the cron job is not running.

What to check: email notification settings, the SMTP log, sender domain verification, mail service limits, the email count per cron run, the spam folder, and the template for the specific event.

How to fix it: configure SMTP, use a domain-based sender address, enable the required notifications, send a test email, and reduce cron load if you send a large batch of notifications. If SMTP shows the emails leaving but they do not arrive, the problem is already in delivery or recipient-side filtering.

An Email Reply Does Not Return to the Correct Ticket

Symptom: the customer replies to the email, but the reply is not added to the ticket history or creates a separate request.

Possible causes: Email Piping is not enabled, Reply-To Email points to an address that is not connected, the inbound mode does not accept replies, the ticket ID is missing from the subject, inbound checks run too infrequently, or the mail connection is not working.

What to check: the IMAP, Gmail, or Microsoft Exchange connection; the Allowed emails mode; the Reply-To Email address; whether the ticket identifier is present in the subject line; and inbound processing logs.

How to fix it: use an address that is genuinely connected to Email Piping, keep the ticket ID in the notification subject, configure warnings for emails without an ID, and review the polling frequency. If the system accepts only replies, a new email without an ID should be blocked predictably, not disappear without feedback.

An Agent Cannot See the Right Tickets or Sees Too Much

Symptom: a staff member logs into WordPress but cannot see the required requests in SupportCandy, cannot reply, or, on the other hand, can access data they do not need.

Possible causes: the user was not added as an agent, the wrong role was assigned, role permissions limit visibility, the ticket is assigned to another group, a filter hides part of the list, or email visibility is configured too broadly or too narrowly.

What to check: the Support Agents section, the agent's role, role permissions, ticket assignment, the active list filter, and email visibility settings for conversations.

How to fix it: add the user as an agent, assign a role with minimally sufficient permissions, review the "my tickets" filter and global filters, and configure email visibility by role. Do not grant WordPress administrator rights just for ticket access.

Form Fields Do Not Appear or Required Rules Behave Unexpectedly

Symptom: a field was created but does not appear in the form; a required field is not validated; a conditional field appears for the wrong category.

Possible causes: the field was created under Ticket Fields but never added to Ticket Form Fields; the visibility condition uses the wrong AND or OR combination; field loading order conflicts with expectations; or the customer is viewing a cached page.

What to check: whether the field is present in the form, whether it is marked required, its width, Load after, the visibility conditions, and the behavior on a clean uncached page.

How to fix it: add the field to the form, simplify the condition to a single rule, test required behavior with a sample request, and clear the cache. If the conditional logic is too complex, split the form into simpler categories.

PHP Warnings or Strange Failures Appear After an Update

Symptom: after updating WordPress, PHP, or the plugin, you start seeing warnings, blank lists, button issues, or compatibility messages.

Possible causes: a PHP version conflict, an incomplete database update, a conflict with the theme or another plugin, stale cache files, or an issue that has already been fixed in a newer release.

What to check: the current SupportCandy version on WordPress.org, the changelog, PHP requirements, the error log, the support forum, whether there are similar reports, and behavior on a staging copy without third-party optimizers.

How to fix it: update the plugin to the current stable version, clear the cache, verify PHP compatibility, and temporarily disable conflicting optimizers on a staging copy. If the issue persists, prepare the exact symptom, PHP version, reproduction steps, and a screenshot for support.

When SupportCandy Is a Strong Choice

SupportCandy is a strong fit for sites where support should live inside WordPress rather than in a separate service. This is especially useful for stores, learning projects, service dashboards, agencies, private client portals, and sites where users already sign in to an account area. The plugin provides a clear foundation: a portal, tickets, agents, roles, fields, statuses, notifications, attachments, internal notes, and extensions for more advanced workflows.

The choice becomes especially effective if you are willing to spend time on the initial setup. A ticketing system does not become useful on its own. It has to be adapted to your request categories, staff roles, support pages, mail delivery, statuses, and handling rules. Once that work is done, it starts saving time because every ticket follows a predictable route.

You should not roll out SupportCandy as "just another form" if you are not prepared to answer inside the system, monitor notifications, and keep the queue organized. In that case, a regular contact form is simpler. But if your support operation is growing, repeated questions are becoming common, multiple people are involved, attachments matter, and history needs to stay visible, moving to tickets is justified.

Before the live rollout, run through this short final check:

• The support page is created and selected in settings.
• A test customer can create a request and open it through the link in the email.
• A test agent can see the ticket, reply to it, and does not have unnecessary WordPress permissions.
• The SMTP log confirms notification delivery.
• The statuses after customer and agent replies match your workflow.
• The form contains only the needed fields, and conditional fields have been tested with sample categories.
• Cache and script optimization do not break the support page.

If those items are in place, you can move on to a live test and download SupportCandy for rollout on your site. Start with the baseline workflow, and add extensions gradually once it becomes clear which bottlenecks your team actually has.