The support desk

Help Centre → Requests.

The queue opens on Needs a reply: every request that is new or open, not everything ever. A desk that opens on four thousand closed requests is a desk nobody opens twice. Once you reply, a request is waiting on customer and leaves the queue until they answer. Assigned to me is the same queue, narrowed to the requests assigned to you. High and urgent is the same queue again, narrowed to the requests marked High or Urgent.

Each request has:

• a reference like K4M2-P7QX, which is what a customer quotes. It is random rather than sequential, so it does not tell the world how many requests you have had, and it avoids I, O, 0 and 1 because those are where reading one down a phone line goes wrong;
• a status — new, open, waiting on customer, resolved, closed;
• a priority (low, normal, high or urgent) and an assignee;
• the topic the customer chose under What is it about?, shown as a small label under the subject in the queue and at the top of the request's sidebar. A sub-topic is named with the topic above it, such as Billing › Refunds;
• the product it was sent about, when it came from Ask about this product or a link naming one (see Opening the form already filled in), under the topic in the request's sidebar, named as it is called now and linked to its page;
• the customer's rating, if they answered How did we do? (see below), shown under the topic in the request's sidebar with anything they wrote.

Statuses move on their own: replying sets it to waiting on customer, and a customer replying sets it back to open. You rarely need to touch it. A request waiting on the customer can also resolve itself after a number of days you choose; see When a customer does not answer below.

The note under Status on a request's screen says whether saving it as Resolved emails the customer. If customer emails were off when you opened the request and have been switched on since, saving it as Resolved does not email the customer, as the note said. If the note said the customer would be emailed and customer emails have been switched off since, nobody is emailed. Either way the message after the save says the customer was not emailed, and it still names the colleague you assigned the request to in the same save.

Priority. Every request from the form starts as normal. The customer never chooses it, and never sees it: it is your team's note to itself, set on the request's own screen or with Set priority… below. High and urgent requests carry a label under their subject in the queue, amber for high and red for urgent, and have the High and urgent tab to themselves. Once you mark a request urgent, the emails to your team about it (the customer's replies, and Assigned to you) start their subject with [Urgent]; a high one's do not. The order of the queue does not change: it is always the latest activity first.

Doing several at once. Tick the requests in the queue, or the box at the top of the list to tick every request on the page, choose an action under Bulk actions and press Apply:

• Resolve marks them resolved. While Email the customer on updates is on, each customer gets the Resolved email, as when you resolve one request, and Apply first asks "This sends 12 emails to customers." with the number it will send (a request already resolved is not emailed again). Tick Without emailing the customers to resolve them without any email: useful for junk. Nobody is emailed without that question, and only the customers of the requests it counted are. If Resolve would now email the customer of a request the question did not count (customer emails were switched on after you opened the queue, or a customer replied to a ticked request and reopened it meanwhile), Apply changes nothing and says so, and the queue it comes back with asks again. A request a colleague resolved meanwhile is not emailed again. If customer emails were switched off meanwhile, the message says nobody was emailed.
• Close closes them. Closing emails nobody.
• Assign to… hands them to the person you choose, starting on your own name, or Unassigned takes them off everybody. A colleague you assign them to gets an Assigned to you email for each request, as they would one at a time.
• Set priority… sets the priority you choose on all of them.
• Delete permanently deletes them with their whole conversations and any files sent with them. Apply first asks "Delete 25 requests and their conversations for good?" with the number you ticked. It cannot be undone.

The message after Apply says what was done, such as "12 requests resolved.", and the queue comes back on the same tab, topic, search and page. A request the action would not change (already resolved or closed, already with that person, already at that priority) is left as it is: it is not counted, and it keeps its place in the list. It works on the requests on the page you are looking at, up to 25 at a time; for more, do it again on the next page. Anyone who can answer requests can use it, as they can delete or resolve one request.

Resolve and Assign to send their emails one after another while you wait, so through a slow mail server a page of 25 can take a while. The plugin gives the server the time it needs and finishes the job even if your browser stops waiting; if no message appears, reload the queue to see where things stand.

The search above the queue finds requests by reference, subject or email address, with your words as you typed them less anything shaped like an HTML tag, so a search for a coupon code such as 30%BF finds the request that quotes it and stays in the box. A request sent with version 1.10.0 or earlier keeps the subject it was stored with then, which may be missing part of such a code, and a search with a < in it does not find the < in those older subjects.

The Topic select beside the search narrows the queue to one topic when you press Filter beside it, and a topic includes the topics under it, so choosing Billing lists Refunds requests as well. It works with the tabs, the search and the page links, so moving between them keeps the topic chosen, and the numbers on the tabs count that topic's requests. A request sent before its topic was deleted, or with no topic chosen, has no label and is left out of every topic's list.

What a customer's message keeps#

A customer's message keeps what people write a message with: paragraphs, line breaks, bold, italic, underlined and struck-through words, lists, links, code and quotes. Anything else is shown as its words, so a message cannot look like part of the request's screen: no coloured box, no button, no picture from another site. Files a customer attaches are shown under their message as before. Messages kept by earlier versions are shown the same way. Your own replies and notes keep the formatting the reply box gives them.

Who answers each topic#

Settings → Support Desk → Automatic assignment lists every topic with a person beside it. A new request is assigned to the person chosen for its topic the moment it arrives, and, while Email me when a request arrives is on, the new-request email goes to them as well as to the address under Send notifications to (one email, if the two are the same address). A sub-topic left at Same as parent topic goes to whoever answers the topic above it; a top-level topic left at None stays unassigned, as every request did before. The customer's form offers only topics that have at least one article, so a topic without any is marked Customers cannot choose this topic until it has an article: a person chosen for it is kept, and gets its requests once it has one.

The list offers the same people as Assigned to on a request: anyone who can answer requests (see below). If someone chosen here later loses that, new requests in their topics wait unassigned rather than going to them; the choice is kept, shown with (cannot answer requests) after their name, and works again if they get it back. The same person stays on a request's Assigned to list too, so saving the request for another reason does not unassign it.

With WPML or Polylang, the Settings screen lists the topics of the language wp-admin is in. Saving it changes those topics only; people chosen for the other languages' topics are kept. The Requests screen is not limited that way: whatever language wp-admin is showing, each request shows the topic the customer chose, in the language they chose it in, and the Topic filter lists every language's topics. A topic with the same name in two languages carries its language's code there, such as FAQ (EN) and FAQ (ES), and choosing one lists that language's requests only.

When a request is handed to somebody#

Assigning a request to a colleague on its screen emails them Assigned to you, with the request's subject and reference, a link to it and the customer's first message, in the language they chose in their own profile (Users → Profile → Language), or in your site's language if they left it at the site default. The notice after Save names who was emailed. Assigning a request to yourself sends nothing, and neither does the automatic assignment above, since that person is already on the new-request email. The email is one of the notes to the desk, so Email me when a request arrives turns it off along with the others. Developers can hook trhc_ticket_assigned (request id, new person, previous person).

How did we do?#

When a request is resolved, the customer is asked How did we do? They answer Good or Not good, and can add a comment of up to 500 characters.

Settings → Support Desk → Ask customers to rate resolved requests. It is on for a new install, and off for a desk that already had the plugin before this was added, so your customers are not asked anything new until you switch it on.

• Where they are asked. On the request page, between the conversation and the reply box, while the request is resolved. The Resolved email asks too, with a Good and a Not good link. The links only open the request with that answer chosen; the rating is kept when the customer presses Send rating, because email security scanners open every link in a message. The email goes only while Email the customer on updates is on; with it off, the question is still on the request page.
• Who can rate. The customer: whoever holds the private link to the request, or the account that sent it. Somebody who works the queue, opening the customer's view from the request screen, is told only the customer can rate it, and cannot rate on their behalf.
• One rating per request. The customer can change it while the request is resolved. Once you close the request, it is locked, and the request page shows what they gave. If the customer replies, the request reopens and the question goes away; the rating is kept, and they are asked again when you resolve it again.
• The request screen shows Customer rating under the topic: a green Good or a red Not good, when, and the comment underneath. A request nobody has rated says Not rated yet while ratings are on.
• The dashboard adds a Rated good card, after First reply: the share of ratings given in the last 30 days that were Good, and how many ratings that is. A customer who did not answer counts in neither half. The card shows 100% only when every rating was Good and 0% only when none was, so one Not good among a few hundred reads 99% rather than rounding up to 100%. Under Needs a reply, Rated not good lists up to five requests rated Not good in the last 30 days, newest first, with the start of what the customer wrote.

Switching it off removes the question and the dashboard card, and a rating sent from a page left open is not kept: the page tells the customer the request can no longer be rated. If your site could not save a rating, the page says so and keeps their answer and comment in the form, so they can send it again. Ratings already given stay, and still show on the request screen and in a personal data export. A request resolved before you switched it on shows the question on its page too, but nobody is emailed about it.

A rating is kept with the request: Good or Not good, the comment, and when. No IP address or browser detail is stored, and nothing is sent anywhere.

If your database did not accept the new columns, a red note under the switch says ratings are not being collected. Switch the plugin off and on again under Plugins to try once more.

When a customer does not answer#

Once you reply, a request waits on the customer. Many never answer: your reply fixed it and they did not say so, or the problem went away. Help Centre can resolve those requests for you, so the queue stays tidy and the customer is still asked How did we do?

Settings → Support Desk → Resolve requests waiting on the customer. Choose After 3 days, 5, 7, 14 or 30. The default is Never, leave them waiting, for a new install and for a desk that updates, so nothing changes until you choose a number.

• The count starts at your last reply. A private note does not restart it, and neither does changing the priority or who the request is assigned to. A reply from the customer reopens the request, as always, and the count starts again from your next reply.
• Left alone: urgent requests, which never resolve this way, and a request whose last message is the customer's (one you set to waiting on customer by hand after they wrote).
• A reply at the same moment counts. Whether somebody has written since your reply is asked again as the request is resolved or reminded, so a customer whose reply arrives while the check is running is not told the request was resolved because you had not heard back, nor asked whether they still need help. A reply of yours at that moment starts the count again.
• What the customer gets. While Email the customer on updates is on, the Resolved email, saying the request was resolved because you had not heard back, with the link to reply and reopen it, and How did we do? while ratings are on. The request is resolved, not closed, so their reply reopens it just as it reopens a request you resolved yourself.
• A reminder first, if you like: Remind the customer first sends an email 1, 2 or 3 days before, asking whether they still need help, with your last reply quoted and the date the request resolves. That date is kept: if the reminder goes out late, the request waits until the date it gave. A reminder is never sent sooner than a day after your reply, and only while customer emails are on.
• Old requests go quietly. A request already more than a week past its date when Help Centre first looks at it is resolved without any email or reminder. So switching this on with a backlog does not email everybody you ever answered: with After 7 days, the requests you answered more than 14 days ago are resolved without an email.
• On the request's screen a line in the conversation says what happened and when: "Reminder emailed to the customer. The request resolves on 29 October 2026 unless they reply.", or "Resolved automatically after 7 days without a reply. The customer was emailed." (or was not). The customer does not see these lines.
• In the queue such a request's status reads Resolved automatically until somebody writes on it again.
• The dashboard has a Resolved automatically card: how many requests resolved themselves in the last 30 days. It shows while the setting is on, or while any did. A desk that has not chosen a number is offered it on the dashboard once three requests or more have waited on the customer, untouched, for more than 7 days, with that number. Resolve after 7 days sets it; No thanks hides the offer, and the setting stays under Settings.

Nothing is resolved while the support desk itself is switched off, because the customer's link then shows nothing to reply in. Customer emails switched off only stop the emails: requests still resolve.

It runs as a WordPress scheduled task once an hour, which is booked only while the setting is on and is removed when you deactivate the plugin. Scheduled tasks run when somebody visits the site, so on a quiet site a request may resolve a little after its day. Each run handles the requests it can in 20 seconds and leaves the rest for the next hour.

Saved replies#

Help Centre → Saved replies.

A desk answers the same dozen questions over and over, and typing them out again each time is slower, less consistent and worst at the end of a long day. Write each answer once here, give it a name you will recognise in a list, and it appears as a button above the reply box on every request.

Emptying a name is how a saved reply is removed. There is no separate Add button: a blank pair of fields sits under the last one you saved, and there are always two spare.

An answer can carry any of these, and each is replaced with the real thing as the reply drops into the box — never left for you to notice:

A placeholder with nothing to fill it is removed along with the space in front of it, so a reply never goes out with a gap or a double space where a name should have been.

The text arrives at your cursor rather than replacing what is already in the box, so half a reply you have typed survives reaching for a saved one to finish it. It works on both tabs of the editor, Visual and the one beside it, called Code or Text depending on your version of WordPress. Text in a saved reply that shows a tag, such as <code>, arrives as that text, and so does a < in the customer's subject; neither turns into a real tag on the way. Only the buttons above the reply box put anything into it, whichever way the request was opened.

Delete request, on the request's own screen, removes it and its whole conversation for good — for spam, or when a customer asks for their details to be erased.

The list shows 25 requests a page, with links to the first and last pages, the pages either side of the one you are on, and Previous and Next.

WooCommerce orders#

On a WooCommerce shop, a signed-in customer can choose which of their recent orders a request is about, from a list of their own orders under the subject. It is optional. The request screen then shows that order and the customer's five most recent orders beside the conversation, each linked to the order. A link can choose the order for them with order_id= (see Opening the form already filled in).

This is only for requests sent from an account. A guest types an email address that nobody has confirmed, so their request is never matched to anyone's orders. The orders panel is shown only to people who can manage orders, not to everyone who can answer requests.

Who can answer requests#

Administrators, and on a WooCommerce shop the Shop Manager role, can open the dashboard and Requests, reply, assign and delete. Settings stays with administrators. To let another role answer requests, give it the trhc_manage_requests capability with a role editor plugin.

Private notes#

Write a note instead of a reply and it stays on the request for whoever picks it up next. It is never emailed and never shown to the customer.

How customers get back in#

Signed-in customers see every request they sent while signed in on the page holding [trasl_my_tickets], with the form for a new one underneath. Guests get a private link, sent to them by email, holding a key that opens only their own request — no account, no password.

A request sent as a guest stays behind that link, even if someone later signs in with the same address. The address on an account is not confirmed by anybody, so it is not proof of whose requests they are.

The form#

Text above the form is optional. Leave it empty and the default sentence is shown, in your site's language. A default that an earlier version saved into the box counts as empty too, in English or any language Help Centre comes in. Text you write yourself can be translated with WPML String Translation or Polylang, which find it under Help Centre's settings.

Each visitor can open five requests in ten minutes, and each email address five in an hour. A real customer never gets near that; a script filling in the form with somebody else's address stops there, before your site has sent that person a pile of receipts. Anyone who can answer requests is never limited.

If something goes wrong on sending — a missing topic, or a page left open so long that it expired — the form comes back with the reason above it and what the customer typed still in it. The message comes back as typed, and the email address as typed on one line. The subject and the name come back as they will be kept: on one line and without anything shaped like an HTML tag, and the subject with a coupon code such as 30%BFRIDAY or a < such as the one in under <5 kg as typed. A request sent with version 1.10.0 or earlier keeps the subject it was stored with, which may be missing part of such a code.

Opening the form already filled in#

A link to the page holding the form can choose its topic and type its subject, so a returns page, a menu item or an order email opens the form on the right question. Add these to the page's address:

• topic= a topic's slug or number, such as ?topic=returns. Only a topic the form offers (one with an article) is chosen; any other is ignored.
• subject= words for the subject, such as ?subject=Broken%20mug: one line, up to 150 characters, with anything shaped like an HTML tag left out.
• product_id= a WooCommerce product's number. The form then asks Which product is it about? with that product chosen, and the subject reads About: Blue Mug unless the address gives one. Only a published product is named: a draft, or a private, scheduled or password-protected product, is ignored.
• order_id= one of the signed-in customer's own orders, chosen under Which order is it about?. It is ignored for a guest, and for an order that is not theirs.

Together: https://example.com/contact-support/?topic=returns&subject=Return%20request.

Everything filled in is shown in the form, and the customer can change it, or choose Not about a product, before sending. Nothing about the customer is read from an address, not their name, email address or message: addresses are passed around, and kept in browser histories and server logs. If a send fails, the form comes back as the customer sent it rather than as the link filled it in. If another plugin on your site already uses topic= in its own addresses, as some forum plugins do, choose the topic with the shortcode instead.

[trasl_support_form] takes topic, subject and product too, for a page of its own: [trasl_support_form topic="delivery"]. A topic or subject in the page's address comes before the shortcode's.

Ask about this product. On a WooCommerce shop, Settings → Support Desk → Show an "Ask about this product" link puts a plain link under the add to cart button of every product, in your theme's own link style, opening the form on your Requests page about that product. It is off until you switch it on, and waits for a Requests page to be chosen. It is there for a product that is out of stock too. Signed-out visitors see it while Allow requests without an account is on. The link carries the product's number and nothing else, so a page cache can keep the product page as it is for everybody.

The request's screen shows the product under the topic, and the email to your team about the new request, and Assigned to you, name it with a link to its page. The customer's emails do not.