The Same Answer, Typed Forty Times
Every support team keeps its standard answers somewhere: a text file, a pinned note, a draft folder. Copying the words was never the hard part. The hard part is the status change that should go with them, and the case where the standard answer is confidently wrong. What a canned reply should carry besides its text, and what it should refuse to do.
It is a Tuesday morning and the IT desk has forty tickets that all say roughly the same thing: the password reset email has not arrived. The agent on the queue has the answer in a text file on her desktop, written two years ago and polished since. Check the spam folder, wait five minutes, reply here if it still has not come. She copies it, pastes it, changes the name, sends. Forty times. By lunch the replies have all gone out and the queue looks healthy. What she did not do, on perhaps a dozen of them, was move the ticket to “waiting on requester”. Those twelve are still counting down against the resolution target as if somebody on the desk were working on them, and two of them will breach overnight while their requesters sit on the answer.
The short version, first
A canned answer in a text file saves typing. A canned reply in the helpdesk is worth having only for what rides with the text: the status, the priority, the owner and the tags change in the same send, so “waiting on requester” is never the step somebody forgets. In AWRA OpsHub a canned reply is a body with fourteen placeholders plus up to four actions, kept in a personal or a shared library. Inserting one renders it against the ticket into the reply box, where the agent can edit every word and drop its actions before sending. The actions run with the agent’s own permissions, never the author’s, and the whole send succeeds or fails as one. The risk is the other side of the convenience: a confident answer sent to the wrong case. The product makes that harder to do by accident, and some of what would make it harder still is listed at the end as work we can add.
Why the text file keeps winning
Most helpdesk tools have had a snippets feature for years, and most agents still keep their own text file. The reason is straightforward. A snippet that only inserts words saves nothing over the clipboard, and the agent’s file is better: it is theirs, it is phrased the way they talk, and they can search it with the same keystrokes they use everywhere else. If the tool offers the same thing in a smaller box, nobody switches.
The text file has one weakness, and the opening scene shows it. A reply is rarely only words. “Please send a screenshot” means the ticket should now wait for the requester. “This is fixed, reply if it comes back” means the ticket is resolved. “I have passed this to the network team” means it has a new owner. Each of those is a second click in a second place, and the second click is the one that gets dropped on the fortieth ticket of the morning.
The status change is not housekeeping either. In this product a ticket in waiting on requester has its resolution clock paused. Escalation rules for an overdue resolution skip it, and the requester answering, from the tracking page or by email, puts it straight back into progress. Forget the status and the clock keeps running against a ticket that is not yours to move. Set the status and forget the reply, and the clock stops on a requester who was never asked anything. Both mistakes happen because the words and the state are two separate acts. A canned reply exists to make them one.
The words were never the hard part. The second click was.
What a canned reply can carry
A canned reply has a title, an optional body and up to four actions. It needs at least one of the two: a body with no actions is a plain snippet, and a reply with actions and no body is a one-click triage button. Both are allowed, and an empty one is refused when you save it.
| Action | What it does | Who may trigger it | What else happens |
|---|---|---|---|
| Set status | Moves the ticket to any of the six statuses | An agent who may manage tickets | Requester and watchers are told; a resolution asks the requester for a rating |
| Set priority | Changes it to low, normal, high or urgent | An agent who may manage tickets | On a live ticket the due dates move with the new priority |
| Add tags | Adds lower-case tags to the ones already there | An agent who may manage tickets | Existing tags are kept |
| Assign | Gives the ticket to a named, current employee | An agent who may assign tickets | An open ticket moves to in progress and the new owner is notified |
The order is fixed, and one detail of it matters. Status always runs last. A reply that assigns a ticket and resolves it would otherwise be bumped back to in progress by the assignment, because assigning an open ticket moves it into progress. Running status last means the reply ends in the state its author chose.
The reply itself is either public or an internal note, set per canned reply. A public reply is emailed to the requester and counts as the first response; an internal note stays on the desk and does neither. That distinction has a post of its own, Making the First Real Reply the One That Counts, and it carries over unchanged: a canned internal note never stops the first-response clock.
Fourteen placeholders and not one more
The body can name the requester, the ticket and the agent through placeholders written in double braces: the requester’s full name, first name and email; the ticket’s reference, subject, status, priority, category, department and resolution due date; the agent’s name, first name and email; and your organization’s name. Fourteen in all, listed on the library page beside the editor.
That list is closed on purpose. A template engine that walks property paths will happily print anything it can reach, and a canned reply is written once and sent thousands of times by people who did not write it. Here only those fourteen names resolve. Anything else between double braces is left exactly as written, so a typo shows up as a typo in the reply box instead of turning silently into a blank. Substitution happens in a single pass, so a requester who registers under the name of a placeholder sees their own name printed literally rather than having it expanded. Line breaks and other control characters are stripped from every value, and the one place the reply becomes HTML, the email to the requester, escapes the text before it turns newlines into line breaks. Those properties are each covered by a test.
Where a placeholder can still embarrass you
A placeholder with nothing behind it renders as nothing. A ticket with no category turns “your {{ticket.category}} request” into “your request” with the word simply gone, and a ticket with no due date leaves a gap where the date should be. A requester known only by an email address has that address as their first name, so a greeting built on the first-name placeholder greets them by their email. None of this is wrong, but all of it is visible to the customer. Write bodies that still read well when a value is empty, and keep due dates and categories out of replies that go to tickets which may not have them.
Two ways to use one, and why the slow one is the default
On a ticket, the canned replies sit above the reply box, searchable by title, text and folder, most used first. Each one shows its folder, whether it is shared or personal, and in plain words what it will do besides insert text: “Set status to Waiting Requester · Add tags: password”. There are then two ways to use it.
-
Insert
Clicking the title renders the body against this ticket on the server and drops it into the reply box, after anything already typed. The agent can rewrite every word. Below the box, each inserted reply is listed with “on send it will also:” and its actions, next to a button that drops those actions. Several replies can be inserted into one message, up to ten; one reply is posted and each one’s actions run in the order they were inserted, so a later status wins.
-
Apply
A lightning-bolt button beside each title sends the stored reply and runs its actions in one click, after a confirmation that asks whether to send it now. The rendered text is not shown first. This path is for replies that never change: the routine acknowledgement, or the actions-only triage reply with no body at all.
Insert is the path to reach for, because the danger of a canned reply is never the typing. It is the agent who sees “password reset” in a ticket that is actually about an account locked by the security team, and sends forty polished words that tell the requester to check their spam folder. The words are confident and well written. That makes them convincing, and it is exactly why they are dangerous on the wrong case. A rendered reply sitting in an editable box, with its side effects spelled out underneath, gives the agent one more look before it goes.
Three smaller rules in the composer come from real mistakes. If an inserted reply is an internal note, the Internal note box is ticked for the whole message and the agent is told so; it is never unticked automatically, because unticking it once sent a half-written internal note to a requester. If the agent clears the reply box, every inserted reply is dropped with it, so a status change cannot outlive the text it belonged to. And if the agent edits the text heavily, the actions still run and the use is still counted, because the agent chose that reply for this ticket and the text is theirs to adjust.
The answer depends on what the requester actually wrote
Insert and read it
The rendered text lands in the reply box with its actions listed underneath. Change what needs changing, drop any action that does not fit, then send.
The reply is identical every time, such as an acknowledgement
Apply in one click
The stored text is sent and the actions run immediately. Keep these short and free of placeholders that might be empty.
You only need to triage: tag it, set priority, hand it on
An actions-only reply
Write the reply with no body. Applying it changes the ticket without sending the requester anything.
You wrote something good and will need it again
Save it as your own
Add it to your personal library. If it is good enough for the whole desk, ask whoever curates the shared library to adopt it.
A shared reply cannot do more than the agent using it
Canned replies live in two libraries. Your personal library is yours alone: anyone who can work tickets can write to it, and to everyone else your replies do not exist, so opening one of a colleague’s by its address returns “not found” rather than “forbidden”. The shared library is visible to every agent, and writing to it needs a separate permission, so the answers the whole desk relies on are curated by somebody accountable for them. Folders follow the same split, and a reply must live in a folder from its own library.
The more interesting rule is about the actions. A supervisor can write a shared reply that resolves a ticket and assigns it to the second-line team. An agent who may only reply can still use it. When they do, the reply goes out, and the actions they are not allowed to take are skipped and named in the confirmation: “Skipped: status (you do not have permission), assignee (you do not have permission).” The permission belongs to the person sending, not to the author. Without that, a shared library would become a quiet way round every permission on the desk, since anything a supervisor could do once could then be done by anyone with access to the button.
The same check catches a reply that has gone stale. A canned reply that assigns to a named person is refused at save time if that person is not a current employee. If they leave later, the reply still sends, the assignment is skipped, and the agent is told that the assignee is no longer an active employee. The ticket does not end up assigned to somebody who has gone.
All of it or none of it
Sending a canned reply is one database transaction: the comment, every action, the usage count and the audit entry. If any step fails, nothing is kept. That replaced an earlier order in which the reply was posted and emailed first and the actions ran afterwards, so a failure partway through left the requester holding an email that said “resolved” on a ticket that was still open. There is a test that makes the status notification fail on purpose and checks that no comment, no status change and no use survive.
Each use is written to the audit log with the reply’s title, the ticket reference, and two lists: the actions that ran and the actions that were skipped. That answers the question a supervisor asks after a complaint, “who closed this, and was it a person or a template?”, without anyone needing to remember. Each reply also keeps a usage count, incremented atomically so two agents using it at the same moment both count, and the library is sorted by it. The replies nobody uses sink to the bottom, which is a gentle prompt to delete them.
On the phone
The mobile app’s ticket screen has the same picker, with each reply already rendered against the open ticket. An agent picks one canned reply per message, edits it, and sends, and its actions run on the server under the same rules as on the web. A reply with no body is applied directly. An agent who writes something worth keeping can save it from the app as one of their own canned replies. The shared library, the actions and the folders are curated on the web, which is the right place for a decision that changes what forty colleagues send.
Six additions that make a canned reply harder to send to the wrong case
Ordered by how often each one would have stopped a confident answer reaching the wrong ticket, or a forgotten step being forgotten.
A preview on one-click Apply
The confirmation shows the rendered text and flags any placeholder that resolved to nothing or stayed unresolved, before a word reaches the requester.
Replies scoped to a queue or category
A shared reply can be limited to the departments or categories it was written for, so a billing answer is not offered on a hardware ticket.
Knowledge-base articles in a reply
A placeholder or picker that inserts a published article’s title and link, so the reply follows the article when it is updated.
Category and department actions
Recategorise or move a ticket to another queue as part of a reply, with the routing and due dates that follow from the new category.
Reopen rate per canned reply
How often a ticket closed by each reply comes back, beside its usage count, so the confident answer that keeps being wrong is visible.
Version history for shared replies
Each edit to a shared reply kept with its author and date, and each audit entry tied to the version that was sent.
The preview is small and closes the one path that sends text nobody has read. Scoping and the reopen rate belong together, because the second tells you where the first is needed.
Tell us what your desk sends forty timesFour questions for any helpdesk that offers macros
If a supervisor’s macro closes tickets, can a junior agent use it?
What you will probably hear
Yes, macros are shared with the team.
How to read it
Ask whose permissions the actions run under. If the answer is the macro’s, the shared library is a way round your role design.
What happens if the reply sends but the status change fails?
What you will probably hear
That should not happen.
How to read it
Ask whether the reply and the actions are one operation. If they are two, the customer can hold an email that contradicts the ticket.
What does a placeholder print when the field is empty or misspelt?
What you will probably hear
It is replaced with the value.
How to read it
Ask for the empty case and the typo case specifically. Blank is quiet and invisible; left-as-written is ugly but noticeable before sending.
Can I see which tickets a macro changed, and how?
What you will probably hear
It shows in the ticket history.
How to read it
Ask whether the log names the macro and lists the actions that were skipped as well as those that ran. That is the question after a complaint.
What AWRA OpsHub does today
- Personal and shared libraries, with folders, search, and a separate permission for writing to the shared one.
- Fourteen placeholders for the requester, the ticket, the agent and your organization, rendered on the server in one pass from a closed list.
- Four actions per reply: set status, set priority, add tags and assign to a current employee, with status always applied last.
- Insert into an editable reply box, with each reply’s actions listed and removable before sending, and up to ten replies in one message.
- One-click Apply for replies that never change, and actions-only replies for triage.
- Actions gated on the sending agent, with anything skipped named in the confirmation and the reason given.
- One transaction per send, so the reply, the actions, the count and the audit entry succeed or fail together.
- An audit entry per use listing the actions applied and skipped, and an atomic usage count that sorts the library.
- The same picker in the mobile app, with saving to your personal library from the phone.
More we can add to your workspace
- A rendered preview on one-click Apply, with a warning for any placeholder that came out empty or unresolved.
- Fallback text for an empty placeholder, such as “there” when a requester has no name on file.
- Shared replies scoped to a department or category, offered only on the tickets they were written for.
- A knowledge-base article picker inside a reply, inserting a published article’s title and link.
- Category and department actions, moving a ticket to another queue with the routing that follows.
- Tag removal as an action, alongside adding tags.
- A public reply and an internal note from one canned reply, posted together in one send.
- Reopen rate per canned reply, shown beside its usage count.
- Version history for shared replies, with each audit entry tied to the version sent.
- Several canned replies in one message on mobile, as the web composer already allows.
Where we point you to a specialist
- We will not let a canned reply run an action that the agent sending it could not take by hand. The author’s permissions stay with the author.
- We will not have the system choose a canned reply for a ticket and send it to a requester on its own judgment. An agent picks the reply for each ticket, because the cost of a confident wrong answer falls on the customer.
The Apply preview and the empty-placeholder fallback are small and change what customers see as soon as they ship. Scoping by queue and the reopen rate are the pair we would scope first for a desk with more than one team sharing a library.
Bring us your text file
The quickest way to judge canned replies is to take the answers your agents already keep on their desktops and ask, for each one, what should happen to the ticket when it is sent. If the answer is usually “nothing”, a text file is fine. If it is “wait on the customer” or “hand to second line”, we would like to show you that step riding with the words.
Talk to us about your helpdeskFrequently asked questions
What can a canned reply do besides insert text?
It can set the ticket status, set the priority, add tags and assign the ticket to a current employee, all in the same send as the reply. The status is always applied last, so a reply that assigns and resolves ends resolved.
Can I edit a canned reply before it is sent?
Yes. Inserting a canned reply renders it against the ticket and puts it in the reply box, where every word can be changed and any of its actions can be dropped before sending. The one-click Apply button sends the stored text without showing it first, so keep that for replies that never change.
Who can create and edit shared canned replies?
Anyone who works tickets can keep a personal library that only they see. Writing to the shared library, which every agent can use, needs a separate permission that an administrator grants.
What happens when an agent uses a shared reply with actions they are not allowed to take?
The reply is sent and the actions they may not take are skipped. The confirmation names each skipped action and the reason, and the audit log records which ran and which did not.
What does a placeholder show if the ticket has no value for it?
It shows nothing, so a ticket with no category leaves a gap where the category name would be. A misspelt or unknown placeholder is left exactly as written, so it is visible in the reply box before sending.
Can agents use canned replies in the mobile app?
Yes. The app lists the same personal and shared replies, already rendered for the open ticket, runs their actions under the same permission rules, and lets an agent save a reply as one of their own. Shared replies, actions and folders are managed on the web.
