互客鱼 返回主站

运行您的工作区

收件箱和人工接管

收件箱是您的潜在客户和接管控制台。/app/inbox 列出每个捕获的潜在客户;打开一个显示产生它的完整对话记录, 并允许您作为人工客服介入以继续该线程。

布局

/app/inbox 在左侧显示潜在客户,按最近性排序。 点击一个,右侧面板显示产生它的对话:一侧是访客消息, 另一侧是智能体回复,过去接管的人工客服消息有自己的角色 (user / assistant / human-agent)。

/app/conversations 的对话索引涵盖每个对话, 无论是否产生了潜在客户——用于探索未转化的过去会话。 从那里您可以打开对话并使用相同的接管控件。

实时更新

每个打开的对话都订阅其私有 Reverb 频道(conversation.{id}) 以进行实时更新。新消息无需轮询即可出现;接管状态传播到访客的小部件 和查看同一线程的任何其他操作员。

接管

点击 接管。会发生以下几件事:

  1. 对话获得设置为您自己的 claimed_by_user_id + claimed_at(路由:POST /app/conversations/{conversation}/claim)。
  2. 在对话的私有频道上触发 conversation.claimed Reverb 事件——访客的小部件在聊天头部显示"人工客服在此"。
  3. AI 暂停。每个访客消息路由到收件箱;您输入的每个回复都通过 POST /app/conversations/{conversation}/reply 作为 human-agent 角色消息流式传输给访客。

释放

点击 交还给机器人 以释放(路由: POST /app/conversations/{conversation}/release)。下一个 访客消息再次通过 RAG 管道。访客的聊天头部切换回智能体的角色设定。适用于:

  • 您回答了非脚本问题,其余部分回到 FAQ 领域。
  • 访客满意并可能离开。
  • 您结束轮班——交还保持 24/7 覆盖。

捕获潜在客户

潜在客户通过两种方式进入:

  • 访客驱动 ——小部件的内联潜在客户表单,由行为规则或访客明确要求联系时触发。提交的潜在客户进入 /app/inbox
  • Webhook 驱动 ——每个捕获的潜在客户都会触发 lead.captured 出站 webhook,以便您可以将其分发到您的 CRM。详见 出站 webhook

应用内实时通知

管理 shell 每 30 秒轮询一次 GET /app/leads/feed, 获取工作区中新捕获的潜在客户,并将每个潜在客户作为 sonner toast 显示在管理 SPA 每个页面的右下角。点击 toast 直接跳转到收件箱行。

顶部标题中的铃铛按钮向浏览器请求本机通知权限。授予后, 每个新潜在客户也会触发操作系统级别的通知,因此工作区成员会在 未聚焦的标签页上收到提示。权限是按域名的——一旦拒绝,只能从浏览器的 设置中撤销。

轮询在隐藏标签页上暂停,以防止空闲仪表板消耗 HTTP。 光标存储在 sessionStorage 中,因此打开第二个标签页不会 对已看到的潜在客户重复 toast。

电子邮件通知

每个捕获的潜在客户都会通过电子邮件分发给每个工作区所有者和管理员。 通知(App\Notifications\NewLeadCaptured)是排队的—— 访客的 HTTP 请求永远不会等待 SMTP,因此慢速邮件程序不会减慢 潜在客户捕获或聊天。

电子邮件实际到达的两个要求:

  1. 队列工作器正在运行。在生产中我们使用 database 驱动程序——确保 php artisan queue:work --queue=default 在进程监督器上运行(Laravel Cloud 上的集群内工作器会处理这个问题)。 如果没有它,排队的通知会在 jobs 中堆积且永远不会发送。
  2. .env 中配置了 MAIL_MAILER + 匹配的凭据。 默认是 log ——适合开发但不会发送实际电子邮件。 在生产中切换到 smtp / resend / postmark 并通过 php artisan tinker --execute 'Mail::raw("ping",fn($m)=>$m->to("you@example.com")->subject("test"));' 验证。

接收者被过滤为 workspace_users.role IN ('owner', 'admin')accepted_at IS NOT NULL。待处理的邀请者和观察者不会收到 潜在客户电子邮件。电子邮件的页脚反映您的白标网站标题(在设置 → 系统中设置)。

清理对话日志

每当访客在 24 小时内首次加载小部件时,都会写入一个新的 Conversation 记录。未经输入就路过的访客仍然会产生一行, 这意味着 /app/conversations 会随着时间的推移堆积空会话。 有两种功能使其易于管理:

  • 仅参与过滤器(默认)。列表隐藏没有访客消息的对话。 在过滤器栏中切换 显示全部 以查看每个会话—— 当您寻找机器人流量或 QA 负载时有用。
  • 每行删除。管理员和所有者角色在悬停时看到垃圾桶图标。 删除通过 DB 外键级联到消息、潜在客户和应用标签;分析事件被保留 (FK nullOnDelete),因此聚合统计保持不变。
  • 批量删除空对话。过滤器栏中的按钮清除工作区中 没有用户角色消息的每个对话。访客发送至少一条消息的会话永远不会被触及。
  • 批量删除选中项。勾选任何可见行上的复选框,然后点击 删除 N 个选中项Conversation 上的工作区 全局作用域保护跨租户 ID 走私——来自其他工作区的 ID 在服务器端静默丢弃。

观察者和编辑者看不到删除功能;ConversationPolicy::delete + WorkspacePolicy::bulkDeleteConversations 检查需要管理员或所有者。 删除是不可逆的——没有软删除跟踪,审计日志尚未捕获对话删除。

审计日志

对话的特权操作(认领、释放)将行写入 audit_logs 表以进行 取证可追溯性。v1 中没有用于浏览它们的 UI 页面;需要调查时直接查询表。