Who has read a message

Basic ticks, Advanced read activity.  There are two different questions hiding behind “has this been read”, and Protocol answers them in two different places. Did my client see it? is the tick on your own message. Has anyone on my team picked this up? is Read activity.

The tick on your own message

Every message you send carries a small status next to its timestamp. It has four states, and they are four rather than three on purpose: a message that never left is not the same as one that arrived.

The Seen ticks pick up your app’s accent colour, so they are green on the default theme and whatever you have branded to otherwise. Red is always red.

In a group, the tick describes everyone at once. It only reaches Seen when every other person in the conversation has read it, and it only reaches Delivered when it has reached every one of their devices. So one person who has not opened the app all day holds the whole group’s tick at Delivered. That is the honest reading of it: the tick answers “has everybody”, not “has anybody”.

If you turned Seen off, messages stop at Delivered and never advance, in both directions, for your whole workspace. The switch lives in My App → Settings → Features. See Messaging basics.

Seeing it person by person

In a direct chat or a small group, open the message’s action menu and choose Info. It lists each recipient with their own state and, for anyone who has read it, the time they did. This is only offered on messages you sent, because it is your delivery you are inspecting.

Big groups and announcements count instead of listing

Past about fifty people, and in any announcement or broadcast group whatever its size, receipts switch from a per-person list to aggregate counts. Info then shows numbers:

So in a broadcast to forty clients you can see that twelve have read it. You cannot see which twelve, and the tick on the bubble is worked out from those counts rather than from a list of names.

This is a consequence of size, not a feature that is missing. A per-person receipt list is a row for every recipient on every message. On a roster-wide announcement that is hundreds of rows per message, recalculated every time anyone opens the thread, and a live receipt sent to every member each time one person reads. Past a certain size that stops being information and starts being a cost everyone in the conversation pays, so above the threshold Protocol keeps the counts and drops the list. Small groups and one-to-one chats are unaffected and keep full per-person receipts.

Two things follow from it that are worth knowing:

• If you turned Seen off, the read count reads 0 in these conversations. Delivery counts still work. Nothing is broken, the “seen” half is simply hidden as designed.
• If what you actually need is “did this one client read it”, send it in their direct thread. A one-to-one conversation always gives you a real per-person receipt.

What the counts cannot tell you is whether your team has dealt with a thread. That is a different question, and it has its own answer.

Read activity: who on your team opened this

Your inbox is shared. The owner and every admin see the same conversations and the same unread badges, and whoever opens one clears it for everybody. (If that is new, start with Messaging basics.) The useful question in that arrangement is rarely “did the client read it” but “has anyone here picked this up yet”.

Open the conversation’s header menu (⋮) and choose Read activity.

It is a log of the thread, newest first. Each row says who, from where, what they did, and when.

• Who. The real person, not the shared brand voice. An admin who replies as you is recorded as themselves, with (acting as owner) alongside, so the log names the human even though your clients only ever saw one coach.
• From where. Web or Mobile for a person. An AI agent or an outside integration has no app, so it shows the channel it came in on instead (MCP, API key). A session that never said what it was shows a dash rather than a guess. This list is evidence, so it does not fill in blanks.
• What they did. Three outcomes, and the difference between them is the whole point:
  • Marked read, with how many messages it cleared. Somebody handled it.
  • Marked unread, put it back for the team. Somebody looked, decided it was not theirs, and handed it on.
  • Viewed only, did not clear the badge. Something read the thread without touching the unread state. Your AI assistant and anything reading through the API always land here. This is your proof that a bot looking is not the same as a person reading.

Read it as a sequence, not a tally. An open followed by an un-read is careful work, not somebody clearing your messages and walking away.

Two more things about it:

• It is thread level, not per message. It tells you the conversation was opened and how far the read watermark moved, not which individual message somebody’s eyes landed on.
• It is never shown to clients, in the dashboard or through the API. The shared inbox presents one coach to them by design, and this view exists precisely to see behind that. It also lives in the web dashboard only, so if you are on your phone you will not find it there.

How far back it goes. Read activity is kept for 180 days. That is deliberate: the complaint it exists to settle, “this conversation went read on its own”, usually surfaces weeks after the fact.

Mark as unread: the undo

The same header menu (⋮) has Mark as unread. It takes the most recent message that is not yours and flips it back to unread, then closes the thread.

Because the inbox is shared, it goes back to unread for your whole team, not just for you. That is what makes it useful, and it is why it matters more here than in a personal inbox:

• It is the only way to undo an accidental read. Once a thread is opened, its badge is cleared for everyone, and there is no other route back.
• It is how you hand something on. Open it, see it needs the person who actually ran that session, put it back.

Two side effects worth expecting. The sender’s own tick on that message drops from Seen back to Delivered, because as far as the record goes it is unread again. And the action is written into Read activity on its own row, so your teammates can see you handed it on rather than only that you opened it.

Mark as unread is in the mobile app too, so a thread you open on your phone between sessions can go straight back to the team.

Next: how all of this looks for your clients Messaging on mobile →