人への引き継ぎ

人が必要になる会話もあります。Busymate AI ではユーザーが人を呼び、チームメンバーが同じ会話へ参加できます。説明し直す必要も、別のチャネルへ移る必要もありません。アシスタントとチームがひとつのスレッドを共有します。

ユーザーが人を依頼する方法

ユーザーはそう伝えるだけです。「誰かと話せますか」「人につないで」「担当者が必要です」のように人との会話を求めると、アシスタントは無理に続けず、要求を認識して引き継ぎを起こします。ユーザーはその場に留まり、別のウィジェットやメールへ送られることはありません。

チームが参加する方法

チーム側では、操作担当者の受信箱に人を待っている会話が集まります。メンバーがひとつを開くと、ユーザーとアシスタントが積み上げた履歴全体を確認し、引き継いで同じスレッド内で返信できます。ユーザーにとっては途切れません。同じ会話で、回答者が人に変わるだけです。

担当者の対応が終われば、会話をアシスタントへ戻せます。引き継ぎはスレッドの一場面であり、行き止まりではありません。

割り当てと担当者への通知

ワークスペースの Console で手動取得、ラウンドロビン、最少稼働から選びます。自動モードが対象にするのは、現在対応可能と表示され、まだ処理枠があるアクティブなワークスペースメンバーだけです。各判断にはアルゴリズム、対象担当者数、選ばれた担当者、計測負荷が記録されるため、説明できない、または架空の割り当てが成功として扱われることはありません。

永続的なアプリ内受信箱が担当者の主要チャネルです。自動割り当てされた依頼の通知は該当担当者だけに宛てられ、連携済みの Web Push、APNs、個人 Telegram エンドポイントへ既存の通知ファンアウトで送られます。少なくとも1つのエンドポイントが送信成功を返した場合にだけ、そのプロバイダー経路が delivered になります。通知先を選択していないアプリ内通知は accepted のままです。

メール、テナントが設定した Telegram 宛先、webhook 経路も設定できます。これらは明示的なキュー型拡張ポイントです。デプロイ環境に認証済み配信ワーカーが用意されるまでは queued のままで、Busymate AI は設定されただけで配信済みと表示しません。配信履歴では queued、dispatching、accepted、delivered、failed、skipped を区別します。

有効化

人的引き継ぎはオプトインです。チームが回答できる準備を必要とするため、テナントで有効にするまではオフです。ガバナンスとモデルポリシーで有効にすると、アシスタントが人への経路を提示し、操作担当者の受信箱が稼働します。オフのままなら、提供できない人への接続をアシスタントが約束することはありません。

正直さを組み込んだ設計。 引き継ぎがオフなら、アシスタントは「誰かにつなぎます」と言いません。実際に人を配置したときだけ、人という選択肢を提示します。約束を本物に保つためです。

次へ

• ガバナンスとモデルポリシー — 引き継ぎを有効にし、回答できる人を設定する。
• アシスタント体験 — ユーザーが人を依頼する場所を確認する。