SupportCandy Timer - WordPress Plugin

How to Set Up SupportCandy Timer for Time Tracking in WordPress Tickets

SupportCandy Timer is not meant to be a decorative counter on the page. It is built for disciplined time tracking inside your support operation. In this guide, we will look at how to turn the timer into a practical tool: prepare SupportCandy, enable the widget inside the ticket view, configure auto-start and auto-stop, assign the right permissions to agents, add time to the ticket list, and use time logs in notifications.

This article is written for a site owner, support manager, webmaster, or developer who already uses SupportCandy or is planning to move customer support into WordPress. We will not cover purchasing, licensing, or checkout. The focus here is on configuring a product you already have, verifying the setup, avoiding common mistakes, and walking through a practical scenario where ticket time is needed for reporting or internal oversight.

SupportCandy Timer is especially useful when a single ticket may pass through several team members. The official add-on page says the timer runs independently for each agent, allows manual entries, shows total time in the customer widget, displays time in the ticket table, and supports time macros in notifications. That means the administrator's real job is not simply to turn on the timer button, but to set rules that make the data useful instead of confusing the team.

Below, you will find a detailed setup guide, an agency-style configuration example, a troubleshooting section, an FAQ, and a related-solutions block. Any uncertain points are stated carefully: if the documentation does not confirm a specific capability, it is not presented here as a fact.

When Ticket Time Tracking Actually Helps

A timer inside a help desk plugin has a clear practical role: it ties the customer's request, the agent's work, and the final time spent together in one place. Without that kind of tracking, teams usually rely on memory, outside spreadsheets, or a separate time-tracking service. That works while ticket volume is low. Once requests start piling up, gaps appear: an agent replied to the customer but did not log the time; a manager sees a closed ticket but has no idea how much effort it required; a customer asks why the task took so long, and there is no clean activity log to review.

SupportCandy Timer closes exactly that gap. Inside the ticket view, an agent can start, pause, and stop the timer, then save an entry with a description. If time needs to be added after the fact, the widget documentation describes manual log creation with fields for time, start date, author, and description. That makes the plugin useful not only for strict minute-by-minute tracking, but also for reconstructing work after a phone call, an internal conversation, or an offline task connected to the ticket.

One important nuance: this is not a universal project management tool or a full billing system. The timer records time in the context of a ticket. If you need invoices, rates, work approvals, payroll, advanced project reports, or accounting sync, you will need a separate process or a different tool. Still, for a WordPress site handling customer support, the advantage is obvious: the agent does not have to leave the ticket just to log work.

Who Should Enable Timer Right Away

This plugin is worth considering if your support team handles requests related to websites, plugins, themes, WooCommerce orders, LMS courses, paid services, or internal company tasks. In those scenarios, ticket-level time helps you measure workload, spot expensive request categories, and see where documentation or a knowledge base is saving the team hours.

• Agencies that maintain client websites and want to see how much time each request takes.
• Digital product support teams where a single ticket may require investigation, a reply, testing, and a follow-up.
• Owners of a self-hosted WordPress help desk who want to keep ticket history and effort tracking on their own site.
• Support managers who need more than just "Open" and "Closed" statuses and want to understand the real workload.

When the Timer May Be Unnecessary

If your support team only answers occasional simple questions and does not report on time, SupportCandy Timer may add discipline without delivering much practical value. It can also get in the way if the team is not ready to agree on the rules: when to start the timer, what counts as work time, who fixes incorrect entries, and whether the customer should see total hours. Without an internal policy, the timer quickly turns into just another button that some staff members forget to click.

A good rule for getting started: enable Timer only after agents, statuses, notifications, and the basic ticket-handling process are already set up in SupportCandy. The timer should measure a process that already makes sense, not compensate for chaos in support.

How Time Logs Work in SupportCandy Timer

The official product page describes several important mechanics. An agent starts or pauses the timer directly inside the ticket. When the work is done, the agent stops the timer, adds a description, and saves the entry. You can also add a manual log. For team workflows, one detail matters most: the timer runs independently for each agent. Multiple staff members can track their time in parallel on the same ticket, and the final time for the ticket is calculated as the total of all logs.

That sets Timer apart from a simple "time spent" field. You get not only a final total, but also structure: who worked on the ticket, when the entry started, how much time was added, what description was saved, and which actions are available to a user with the right permissions. As a result, the log can be used for internal review, customer-facing explanations, or notification templates.

The Timer Inside the Ticket

The Timer widget documentation says the widget appears in the sidebar area of the individual ticket page. From there, the agent can start, stop, and pause the timer, add new logs, review saved entries, and reset the timer if needed. Resetting requires special caution: the documentation explicitly says it deletes previously saved logs.

For day-to-day work, that leads to a simple pattern: the agent opens the ticket, starts the timer, performs the task, stops the timer, and writes a short description. The description should not be a long copy of the reply sent to the customer. It is better to record the type of work instead: "form error investigation," "reply to customer after testing," "access restored," "WooCommerce order review." Entries like these are much easier to analyze later.

Manual Log

A manual log is useful when the work has already been completed but the timer was never started. The documentation says that when adding a log, you specify time in the XXd XXh XXm format, the start date, the author, and a description. If the user does not have permission to modify other agents' logs, the entry is added under that user's own name. If the permission is available, the log author can be selected manually.

Manual entry should be treated as a correction, not the default workflow. If the team is almost always adding time manually at the end of the day, the data becomes less accurate. In that case, it is better to rethink the process: make timer start part of the ticket-handling checklist, move the widget higher in the sidebar widget order, and agree on which actions must always be tracked.

Total Time, Customer Widget, and the Ticket Table

SupportCandy Timer can display the total time for a ticket. The official add-on page also says agents can see the total time across tickets for a specific customer in the customer widget, and the total time field can be added to the ticket table. That is especially useful for a manager: in the list, you can immediately spot requests that consumed too much time, even if they were formally closed without delays.

Customer visibility should be enabled intentionally. Based on the product description, customers can see the timer widget if allowed, but only as time data, without any rights to manage logs. For some sites, that level of transparency is helpful. For others, it creates unnecessary questions, especially if the team has not yet agreed on what should be tracked. That is why it is usually better to keep the widget visible only to agents and managers at first, then enable customer visibility after a trial period.

What to Check Before Installing It on a Live Site

Before installing Timer, make sure the main SupportCandy setup is already functioning as a real help desk and not sitting in a half-configured state. On WordPress.org, the main SupportCandy plugin is presented as a self-hosted ticketing system with agents, roles, notifications, custom fields, attachments, a REST API, macros, and appearance settings. Timer is an add-on for that system, so it inherits the quality of the underlying setup.

Basic Dependencies

The official Timer page lists the minimum WordPress and PHP requirements. This article does not tie instructions to specific interface versions because those can change, but before installation you should open the product page and compare the requirements with your site. If the site is running an outdated PHP version or has not been updated in a long time, check compatibility on a copy of the site first.

• Make sure the main SupportCandy plugin is installed and active.
• Verify that at least one test ticket exists and can be opened in the admin panel or agent portal.
• Add real agents through Support - Support Agents - Agents and assign their roles.
• Make sure ticket statuses are clear to the team, especially the statuses used for closing tickets.
• Set up email notifications and SMTP if you plan to send customers messages that include time or logs.

Agent Roles and the Right to Correct Other People's Entries

One of the most sensitive settings is the ability to change other agents' logs. The Timer widget documentation shows the path to the Modify Others time log permission through the agent role. That permission makes sense for a support manager or administrator who needs to fix team mistakes. A regular agent usually does not need it: if everyone can edit their coworkers' entries, the time history stops being trustworthy.

Before enabling Timer, define a role matrix. For example, an agent can run their own timer and add their own entries; a senior agent can correct logs created during their shift; an administrator can delete bad entries and reset the timer only after review. That model does not require complex automation, but it sharply reduces the risk of accidental edits.

Notifications and Macros

SupportCandy documentation separately describes the {{time_logs}} and {{time_spent}} macros. They can be used in notifications and other templates where macro insertion is supported. Before adding them to a customer email, check the delivery channel itself: the official getting started section says email notifications are not enabled by default, and real delivery requires a working SMTP plugin.

Do not add time to customer emails on day one of testing. First, make sure agents are logging time consistently, descriptions do not contain internal information, and the totals do not need manual cleanup. For internal notifications, you can start using the macros earlier because they help managers see what happened with the ticket.

Installing the Add-On and Running the First Check

Timer installation depends on how you receive the add-on in your SupportCandy setup. For the main SupportCandy plugin, the official documentation describes two standard ways to install a WordPress plugin: through the plugin directory and by manually uploading a ZIP file through Plugins - Add New - Upload Plugin. The same basic logic applies to the add-on: use the standard WordPress interface and do not download files from questionable mirrors.

A Safe Installation Order

1. Create a site backup or test the add-on on a staging copy if tickets are business-critical.
2. Update the main SupportCandy plugin to a version that is compatible with your add-on set, if the developer documentation requires it.
3. Upload the Timer ZIP file through the standard WordPress plugin installation screen.
4. Activate the add-on and open Support - Settings - Timer.
5. Open a test ticket and check whether Timer appears in the list of ticket widgets.
6. Create a short test entry, stop the timer, and make sure the log appears in View Logs.

If you do not see the widget in the ticket after activation, do not rush to reinstall the plugin. SupportCandy has separate ticket widget settings: widgets can be enabled, disabled, renamed, reordered, and restricted by role. So first check whether Timer is enabled under Support - Settings - Ticket Widgets.

The First Test Entry

Do not use a real customer ticket for testing. Create a test request, assign it to an agent, and run through the full cycle: start, pause, resume, stop, describe, and review the log. Then add a manual log with a small amount of time and make sure the time format is accepted. If the system expects the XXd XXh XXm format, do not enter arbitrary strings like 1:30 or 90 minutes unless the documentation or interface explicitly confirms that format.

Quick checkpoint after installation: the add-on is only ready for configuration once a test agent can see the widget inside a ticket, save a log, and an administrator can see both the total time and the list of entries.

Configuring SupportCandy Timer After Installation

The Support - Settings - Timer section contains the key behavior settings. Do not enable everything at once. The best way to configure SupportCandy Timer is to begin in manual mode: the agent consciously starts and stops time tracking. Once that is working, you can decide whether automatic actions are actually useful.

Auto-Start When a New Ticket Is Created

The Auto start on create new ticket setting automatically starts time tracking when a new ticket is created. The documentation clarifies that the log will be added to the default agent account. That is only useful in limited scenarios, for example, when all new requests first go to one on-duty agent and the initial handling time always needs to be tracked.

For most teams, it is better to leave auto-start off at first. Otherwise, you will end up with entries that technically began when the ticket was created but do not reflect real work. Be especially careful with tickets that come in through email piping, forms, the API, or integrations: a ticket may be created overnight, and an agent may not see it until much later. If auto-start is enabled without the right default agent and a clear policy, the stats will become noisy very quickly.

When Auto-Start Makes Sense

• You have a dedicated first-line agent who handles all new tickets immediately.
• You need to measure initial triage time, not the full lifetime of the ticket.
• The team understands that the automatic entry belongs to the default agent and reviews those logs at the end of the shift.

When Manual Start Is Better

• Tickets come in from different channels and may wait for assignment.
• One ticket often passes through several specialists.
• You are just rolling out time tracking and do not yet know how the team will use the data.

Default Agent for Auto-Start

If auto-start is enabled, the default agent field becomes critical. The documentation says the automatic log is added specifically to that agent. Do not pick a random site administrator. It is better to assign a clear role or a responsible staff member who actually handles incoming requests. If that role does not exist, auto-start will create false individual workload data.

After selecting the default agent, run a test: create a customer ticket, open the log, and check who it is assigned to. Then close the ticket and see what happens when auto-stop is enabled. Only after that check should you move the setting into the live workflow.

Auto-Stop When a Ticket Is Closed

Auto stop on close ticket automatically stops active timers when the ticket is closed. This is a safer setting than auto-start because it reduces the risk of forgotten timers. In practice, an agent may close the ticket after replying to the customer and forget to click stop. Auto-stop helps keep extra hours from piling up.

That said, it still needs oversight. If the team sometimes closes a ticket temporarily and later reopens it, automatic stopping can break one long work period into several logs. That is not an error, but the manager needs to understand how to read that data. For workload reporting, several accurate logs are usually better than one long and ambiguous one.

Timer Widget Visibility

The Timer widget is enabled through Support - Settings - Ticket Widgets - Timer. In the general SupportCandy widget settings, you can enable and disable widgets, rename them, change their order, and assign visibility permissions. The Timer widget documentation also points to visibility control through allowed agent roles.

The recommended logic looks like this:

• For first-line agents, the widget should be visible if they genuinely work with tickets and are expected to track time.
• For trainees, you can enable the widget but keep permission to edit other agents' logs turned off.
• For managers, you can enable the widget and allow log review if they are responsible for quality control.
• For customers, only enable visibility after testing, because the customer will see the time but not the context behind internal actions.

The Modify Others time log Permission

This permission determines whether an agent can add, modify, or delete entries on behalf of other people. The documentation directly links it to the ability to choose a log author and edit someone else's entries. On a small site, it may seem convenient to give this right to everyone, but for reporting that is a bad habit.

The practical approach is to give permission to modify other people's logs only to the support administrator or a senior agent. If a regular staff member makes a mistake, they can ask a senior teammate to fix the entry or add a corrective log with an explanation. That keeps the history under control and prevents agent-level data from becoming mixed together.

The Time Field in the Ticket List

The official Timer page says total time can be added to the ticket list table. The ticket list items documentation explains that the ticket list is built from available fields and that fields can be added to the agent ticket list or the customer ticket list. For a support manager, this is one of the most useful ways to spot overloaded tickets without opening every single one.

Do not add the time field to every view right away. Start by showing it in the agent list or in a separate saved filter for the manager. In the customer list, a field like this is only useful when you truly want to show customers the effort spent and the team is prepared to explain the numbers.

Time Macros in Notifications

SupportCandy supports the {{time_logs}} and {{time_spent}} macros. The first can output timer logs, while the second shows the time an agent spent on the current ticket. The exact result depends on the template context, so before sending anything to customers, test the email on a sample ticket.

For an internal notification after a ticket is closed, you can use a template fragment like this:

Ticket summary:
Subject: {{subject}}
Status: {{status}}
Total time: {{time_spent}}

Work log:
{{time_logs}}

Ticket link:
{{ticket_url_plain}}

This is not a code customization of the plugin. It is a safe use of documented macros inside a notification template. To roll it back, remove this block from the email template and save the settings. The check is simple: create a test ticket, add one or two logs, close the ticket, and review the email at a test address.

Practical Scenario: An Agency Tracks Billable Support

Imagine an agency that maintains client websites on WordPress. A customer writes to support because a form on the product page is not submitting, and the browser console shows an error from a third-party script. The agent needs to inspect the site, reproduce the issue, disable the conflicting setting, reply to the customer, and leave an internal note. Without the timer, the manager only sees a closed ticket. With Timer, they can see how much time went into diagnosis and the fix.

Goal

Create a clean work log for a single ticket: time spent diagnosing the issue, time spent fixing it, and a short description of each action. The final result is meant for the manager's internal report, not for automatic invoicing. If the agency uses a separate billing system, SupportCandy Timer data can still serve as the basis for manual cross-checking.

Preparation

• The main SupportCandy plugin is installed, and both a test customer and a test agent have been created.
• The Timer widget is enabled for the agent role.
• The Modify Others time log permission is available only to the senior agent or administrator.
• Auto stop on close ticket is enabled, while Auto start on create new ticket remains disabled during rollout.
• The total time field has been added to the agent ticket list, or a separate manager view has been created.

Steps

1. The agent opens the ticket and starts the timer before beginning diagnosis.
2. After reproducing the issue, the agent pauses the timer if they switch to another ticket or need to wait for access.
3. When work resumes, the agent restarts the timer and applies the fix.
4. After verifying the result, the agent stops the timer and adds a description such as: "Form check, script conflict, test submission."
5. If part of the work happened outside the open ticket, the agent adds a manual log with the correct start date and a short description.
6. The senior agent opens View Logs, reviews the entries, and closes the ticket.

Verification

After the ticket is closed, check three places. First, the widget itself should show the log list and total time spent. Second, the agent ticket list should display the total time if the field was added. Third, the test notification with macros should correctly show the time or the work log if you added them to the template.

One Important Detail

If the agent forgot to stop the timer, auto-stop on ticket close can reduce the damage, but it will not fix the whole process. The time between the actual end of the work and the moment the ticket is closed will still end up in the log. That is why, after the first few days of rollout, you should review the longest tickets and discuss with the team which entries look suspicious. That is a normal part of building discipline around the setup.

How to Use the Timer Without Distorting Reports

Time tracking is easy to ruin not with a technical mistake, but with weak rules. If one agent starts the timer only for active work, another includes waiting for the customer's reply, and a third adds time at the end of the day from memory, the final report may look convincing while still being a poor basis for decisions. That is why Timer should be introduced together with a short internal policy.

Separate Work Time From Waiting Time

The documentation confirms start, pause, and stop logs, but it does not describe any automatic distinction between active work and waiting time. That means the team needs to define the rule. In most help desk scenarios, the log should include only active agent work: reading the ticket, checking the site, replying, testing internally, or preparing instructions. Waiting for the customer, waiting for access, or time between tasks is usually not counted as labor.

Write Descriptions You Can Still Understand a Month Later

The log description is a small field, but it is what makes the time meaningful. An entry like "work" is almost useless. An entry like "SMTP check, notification test, customer reply" already explains why the ticket took time. A manager should not have to read the full conversation just to understand the work pattern.

Parallel Agents Are Not a Mistake

The official Timer page explicitly says that multiple agents can run their own timers in parallel for the same ticket. That matters for complex requests: one staff member may be communicating with the customer while another investigates the technical side. In that case, the total time can be greater than the calendar duration of the ticket work, and that is normal. It reflects the team's total labor, not the elapsed time from open to close.

Use Reset Timer Only as an Emergency Action

The documentation says reset deletes previously saved logs. So this is not a button for "starting over" after a minor mistake. It is better to correct the specific entry if the user has permission, or add an adjusting log with an explanation. Reset only makes sense in a test ticket or in a clear error case where everyone understands the consequences.

How to Verify the Setup After Configuration

After configuring Timer, do not just check whether the buttons click. You need to confirm that the data travels through the full chain: ticket widget - log history - total time - ticket list - notification macros - controlled role permissions. That kind of test does not take long, but it immediately surfaces most rollout mistakes.

A Quick Admin Test

1. Create a test ticket on behalf of a customer or test user.
2. Open the ticket as an agent who is allowed to use the Timer widget.
3. Start the timer, wait briefly, stop it, and save a description.
4. Add a manual log in the XXd XXh XXm format.
5. Open View Logs and verify the author, start date, time, and description.
6. Log in as an agent who does not have the Modify Others time log permission and make sure they cannot change someone else's entries.
7. Check the ticket list if the total time field has been added to it.
8. Send a test notification with macros and confirm that the email does not reveal unnecessary internal details.

What Counts as a Successful Result

The setup can be considered working if the agent sees Timer only where they should, can save their own log, cannot change other people's entries without permission, and the manager can see the total ticket time. If you enabled customer visibility, the customer should see only what you are prepared to show. If macros are used in emails, they should read clearly, without technical clutter, and they should not break the notification template.

Test Timer against a realistic workflow: one test ticket, two agents, one manual log, one closure, one email. That tells you far more than a formal check that only confirms "the widget appeared."

Rollout Rules for the Support Team

The technical setup of Timer takes less time than getting people to use it consistently. Once the widget itself has been verified, it is worth writing a short internal policy. It does not need to be a long, multi-page document. It is enough to define which actions are tracked, when an agent should pause the timer, who corrects mistakes, and which values appear in reports.

This policy matters even more because agent timers are independent. Two staff members may work on the same ticket, and both will add their own logs. That is correct if you are measuring total team effort. But if a manager expects to see "how many hours the ticket was active on the calendar," the number will look inflated. Before the first report, make sure everyone agrees that Timer shows labor effort, not the lifetime of the ticket.

What Should Count as Work Time

Only include actions the agent actually performs on the request: reading the message, checking an attachment, testing on the site, investigating the cause, preparing a reply, writing an internal note, or rechecking after a fix. Do not include waiting for access, waiting for the customer, a break, switching to another ticket, or the time when the ticket is open in the browser without active work.

If some of the work happens outside the browser, for example, the agent calls the customer or checks the issue in a separate service, use a manual log. In the description, note that it was outside work. That way, the manager will later understand why the entry was added manually rather than through the live timer.

How to Describe Logs

The description should be short, but still auditable. Bad descriptions: "reply," "check," "worked." Good descriptions: "form and SMTP check," "theme conflict test," "customer reply with instructions," "recheck after clearing cache." This style makes the history readable without a full ticket deep dive.

If your team supports clients under contract, do not put internal judgments, debatable wording, or private details into the description. Even if the customer cannot currently see the logs, those entries remain in the support system and may show up later through macros or exports. For internal analysis, neutral technical wording is the safer choice.

Who Should Correct Mistakes

Mistakes will happen: a forgotten stop, the wrong manual log duration, an entry under the wrong agent, or an overly vague description. It is not a good idea to give everyone the Modify Others time log permission just for convenience. It is better to assign responsibility: the senior agent reviews questionable entries at the end of the shift, and the administrator only steps in for system-level issues.

If the mistake is not critical, do not delete the entire log history. Add the correct entry or edit the specific log using a user who has permission. Reserve timer resets for test requests and rare situations where all saved logs really do need to be removed.

How to Analyze the Data Without Fooling Yourself

The first time reports should not be used for hard employee evaluation. At the beginning, the team is still learning to click the timer, pause it correctly, and write useful descriptions. It is better to watch for trends: which ticket categories take the most time, where canned answers are needed, where customers lack documentation, and which requests regularly require a second agent.

After a few weeks, you can compare average time by category, complex tickets involving multiple agents, and requests where time differs sharply from the norm. If the data looks strange, check the logging process first and only then draw conclusions about individual performance.

Using Timer Together With the Ticket List, Customer Widget, and Notifications

SupportCandy Timer becomes much more useful when its data does not stay locked inside the sidebar widget of a single ticket. The official add-on page mentions three output directions: total time in the customer widget, a time field in the ticket list table, and timer log/time spent macros in email notifications. Each of these serves a different purpose, so they should be enabled selectively.

Ticket List for the Manager

The time field in the ticket list helps you quickly find requests with a high support cost. But do not overload the main list for every agent. If you add too many columns, the agent view becomes harder to read. A strong approach is to create a separate manager view or saved filter where total time appears alongside subject, status, priority, and assignee.

That kind of list answers specific questions: which tickets took the most time, who worked on the request, whether the ticket is closed, and whether it belongs to a recurring issue. If you already use categories or custom fields, you can analyze time alongside them. At that point, Timer becomes more than just a timer. It becomes a basis for improving support operations.

Customer Widget for Customer Context

The customer widget is useful when an agent needs to understand a customer's history. If one user has accumulated many labor-intensive tickets, that may point to a complex product, weak documentation, a problem with a specific integration, or a customer who needs a different support format. The official Timer description says agents can see total time spent across customer tickets on the individual ticket screen.

Do not turn that into a reason to argue with the customer. Total time is an internal quality signal. If one customer consistently requires a lot of work, first check whether your answers are clear enough, whether a knowledge base exists, whether the same issue keeps repeating, and whether a separate onboarding process is needed.

Notifications With Macros

Time macros should be added gradually. An internal email after ticket closure can include {{time_spent}} and {{time_logs}} so the manager sees the result without opening the ticket. Customer emails should usually stay shorter: in some cases, it is best not to show time at all, while in others it makes sense to show only the total if that is part of the service agreement.

Before publishing the template, test how the macros look with one log, several logs, and an empty history. If the email looks awkward when the log is empty, do not use the macro in the customer template, or keep it only in an internal notification.

If the Timer Is Not Visible, Time Is Not Saving, or Reports Look Strange

SupportCandy Timer troubleshooting usually comes down to roles, widget visibility, manual time format, closing statuses, and team habits. Below are common symptoms for this kind of add-on. They do not replace official support, but they do help you quickly understand where to look first.

The Timer Widget Does Not Appear in the Ticket

Symptom: the add-on is active, but the agent cannot see the timer on the ticket page. Possible causes include the widget being disabled in Ticket Widgets, the agent role not being included in allowed roles, the user not being added as a SupportCandy agent, or the wrong ticket screen being open.

What to check: open Support - Settings - Ticket Widgets and make sure Timer is enabled. Then check the user's role under Support - Support Agents - Agents. If the role is restricted, add it to the widget's allowed roles.

How to fix it: enable the widget, assign the correct role to the agent, save the widget order, and refresh the ticket page. If the widget is meant only for managers, do not widen access to all agents without a reason.

A Manual Log Is Not Accepted

Symptom: the agent tries to add an entry, but the system does not save the time or shows an error in the time spent field. The documentation lists the XXd XXh XXm format, so arbitrary formats may fail.

What to check: enter a test value in the expected form, such as 0d 1h 15m, if that matches the interface in your version. Also verify that the start date and description are filled in.

How to fix it: standardize one format in the instructions for agents. If the team is used to decimal hours from an outside system, convert them to days, hours, and minutes first instead of entering them as a fraction.

The Agent Cannot Choose the Log Author

Symptom: there is no author selector in the log form, even though the manager wants to add an entry for another employee. This is expected behavior if the user does not have the Modify Others time log permission.

What to check: open the agent role and review the other permissions section. The permission must be assigned to the exact role the user is using inside SupportCandy.

How to fix it: grant the permission only to the senior agent or support administrator. If you give it to everyone, fixing one isolated problem creates a permanent risk of uncontrolled log editing.

The Timer Keeps Running After the Work Is Done

Symptom: logs show unusually large values because the agent forgot to stop the timer. The cause may be that auto-stop on ticket close is disabled, or that the ticket stayed open long after the actual work ended.

What to check: whether Auto stop on close ticket is enabled, which statuses count as closing statuses in your workflow, and whether the agent closes the ticket immediately after replying.

How to fix it: enable auto-stop if it fits your workflow, and add a checklist step for agents: "stop the timer before closing." Correct suspiciously long entries through a user with edit rights, not through a blanket reset.

The Customer Can See Time the Team Is Not Ready to Show

Symptom: a customer user can see the timer widget or the time value and starts asking questions about internal effort. The cause is overly broad widget visibility.

What to check: the visibility settings for the Timer widget and customer view. The official product page says customers can see the widget if allowed, but only the time.

How to fix it: temporarily limit customer visibility, refine your logging rules, and only then restore customer-facing output if it is actually needed for the contract or support process.

An Email With Macros Looks Confusing

Symptom: a notification using {{time_logs}} or {{time_spent}} contains too much service information or does not show the expected value. The cause may be template context, empty logs, or an unsuitable sending scenario.

What to check: use a test ticket with one clear log and verify your email notification and SMTP settings. The official documentation reminds you that email notifications require a properly configured sending setup.

How to fix it: start by adding the macros to an internal email for the agent or administrator. Move only a brief summary into the customer email, and only if it is genuinely needed.

When SupportCandy Timer Is the Right Choice

SupportCandy Timer is a strong fit if you want to track time directly inside WordPress tickets and already trust SupportCandy as your help desk core. Its main strength is how closely it matches real agent work: the timer lives in the ticket view, logs are saved next to the request, total time can be shown in the list, and macros help bring that data into notifications.

Before rolling it out, you need to make a few decisions: who can see the Timer widget, who can change other people's logs, whether auto-start is needed, whether time should be shown to customers, and whether macros should be used in emails. Once those rules are defined, the plugin helps you do more than just "count minutes." It helps you see the actual support workload.

After configuration, open a test ticket, run the full cycle with two agents, review the log list, check the time field in the ticket list, and inspect the email with macros. If the result is clear, you can download SupportCandy Timer and move on to a careful rollout on the live site.

The main practical takeaway is simple: Timer is not useful by itself. It becomes useful as part of a disciplined support process. It produces good data only when the team shares the same understanding of what counts as work, when to pause, and who is responsible for fixing mistakes in the logs.