Live monitoring for digital conversations

Quality scoring tells you how an agent handled a conversation after it ended. Live monitoring tells you what is happening right now — and a supervisor can step in while the customer is still waiting. On digital channels (web chat, SMS, WhatsApp, social, email) there are four actions:

Watch — silently follow the thread. Supervisors see the transcript live without the customer or the agent being told.
Whisper — send a private coaching tip to the handling agent. The tip lands as an internal note in the agent’s open thread; the customer never sees it.
Barge — take over the conversation. From this point on the supervisor’s replies are what the customer sees, and the thread is reassigned to the supervisor.
Unwatch — stop a watch session (available to the supervisor who started it).

Every action is visible on the supervisor wallboard and in the agent’s thread as a live badge (watching / coached / seized), so the whole team can see who is overseeing which conversation.

1. Where supervisors open a conversation

Supervisors access live monitoring from two places in the dashboard:

Inbox — open any live conversation from the inbox list. The thread rail shows the live transcript, and the Watch and Whisper actions are available in the action bar. A green “Watching” badge appears on the conversation card in the inbox list while a supervisor is watching, visible to other supervisors on the team.
Wallboard — the team wallboard shows a per-agent live-state grid with active-conversation counts and channel mix. A conversation being watched by another supervisor carries a “Watching” badge on the wallboard tile, and a barged thread shows the supervisor’s name in place of the handling agent so the shift lead can see who took over.

An agent who opens their own thread sees the supervisor’s presence as a live “Coaching” or “Seized” badge next to the conversation header — delivered over the same inbox WebSocket the agent already subscribes to, so there is nothing new for them to poll.

2. What each party sees

Watching

The supervisor follows the transcript in real time, exactly as the agent sees it. The supervisor is invisible — no customer-visible marker, no notification to the agent, no change to the conversation itself. The only visible sign is the “Watching” badge on the wallboard, which is visible to other supervisors.

Whisper

When a supervisor whispers a coaching tip:

Agent view — the tip lands as an internal note in the agent’s open thread, marked supervisor coaching with the supervisor’s identity and a timestamp. The note appears inline in the agent’s thread rail within seconds, delivered over the existing note.internal.created inbox WebSocket event.
Customer view — invisible. The coaching note is an internal note (conversation_internal_notes) scoped to the assigned agent. It never appears in the customer’s transcript or outbound messages.
Supervisor view — the whisper response confirms delivery with a whisper_note_id and whisper_published boolean, so you can verify the tip landed before moving on.

Barge

A barged conversation changes visibly for all parties:

Customer view — the next reply comes from the supervisor’s identity rather than the original agent’s. The thread continues without interruption; the customer sees a different name on replies but no server-side disclosure announcement (unlike voice barge, where an audible disclosure plays).
Agent view — the thread assigns to the supervisor and the agent’s open-thread view shows the “Seized” badge. The agent can still see the full transcript for context but can no longer reply into the customer-facing thread.
Supervisor view — the conversation appears in the supervisor’s personal inbox as an active assigned thread. Replying from the inbox sends the customer-visible message.

3. Channel support matrix

Live monitoring works across every digital channel. The table below shows which actions apply to each channel:

Channel	Watch	Whisper	Barge	Notes
Web chat	supported	supported	supported	Inbound web chat widget threads support the full triple. The agent and supervisor share the same inbox rail.
SMS	supported	supported	supported	Full support. Channel concurrency caps apply to barge; a supervisor who is already at their SMS cap receives `422`.
WhatsApp	supported	supported	supported	Full support. Barge respects the channel cap on `whatsapp`.
Email	supported	supported	supported	Full support. Email channel caps (commonly set to `1`) are enforced on barge — a supervisor already handling a live email cannot barge into a second one unless the cap allows it.
RCS	supported	supported	supported	Full support. RCS business messaging threads are monitored identically to SMS.
Facebook Messenger	supported	supported	supported	Full support (channel slug: `messenger`).
Instagram	supported	supported	supported	Full support (channel slug: `instagram`).
Viber	supported	supported	supported	Full support (channel slug: `viber`).
Line	supported	supported	supported	Full support (channel slug: `line`).
Telegram	supported	supported	supported	Full support (channel slug: `telegram`).
WeChat	supported	supported	supported	Full support (channel slug: `wechat`).
KakaoTalk	supported	supported	supported	Full support (channel slug: `kakao`).
Zalo	supported	supported	supported	Full support (channel slug: `zalo`).
Apple Messages for Business	supported	supported	supported	Full support (channel slug: `apple_messages`).
AI agent threads	supported	supported	supported	AI-managed conversations (channel: `agent`) support the full triple — the supervisor watches the AI’s handling and barges to take over when the AI escalates.
Voice	not supported	not supported	not supported	Voice calls use the dedicated voice monitoring surface at `POST /api/v1/voice/calls/:id/listen	whisper	barge` with a softphone call leg. See Live monitoring for voice calls.
Video	not supported	not supported	not supported	Video rooms use the LiveKit room supervision surface in the attendant console.

Live monitoring is channel-agnostic at the service layer — it reads the conversation row and stamps the supervision marker regardless of channel. The “not supported” rows above are for voice and video, which have their own dedicated supervision surfaces with audio/room-mixer semantics. Every digital channel listed above supports the full watch / whisper / barge / unwatch quadruple.

4. Hand-back semantics and audit trail

Returning a barged thread to the agent

Barge reassigns the conversation to the supervisor. To hand it back:

curl -X POST https://api.orbit.devotel.io/api/v1/conversations/conv_123/assign \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{"assigned_to": "agent_user_2"}'

This is the standard conversation assign endpoint — the same one a supervisor uses for any manual reassignment. Unwatching does not hand back a barged thread; it only clears the watch marker. The thread stays assigned to the supervisor until an explicit assign moves it.

Audit trail

Every watch, whisper, barge, and unwatch action is audit-logged with:

The acting supervisor’s user ID
The conversation ID
The action (supervisor.digital_monitor.watch, .whisper, .barge, .unwatch)
The caller’s IP address
The resulting trait (watching / coach_tip / seized) and post-action assignee
A timestamp

To query the audit trail for a specific conversation:

curl "https://api.orbit.devotel.io/api/v1/audit-log?resource=conversation&resource_id=conv_123&action=supervisor.digital_monitor" \
  -H "X-API-Key: dv_live_sk_your_key_here"

Filter by action to isolate a specific monitoring event:

Action filter	What it returns
`supervisor.digital_monitor.listen`	Every watch session started on this conversation
`supervisor.digital_monitor.whisper`	Every coaching tip sent on this conversation
`supervisor.digital_monitor.barge`	Every takeover of this conversation
`supervisor.digital_monitor.unwatch`	Every watch session ended on this conversation

The audit log is tamper-evident and tenant-scoped — a supervisor can only query their own workspace’s entries.

5. Supervisor-side limits

Limit	Value	Behaviour when exceeded
Whisper tip character cap	500 characters	The API returns `422 EMPTY_TIP` for an empty tip and silently truncates tips over 500 characters at the service layer.
Wiki whisper deduplication	10-second window per (conversation, supervisor)	A second whisper within the window is not debounced at the API layer — the note is written again — but the SSE frame deduplicates so the agent sees one notification.
Barge idempotency	Per (conversation, supervisor)	A supervisor who already owns the thread and calls barge again receives `already_barged: true` with no re-stamping.
Barge channel concurrency	Per your team’s channel caps (set at Settings → Team → Channel concurrency caps)	If the supervisor is already at their maximum concurrent conversations for the thread’s channel, barge returns `422` with a reason referencing the cap. This is the same gate that a manual `POST /conversations/:id/assign` enforces.
Max watchers per thread	No hard limit	Multiple supervisors can watch the same thread concurrently. Each supervisor’s watch marker is independent — unwatch clears only the caller’s marker.
Thread state gate	Open conversations only	Closed or archived threads return `422 ALREADY_CLOSED` for every action.
Assignee gate	Whisper and barge require an assigned agent	An unassigned conversation returns `422 NO_ASSIGNEE` for whisper and barge. Watch does not require an assignee.

6. Privacy and compliance guidance

Whisper visibility

Whisper coaching notes are written to the conversation_internal_notes table as internal notes — the same table that stores colleague notes and system annotations. They are never exposed to the customer and never appear in the message transcript. The note author is the supervisor who sent the whisper; the note content is the coaching tip text.

Retention of coaching notes

Coaching notes follow the same retention policy as internal notes. They are not ephemeral — a whisper note persists until the tenant deletes the conversation or a workspace admin purges internal notes. This means a whisper from six months ago is still readable in the conversation history if the thread has not been deleted.

Works-council / labour-relations considerations

Live monitoring raises questions that vary by jurisdiction, workforce agreement, and internal policy. Devotel Orbit provides the controls; your organization’s policy determines how they are used:

No silent monitoring of the agent desktop — watch shows the conversation transcript only. It does not provide keystroke logging, screen recording, or desktop monitoring. The agent’s private browser tabs and applications are never observable through Orbit.
Watch is invisible to the agent by design — the agent is not notified when a supervisor begins watching. If your jurisdiction or works-council agreement requires agent notification, configure your internal policy to require supervisors to open the conversation from a wallboard tile (which displays a badge) rather than from the inbox.
Whisper coaching notes are discoverable — the agent can see every whisper note in their conversation history. There is no “invisible whisper” — every coaching tip lands as a visible internal note in the thread. An agent auditing their own conversations can read every whisper they received.
The audit trail is comprehensive — every monitoring action is logged with the supervisor, the conversation, the action, and a timestamp. The audit log is the single source of truth for “who monitored which conversation and when”; it is not editable and not deletable by supervisors.
Tenant-owned controls — monitoring is enabled at the tenant level (available to any workspace with the feature). There is no global “disable monitoring” tenant flag. If your organization requires monitoring to be off for certain agents or teams, use the role gate: restrict the supervisor role to designated staff and do not grant it to agents being monitored.

7. Real-time transports

The live-monitor actions are delivered over two real-time transports:

Transport	What it delivers	Who consumes it
`conversation.live_monitor` SSE frame (tenant channel `events:<schema>`)	The supervision marker (supervisor ID, trait, conversation ID, channel, timestamp).	The supervisor wallboard and inbox list — these render the “Watching” / “Coaching” / “Seized” badges in real time without polling.
`note.internal.created` inbox WebSocket event	The whisper coaching note (note ID, author, content, `supervisor_whisper: true` marker).	The handling agent’s open thread — the note surfaces inline in the thread rail immediately.

The SSE frame carries the supervised_by payload: supervisor_user_id, kind (watching / coach_tip / seized), and since timestamp. The wallboard reads this to show “Supervisor Smith is watching thread #conv_123” without a page refresh. The inbox WebSocket event is the same transport the agent’s thread already handles for colleague notes and system annotations — the supervisor_whisper: true flag lets the FE render a distinct “coaching from your supervisor” variant. When a supervisor unwatches, the SSE frame carries action: "unwatch" with supervised_by: null — the wallboard badge clears on the next tick rather than on the next poll.

8. Interaction with channel concurrency caps

Channel concurrency caps are set at Settings → Team → Channel concurrency caps and apply to barge as follows:

When a supervisor barges into a conversation, the barge write consults assertAgentChannelCapacity for the conversation’s channel and the supervisor’s current active count on that channel.
If the supervisor is already at their cap (for example, email = 1 and they already own a live email thread), the barge is refused with 422 rather than silently overflowing the supervisor’s inbox.
The cap gate skips when the supervisor already owns the thread (the idempotency path — already_barged: true), because re-barging does not create a new assignment.
Tenants without configured channel caps are unaffected — the cap helper fail-opens when no cap row exists, so existing workspaces keep their current behaviour.
Watch and whisper do not consult the channel cap — only barge, because only barge changes the assigned_to ownership.

The cap enforcement is the same gate that a manual POST /conversations/:id/assign, a warm transfer, and an auto-assignment all pass through, so a supervisor barging in follows the same concurrency rules as any other assignment.

9. Troubleshooting

Whisper fails to render in the agent’s thread

Check that the whisper note was written — the whisper API response carries whisper_note_id and whisper_published. If whisper_note_id is present but whisper_published is false, the note was saved but the real-time delivery failed (a transient Redis issue). The note is still in the conversation history.
Check that the note is visible in the audit log — query the audit trail for action=supervisor.digital_monitor.whisper on this conversation. The details.whisper_note_id field confirms the note was written.
Check that the agent’s inbox WebSocket is connected — the whisper delivery rides the note.internal.created event on the agent’s existing inbox WebSocket. If the agent’s WebSocket is disconnected (browser tab closed, network interruption), the note will not surface until they reconnect and the thread reloads.

Barge is rejected with 422

Common causes:

Channel concurrency cap exceeded — the supervisor is already at their maximum concurrent conversations for this channel. Check the supervisor’s current active conversations at Settings → Team → Channel concurrency caps and either raise the cap or transfer an existing thread before barging.
Thread is not open — closed or archived threads cannot be barged into. Confirm the conversation status is open.
No assigned agent — barge requires an assigned agent to relieve. An unassigned thread returns 422 NO_ASSIGNEE. Assign the thread first, then barge.

Audit trail shows no entries for monitoring actions

Check the role — monitoring endpoints require an elevated role (owner, admin, or supervisor). A developer, billing, or viewer seat gets 403 at the route layer and no audit entry is written.
Check the action filter — the audit action prefix is supervisor.digital_monitor. (with a dot, not a slash or underscore). An exact match query for action=supervisor.digital_monitor.barge returns only barge entries.
Check the tenant scope — the audit log is tenant-scoped. A supervisor querying from the wrong workspace gets an empty result.

Watch a conversation

From the dashboard, a supervisor opens any live conversation and chooses Watch — or over the API:

curl -X POST https://api.orbit.devotel.io/api/v1/conversations/conv_123/monitor/watch \
  -H "X-API-Key: dv_live_sk_your_key_here"

The response confirms the session is active and reports the stamped marker:

{
  "conversation_id": "conv_123",
  "action": "listen",
  "status": "active",
  "trait": "watching",
  "assigned_to": "agent_user_2",
  "supervised_by": {
    "supervisor_user_id": "sup_user_1",
    "kind": "watching",
    "since": "2026-08-24T14:03:11.000Z"
  }
}

Watching is read-only — the supervisor is invisible to the customer and never appears in the transcript. Stop the session with Unwatch:

curl -X POST https://api.orbit.devotel.io/api/v1/conversations/conv_123/monitor/unwatch \
  -H "X-API-Key: dv_live_sk_your_key_here"

A supervisor can only stop their own watch session — one supervisor cannot clear a colleague’s marker. If the thread was taken over (barged), stopping the watch does not hand it back; assign it back to the agent explicitly.

Whisper a coaching tip

When an agent is mid-conversation and a supervisor can see the right move, they can coach without the customer seeing anything:

curl -X POST https://api.orbit.devotel.io/api/v1/conversations/conv_123/monitor/whisper \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{"text": "Offer the retention credit — it is on their profile."}'

The tip arrives in the agent’s open thread as an internal note marked supervisor coaching, delivered over the note.internal.created inbox WebSocket event the agent already subscribes to — so there is nothing new for the agent to poll. The tip is bounded to 500 characters; an empty tip returns 422 EMPTY_TIP. Whisper requires an agent to be actually assigned to the conversation (you cannot coach nobody) and an open thread (closed/archived threads return 422).

Barge in (take over the thread)

When coaching is not enough, the supervisor takes the thread:

curl -X POST https://api.orbit.devotel.io/api/v1/conversations/conv_123/monitor/barge \
  -H "X-API-Key: dv_live_sk_your_key_here"

From that moment the conversation is assigned to the supervisor and their replies are the ones the customer sees. Barge is idempotent — a supervisor who already owns the thread gets already_barged: true back and nothing re-stamps. The takeover respects your team’s channel concurrency caps: if the supervisor is already at their maximum for that channel (for example email = 1), the barge is refused instead of silently overflowing their workload — the same rule a manual reassign would apply.

Who can monitor

Every live-monitoring endpoint requires an elevated role — owner, admin, or supervisor — plus a full agent seat in your workspace. A developer or billing member gets 403.

Common failure codes

Status	Code	What it means
422	`ALREADY_CLOSED`	The thread is closed or archived — monitoring needs a live subject
422	`EMPTY_TIP`	Whisper came with an empty coaching tip
422	`NO_ASSIGNEE`	Whisper or barge tried on an unassigned thread
403	—	Caller is not owner/admin/supervisor
404	`NOT_FOUND`	The conversation id does not exist for this tenant

WhatsApp

Developer console

Contact center

Guides

Messaging Controls

Audience & Support Tools

Supervisor live monitoring for digital conversations: watch, whisper, barge

Live monitoring for digital conversations

1. Where supervisors open a conversation

2. What each party sees

Watching

Whisper

Barge

3. Channel support matrix

4. Hand-back semantics and audit trail

Returning a barged thread to the agent

Audit trail

5. Supervisor-side limits

6. Privacy and compliance guidance

Whisper visibility

Retention of coaching notes

Works-council / labour-relations considerations

7. Real-time transports

8. Interaction with channel concurrency caps

9. Troubleshooting

Whisper fails to render in the agent’s thread

Barge is rejected with 422

Audit trail shows no entries for monitoring actions

Watch a conversation

Whisper a coaching tip

Barge in (take over the thread)

Who can monitor

Common failure codes

See also

​Live monitoring for digital conversations

​1. Where supervisors open a conversation

​2. What each party sees

​Watching

​Whisper

​Barge

​3. Channel support matrix

​4. Hand-back semantics and audit trail

​Returning a barged thread to the agent

​Audit trail

​5. Supervisor-side limits

​6. Privacy and compliance guidance

​Whisper visibility

​Retention of coaching notes

​Works-council / labour-relations considerations

​7. Real-time transports

​8. Interaction with channel concurrency caps

​9. Troubleshooting

​Whisper fails to render in the agent’s thread

​Barge is rejected with 422

​Audit trail shows no entries for monitoring actions

​Watch a conversation

​Whisper a coaching tip

​Barge in (take over the thread)

​Who can monitor

​Common failure codes

​See also

Live monitoring for digital conversations

1. Where supervisors open a conversation

2. What each party sees

Watching

Whisper

Barge

3. Channel support matrix

4. Hand-back semantics and audit trail

Returning a barged thread to the agent

Audit trail

5. Supervisor-side limits

6. Privacy and compliance guidance

Whisper visibility

Retention of coaching notes

Works-council / labour-relations considerations

7. Real-time transports

8. Interaction with channel concurrency caps

9. Troubleshooting

Whisper fails to render in the agent’s thread

Barge is rejected with 422

Audit trail shows no entries for monitoring actions

Watch a conversation

Whisper a coaching tip

Barge in (take over the thread)

Who can monitor

Common failure codes

See also