Run your workspace

Inbox

The inbox at /app/inbox is where leads and live conversations land. Captured leads are listed on the left, sorted by recency; click any row to see the full transcript with every visitor message and agent reply on the right.

What the inbox is

Think of it as a lead-and-takeover console rather than a CRM. It surfaces what the agent collected, lets a human jump in when needed, and hands the conversation back when the issue is resolved.

Status management

The Status column is inline-editable. Leads move through new → qualified → contacted → won/lost; the list auto-refreshes whenever the tab regains focus, so you don't have to remember to reload.

Real-time updates

Each open conversation subscribes to a private Reverb channel (conversation.{id}) so new messages appear instantly without polling. When a teammate takes over, the visitor's widget swaps the agent badge for Human is here in the chat header.

Takeover process

Clicking Take over sets claimed_by_user_id on the conversation and pauses the AI. Visitor messages then route to the inbox; operator replies stream back as human-agent role messages. Hand back to bot releases the claim so the agent resumes responding.

Where leads come from

Leads originate two ways:

• Visitor-driven — the widget shows a form (behavior rule, intent detection, or CTA button).
• Webhook-driven — the lead.captured outgoing webhook fires so your CRM can pull the record.

Notifications

Three alert channels run in parallel:

• In-app toasts polling GET /app/leads/feed every 30 seconds.
• Optional OS-level notifications (requires browser permission).
• Email notifications to workspace owners and admins (requires a running queue worker and a configured mailer).

Conversations index

The Conversations index lists every session — even ones that never produced a lead. You can filter to engaged conversations only, delete individual rows, bulk-delete empty sessions, or bulk-delete a selection. Deletion controls are gated to Admin and Owner roles.

Audit log

Privileged actions (claim, release, delete) are recorded in the audit_logs table with the actor, timestamp, and target id — useful when you need to reconstruct who did what during an incident.