AIでSaaSカスタマーサポートを自動化する方法

SaaSサポートが特殊な理由

私はeeselでAIサポートエージェントを構築しており、ここ数年、それらが実際のサポートキューで本番稼働していく様子を見てきました。SaaSは、読者自身のプロダクトそのものが質問の対象になる業種であり、それが問題の形を変えます。

SaaSサポートを特別なものにする理由は2つあります。第一に、質問が技術的でバージョン固有だということです。「なぜ私のAPI呼び出しは403を返したのか」「新しいプランにSSOは含まれるか」「これをウェアハウスにどう接続すればいいか」といった具合です。一般論の回答では通用せず、もっともらしいだけの間違った回答はスクリーンショットを撮られて解約検討スレッドに貼られます。第二に、あなたのナレッジは散らかっていますが、それはチームがずさんだからではありません。本当の答えは、一部はヘルプセンターに、一部は3週間前のSlackスレッドに、一部は古いマクロに、そして一部はその機能を出荷したエンジニア一人の頭の中にあります。マーケティングサイトしか読まないサポートAIは、それらすべてを自信満々に見逃します。

また、SaaSチームには他のどの業種よりも強く「自分たちで作るか、買うか」という誘惑がのしかかります。なぜなら、あなたには作ることができてしまうからです。私たちが一緒に仕事をしているあるチーム、GENERAL BYTESは、そのトレードオフをはっきりと言い表しています。

「自分たちでLLMアプリケーションを書こうとすることもできましたが、そこに時間を投資したくはありませんでした。メンテナンスする必要のないものが欲しかったのです。」

Karel、GENERAL BYTES

それが正直な見立てです。ドキュメントにRAGパイプラインを配線するのは週末でできるデモですが、プロダクトが毎週リリースされる中でそれを正確に保ち続けるのは、あなたが予算を組んでいなかったフルタイムの仕事です。

ステップ1:キュー全体ではなく、ティア1の対応を選ぶ

最もよくある間違いは、初日からAIをすべてのチケットに向けてしまうことです。やめましょう。安定した、ドキュメント化された答えのある繰り返しチケットから始めてください。そここそがAIチケットデフレクションが安全かつ大量に効くところだからです。

ほとんどのSaaSチームにとって、自動化しても安全なリストは次のようなものです。パスワードとログインのリセット、「Xのやり方は?」といった機能に関する質問、プランと請求の基本、そしてよくあるインテグレーションの設定手順です。人間に残しておくべきなのは、答えが変わりうるものや、実際の影響があるものです。バグ報告、障害、返金・ダウングレードの依頼、セキュリティやデータアクセスに関する依頼などです。

この線を最初に引いておく意味は、それが後のエスカレーションルールにもなるという点です。チケットがバグ、障害、請求に関する紛争のにおいがする場合、AIの仕事はそれを見分けて素早く引き継ぐことであり、自分でやってみることではありません。最初の対象範囲の選び方については、ティア1デフレクションのプレイブックでさらに詳しく解説しています。

ステップ2:ナレッジを、すべて接続する

これはSaaSサポート自動化が実際にうまくいくかどうかを決めるステップであり、多くのチームが投資を惜しんでしまう部分です。AIはあなたが与えたものからしか回答できないので、やるべきことは、優れた人間の担当者なら手を伸ばすであろうものすべてを与えることです。

それは公開のヘルプセンターだけにとどまりません。あなたのナレッジベースとドキュメント、解決済みの過去のチケット(実際の言い回しに対する実際の回答を示す、あなたが持つ最も豊かなソースです)、社内のSlackチャンネルとWiki、そして先週何がリリースされたかをAIが把握できるようにするプロダクトの変更履歴も含まれます。私たちが話を聞いたあるB2B SaaSチームは、まさにこれを求めていました。回答時にユーザーガイド、Slack、社内KB、過去のチケットを横断的に参照し、見つけたギャップをフラグ立てして誰かが不足している記事を書けるようにするAIです。

自分で構築する代わりにツールを使う実践的な理由はこうです。eesel AIはヘルプデスク、過去のチケット、そしてConfluence、Googleドキュメント、Slackなど100を超えるソースに数クリックで接続でき、それらを同期し続けます。プロダクトが変わるたびにドキュメントを手動で再インデックスするような事態は避けたいはずです。

ステップ3:すべての回答を根拠づけ、引用元を示させる

信頼できるサポートAIと、負債になってしまうサポートAIを分けるのは、この精度に関する規律です。AIが出すすべての回答は、検証済みのナレッジに根拠を持ち、元のドキュメントへの引用元を伴うべきです。「モデルは答えはXだと考えている」ではなく、「答えはこれで、その出どころはこのヘルプ記事です」ということです。

ここから2つのことが導かれ、どちらもSaaSにとって重要です。まず、AIが一般的な学習データから技術的な質問に答えるのを防げます。これこそが、存在しない機能をでっち上げてしまうハルシネーションの原因です。そして、間違った回答を目に見えるナレッジギャップに変えます。AIが根拠のある回答を見つけられない場合、それは不足しているドキュメントを書くべきだというサインであり、顧客が最初に発見してしまう静かな失敗ではありません。ルールベースのチャットボットにはこれができません。だからこそ、決定木型のボットは実際のプロダクトに関する質問に対してもろく感じられるのです。

これを正しく行っているチームは、対応範囲についてのシンプルな真実を受け入れているチームです。あるサポートリーダーはこう言い表しました。

「AIが質問の100%に答えられるようになることは決してありません。私が必要としているのは、自信を持って処理できるチケットだけを扱い、それ以外はすべて手を出さずにおくAIです。」

あるSaaSサポートリーダー

それがすべてです。根拠のあるところでは高い自信を持ち、それ以外のところではきれいに引き継ぐこと。

ステップ4:信頼度ベースのルーティングとエスカレーションを設定する

グラウンディングはAIに何を言うかを教え、ルーティングはAIにいつ止まるかを教えます。AIには、自信があり回答が根拠づけられているときに自動返信させ、そうでなくなった瞬間、あるいはチケットがステップ1で決めた「人間に残す」カテゴリのいずれかに該当した瞬間に、人間へエスカレーションさせたいはずです。

優れたAIチャットエスカレーションは、単に「受信トレイに送る」だけではありません。会話全体、顧客のプランとアカウントの文脈、そしてAIがすでに確認したソースを引き継ぐので、人間は顧客にもう一度説明させることなく、スレッドの途中から対応を始められます。SaaSのキューでは、ルーティングを実際の組織構造に合わせて配線しましょう。バグ報告はエンジニアリングのトリアージへ、請求に関する紛争は財務へ、エンタープライズアカウントは担当のCSMへ、といった具合です。ワークフローのパターンについては、チケットエスカレーションガイドで扱っています。

ここは、SaaSサポートが単なるコストではなく、静かに成長のレバーになる場面でもあります。私たちが一緒に仕事をしているあるチームは、新規作成されたアカウントからのチケットを「まだ使い方に慣れていないユーザー」の可能性が高いとしてフラグを立ててオンボーディングに回し、有償サービス層に該当するような手間のかかるチケットを見つけ出すことをAIに求めていました。ティア1を自動化することで、人間はまさにそうした拡張につながる業務に集中できるようになります。

ステップ5:本番稼働前に、実際の過去のチケットでシミュレーションする

AIをオンにしてライブで様子を見る、という形でローンチしてはいけません。すでに解決済みの直近数千件のチケットに対して、非公開の環境で実行することでローンチしましょう。これは「準備ができていると思う」を、数字に変えるステップです。

良いシミュレーションは、過去の会話をAIに再生させ、AIが何と言っていたはずかを示してくれます。これにより、実際の解決率を測定し、AIがどのチケットで間違えていたはずかを正確に把握し、顧客が1人も関わる前にコストを予測できます。これはSaaSにとって二重に重要です。私たちが一緒に仕事をしたあるヨーロッパのチームのバイヤーは、社内のISOセキュリティレビューによって足止めされており、AIが本番環境に近づく前に、承認済みのナレッジのみから回答していることの証明を必要としていました。

シミュレーションの結果、AIがティア1の45%をきれいに解決し、特定のトピックでつまずくとわかったなら、それは贈り物です。そのトピックについてドキュメントを修正し、誰にも見られる前に再実行できます。そのドライランで適切なカスタマーサービス指標を追跡することが、正直な本番稼働の目標を設定する方法です。

ステップ6:狭い範囲でまず本番稼働し、そこから広げる

本番稼働する際は、対象範囲を絞り込んでください。1つのチャネル、検証済みのティア1トピックのみとし、それ以外はすべて完全にエスカレーションします。1〜2週間、実際の数字を見守り、ライブトラフィックが浮き彫りにしたギャップを修正してから、トピックを1つずつ広げていきます。

ここが、成果が表れてくる流れです。モビリティデータ系SaaSのGridwiseは、AIが最初の月にティア1リクエストの73%を解決し、7日間のトライアル中に成果が見えたと報告しています。そして、もう少しソフトな成果も本物です。Yellowdigのカスタマーサクセス担当の新人はこう表現しました。

「ベンダーとの関係というより、パートナーシップのように感じます。新しく入ったカスタマーサクセス担当は、eesel AIボットがオンボーディング期間中の親友だったと冗談を言っていました。」

Jon Miron、Yellowdig

eesel自身の顧客基盤全体でも、このパターンは大規模に現れています。160のアクティブアカウントにわたる約183,000件のやり取りのうち、そのほとんどが人間の手を一切介さないティア1の対応です。

よく見かける間違い

SaaSの導入では、いくつかの罠が何度も繰り返し登場します。

• 海を沸かそうとすること。 初日からすべてのチケットタイプを自動化すれば、公の場での間違った回答は確実に起こります。検証済みのティア1の対応から始めましょう。
• マーケティングサイトしか与えないこと。 AIが過去のチケットや社内ドキュメントを読めなければ、実際の質問には答えられません。すべてを接続しましょう(ステップ2)。
• 引用元がないこと。 根拠づけなしに技術的な質問に答えるAIは、いずれ機能をでっち上げます。ソースへのリンクを必ず示させましょう。
• シミュレーションを飛ばすこと。 何も検証せずに本番稼働するということは、顧客にQAをやらせるということです。まずは過去のチケットで実行しましょう。
• 料金体系を後回しにすること。 解決件数ベース、会話件数ベース、チケット件数ベースの課金は本当に異なるものであり、SaaSのボリュームではその差が実際のお金になります。契約する前に、AIと人間のコストの計算を読んでおきましょう。

SaaSサポートにeeselを試す

SaaSサポートキューを自動化しようとしているなら、eesel AIはまさにこの形の問題のために作られています。既存のヘルプデスク(Zendesk、Freshdesk、Frontなど)に組み込め、過去のチケット、ドキュメント、Slackから数分で学習し、実際のチケット履歴でシミュレーションすることで、本番稼働前に解決率を把握できます。料金体系は席数課金なしの従量課金制で、1チケットあたり約0.40ドルなので、コストは実際に自動化した分だけに応じて変わります。

これが特にSaaSにフィットする理由は、その制御性にあります。引用元付きの根拠ある回答、信頼度ベースのエスカレーション、そして自社の履歴に対するドライラン。これにより、間違った回答について怒った顧客から知らされるということが決してなくなります。