Helpdesk Automation: Canned Replies, Assignment & Escalation

A canned reply is a saved answer for the questions your desk hears every week — how to reset a password, where to find an invoice, what happens after a refund is approved. Canned replies live under Helpdesk → Canned Replies. Every agent keeps a personal library, and there is one shared library that every agent can use but only people allowed to manage canned replies can write to. Replies can be filed in folders, and a folder belongs to one library, so a reply meant for the whole team goes in a shared folder rather than in someone’s personal one.

Each reply has a title, its text, and a choice of whether it posts as a public reply the requester sees or as an internal note for the team. The text can carry placeholders where the details change from ticket to ticket. The page lists the fourteen it accepts — among them the requester’s name and first name, the ticket reference, subject, status, category and resolution due date, the agent’s own name, and your organization’s name — each written inside double curly braces. They are filled in on the server in a single pass, and a name that is not on the list is left exactly as you typed it, so a typo shows up in the composer instead of going out to a customer as a blank.

In practice: the support lead at a Nairobi internet provider writes a shared reply called “Router reset steps”. It opens with the requester’s first name placeholder, quotes the ticket reference, and promises an update before the ticket’s due date. When Wanjiku Kamau raises TKT-000418, the agent picks the reply and the composer shows “Hi Wanjiku, about TKT-000418 …” with the due date already written in. A colleague who misspells one placeholder as requester.frist_name sees the braces still sitting in the draft and fixes it before sending — nothing went out half-filled.

A canned reply can also move the ticket on. Its actions can set the status, set the priority, add tags, or assign the ticket to a named agent, and a reply needs text or at least one action to be saved. On a ticket you search your canned replies from the reply box and then choose one of two buttons. Insert drops the filled-in text into the composer so you can adjust it before sending, and the reply’s actions still run when you send. Apply sends the reply and runs its actions at once, for the cases where nothing needs changing.

Actions follow the agent using the reply, not the person who wrote it. The status, priority and tag actions need the permission to manage tickets, and the assignment action needs the permission to assign tickets — the same permissions as the buttons beside the reply box. If a shared reply closes and reassigns tickets but the agent using it may only reply, the reply still goes out, and the actions they may not take are skipped and listed on screen. A canned reply is never a way round a permission. Each reply also counts how often it is used, so the library sorts the busiest first and the ones nobody sends are easy to retire; canned replies work in the mobile app too.

In practice: a Kampala software reseller keeps a shared reply “Licence key resent” that posts publicly, sets the status to resolved and tags the ticket licensing. A senior agent with full ticket permissions clicks Apply and the ticket is answered, resolved and tagged in one step. A new starter who has only been given permission to reply uses the same reply on another ticket: the customer receives the message, and the screen notes that the status and tag changes were skipped, so the ticket stays with its owner to finish. Three months later the lead sorts the library and deletes two replies that have been used once each.

Each category decides how its new tickets find an owner, set under Settings → Support & Helpdesk → Categories & SLA. Default assignee sends every ticket to the one person named on the category, and it is how every category starts. Round robin gives the next ticket to the agent in the category’s pool who has waited longest since their last one, with someone never assigned going first. Fewest open tickets gives it to the pool agent with the lightest open load across the whole desk — not just this category — with the rotation as the tie-break so a quiet desk does not hand every ticket to the same person.

For the two pool strategies you choose at least one agent and, optionally, a cap on open tickets per agent. An agent is skipped when they are no longer employed, when they are on approved leave today, or when they are at the cap. If nobody in the pool is eligible, the ticket stays unassigned and goes to the department queue rather than to someone over their limit — that is the cap doing its job. Saving the pool keeps the rotation where it was, so an agent you add today does not receive the next ten tickets. Assignment never overrides a ticket that already has an owner, and moving an unowned ticket into a category with a strategy assigns it there and then.

In practice: a Mombasa logistics firm sets its Billing category to fewest open tickets with a pool of Achieng, Baraka and Halima and a cap of 12. On Monday Achieng has 4 open tickets across the desk, Baraka 9 and Halima 12. A new billing ticket goes to Achieng. Baraka is on approved leave on Tuesday, Halima is still at 12 and Achieng has climbed to 12 too, so the next ticket is left unassigned and the Billing department queue is told. The lead raises the cap to 15 rather than overriding it, and the following ticket goes to whichever of Achieng and Halima has the lighter load.

An escalation rule says: when this has been true for this long, do these things. Rules are created under Settings → Support & Helpdesk → Escalation Rules. The trigger is one of three: the ticket is still unassigned, counted from when it was raised; it has had no first response past its first-response deadline; or it is unresolved past its resolution deadline. You set the delay in minutes, hours or days, and you can limit the rule to one category. Then you choose at least one action: raise the priority, reassign to the assignee’s manager or to a named person, notify the assignee’s manager and named users, or add a tag. Saved as active, rules are checked every fifteen minutes.

A few rules keep escalation safe. Each rule fires once per ticket, and a reopened ticket can be escalated again. Priority only goes up, so a rule that raises to high never lowers a ticket that is already urgent. A ticket is only reassigned to someone still employed; when the target cannot take it, the ticket stays where it is and the note says why. The unresolved trigger leaves a ticket alone while it is waiting on the requester, because its resolution clock is paused then. And one combination is refused outright: an unassigned rule that notifies the assignee’s manager, because an unassigned ticket has no assignee — notify or reassign to a named person instead.

In practice: a Dar es Salaam utility writes three small rules rather than one big one. Rule one: no first response, 30 minutes past the deadline, notify the team lead, Neema. Rule two: no first response, 2 hours past the deadline, raise to high and reassign to the assignee’s manager. Rule three: unassigned for 1 hour, assign to Juma on the duty desk and tag after-hours. A ticket raised at 08:00 with a one-hour first-response target is still unanswered at 09:30, so Neema is told; at 11:00 it becomes high and moves to the agent’s manager. When an urgent outage ticket meets rule two, its priority stays urgent and only the reassignment happens.

Levels are several rules on one trigger with growing delays — a short delay that notifies, a longer one that raises the priority and hands the ticket up, perhaps a third that tags it for the weekly review. A policy built this way reads as a list anyone can follow, and changing one step means editing one rule. Building one huge rule that tries to do everything at a single delay is the common mistake: it either fires too early for the heavy actions or too late for the gentle reminder.

Escalation rules sit beside the SLA breach alert rather than replacing it. The breach alert tells people a deadline has passed — the assignee and their line manager, or the department queue when nobody owns the ticket. A rule acts on the ticket. Every escalation leaves an internal note on the ticket naming the rule, the reason and what was done, including anything it could not do, such as a reassignment to someone who has left. The Escalation Rules page lists the most recent escalations, so a lead can see at a glance which rules are doing the work and which never fire.

In practice: at a Kigali hospital’s IT desk, a ticket about a ward printer passes its resolution deadline on Thursday at 14:00. The breach alert reaches the assignee, Eric, and his manager straight away. At 16:00 the “Unresolved +2h” rule fires: it raises the ticket to high and tries to reassign it to Eric’s manager, but she left the hospital last month, so the internal note reads that the ticket was not reassigned because the assignee has no manager who is still employed. The lead reads that note on the recent escalations list, fixes the manager on Eric’s employee record, and changes the rule to hand to a named person as well.

The public support form asks the customer for no category, and a ticket’s SLA clock comes from its category — so a form ticket with no category has no deadlines at all, never breaches, and never triggers a first-response rule. The fix is one setting. Under Settings → Support & Helpdesk → Intake Portals, choose a category for public-form tickets. Every ticket from the form then files there, starts with first-response and resolution deadlines, and is routed by that category’s assignment strategy. If the chosen category is later switched off, new form tickets arrive without one, so keep it active. The same page shows whether your public link is live; the form needs both a public link and intake switched on before customers can reach it.

Turning emails sent to your support mailbox into tickets is a setting your administrator has to switch on for your installation. Until then, the Intake Portals page says it is not switched on yet. Once it is, the page gives you a forwarding address and lets you choose the category and priority that emailed tickets start with — the category matters for the same reason as on the form. Permissions are split across the module: anyone who can see all tickets can keep personal canned replies and use the shared ones; writing to the shared library needs the permission to manage canned replies; and categories, assignment, escalation rules and intake settings all need the permission to manage helpdesk settings.

In practice: a Nakuru school’s bursary office opens its public support form to parents and leaves the category empty. A month later the ticket report shows 140 form tickets and not one SLA breach — because none of them had a deadline. The office manager sets Parent Enquiries, with a 4-hour first response on a working-hours clock, as the public-form category. From the next morning every form ticket arrives with deadlines, lands with the bursary clerks by round robin, and is picked up by the existing “no first response +30 minutes” rule. When she asks about email intake, the page tells her it is not switched on yet, and she asks support to enable it.