What an Unanswered @Mention Actually Costs You (With the Math)
I'm Vijendran, founder of Sivect and developer of AI Mention Triage for Jira and Confluence.
Here's a number most teams have never worked out: how many hours a year your engineers lose to @mentions that didn't need to interrupt them the moment they arrived — not mentions that went unanswered forever, just ones that carried no signal of how urgent they actually were, so they got opened immediately, out of caution, instead of handled in the next natural break.
That's not a notification problem. It's a focus-cost problem, and it's measurable.
Where this comes from
I spent years managing engineering teams inside large, distributed global companies — the kind where your team spans four time zones and every day brings somewhere around 30 to 40 notifications: deployment approvals waiting on sign-off, quick pings between engineers working through a problem, clarifications on a story, planning notes in a Confluence page, task assignments, incident updates in a JSM ticket. None of it was noise, exactly. Every one of those was something someone genuinely needed from me. But it all arrived looking identical, and the mental tax of figuring out which ones actually needed me right now versus which ones could wait until the afternoon was relentless.
The problem ran the other way too. When I mentioned an engineer who was deep in a hard problem — properly heads-down, exactly the kind of focus you want from a good engineer — the mention would sit unseen for hours, sometimes a day. Not because they were ignoring it. They were doing the job well. But it meant I often didn't find out my question had been missed until I followed up a second time, by which point whatever was time-sensitive about it usually wasn't anymore.
Same problem, two directions: too much undifferentiated signal coming in, and no way to know whether an outgoing mention had landed with the right urgency. Once I started thinking about it that way, the research below made a lot more sense.
What the research actually says
Workplace interruption has been studied for over two decades, and a few findings hold up well.
Gonzalez and Mark's 2004 field study of analysts, developers, and managers found that people spend, on average, about three minutes on a task before switching to something else — sometimes because they're interrupted, sometimes because they interrupt themselves. Zoom out, and the same workers cycled through roughly ten different "working spheres" a day, spending about twelve minutes in each before moving on.
A follow-up 2005 study by Mark, Gonzalez, and Harris tracked what happens when one of those working spheres gets interrupted: it took an average of around 25 minutes to return to it, and workers typically moved through more than two other tasks in the meantime.
A related 2008 study by Mark, Gudith, and Klocke — frequently mis-cited elsewhere as the source of a "23-minute recovery" figure, which it isn't; that number actually traces back to a 2006 Gallup interview, not this paper — found something more interesting anyway. When people were interrupted mid-task, they compensated by working faster to catch up. Speed recovered. But it came at a real cost: measurably higher stress, frustration, and time pressure. The task got done. The person doing it paid for it.
Further back, Whittaker and Sidner's 1996 paper on email overload identified the exact failure mode still playing out today: tools that deliver a high volume of information without giving it any structure — no priority, no categorisation, no indication of what needs action versus what's just FYI — actively contribute to the problem they were meant to solve.
That 1996 paper could have been describing a Jira or Confluence notification feed. The mention gets delivered. The structure doesn't.
Turning that into a number you can use
Here's a simple model — illustrative, not a guarantee, but built on the research above and easy to adapt to your own team's numbers.
Assume:
- An engineer receives 8 @mentions a day across Jira, Confluence, and JSM (a conservative estimate for anyone working across a few active projects)
- Each unmanaged mention costs roughly 12 minutes of interrupted focus — well under the fragmented-work recovery figures above, since not every mention causes a full context loss
- A batched, end-of-block review of the same mention costs roughly 3 minutes
- That's a 9-minute net cost per mention, multiplied by 8 mentions, multiplied by 220 working days
- At a $75/hour loaded engineering cost
The result: roughly $19,800 per engineer per year in pure interruption cost. Scale that to a team of 10 and you're looking at around $198,000 a year — before counting the knock-on cost of delayed approvals, missed deadlines, or duplicated work when something genuinely gets missed.
To be direct about the limits of this model: these are illustrative estimates built on published research assumptions, not measured outcomes from any specific customer. Your actual numbers will depend on mention volume, role, and how your team already handles notifications. The point isn't the exact dollar figure — it's giving you a way to think about the cost at all.
Do the math for your own team
Swap in your own numbers using this formula:
Annual cost per person = (B − C) × A × D × (E ÷ 60)
| Variable | What it means | Starting point |
|---|---|---|
| A | @mentions received per person, per day | 8 |
| B | Minutes lost per unmanaged mention | 12 |
| C | Minutes for a batched, end-of-block review | 3 |
| D | Working days per year | 220 |
| E | Loaded hourly cost per person | $75 |
Plug in the starting points above and you get (12−3) × 8 × 220 × (75÷60) = $19,800 per person, per year. Multiply by headcount for a team total. Replace any of the five numbers with your own team's reality and the total moves with it.
Why native notification tools don't fix this
Jira and Confluence's native notification systems are good at delivery. They're not designed to answer the three questions that actually determine whether a mention needs your attention right now:
- What does this mention need from me? A request for approval and an FYI comment look identical in your inbox.
- How urgent is it? A mention with a same-day deadline and one that can wait until next sprint arrive with the same visual weight.
- Who's affected if I don't respond? A mention blocking a customer-facing release and one touching an internal experiment get the same treatment.
This isn't a knock on Jira's notification engine — it's doing exactly what it was built to do. The gap is structural: delivery without classification, at scale, becomes noise. It's the same gap Whittaker and Sidner described almost thirty years ago.
What we built to close that gap
The pain point: getting buried in unstructured @mentions across Jira, Confluence, and JSM. The edge: it shortens most of the security review, because nothing ever leaves Atlassian's infrastructure.
This is where I'll mention what we built, because it's directly relevant to everything above: AI Mention Triage for Jira and Confluence classifies every @mention across Jira, Confluence, and Jira Service Management along exactly those three dimensions — Action (what to do), Urgency (how soon), and Impact (who's affected) — before it reaches your inbox. Deadline phrases like "by 03/07/2026," "next Tuesday," "in 3 days," "before the release," "end of week," "end of month," "EoD," or "end of sprint" are picked up automatically from natural language, and urgency escalates as the deadline gets closer.
It's built on Forge, Atlassian's native app platform, and carries the Runs on Atlassian badge — meaning classification happens inside Atlassian's own infrastructure rather than on a third-party server. Personally identifiable information is stripped from mention text through automated sanitisation before anything is sent for classification. In practice, this usually means a much shorter security review, since the app inherits Atlassian's existing security posture rather than introducing a new vendor relationship to assess.
It's the tool I wish I'd had on both sides of that problem — triaging 30-40 incoming mentions a day, and as the person whose own mentions sometimes sat unseen until a second follow-up.
The bigger point, regardless of which tool you use
Whether or not this particular app is the right fit for your team, the math above is worth doing for your own organisation. Most teams have never quantified what an unmanaged mention actually costs — and once you run even a rough version of the arithmetic, it tends to be larger than people expect.
If you've found other ways to bring structure to @mentions — custom notification schemes, JQL-based filters, other Marketplace apps — I'd genuinely like to hear what's worked for your team in the comments.
Research cited:
- González, V. M., & Mark, G. (2004). "Constant, constant, multi-tasking craziness": Managing multiple working spheres. CHI 2004.
- Mark, G., Gonzalez, V. M., & Harris, J. (2005). No task left behind? Examining the nature of fragmented work. CHI 2005.
- Mark, G., Gudith, D., & Klocke, U. (2008). The cost of interrupted work: more speed and stress. CHI 2008.
- Whittaker, S., & Sidner, C. (1996). Email overload: exploring personal information management of email. CHI 1996.
Was this helpful?
Thanks!
Vijendran Selvarajah _Sivect_
4 comments