Who Gets Told: The Notification Map of a Support Ticket
Most helpdesk failures are not slow replies. They are silences — a ticket that reached the system and never reached a person. Here is exactly who gets told, on which event, through which channel, and the four configurations where the answer is nobody.
A support desk does not usually fail loudly. It fails as a gap: a request that was properly submitted, correctly stored, visible on a screen nobody happened to open, and answered four days later by someone who found it while looking for something else. The customer experienced no support at all. The system, meanwhile, has a complete and blameless record of the whole thing.
The cure is not a better dashboard. Dashboards are pull — they work when somebody chooses to look. Notifications are push, and push is the only mechanism that reaches a person who does not yet know there is something to look at. So the question worth answering precisely, before you write a single SLA target, is this: for each thing that can happen to a ticket, who is told?
This article answers that from our own code rather than from a feature list, because the interesting part is not the events that notify somebody. It is the four ordinary configurations where the honest answer is nobody at all.
The map, event by event
Six notification types exist in the helpdesk module, and every one of them appears by name in the notification preferences grid, so a desk can switch any single type on or off per channel. Here is what fires each one.
What happens to a ticket, and who hears about it
The event Who is notified
Submitted, already assigned The assignee
A ticket raised with a category that carries a default assignee arrives pre-assigned, so it goes straight to that person as Ticket Assigned to You — the department queue is skipped entirely.
Submitted, unassigned, has a department Every user in that department
Fired as New Ticket in Your Department Queue, to every login whose department matches the ticket. Note the word login: it selects users, not employees, so an agent without a login is not on this list.
Submitted, unassigned, no department Nobody
This is deliberate and it is also the single most common way a desk goes quiet. The ticket sits in the unassigned queue waiting to be picked up by someone who thinks to filter for it.
Assigned later, by hand or in bulk The new assignee
Assignment also nudges an open ticket to In Progress, which is a small kindness — a queue where everything says Open tells you nothing about what is being worked.
Status changed Requester + watchers
The requester is notified in-app if they have a login, or by email with a signed tracking link if they are an external customer. Watchers get an agent-side notice pointing at the internal ticket view.
Agent posts a public reply Requester + watchers
The same fan-out as a status change, plus the first public reply stamps the first-response time. An internal note notifies nobody — see below, because that asymmetry is load-bearing.
Requester replies The assignee + watchers
Note what is missing: the department queue is not re-notified. A reply on an unassigned ticket reaches only its watchers.
Resolution target passed Assignee + their manager
Sent once per breach by a scheduled sweep, tracked on the ticket so it cannot nag. The escalation half resolves the assignee employee's manager, then that manager's login.
First-response target passed Nobody
The due date is computed, stored and badged on the ticket, and the AI queue summary counts it. Nothing pushes it. This is a real gap and we say so again further down.
Read the right-hand column twice. Two of the nine rows say nobody, and a third quietly excludes the queue. Those three lines explain most of the tickets that ever go missing on a well-configured desk.
Two rules that shape everything else
Before the channels, two behaviours run through every one of those events, and both of them surprise people the first time.
The actor is never notified of their own action. If you change the status, you do not get told the status changed. This is obviously right and it has one non-obvious consequence: if the same person is agent, assignee and watcher on a ticket — normal on a two-person desk — then a great many events produce no notification whatsoever, and the desk concludes notifications are broken. They are not. There was simply nobody else to tell.
Only people with a login are notified in-app. An in-app notification is a row keyed to a user account. An employee without a login has no account to key it to, so assignment, replies and breach escalations all pass them silently. This matters more in Kenya than in the markets most helpdesk software is designed for, because a large share of the people who actually resolve requests — drivers, technicians, site staff, cleaners, security — legitimately have no reason to hold a system login.
A ticket assigned to an employee without a login is a promise made to a person who was never told.
The failure mode nobody tests for
The workaround is not clever, and it is the right one: for any category whose work is done by people without logins, set the default assignee to a supervisor who does have one, and let them hand out the physical work. The ticket then has a named owner who is genuinely reachable, which is the whole point of an assignee.
Where the notice actually lands
An in-app notification is not only in-app. Once written, it is offered to every delivery channel the organization has connected, gated by a preferences grid that crosses each channel against each module and each notification type. So Ticket SLA Breach & Escalation can go to a WhatsApp group while Updates on Tickets You Watch stays in the bell menu.
Which audience can be reached on which channel
| Audience | In-app bell | Chat & SMS channels | |
|---|---|---|---|
| Agent with a login | Yes | Partly — configurable by you | No |
| Requester with a login | Yes | Partly — configurable by you | No |
| Employee requester with no login (token portal) | No | No | No |
| External customer (no login, email known) | No | No | Yes |
Built and maintained Configurable by you, not maintained by us Not built
Chat and SMS are marked configurable because they depend on your own connected workspace and your own entries in the preferences grid — we maintain the forwarding, you own the destination. The email column is narrower than people expect: helpdesk events do not email logged-in users. An agent who wants a mailbox trail should route the relevant types to a chat channel instead.
The channels available for forwarding are Slack, WhatsApp, Microsoft Teams, Telegram, Discord, Google Chat, SMS, mobile push, and your own automations. Each forward is attempted independently and failures are logged rather than raised, so a broken Slack token cannot stop the in-app notice from being written. That ordering is deliberate: the record comes first, the convenience second.
How the external customer is reached
A customer who submits a request on your public form has no account and never will. They are reached by email, and the email carries a temporary signed link to a page showing their ticket and its public conversation. The link is valid for 90 days and is reissued every time they reply, so an active thread keeps working and a forwarded old link eventually stops.
-
They submit on your public form
Name, email, subject, description, priority. If the email matches a customer record in your CRM, the ticket is linked to that customer automatically — which is the only way per-customer support volume ever becomes countable.
-
They get a tracking link by email
Queued, not sent inline, so a slow mail provider cannot slow the form. The message contains the ticket reference, which is what they will quote on the phone.
-
Your agents are notified through the queue
Same rules as any other ticket: the department queue if the category routes it, the assignee if the category pre-assigns, nobody if neither is set.
-
Every public reply emails them again
Internal notes never do. The tracking page shows only the public thread, so an internal note cannot leak through it even by accident.
-
Their reply reopens the ticket
A customer reply on a waiting, resolved or closed ticket moves it back to In Progress and notifies the assignee. A closed ticket that the customer is still unhappy about does not stay closed.
A worked example: the ticket nobody heard about
Monday, a new customer request, on a desk with no category defaults set
Illustrative, and the mechanism is exact. Every consequence in that table follows from one omission: no category. The category is what carries the department, the default assignee, both SLA targets and the choice of clock — so a ticket without one is invisible to routing, invisible to notification, and invisible to the breach report. A desk with no categories configured has no SLA, whatever its settings screen says.
The five-minute check that prevents most of this
Open your ticket categories. For each one, confirm four things are filled: a default department, a default assignee, a first-response target and a resolution target. Then raise one test ticket per category and confirm somebody was actually notified. Do the same for the no-category path by leaving the field blank — if nothing arrives, either make the category required in your own process or set a catch-all department on your intake so unrouted work still has an audience.
What we do and do not do
What AWRA OpsHub does today
- Six named notification types — assignment, department queue, status change, reply, watched-ticket update and SLA breach — each individually switchable per channel in the preferences grid.
- Automatic forwarding of any in-app notice to Slack, WhatsApp, Teams, Telegram, Discord, Google Chat, SMS, mobile push and your own automation endpoints, with per-channel per-type control.
- Watchers: any agent can watch or unwatch a ticket and receive its updates, and the watcher fan-out deliberately skips the requester, the assignee and the person who just acted so nobody is told twice about their own work.
- A signed, time-boxed, no-login email trail for external customers, refreshed on every reply, showing only the public conversation.
- A once-per-breach resolution SLA sweep that notifies the assignee and escalates to their manager, tracked on the ticket so a breach cannot nag daily.
- Automatic reopening: a requester reply on a waiting, resolved or closed ticket returns it to In Progress and tells the assignee.
What it does not do
- No first-response breach notification. The target is computed, stored, badged in the ticket view and counted in the queue summary — but nothing pushes it to anyone. Only the resolution breach is swept.
- No notification to people without a login. In-app notices are keyed to a user account, so an assignee who is an employee with no login is never told about the assignment, the replies, or the breach.
- No re-notification of the queue when a requester replies. An unassigned ticket that the customer chases reaches only its watchers.
- No per-user notification preferences — the grid is set for the organization, not per person, so an agent cannot mute a type just for themselves.
- No reminder before a target, only after. There is a due-soon filter on the queue you can look at; nothing pushes it at you.
- No digest option for helpdesk types: each event is its own notice rather than a rolled-up daily summary.
The first-response gap is the one we would fix first, and it is honestly a small piece of work — the sweep already exists for resolution and would need a second stamp column so it also notifies once rather than every run. If your contracts are written on first response rather than resolution, say so and it moves up the queue.
Questions worth asking any helpdesk vendor
Four questions that separate a notification engine from a notification checkbox
What happens to a ticket that arrives with no category and no assignee — who is told?
What you will hear
"It goes into the queue."
How to read it
That is an answer about storage, not about people. Push for a name. If the honest answer is nobody, that is fine — ours is nobody too — but you need to know it so you can make the category mandatory on your intake.
Can you notify someone who does not have a login to your system?
What you will hear
"Everyone gets a login."
How to read it
A deflection dressed as a feature. In Kenya, a desk where every resolver holds a paid login is a desk that has quietly excluded most of its own workforce. Ask what the per-login cost of that answer is.
Which SLA clocks actually push a notification, as opposed to being displayed?
What you will hear
"Both are tracked."
How to read it
Tracked and pushed are different verbs. Ask to see the scheduled job, or ask them to breach a first-response target in a demo tenant and show you the notification that resulted.
If a channel integration fails, does the notification still exist?
What you will hear
"We retry."
How to read it
Retrying is good. Writing the record first is better. You want the in-app row created and the forward attempted afterwards, so an expired Slack token degrades convenience rather than losing the event.
Two habits that beat any configuration
Notification design has a ceiling, and it is reached quickly. Past that point, two operating habits carry more weight than any settings screen.
The first is a daily unassigned sweep, owned by one named person, at a fixed time. The queue has a filter for exactly this. Five minutes each morning catches every ticket the notification map cannot reach — the no-category arrivals, the customer replies on unowned threads, the ones where the department was guessed wrong. It is the manual backstop for every nobody in the table above, and no software removes the need for it.
The second is to watch deliberately. Watchers are the only mechanism that lets a person who is neither requester nor assignee stay informed, and it is criminally underused. A supervisor who watches the six tickets they actually care about gets a live feed of exactly those, without reading the queue. A supervisor who watches everything gets noise and stops reading. The value is in the restraint.
Our take
Notification coverage is not a feature you buy, it is a configuration you verify. Fill in every ticket category properly — department, assignee, both targets — because the category is the single object that turns a stored request into a notified person. Then raise one test ticket down each path you actually use, including the path where the requester chooses nothing, and confirm a human was told. The desks that lose tickets are almost never the ones with poor software; they are the ones where nobody ever checked what happens when a field is left blank.
Read alongside this: SLAs that mean something covers the two clocks and how the pause works, routing and escalation explains how the category carries the policy, the internal note covers the reply that deliberately notifies nobody, and support metrics that are not vanity explains what to read once the notifications are landing.
See the notification map on your own desk
Six switchable helpdesk notification types, nine forwarding channels, a signed no-login email trail for customers, and a breach sweep that escalates to the manager.
See the helpdesk in AWRAFrequently asked questions
A ticket was raised and nobody was notified. Is that a bug?
Almost certainly not. Check whether the ticket has a category. The category carries the default department and the default assignee, and the notification depends on one of those two being resolved — a ticket with neither is stored in the unassigned queue and notifies nobody by design. The second thing to check is whether the only person who could have been notified is the person who raised it, because we never notify someone about their own action. On a small desk those two causes cover nearly every report of missing notifications.
Can we send helpdesk notifications to a WhatsApp group?
Yes. Any in-app notification can be forwarded to Slack, WhatsApp, Teams, Telegram, Discord, Google Chat, SMS, mobile push or your own automation endpoint, and the preferences grid lets you choose which of the six helpdesk types goes to which channel. The forward runs after the in-app notice is written, so a broken connection degrades delivery without losing the event. What you cannot do yet is set this per person — the grid is organization-wide.
Does the requester get an email when we reply?
It depends on who they are. An external customer with no login gets an email on every public reply and every status change, carrying a signed link to their ticket. A requester who has a login gets an in-app notification instead, not an email — helpdesk events do not email logged-in users today. If your internal staff want mailbox visibility, route the reply and status types to a chat channel rather than waiting for email.
Are we notified when a ticket misses its first-response target?
No, and this is the clearest gap in the module. The first-response due date is computed from the category, stored on the ticket, shown as a badge in the ticket view and counted in the AI queue summary — but only the resolution breach has a scheduled sweep that notifies the assignee and escalates to their manager. If your commitments are written on first response, rely on the queue filters and a daily habit for now, and tell us, because the sweep already exists and adding the second clock to it is a small change.
Who gets the escalation when an SLA breaches?
The assignee, and their manager. The manager is resolved from the assignee's employee record, then that manager's login. If the assignee has no manager set, or the manager has no login, the escalation half simply does not happen — the assignee is still notified. Each breach notifies once, tracked on the ticket, so the sweep cannot nag daily. The stamp is cleared when the due date genuinely moves, which happens when a ticket comes back from waiting on the requester, so a fresh breach can raise a fresh alert.
What is a watcher for, if the requester and assignee are notified anyway?
For everyone else with a legitimate interest: the supervisor of a difficult account, the engineer who fixed it last time, the person covering tomorrow. Any agent can watch or unwatch a ticket, and watchers receive status changes and replies. The fan-out deliberately skips the requester and the assignee so they are not told twice, and skips whoever just acted. Used sparingly it is the most useful notification feature in the module; used on everything it becomes noise and people stop reading.
