The problem a mention solves
Most tickets need one person. Some need one person plus thirty seconds from somebody else: the engineer who knows why that error appears, the account manager who knows what was promised, the colleague who handled the same customer last month. Reassigning the ticket to get that answer is too heavy, because ownership moves and often never comes back. Asking in a team chat is too light, because the question leaves the ticket and the answer never returns to it.
A mention is the middle option. You write an internal note on the ticket, name the person in it, and they get a pointer to that exact note. Ownership does not move. The question and the answer both live on the ticket, where the next person to read it will find them.
That last part is the underrated benefit. A year later, the reason a refund was approved is sitting in the thread rather than in somebody's message history.
Mentions are parsed from internal notes only
The single most important fact about the feature: mentions are extracted from internal notes, not from public replies. Naming a colleague in a message that goes to the customer does not create a mention, and nobody is told about it.
That boundary is protective rather than arbitrary. It means the parser can never be tricked into treating something a customer wrote as an instruction to your team, and it means an agent cannot accidentally expose an internal name and workflow to the person on the other end. It does, however, catch people out exactly once: they type the name in the reply box instead of the note box, nothing happens, and they conclude that mentions are broken.
So the habit to teach is the order of operations. Switch to the internal note first, then write the mention. If your team is already comfortable with the distinction between a note and a reply, this costs nothing; if it is not, this is the feature that will teach them, and a wrong guess here is the difference between a private aside and a message to the customer.
It matches the login name, not the display name
A mention is written as an at sign followed by a name, and the name it matches is the login name of the agent, not the friendly name shown in the console. If somebody signs in as j.okafor and appears in the interface as Jane, then Jane is not what the parser is looking for. Matching ignores case, so the exact capitalisation does not matter.
Tokens that match nobody are dropped without comment. There is no error, no red underline and no message telling the author that the person they meant to reach was never reached. This is a sensible design against typo spam and it is the reason mentions fail quietly rather than loudly, which makes it worth saying out loud in your onboarding.
Two details make it behave better than a naive search would. Email addresses do not trigger a mention, so quoting a customer's address in a note is safe. And naming the same person twice in one note produces one mention rather than two, so a long note that keeps referring back to a colleague does not turn into a pile of duplicates.
The practical advice is short: publish the list of login names somewhere your agents can find it, and choose login names that people can guess. A team whose logins are surnames will use mentions; a team whose logins are numbers will not.
Where a mention actually lands
Mentions collect on a Mentions page in the dashboard, which shows unread ones by default and can be switched to show everything. Each entry carries who wrote it, which ticket it was on, and a snippet of the note around the mention, so most of the time you can tell whether it needs you before you open anything.
You can mark one as read, or clear the whole list at once. The list shows the most recent hundred, which is generous for a working queue and a warning sign if you ever hit it: a hundred unread mentions means the team is using them as a general channel rather than as a request.
One robustness detail worth knowing. Mentions are delivered against the login name rather than an internal account identifier, so an agent's history stays with them through account changes. The corollary is the thing to watch on offboarding: reusing a departed colleague's login for a new hire hands the new person the old mentions.
A mention is not a notification
This is the expectation to set before anybody relies on the feature. Writing a mention puts an item on somebody's mentions page. It does not, on its own, send them an email, ring a phone or post into a team channel. If they do not open the page, they do not know.
For a colleague who works in the dashboard all day that is perfectly adequate. For the engineer who opens it twice a week it is not, and a mention that sits unread for three days is worse than no mention at all, because the agent who wrote it believes the question has been asked.
There is a proper way to close that gap. Every successful mention emits a ticket event that your own integrations can subscribe to, carrying the ticket, the note and who was named, which is the supported route to a chat-tool or email alert. It is worth doing once, centrally, rather than asking each agent to remember which colleagues need chasing. If you already route other ticket events into a channel through your integrations, this is the same wiring with a different event name. And note that the event only fires when a name actually matched somebody, so a typo is silent here too.
Habits that make mentions worth using
The feature is simple; the discipline around it is what decides whether people trust it.
- Name one person, not four. A mention addressed to everybody is addressed to nobody, and the diffusion of responsibility is immediate.
- Ask a specific question. Please look at this is a request for an unbounded amount of work. Can we refund outside the thirty-day window for this customer is answerable in a line.
- Say what you have already tried. The colleague you are pulling in should not have to reconstruct the thread to answer one question.
- Keep ownership explicit. The ticket is still yours. A mention asks for an answer, not for somebody to take it off you, and saying so in the note prevents a silent hand-off nobody agreed to.
- Close the loop in the ticket. When the answer arrives, write the outcome into the thread in your own words, so the next reader does not have to infer it.
What to measure
Two numbers tell you most of what you need. The first is how long mentions sit unread, sampled rather than tracked precisely. If they are answered within a working day, the mechanism is doing its job. If they routinely sit for several days, you have a notification gap, not an attitude problem, and the fix is wiring rather than nagging.
The second is who gets mentioned. Count them over a month and the distribution will be lumpy: one or two people carry most of the questions. That is a knowledge concentration risk sitting in plain sight, and the answer is usually to move whatever they keep repeating into a written answer the whole team can reach.
It is also worth watching the ratio of mentions to reassignments over time. A team that is learning to use mentions well should see reassignments fall, because the questions that used to cost a change of ownership no longer do. If both numbers are climbing together, mentions have become an extra step on the way to a hand-off rather than a substitute for one.
A mention brings a person into one ticket. When the thing you need to bring in is another ticket, a link between the two does the same job for context, and it stays accurate as both move.