Buzz · Blog

The Page That Reached Nobody

Buzz by Skyscape · Care Team Coordination · October 2026

All posts

Quick Overview: The Failure Mode Nobody Logs

  • A message can send successfully and still notify no one, if the mention inside it resolves to nobody.
  • Delivery confirmations do not catch this, because the message did arrive. It simply arrived addressed to no one in particular.
  • The sender believes the page went out. Nobody on the other end knows they were expected to respond.
  • The fix belongs at compose time: verify who a mention resolves to before the message leaves.

She typed @DrPatel, wrote two sentences about the wound, and hit send.

The message posted. It sat in the thread looking exactly like every other message that has ever worked. No error. No warning. No red anything.

The physician's account is under a different name than the one everybody says out loud. There is no DrPatel in that group. The mention resolved to nobody, so nobody was notified. The words @DrPatel sat in the message as plain text, the way a typo does.

Forty minutes later she followed up in person, and that is when both of them found out.

This is not a delivery problem

Most clinical messaging platforms will tell you a message was delivered. Some will tell you it was read. Both of those are true here, and both are useless, because the message was delivered fine.

What failed was the addressing.

Those are different systems and they fail differently. Delivery answers did this text arrive in this thread. Addressing answers did this pull a specific human out of whatever they were doing. A thread that forty people can see is not a page. It becomes a page the moment a mention resolves to somebody, and if that resolution fails, you have posted a note on a wall.

The dangerous part is that the two failures look identical from the sender's chair. Message sent, thread updated, no error. Every visual cue says it worked.

Why it is worse than a bounced message

An email that bounces tells you it bounced. A phone call that fails rings out. Almost every other channel in a hospital gives you some evidence of its own failure.

A mention that resolves to nobody gives you nothing. It is one of the few communication failures with no error state at all, which means the only way to detect it is for someone to notice, later, that the thing they asked for did not happen.

That detection method has a name in patient safety literature. It is called an adverse event.

The Joint Commission's review of sentinel events reported in 2022 identified failures in communication, teamwork, and consistent policy adherence as the primary drivers behind them. Communication failure in practice is rarely a dramatic misunderstanding. It is more often a message that everybody assumed reached somebody.

The other two ways addressing fails quietly

Once you start looking for this, there are three versions of it, and only one of them is the obvious one.

It reached nobody. The mention resolved to no user. Discussed above.

It reached everyone. Somebody meant to page one person and paged the entire group. Nobody complains about this in the moment, because the mass page looks like a normal message. It shows up later as attrition, when twelve people have learned that alerts from this unit are usually not for them.

It reached the same person twice. A team mention and an individual mention that overlap. Two alerts, one human, and a small tax on their trust in the system.

None of these three throws an error anywhere. All of them degrade over months.

Verification belongs before the send

The reframe is that this is a compose-time problem being treated as a delivery-time problem.

By the time a delivery report exists, the message is gone and the clinician has moved on. Nobody reads delivery reports on a busy shift, and a system that requires them to is a system that has moved the work to the wrong place.

The right moment to catch an addressing failure is the moment before it becomes one, while the sender is still looking at the screen and can fix it in two seconds.

How Buzz handles it

Typing @ in a Buzz group chat opens user suggestions; @@ opens team suggestions. Names match on first name, last name, or any fragment, so @Smith works when four people in the group share a first name.

The autocomplete list appears only when more than one person matches. If the stem is already unique, you keep typing and nothing interrupts you. Buzz inserts the shortest unambiguous form: a bare @Kartik when that is unique, a fuller name only when it is not.

That choice is deliberate, and it runs against how most platforms work.

Mentions get typed mid-sentence, at conversational speed, often one-handed and often moving. A platform that demands a dropdown selection for every mention has converted a keystroke into a precision tap, and a precision tap in a corridor with gloves on fails in ways typing does not.

It matters even more on the reading side, because a message is written by one person and read by everyone in the group. Compare:

@Kartik can you check the wound note before you leave?

with the same line rendered the way most platforms render it. Then imagine three mentions in one message:

@Kartik Shah, @Shivakumar Thirunayam, @Jonathan Allen.

The sentence stops being a sentence. Compressed mentions match how clinicians actually speak. Nobody says "Shivakumar Thirunayam, can you check the wound." They say Shiv.

The verification layer sits on top of that rather than in front of it. Above the input, a status chip shows how many user and team mentions are in your draft. Tap it and you get the full list of who they resolve to. It raises three flags:

  • NO MATCH. This mention resolves to nobody. This is the silent failure, caught before it happens.
  • EVERYONE! You are about to page the entire group. Sometimes that is correct. It should be a decision rather than a surprise.
  • OVERLAP. Somebody is being paged twice, once individually and once through a team. Drop one.

After sending, a mention stays interactive. Tap it and Buzz shows the fully resolved identity, so a compressed @Maroun confirms as the full name and the reader can see exactly who was meant. Tap a team mention and you get the matching team members present in that group, or a clear no-match message when none apply.

Team mentions are worth a separate note. Addressing a role rather than a person means your escalation path survives shift changes, PTO, and reassignment. You do not have to know who is on tonight. And team resolution is scoped to the conversation, so a team page reaches team members who are in that group and nobody outside it. The blast radius is bounded by design.

What this does not do

The chip verifies that a mention resolves to a real person in that conversation. It does not verify that the person is on shift, awake, holding their phone, or the right clinical choice for the question. Those are different problems and this feature does not solve them.

It also cannot help with a message where the sender addressed the wrong correct person. @Patel resolving cleanly to the wrong Patel is a human error, and no chip catches it. Tapping the mention afterward to see the resolved name is the closest thing to a safety net, and it depends on somebody looking.

What it removes is the specific failure where a clinician believes a page went out and it never existed. That one is worth removing on its own.

The test

Ask three people on your unit whether they have ever discovered, after the fact, that a message they sent never actually notified anyone.

If nobody has, either your naming conventions are unusually clean or your team has stopped mentioning people at all and is calling instead. Both are worth knowing.

See how mentions resolve in Buzz

Buzz verifies mentions before you send, so a page that reaches nobody gets caught while you can still fix it. See how mentions, teams, and STAT escalation work together on the Group and One on One Collaboration page.

Sources