What it is
A canned response is a titled block of reply text an agent can drop into a ticket comment with one click. It is the help-desk answer to the fact that most of a queue's replies are the same handful of paragraphs - "we've received this and here's what happens next", "please reboot and confirm", "closing as resolved, reopen within 7 days if it recurs" - typed slightly differently every time by whoever happens to pick up the ticket.
Bodies can carry substitution tokens so the inserted text is already addressed to the right person and already names the right ticket.
Inserting one into a reply
Open a ticket in TATER Ops and look at the comment box at the bottom of the detail panel. Next to Post there is a 📋 button (Insert a canned response).
- Click 📋. The picker opens with a search box focused, listing every canned response in the org by title, with its category and the first line of its body.
- Type to filter. Search matches on title, category and body, so you can find a macro by a phrase inside it, not only by what it was named.
- Click the one you want. Its text is substituted and appended to the comment box - it does not replace what you have already typed, so you can write a sentence of context and then drop the standard block underneath it.
- Edit freely, then Post. Insertion is just text; nothing is locked afterwards.
The list is loaded once per session and cached, so the picker opens instantly. If you have just created a macro in another tab and do not see it, reload the page.
The five substitution tokens
Anywhere in a body, these placeholders are replaced from the ticket you are replying to, at the moment you insert it. They are substituted client-side - the stored body always keeps the raw {{token}} text, so the same macro produces the right names on every ticket.
| Token | Replaced with | Fallback |
|---|---|---|
{{requester}} | The requester's display name; failing that their email; failing that the ticket's contact email | there - so a greeting still reads "Hi there," rather than "Hi ," |
{{ticketId}} | The ticket's id | empty |
{{ticketTitle}} | The ticket's title | empty |
{{agent}} | Your own display name, from the signed-in account | empty |
{{category}} | The ticket's category | empty |
Token names are matched literally and are case-sensitive: {{ticketId}} substitutes, {{ticketid}} does not. A misspelled token is not an error - it is simply left in the text, which is the visible symptom to look for if a macro posts with braces still in it.
Only {{requester}} has a non-empty fallback. Every other token collapses to nothing when the ticket does not carry that field, so phrase around them - "Regarding {{ticketTitle}}" degrades cleanly to "Regarding", while "Your ticket, {{ticketTitle}}, is now closed" leaves a stranded comma. Email-intake tickets and tickets created straight from a monitor are the common cases with sparse fields.
Creating and editing macros
Open the picker and click ⚙ Manage (or reach the same dialog from any ticket). The manager lists every existing macro with edit and delete actions, and carries the new/edit form underneath.
- Title - required, up to 200 characters. This is what the picker shows and what agents search first, so name it after the situation ("Awaiting user reboot"), not after the answer.
- Category - optional, up to 100 characters. Free text, shown as a chip beside the title in the picker and usable as a list filter. Categories are derived from what is in use rather than configured up front, so simply typing a new one creates it.
- Reply text - required, up to 20,000 characters. The body, including any tokens.
Save creates a new macro, or updates the one being edited. Clear resets the form back to "New canned response" without saving. Editing preserves the original author and creation time; every create, update and delete is written to the activity log as a tasker-canned-response entry with the macro's title.
Who can do what
| Action | Minimum role |
|---|---|
| List and insert canned responses | Auditor |
| Create or edit a canned response | Auditor |
| Delete a canned response | Admin |
Macros are scoped to the organization - they are visible to that org only, and an edit or delete is resolved within the caller's org scope, so an id from another org cannot be reached by guessing it.
What makes a macro worth saving
- Save the reply you keep re-typing, not the reply you wish you sent. A macro nobody recognises in the picker never gets used; one that matches the sentence an agent was about to write does.
- One macro per moment, not per topic. "Password reset - acknowledged", "Password reset - waiting on the user", and "Password reset - closing" are three usable macros; one long "Password reset" macro that has to be edited down every time is not.
- Keep policy statements in one macro and reference it. When the wording of a commitment changes (an SLA, a retention period), you want to edit it in one place rather than find it embedded in nine.
- Do not encode a decision in a macro. "Closing as resolved" is a template; "This is not covered by your contract" is a judgement that should be written deliberately each time.
Related
- TATER Ops - the ticket queue these replies live in, and Queue Workers for restricting who sees a category
- Ops Customization - categories, priorities, statuses and SLAs
- Ops Public Intake - where email-sourced tickets (the ones with sparse fields) come from
- Ticket Auto-Triage - automatic routing before an agent ever opens the ticket
- Activity log - the record of macro creates, edits and deletes