チャットボットワークフロー: チケットを解決する設計方法

チャットボットワークフローとは実際には何か

チャットボットを分解すると、残るのは2つだけだ。会話インターフェースと、その下にあって次に何が起こるかを決めるロジックである。そのロジックがワークフローであり、あらゆるカスタマーサービスAIの本当のエンジンだ。Tidioは会話フローチャートガイドの中でそれを率直に述べている。チャットボットとは「会話型ユーザーインターフェースを備えた決定木図にすぎない」と。

それはワークフローの形については正しいが、興味深いのは各ノードの中身だ。ワークフローは単に「ユーザーがAをクリックしたらBに進む」というだけのものではない。優れたワークフローは、見たことのないメッセージを理解し、ナレッジベースから正しい回答を見つけ出し、安全にクローズしてよい質問と絶対に触れてはいけない質問の違いを見極めなければならない。地図を描くこと自体は簡単だ。各ステップの中にある判断こそが、チャットボットワークフローの成否を分ける。

まずは全体像をひと目で見てもらい、そのあと各段階を順に見ていこう。

サポートチャットボットワークフローの6つの段階

ルールベースであれAIであれ、ほぼすべてのサポートチャットボットワークフローは同じ6つの段階を通過する。それぞれに名前をつけることで、自分のワークフローのどこが弱いのかが一目瞭然になる。

1. トリガー。 何かがワークフローを起動する。顧客がチャットバブルを開く、メールを送る、WhatsAppでメッセージを送る、あるいはヘルプデスクに新規チケットが届く、といった具合だ。トリガーには、チャネル、顧客の注文履歴、閲覧していたページなど、後で必要になるコンテキストも含まれる。
2. 意図の理解。 ボットが相手が本当に何を求めているかを把握する段階だ。ルールベースのフローはボタンとキーワードでこれを行うが、AIワークフローは自由記述のテキストを直接読み取るため、「荷物がまだ届かない」も「注文はどこ」も、どちらの言い回しも台本化することなく同じ意図として扱われる。
3. 知識の検索。 ボットがヘルプセンター、過去のチケット、内部ドキュメント、あるいは注文データベースのようなライブシステムから回答を探し出す段階だ。ここはほとんどのデモが省略する段階であり、実際のワークフローの成否がかかる部分でもある。根拠となる情報がないボットは、ただでっち上げるだけになる。
4. 判断と分岐。 意図と回答がそろった時点で、ワークフローは進むべき経路を選ぶ。直接答える、確認の質問をする、行動を起こす、あるいはエスカレーションする、のいずれかだ。ここがワークフローの頭脳であり、確信度チェックが行われるべき場所でもある。
5. 行動を起こす。 単純な質問であれば「行動」とは単に返信することだ。本当の解決のためには、注文の確認、返金の発行、チケットへのタグ付けとルーティング、フィールドの更新など、何かを実行する必要がある。話すことしかできず行動できないワークフローは、偏向(デフレクション)止まりで、決して解決には到達しない。
6. 解決またはエスカレーション。 会話は2通りのどちらかで終わる。ボットが解決するか、完全なコンテキストを添えてきれいに人間へ引き継ぐかだ。顧客を新しいキューに放り込んで一からすべて説明させるような引き継ぎは、引き継ぎではなく罰だ。

図の上ではなく、実際の製品の中で段階2から6がどう見えるかを紹介しよう。顧客が質問し、エージェントが接続された知識から回答し、対応できなくなった瞬間に人間を提案する。

つい最近、あるSEOツールの実際のウェブサイトチャットで、まさにこの流れが展開されるのを見た。ボットはドキュメントに基づいて2つのハウツーの質問に答え、ユーザーが「人と話せますか?」と入力した瞬間、迷わず引き継いだ。この鮮やかな偏向からの引き継ぎこそ、実際の現場で健全なワークフローがどう見えるかであり、目指す価値のあるパターンだ。

ルールベース vs AIエージェントのワークフロー

最も重要な決断は段階の一つではなく、そもそもどちらの種類のワークフローを構築するかだ。この2つはホワイトボード上では似て見えるが、本番環境ではまったく違う振る舞いをする。

ルールベースのワークフローは、手作業で描く決定木だ。予測可能で、考えるコストも低く、3つのボタンの奥にある「注文状況を確認する」のような狭くて件数の多いフローには本当に向いている。落とし穴は台本にないすべての事態であり、その数字は容赦がない。Tidioは、たった7つのはい/いいえの質問からなる「シンプルな」ツリーだけで、すでに128通りの可能性に分岐すると指摘しており、だからこそ彼ら自身のルールは「1つの決定ボットには1つのトピックだけ」なのだ。それを超えると、顧客は想定していなかった何かを入力し、ボットはそれをどこにも送る先がなくなる。おなじみのフローチャートの行き止まりだ。結果として、新しい言い回しが出てくるたびに枝を追加し続ける、絶えず肥大化するツリーを維持することになり、それでも人々が実際に書く言葉のペースには追いつけない。

AIエージェントのワークフローは、この労力を逆転させる。すべての経路をあなたが列挙する代わりに、エージェントが自由記述のテキストから意図を読み取り、知識から回答を取得し、自分の手に負えないと認識することも含めて何をすべきか判断する。もはや枝を描くのではなく、ガードレールを設定するだけでよくなる。

これは「ルールはもう終わった」という主張ではない。多くの優れたワークフローは、決定論的な部分(営業時間や必須の注文番号など)にはルールを使い、あいまいな言語理解はAIに任せている。しかし、顧客が書くあらゆる範囲の内容に対応することを期待してサポートワークフローを構築するなら、純粋な決定木は永遠に足を引っ張り続ける。チームが件数の増加とともに、台本化されたボットから本物のAIエージェントへと移行するのも同じ理由だ。

本当に重要な2つの意思決定ポイント

AIが言語理解を担うようになると、設計作業は2つの問いに収束する。ボットはいつ自分で行動すべきか、そしていつ手を引くべきか、だ。これさえ正しくできれば、ワークフローの残りの部分はほぼ自然と機能する。

キーワードではなく確信度でルーティングする

サポートチームから最もよく求められる制御機能は、確信度ベースのルーティングだ。ボットには確信が持てることだけを処理させ、それ以外には手を出させない。Gorgiasで月間約7,000件のチケットを処理している、あるDTCサプリメントブランドのCXリードは、その恐れを私よりもうまく言い表していた。AIが100%の質問に答えることは決してない、と彼女は語った。もしAIが単に「すみません、わかりません」と返すだけなら、彼女は7,000件のチケットをさかのぼって、それが実際に役立ったかどうかを確認することはできない。彼女が求めていたのは、「確信を持って処理できるチケットだけを処理し、それ以外はすべて手をつけない」AIだった。

これこそが、判断と分岐の段階で確信度をスコアリングする理由のすべてだ。すべてに答えるワークフローは、自信満々に間違えるワークフローでもある。自分自身の確信度をスコアリングするワークフローは、簡単なチケットを自動解決し、中程度のケースでは人間向けに返信案を下書きし、理解できないものには決して手を出さない。

これはハルシネーションに対する最良の防御策でもある。モデルがうまく振る舞ってくれることを祈る代わりに、下限を設定する。しきい値を下回ったら、ボットは送信せずに下書きし、当てずっぽうで答える代わりにエスカレーションする。意図の確信度しきい値は、成熟したツールにおいては抽象概念ではなく実際に調整可能なダイヤルだ。

エスカレーションは後付けせず、設計する

もう一つの意思決定ポイントは人間への引き継ぎであり、これはハッピーパスと同じくらいの設計を必要とする。私は営業電話の中で、ほぼ同じ目標がほぼ同じ言葉で語られるのを何度も耳にする。バス追跡サービスで月間200〜250件のZendeskチケットを扱うあるサポートマネージャーは、「受信するZendeskチケットの60%を処理し、より良い分析と解決のために本物の人間を呼び込むべきタイミングを把握できる」エージェントを求めていた。「本物の人間を呼び込むべきタイミングを把握する」という後半部分こそが重要な部分だ。

優れたエスカレーションは、会話全体、顧客のコンテキスト、そしてボットが推測した問題の内容を、そのまま正しい人間またはキューへと運ぶため、誰も何かを再説明する必要がない。だからこそ、成熟したビルダーは引き継ぎを、実際のペイロードを添えた終端ステップとして扱う。ZendeskのAIエージェントビルダーでは、「エージェントへの転送」は終端ステップであり、顧客には見えない会話履歴全体を静かにチケットとして生成する。eeselも、設定次第で下書きした返信とコンテキストを内部ノートとして残すか、ヘルプデスクへ引き継ぐことで、同じことを行う。

ボットに何を触らせてよいかについても制御したいはずだ。実際のチームはこれを常に求めており(「AIに通したくない特定のチケットがある」)、特定のチケットタイプを除外できない、あるいは明示的に呼び出されたときだけ動くことができないワークフローは、本番のキューに投入する準備ができていない。エスカレーションはフォールバックではなく、れっきとした一つの分岐だ。AIエージェントのエスカレーションについての詳しい解説では、その仕組みをさらに掘り下げている。

よくあるチャットボットワークフローの失敗

壊れたワークフローについては、どんな仕様書よりも顧客の方がうまく説明できる。あるr/automationのスレッドが、その症状を的確に言い当てていた。

"the tells: loop you back to FAQ, ask you to rephrase (3 times), refuse to escalate. the fix isn't a smarter chatbot. it's a chatbot that knows when to hand off."

壊れたワークフローの大半は、同じ一握りのパターンで失敗する。次の点に注意しよう。

• 行き止まり。 ルールベースの定番の失敗だ。「どこか」が人間であってもいいので、すべての経路は必ずどこかへつながっているべきだ。顧客を先に進めない状態で閉じ込める分岐があれば、それはバグだ。
• 自動化のしすぎ。 偏向率(デフレクション数)を追い求めるあまり、ボットにすべてを答えさせてしまうこと。これが、自信満々の誤答が大量に発生する原因になる。ボットには確信が持てることだけをやらせよう。
• 知識の根拠がない。 優れた決定木を持っていても、検索元となる情報がなければボットは即興で答えることになり、その場しのぎのサポート回答こそが、SNSでスクリーンショットを晒される原因になる。すべての回答を実際のドキュメントと過去のチケットに根拠づけよう。
• 後付けのエスカレーション。 顧客がすべてを一から説明し直すことになる、冷たいキューへの引き継ぎ。コンテキストを必ず運ぶこと。
• 検証なしでのリリース。 実際に届くメッセージに対して一度もテストしないまま、ワークフローを本番の顧客に解き放ってしまうこと。これが、最後にして最もよく省略されるステップへとつながる。

本番投入前にワークフローをテストする

ここは、ほとんど誰もやらない部分であり、私がすべてのロールアウトに組み込んでいる理由でもある。顧客と話す前に、実際の過去のチケットに対してワークフローを実行しておくのだ。私はこれを、自信ありげなボットが静かに間違った答えを出しているのを目の当たりにして、痛い思いをしながら学んだ。だから今では、新しいエージェントが最初に行うのはライブの会話ではなく、過去のチケットに対するシミュレーションだ。

シミュレーションは、クローズ済みの何千件ものチケットをワークフローに通し、本番投入前に、ボットが実際に何と答えていたか、何パーセントを解決できていたか、どのテーマに弱いかを正確に示してくれる。そこでギャップを見つけ、不足しているドキュメントを追加し、確信度のしきい値を調整して、再実行する。これによって、「うまくいくといいな」が指し示せる数字に変わる。それはおおよそ、信頼できるワークフローと、毎朝不安になるワークフローの違いに等しい。

テストされたワークフローの成果は、すぐに現れる。Gridwiseでは、eeselが最初の1か月でティア1リクエストの73%を解決し、その結果は7日間のトライアル期間中に確認できた。Smavaは、月間10万件以上のドイツ語チケットに対して完全に自動化されたエージェントを稼働させている。これらの数字はどちらも、運の良いプロンプトから生まれたものではない。リリース前に実際のチケットに対してテストされたワークフローから生まれたものだ。

あなたのチャットボットワークフローにeeselを試してみる

ここまで読んだなら、チャットボットワークフローが要求する作業がわかるはずだ。段階をマッピングし、回答に根拠を持たせ、確信度を調整し、エスカレーションを設計し、すべてをテストする。eeselは、その作業をあなたの代わりに行う。ヘルプデスクとドキュメントを接続すれば、初日から過去のチケットと知識をもとにワークフローを構築し、いつ介入していつどう引き継ぐかを平易な言葉で設定でき、たった一人の顧客の目に触れる前に、過去のチケットに対して全体をシミュレーションできる。

Zendesk、Freshdesk、Gorgias、Slack、Shopify、Confluenceをはじめ100以上のツールと連携し、標準で80以上の言語に対応し、チケット1件あたり0.40ドルの従量課金制で席課金は一切ない。実際に数字を計算してみると、このモデルは人件費よりも安く済むことが多い。ワークフローがあなたのヘルプデスクの中でライブに動く様子は、こちらで見られる。

チャットボットワークフローが自分のキューに合うかどうかを確かめる最も早い方法は、自分のチケットに対して実際に動かしてみることだ。それが無料トライアルであり、クレジットカードは不要で、何かにコミットする前にシミュレーションが実際の解決率を教えてくれる。