Intercom adds live conversation-viewer visibility to Inbox Table view

Intercom adds live co-viewing visibility to Inbox Table view

Intercom's September 17 update adds teammate avatars to conversation rows in Inbox Table view. The stated purpose is simple: operators can see when a colleague is already handling a conversation and avoid duplicate replies. The change is small compared with a new AI agent or connector, but it addresses a failure mode that becomes more important as service work is shared across humans, automations and assistants.

Duplicate replies are not only a customer-experience problem. They create conflicting instructions, split ownership and unreliable evidence about who took the final action. A visible co-viewing cue gives an operator a chance to coordinate before another response is sent. It does not guarantee exclusive ownership, so teams should treat it as a concurrency signal rather than a locking mechanism.

Sources: Intercom changelog, September 17, 2026

Presence is a control signal, not an assignment rule

An avatar on a row answers one question: someone else is looking at this conversation now. It does not necessarily say who owns the customer outcome, whether that person is drafting, whether an automation is about to act or whether the viewer has authority to close or escalate the case. Support operations should keep assignment and ownership rules separate from presence so a temporary viewer does not become the accidental decision owner.

The useful operating pattern is to combine three states: assigned owner, current viewers and pending actions. If those states disagree, the workflow should make the conflict visible. For example, a conversation can be assigned to one teammate while another investigates it, or an agent can prepare a response while a human is reviewing a refund. Presence helps only when operators know which state actually controls execution.

Customer-facing actions need idempotency beyond the inbox

Duplicate replies are one form of collision, but the same conversation can also trigger duplicate CRM tasks, refunds, credits, follow-up emails or lifecycle changes. Once support tooling calls external systems, the concurrency control must travel with the action. Use a stable execution key or business-action identifier so a retry, second operator or automation cannot create the same consequential action twice.

Keep the action record close to the system that owns the consequence. A refund identifier belongs with the payment action, a CRM task ID belongs in CRM and a lifecycle suppression change belongs in the messaging system. The conversation can link to those records, but it should not be the only place where the business can prove what happened.

Measure collisions instead of assuming collaboration works

Support leaders can sample conversation histories for evidence of overlapping work: multiple replies within a short window, reopened items immediately after closure, duplicate external actions, conflicting notes or handoffs that occurred after another teammate had already completed the task. The goal is not to rank operators; it is to identify workflows where the interface does not expose ownership early enough.

Add the co-viewing feature to that review as an observable control. When a duplicate still occurs, ask whether the second operator could see the active viewer, whether ownership was clear, whether a pending automation was visible and whether the downstream action had duplicate prevention. That separates interface visibility problems from policy or integration problems.

AI makes human presence information more valuable

As service agents automate more steps, teams need a shared picture of work in progress. A human can notice another person's avatar, but an AI workflow may need a machine-readable equivalent: current owner, active execution, approval pending, or action already completed. RevOps should not assume that a visual collaboration cue automatically protects agent-triggered writes.

The durable control is a customer-action state that both people and automations can inspect before acting. It can be as simple as an execution record with status, owner, target system and action key. The UI can then surface the state for humans while integrations use it for duplicate prevention. Presence becomes one input to that control rather than the control itself.

What to verify in the Table-view rollout

Confirm that the new avatars appear for the teams and inboxes where operators actually coordinate, then create a controlled overlap test with two teammates. Have one person open a conversation while the other works from Table view, and verify what each person can see before either replies. Repeat with assignment changes, snoozed conversations and a case that triggers an external action so the team understands where the visibility starts and stops.

Intercom's change is a narrow product update with a broad operations lesson: concurrency is easier to manage when work in progress is visible before the next action happens. Use the feature as an extra coordination cue, then keep authoritative ownership, duplicate prevention and downstream action evidence in the systems that are responsible for the final customer outcome.