ウィロークリーク動物病院には、日中のほとんどを手術に費やす獣医師が 1 人と、カウンターで忙しく働くフロント係がいます。AI エージェントの受付が、ウェブサイトのチャットと電話の応対をします。プリヤが*「ベラのお薬について、エリス先生から折り返し電話をもらえますか？」*と書いてきたら、病院が知りたいのは今すぐです。チャットが終わって 30 分後ではなく、プリヤがまだウェブサイトにいて、ほかの病院にかけ直してしまう前の、その瞬間に。
これが Live の役割です。対話インサイトのはい / いいえフィールドのうち 1 つに、一度に 1 つだけ付けます。するとエージェントは会話の最中にリクエストを検知し、そのフィールドのラベルに付いた通知ワークフローが数秒で動きます。オンにしなかったフィールドは、これまでとまったく同じように動き続けます。
その土台になる はい / いいえフィールド
対話インサイトは、AI がすべての会話について答える短い質問のリストです。各質問がフィールドで、各フィールドには種類があります：はい / いいえ、選択肢（あらかじめ書いた値のリストの中の 1 つ）、テキスト、数値。
はい / いいえフィールドは、答えが 2 つある質問を 1 つたずねます。ウィロークリークの対話インサイト受付フォローアップには折り返し電話というフィールドがあり、その抽出の指示には、答えが「はい」になるときが書かれています：「お客様が、獣医師か病院に折り返し電話を頼んできたとき。」
ラベルとして出力がオンだと、答えは会話上のラベルになります：
| フィールドの種類 | ラベルとして出力がオンのとき、会話に付くもの |
|---|---|
| はい / いいえ | 答えが「はい」のときはフィールドの名前 折り返し電話。「いいえ」のときは何も付きません |
| 選択肢 | AI が選んだ値。たとえば 緊急 |
| テキスト、数値 | ラベルになることはありません |
ワークフローが待ち受けているのはラベルです。メール通知とは、ラベルが会話に追加されたときに起動するワークフローのこと。だからメールを送るのは、このラベルです。
1 つのラベル、複数のリクエスト
ラベルは、会話に付いているか、付いていないかのどちらかです。これは「この相談はワクチンのことでしたか？」のように、一度「はい」になったら「はい」のままの質問には合っています。リクエストには合いません。お客様は、何度でも頼んでくるからです：
- Live なしでは、分析が初めて「はい」と答えたときにラベルが付きます。1 時間後にプリヤがもう一度頼んでも、ラベルはすでに付いているので、何も追加されず、通知も再び動きません。
- Live ありでは、エージェントがリクエストを検知するたびに、ラベルの下に番号付きのリクエストとして記録されます：「Request 1」、「Request 2」。ラベルは、開いているリクエストがあるあいだ会話に残り、最後の 1 つが対応済みになると外れます。新しいリクエストのたびに、通知を再び動かせます。
Live にできるのははい / いいえフィールドだけなのは、そのためです。「はい」はお客様がしたことの記録であり、次の「はい」は新しいリクエストです。選択肢の値は会話を描写するものなので、数える対象がありません。**「During the conversation」**セクションに並ぶのは、ラベルを出力するはい / いいえフィールドだけです。対話インサイトに 1 つもないときは、*「受付フォローアップ has no yes/no fields that produce a label, so nothing can be Live yet.」*と表示されます。
フィールドを Live にすると何が変わるか
折り返し電話がラベルを出力していて、そのラベルにメール通知が付いているとき：
| Live でない | Live | |
|---|---|---|
| 通知が届くとき | 会話が終わったあと、対話インサイトが実行されたとき | お客様が頼んでから数秒以内。まだその場にいるあいだに |
| 同じ会話で、そのあともう一度頼んできたとき | 何も起きません：ラベルはすでに付いているからです | 新しいリクエストと、新しい通知 |
| 見つけるのは誰か | 会話のあとのチェック | お客様が頼んでいる最中に、エージェントが。見逃しても、会話のあとのチェックが見つけ、その時点で通知が出ます |
会話のあとの分析は、Live フィールドの下でも動き続けます。これがセーフティネットです。エージェントが検知しなかったリクエストも、会話が終わったときに記録され、通知されます。Live がなかった場合とまったく同じように。
Live が働く場所
エージェントが話すところならどこでも：ウェブサイトのチャットウィジェット、エージェントのテストページ、WhatsApp をはじめとするメッセージチャネル、メールでのやり取り、そして着信も発信も含む電話です。
電話では、エージェントはリクエストを検知しようと 1 回だけ素早く試みます。最大でも 2 秒なので、発信者を待たせることはありません。うまくいかなければ、エージェントは自分の言葉で会話を続け、代わりに通話の最後のチェックがリクエストを見つけます。会話として記録されない通話は、Live では検知されません。
Octo に頼んで設定する
一番早いのは、Octo への 1 文です：
折り返し電話を頼んできたら、そのたびにすぐメールで知らせて。Octo はラベルを出力するフィールドを見つけ（なければエージェントの対話インサイトへの追加を提案し）、通知ワークフローを組み立て、フィールドを Live にする前に、この変更が届く範囲すべてを見せます。あなたが同意するまで、何も変わりません。
言葉が重要です。「今すぐ」「即座に」「頼んだらすぐ」「チャットしている最中に」「頼むたびに」は、リアルタイムを求める言葉です。単なる「折り返し電話のリクエストがあったら知らせて」だと、会話のあとに届く普通の通知になり、Octo はそれをリアルタイムにできると一度だけ伝えてきます。
または設定タブでオンにする
-
/agents でエージェントを開き、設定 に進みます。
-
対話インサイトが紐付いている 会話の終了後 の下には、専用のセクション 「During the conversation」 があります：
Turn a yes/no field Live and this agent flags it as soon as the customer asks, so its workflows run within seconds. Fields that aren’t Live are still found after the conversation ends.
対話インサイトが何も紐付いていないときは、*「Attach a Dialog Insight above to choose what this agent flags while the conversation is still going.」*と表示されます。
-
ラベルを付けるはい / いいえフィールドにはそれぞれカードがあり、Live スイッチと、そのラベルに付いたワークフローが表示されます。選択肢・テキスト・数値のフィールドは一覧に出ません。Live にできるのは、はい / いいえフィールドだけです。
ラベルを出力するはい / いいえフィールドごとに、カードが 1 枚。 -
折り返し電話 の Live をオンにします。確認ダイアログ 「Turn on Live detection for “折り返し電話”?」 が開きます。読んでから、「Turn on Live」 を押します。
スイッチを切り替えられるのは、ワークスペースのオーナーと管理者だけです。それ以外の人には読み取り専用で表示され、*「Only workspace owners and admins can change Live detection.」*と書かれています。
確認ダイアログが伝えてくれること
確認ダイアログは、スイッチが届く範囲すべてを、「This changes it for」 の下に一覧します：
- この対話インサイトを使う、すべてのエージェントとキャンペーン。 スイッチはエージェントではなく、対話インサイトに付いています。受付がこれを時間外対応の回線と共有していれば、両方が検知を始めます。共有された対話インサイトは、カードの上にそのことを表示します：「Shared with 1 other agent. A Live switch here changes it for all of them.」
- ラベルに付いたすべてのワークフローと、それぞれがいつ動くか。*「Built for after the conversation. It reads the AI summary, which doesn’t exist yet while a conversation is live.」*の表示があるワークフローは、Live をオンにする前に一度目を通しておく必要があります。
- モデルがツールを使えないエージェント。 会話の最中には何も検知できません。そのリクエストは、会話の終了後に見つかります。
ダイアログを開いているあいだに、エージェント、キャンペーン、またはワークフローがこのフィールドを使い始めていた場合は、*「Something changed since you opened this」*と表示され、「Review again」 を求められます。
お客様に伝わること
エージェントは、指示の内側で自分の言葉で答えます。台本の一行を読み上げることはなく、誰に通知が行ったかをお客様に明かすこともありません。
そこに 1 つのリスクが残ります。チームにできる以上のことを、エージェントが約束してしまうことです（「5 分でエリス先生からかけますよ」）。そこで確認ダイアログには、エージェントの名前を冠したチェックボックス 「Tell 受付 what we can promise」 があり、これが指示に 1 行追加します。最初はこう書かれています：
When a customer asks about “折り返し電話”, tell them the team will follow up. Don’t promise a specific time.
「同じ日の午後には折り返します」のように、チームが実際にしていることに合わせて編集してください。この行が入るのはこのエージェントの指示だけで、フィールドを共有するほかのエージェントの指示には入りません。
繰り返しのリクエストと通知ワークフロー
各カードには、「Workflows on the label」 の下に、各ワークフローがいつ動くかが表示されます：
| カードの表示 | 意味 |
|---|---|
| 「Runs for each new request (requests within 30 minutes are merged)」 | ワークフローのトリガーが、繰り返しのたびに動きます。Octo がリアルタイムの通知を組み立てるとき、この設定にします |
| 「Runs when the label is added: the first request, and again after every request is handled」 | Live より前に、あるいは繰り返しなしで組み立てられた通知です。そのままにされています。リクエストごとに切り替えるよう、Octo に頼みましょう |
| 「Runs once per conversation until this field is Live」 | まだ Live でないフィールドに付いた、繰り返す通知です |
おしゃべりな、あるいは意地悪なお客様が受信箱をあふれさせないための、上限が 2 つあります：
- 30 分以内のリクエストは 1 つにまとまります。 開いているリクエストの 30 分以内にもう一度の「折り返しください」は、同じリクエストです。1 つのリクエスト、1 つの通知。リクエストには 「Asked again at 4:12 PM, merged into this request」 と表示されます。
- ワークフローを動かすのは、24 時間で会話あたり最大 5 件のリクエストです。 6 件目以降も記録され、表示もされますが、「Alert limit reached」 の印が付き、メールだけでなくワークフロー全体がスキップされます。ワークフローが CRM の更新やメッセージ送信もしていれば、それらのステップもスキップされます。
通知メールの内容
Octo が組み立てる通知は、リクエストの情報を引き渡すので、メールはどのリクエストかを示します。2 回目のリクエストから、件名の末尾は「(2回目のリクエスト)」「(3回目のリクエスト)」と続きます。お客様の名前の上の行は、折り返し電話 · 2回目のリクエスト · リクエスト1はまだ対応されていません のようになります（最初のリクエストでは、ラベルだけが表示されます）。その下：
- お客様が電話番号かメールアドレスを残していれば、電話する と メールする のボタン。
- AIのメモ（お客様の言葉を引用している場合があります）：エージェントがリクエストを検知したときに、そのリクエストについて書いたものです。「会話中にAIエージェントが記入しました。AIによる要約は会話の終了後に届きます。」 プレーンテキストで表示されるので、お客様が打ったものが、受信箱の中でリンクに変わることはありません。
- 会話からの最近のメッセージ。
- 会話を開く と 対応済みにする。「対応済みにする」は、そのリクエストのところで会話を開くだけです。それ自体で何かを変えることは決してありません。メールをスキャンするプログラムは、メールの中のリンクをすべて開くからです。そこでもう 1 クリックで対応完了です。開いているお客様のリクエストを追跡して対応済みにする をご覧ください。
一度だけ試してみる：テストでも本物の通知が送られます
エージェントのテストページや 音声を試す での会話も、ほかと同じように Live で検知されます。通知ワークフローは本物として動きます。メールは実際のアドレスに届きます。Live の動きを一番早く確認できる方法なので、一度試してみてください。
そのあとのテストを通知から外すには、Octo に頼みます：
本物の会話だけ通知して。会話の出所でのフィルタが追加され、テストページ、音声を試す、テストバッチからの会話は、もう通知を動かしません。テスト会話のリクエストは、受信箱には引き続き表示されます。
緊急用ではありません
Live のカードにはどれも、「Alerts can be delayed or missed. Not for emergencies.」 という行が付いています。これは文字どおりの意味です。通知は、ワークフローが送る 1 通のメールです。メールは遅れることも、フィルタに引っかかることも、読まれないこともあります。
緊急に関するフィールドでは、確認ダイアログがもう一度それを伝え（「Email alerts can be missed or delayed; they are not an emergency service.」）、エージェント用に別の行を提案します：
If the customer describes an emergency, tell them to call 911 or their local emergency number now. Don’t say that the team has been told.
動物病院なら、緊急対応の動物病院の名前に書き換えたうえで、そのまま残してください。Live は、リクエストをチームへ早く届けます。それでチームが緊急サービスになるわけではなく、お客様にそう思わせてはいけません。
Live をオフにする
スイッチを戻し、「Turn off Live」 で確定します。エージェントは、会話の最中にこのフィールドを検知しなくなります。会話の終了後に見つかる方式へ戻るので、通知は遅れて届くようになり、同じ会話の中での繰り返しのリクエストは、再び通知しません。すでに開いているリクエストは、誰かが対応済みにするまで開いたままです。
次に読む
- 開いているお客様のリクエストを追跡して対応済みにする — 受信箱側の話。対応待ちの会話の見つけ方と、各リクエストの締め方。
- 対話インサイトを設定する — Live スイッチが付くフィールド。