AIベンダーの切り替えが引き継ぎの問題である理由
私はeeselでAIエージェントを作っており、「別のAIに移りたい」という相談に呼ばれることがよくあります。「AIが悪い」から始まる相談はほとんどありません。今年のeeselの営業通話では、Zendeskを使うあるEC事業者がネイティブAIを試して「高すぎるうえに性能が足りない」と判断し、「昨日にでも」切り替えたいと言っていました。ハードウェアのサポートチーム(月約250チケット、4言語、こちらもZendesk)は、ベンダーが事業の進め方を変えたため、AIツールから離れざるを得ませんでした。どちらも日付を自分で選んだわけではありません。ほかの誰かが決めたのです。
こうなると、人は慎重にやるべき部分を飛ばします。期限が昨日だったり、ベンダーに決められたりすると、一括切り替えが早い選択肢に見えます。ですが、たいていそうではありません。壊れるのは新しいAIの回答ではなく、自分が会話の担当だと互いに思い込んでいる2つのシステムの間の引き継ぎだからです。eeselは長年、本番のサポートキューにAIエージェントを導入してきました。そして、自信ありげなボットが実際の顧客に誤った回答をするのを見てきたため、すべての導入を、公開前に過去のチケットでシミュレーションしています。それでも、切り替えで起きる問題の大半は配管の問題です。1つのチャットに2つのボットが返信する、チケットが二重に作られる、履歴が移っていない、といったことです。
そこで、頭に置いておきたい捉え直しがあります。あなたはAIを移しているのではありません。ルーティングの判断を移しているのです。旧環境が残っている限り、一部ずつ、行ったり来たりしながら移せます。このガイドは、私が実際にやる順番で進めます。各ヘルプデスクの標準機能は、2026年10月20日時点で各ベンダーのドキュメントと照合しています。棚卸し、本番外での構築とテスト、シャドウ、パイロット、拡大の順で、対応中チャット、チーム、ロールバックの発動条件、契約日も並行して扱います。
関連する2つの記事が、ここでは繰り返さない部分を扱っています。ヘルプデスク内蔵のAIの上にサードパーティAIを載せるかどうかをまだ検討中なら、AIレイヤーと内蔵AIを読んでください。パイロットの週ごとの進め方が知りたければ、AIサポートのパイロットの進め方にあります。
ステップ1:旧AIが行っていることと、移行できるものを棚卸しする
まず、旧AIが行っていることをすべて書き出します。誰も設定したことを覚えていないものも含めます。次に、リストを2つの山に分けます。ヘルプデスク内にあるもの(エクスポートで移せる、またはそのまま残る)と、AIベンダーの内部にあるもの(作り直しが必要)です。後者についての正直なまとめは、ナレッジは持ち運べるが、設定は持ち運べないということです。
私なら次の仕分けから始めます。各ヘルプデスクのドキュメントが、データの取り出しについて述べている内容も付けてあります。
| 持っているもの | 移行できるか | ベンダーのドキュメントの記載 |
|---|---|---|
| ヘルプセンターの記事などのナレッジ | はい、たいてい簡単な部分 | ヘルプデスクに残るため、ヘルプセンターを読む新しいAIならエクスポートは不要です。GorgiasはKnowledgeページで、AI向けのコンテンツをオン/オフできます |
| マクロ | はい | Gorgiasは名前、本文、タグ、idの列付きでマクロをCSVにエクスポートします。Zendeskについてはマクロのエクスポートを参照してください |
| チケット履歴 | はい、ただし制限あり | Zendeskはチケット、ユーザー、組織をエクスポートでき、形式はJSON、CSV、XMLですが、アカウントオーナーがZendeskサポートに有効化を依頼する必要があり、エクスポートツールはTeamプランにはありません(REST APIはあります)。Gorgiasはチケットをエクスポートでき、CSVで1ビューあたり最大100万件です |
| フロー、インテント、プロンプト | いいえ | 作り直しです。同じベンダー内でも起こります。Zendeskの移行ガイドは、AI agents - Essentialや従来のボットビルダーから新しい体験に移る場合、エージェントの作り直しが必要になることがあり、チャネルごとに別のエージェントになると述べています |
| アクションとAPIフック | いいえ | 作り直したうえで、各接続を再認証します |
| 自動返信、ウェルカムメッセージ、ルール | いいえ | 今のうちにリスト化してください。残ったルールが新しいAIと並んで返信してしまうことがあります。ステップ4で、それぞれ意図的にオフにします |
| ボットだけの会話ログ | 解約前に確認 | Zendeskのエクスポートページには、AIエージェントチケットはそのツールではエクスポートできないとあります。旧ベンダーに、何をいつ渡してくれるか確認してください |
| ベースライン数値 | 自分で記録する必要あり | 誰も代わりにエクスポートしてくれません。切り替え後ではなく、ステップ1で取得してください |
最後の行が忘れられがちです。何かを変える前に旧AIの数値を記録しておかないと、新しいAIを記憶と比べて評価することになります。移行予定のチケット種別について、直近8〜12週間のデータを取得してください。解決率(旧ベンダーの数え方に合わせたもの)、引き継ぎ率、7日以内の再問い合わせ、初回返信時間、CSATです。ベンダーによって「解決」の定義が異なるため、定義を選ぶ前にAIの解決率のガイドとカスタマーサービスKPIの一覧を読むことをおすすめします。
もう1つ、効果のある棚卸しの習慣があります。旧AIの振る舞いを、単純なルールとして書き出すことです。何を断るか、いつ引き継ぐか、どんなトーンを使うか、どの話題には決して触れないか。それらの文が新しいAIへの指示になり、設定のうち実際に引き継げる部分になります。新しいAIに読み込ませる前に、ナレッジベースも整理したいなら、ナレッジベース監査が最も安上がりな1週間になります。
ステップ2:本番に触れずに新しいAIを構築してテストする
新しいAIは本番外で構築し、顧客に届かない場所でテストします。主要なヘルプデスクはどれもそのための場所を用意しており、多くは無料です。
- Zendesk: サンドボックスでのテストは自動解決を消費しません。テスト用ウィジェットや会話シミュレーターも同様ですが、本番でのテストは消費することがあります。また、フローを作っていない人にテストしてもらうことをZendeskは勧めています。設定方法はサンドボックスと本番のガイドにあります。
- Freshdesk: Email AI AgentにはEvaluateタブがあり、テストセットを手作業で作る、サンプルメールを生成する、または解決済みの過去チケットをインポートできます。Freshdeskはデプロイ前に代表的なクエリを少なくとも20件用意することを勧めており、プレビューは進行中の会話に触れません。Freshdeskのサンドボックス設定も参照してください。
- Gorgias: Playgroundでのテスト会話は課金されず、購入者に実際のメッセージも送られません。
- HubSpot: カスタマーエージェントにはバッチテストがあり、各回答を良い・悪いで評価します。
これらのツールは各ベンダー自身のAIをテストするものなので、新ベンダーのAIは新ベンダーのツールでテストすることになります。私なら、両方のAIが回答する共通のテストセットを加えます。最初に移すレーンの実際のチケットを約50件、種別でラベル付けして用意し、厄介なものも含めます(怒っている顧客、ドキュメントが誤って答えてしまう質問、人に回すべき依頼)。新旧のAIが同じ50件に答えれば、違いは意見ではなくなります。AIサポートエージェントのテストのガイドに完全なテスト手順があり、敵対的テストには借りられる難しいチケットが載っています。
ここで、eeselのシミュレーションが役に立ちます。チャットで直近のチケットに対するシミュレーションを依頼すると、それらを再現し、チームが実際に送った内容と比べて回答を採点し、差分を一覧にして、指示の変更案を出します。解決率やコストの予測はしませんし、顧客が1通も回答を見ていない段階でそれをするツールは信頼できません。ただ、どのチケット種別が準備できているかは、午後の数時間でわかります。
ステップ3:段階的に切り替える。シャドウ、パイロット、拡大の順
ほぼすべての導入プレイブックが一致する部分です。日付を決めるのではなく、段階的に切り替えます。新しいAIがまだ実力を示していない分は旧AIが引き続き回答し、その割合を段階的に引き上げます。
| フェーズ | 新AIの役割 | 旧AIの役割 | 次に進む条件 |
|---|---|---|---|
| シャドウ(約1週間) | 下書きまたは社内メモのみ。顧客には何も届かない | 全員に回答 | レーンの下書きが、チームの送信内容と概ね一致し、誤ったアクションを提案する下書きがない |
| パイロット(約2週間) | 1つのチケット種別の5〜10%に回答 | 残りに回答 | パイロットが、書面にした合格ラインを満たす(パイロットのスコアカードにコピーできる基準があります) |
| 拡大(2〜3週間) | 25%、次に50%、次に100%。各段階でチャネルまたはチケット種別を追加 | 段階ごとに縮小 | 段階ごとに変更が1つで、数値が維持された |
| ロールバック期間(約4週間) | 新規会話の100% | 設定は残すが、新規チャットはオフ | ロールバックの発動条件が発動しなかった(下記参照) |
1つのチケット種別の5〜10%という大きさを私が選ぶのには理由があります。傾向が見えるだけ大きく、誤った回答が届くのがキューの半分ではなく少数の顧客で済むだけ小さいからです。そして、数値を読み取れる状態に保つルールが1つあります。変更は一度に1つにして、日付を記録することです。同じ日の午後に範囲の拡大と新しい指示を入れると、何が結果を動かしたのかわからなくなります。
どう割合を振り分けるかはヘルプデスクによって異なります。各ベンダーのドキュメントが示している内容は次のとおりです。
| ヘルプデスク | 一部を1つのAIに振り分ける | 旧AIをオフにする |
|---|---|---|
| Zendesk | AIエージェントごとにチャネルを選びます。1つのチャネルで有効にできるAIエージェントは1つだけです。A/Bのトラフィック分割はありますが、アカウントマネージャーによる有効化が必要です | Manage channelsでチャネルのチェックを外し、もう一方を有効にする |
| Freshdesk | チケットソース(メールボックス、ポータル、フォーム)ごと。「Deploy to internal team」と「Deploy with custom rules」の戦略があります | 新しいエージェントを割り当てる前に、そのソースの既存エージェントを無効にする。デプロイは即時で、新しいチケットのみが対象 |
| Gorgias | Deployでチャネル(メール、チャット、SMS、SNSのDM、WhatsApp)ごとにAI Agentを有効にし、「Prevent AI Agent from answering」ルールでタグ、送信者、キーワードによってチケットを除外する | チャネルのON/OFFトグルを切り替える。除外されたチケットにはai_ignoreタグが付く |
| HubSpot | チャネルのデプロイで、会話のカバー率、稼働時間、含める/除外する連絡先リストを設定 | Account and Billingでエージェントをオフにするか、チャネルから外す |
上のZendeskのダイアログは、すべてを左右する制約を示しています。1チャネルにつきAIエージェントは1つです。旧AIがZendesk自前のもので、新AIがサードパーティのレイヤーなら、チャネルで分けるか、サードパーティのレイヤーがフィルタできるタグやキューで分けることになります。Zendeskの標準機能が制御できるのは、Zendesk自前のAIだけだからです。両側から見える分割ルール(チャネル、タグ、キュー、顧客リスト)を選び、計画に書き込んでください。
Luxedoのカレンダーは、他のAIを置き換えるものではありませんでしたが、私ならこれを真似します。プロジェクターメーカーのLuxedoは、2026年7月にGorgiasをeeselに接続し、8月はナレッジと指示の構築に使い、8月最終週にチケットのトリガーをオンにしました。eeselは返信の下書きと要約を付けた社内メモを残し、人が送信します。8月8日から9月8日の間に、21件のチケットを準備しました。誰も何にも驚きませんでした。それこそが、段階的な拡大の狙いです。
ご自身の計画用のプランナーをご用意しました。開始日とフェーズの長さ、旧契約の更新日と解約予告期間を入力してください。カレンダーを組み立て、解約予告の期限がパイロットのgo/no-goの前に来るか後に来るかを表示します。ここが意外と見落とされます。
ステップ4:サードパーティのボットが絡む場合の重複チケットを止める
旧AIか新AIのどちらかがZendesk上のサードパーティのボットである場合、避けて通れないルール変更があります。Zendeskの告知によると、2026年5月4日から、エスカレーションされた会話だけでなく、ボットが対応するすべての会話に対してAIエージェントチケットが強制され、AIエージェントとサードパーティのボットが対応する会話の唯一のチケット作成の仕組みになります。ボットがボットだけのチャットで独自にチケットを作る設定のままだと、1つの会話に対してチケットが2枚できます。
告知は3つのことを求めており、私は旧ボットにも新ボットにも使えるチェックリストとして扱います。
- チケット作成を点検する。 ボットプラットフォームの「チケット作成」アクションと、ボットのイベントからチケットを作るカスタムwebhookを探します。解決済みチケットにメタデータを付けたい場合、ZendeskはreleaseControlアクションを勧めています。
- テストして周知する。 変更が本番に届く前にサンドボックスで連携を試し、チームにAIエージェントチケットの形式を見せます。
- 旧来の経路を無効にする。 重複する手動のチケット作成をすべてオフにします。
Zendeskは安心材料を1つ付け加えています。サードパーティのボットとのやり取りには自動解決の課金が発生しないため、これらのチケットは請求ではなく可視性を増やします。ただし、容量は消費します。AIエージェントチケットはストレージ上限に算入され、ほとんどのユーザーには読み取り専用で、会話が人にエスカレーションされるまでトリガーやオートメーションは作動しません。これが管理者の席からどう見えるかを、私がこの記事を書く数日前に投稿されたスレッドから紹介します。
"The main issue is that there appears to be no way to disable Zendesk from creating an AI Agent ticket for EVERY SINGLE interaction an end user has with the bot, not just handoffs."
同じスレッドの返信が、実務上の利点をうまく言い表しています。
"Luckily they’re easy to exclude from reports and views, but definitely annoying to parse through when you need to find something."
その裏にある仕組みがZendeskのswitchboardで、これを理解しておくと、重複によるバグのほとんどを防げます。各会話には、一度に有効なswitchboard連携がちょうど1つだけあり、ほかは待機状態です。したがって並行運用中に「両方のボットが同じチャネルで稼働している」とは、各会話をどちらか1つのボットが担当し、新しい会話をどちらが受けるかは既定の応答者が決める、という意味です。知っておくべき落とし穴が1つあります。会話で有効だったswitchboard連携を削除すると、新しいメッセージはpassControl webhookなしで既定の連携に再割り当てされます。旧ボットは、その対応中の会話が閉じてから削除してください。それより前に消してはいけません。switchboardのオーケストレーションのガイドでさらに詳しく扱っています。
ほかのヘルプデスクでも、同じ原則が別の言葉で現れます。Freshdeskでは各チケットソースに有効なAIエージェントを1つ持たせることができ、2つ目を割り当てようとすると競合として警告されます。解決策はどこでも同じです。1つの会話に1つの担当、それを自分で書いたルールで決めることです。また、重複はチケットだけではありません。たとえばGorgiasは、チャットでAI Agentが稼働すると、Article Recommendationsを自動的にオフにし、購入者に2通のメッセージが届かないよう、カスタムの自動返信ルールを見直すことを勧めています。旧来のウェルカムメッセージと自動返信はステップ1でリスト化しておき、意図的にオフにできるようにしてください。
ステップ5:両方を並行して動かし、同じ条件で比較する
パイロットと拡大の序盤では、2つのAIが別々の割合で稼働します。これを活用してください。最も役に立つ比較は、新しいAIと前四半期の比較ではなく、同じ週の同じチケット種別での新旧AIの比較です。季節要因、製品ローンチ、価格変更は、両方に等しく影響するからです。
拡大の間は、パイロットが人間のみの対照キューを残すのと同じように、旧AIにホールドアウトを残してください。ZendeskのA/Bのドキュメントでは、最初のグループが対照群になっており、サイズの決め方はパイロットガイドで説明しています。そのうえで、両側で同じ定義にした4つを比較します。
- 解決: AIが7日以内の再問い合わせなしでクローズした会話。ベンダー独自の解決フラグではありません。
- 引き継ぎ率と品質: どれくらいの頻度で引き継ぐか、受け取った担当者が聞き直す必要があるか。
- 再問い合わせとCSAT: 同じ問題で戻ってくる顧客と、そのやり取りへの評価。
- 対応した会話あたりのコスト: ベンダーごとに課金の単位が異なるため、どちらも、チームが本来対応していたはずの会話あたりのコストに換算します。
最後の項目は、課金単位が大きく異なるため間違えやすい部分です。Zendeskは自動解決に課金し、HubSpotのエージェントはHubSpotクレジットで動き、FreshdeskのFreddyには独自のセッション課金があります。比較を作る前に各ベンダーの最新の料金ページを確認し、定義をそろえるためにCX向けAI指標のガイドを使うことをおすすめします。
ステップ6:すでに進行中の会話を守る
この節は2回読むことをおすすめします。午後2時55分に旧AIとのチャットを始めた顧客が、設定を切り替えたからという理由で午後3時に別のAIに引き渡されてはいけません。ルールはこうです。新しい会話は新しいAIに振り分け、対応中の会話は始まった場所で完了させる。
ベンダー自身の挙動も、おおむねこのルールと一致しているため助かります。
- HubSpot: カスタマーエージェントをオフにしても、会話が解決されるまで既存のスレッドの対応を続けますが、新しいスレッドは受けません。
- Freshdesk: デプロイは即時で、新しいチケットのみが対象です。それ以前に届いたチケットには遡って回答しません。
- Zendesk: メッセージングのAIエージェントチケットは、応答なしで4日が経過する、AIが制御を手放す、または(サードパーティのボットでは)ボットが解決済みと判断するまで、対応中として扱われます。
次に、AIと担当者の間の引き継ぎと引き戻しです。これは多くのチームの想定とは異なる動きをします。Zendeskのメッセージングでは、エージェントはチケットがクローズされるまで最初の応答者のままです。引き戻しが起きるのは、チケットが解決済みからクローズに移ったときだけで、既定ではそれに4日かかります。つまり、その期間内に戻ってきた顧客は、AIではなく、担当者との旧来の会話に入ります。「解決の4日後にチケットをクローズ」というオートメーションは、1時間に短縮することも28日に延ばすこともできますが、CSATを使う場合は、チケットが解決済みに設定された瞬間にアンケートが送られるため、少し余裕を持たせてください。切り替え中は、これが特別な意味を持ちます。戻ってきた顧客に誰が回答するかは、AIの設定ではなく、このタイマーで決まります。
Gorgiasには別の引き継ぎ制御があります。常にエスカレーションするトピック、引き継ぐことをメールやSMSで顧客に伝えるかどうかのトグル、そしてチャットでは引き継ぐ前の確認ステップです。どのヘルプデスクを使う場合でも、顧客が同じ説明を繰り返さずに済むよう、新しいAIの引き継ぎが担当者に必要なコンテキストを渡せることを確認してください。良い引き継ぎに何が含まれるかは、AIエージェントの引き継ぎのベストプラクティスのチェックリストとZendeskの引き継ぎガイドで扱っています。
この「尾」はどれくらい続くのでしょうか。ご自身のデータを確認してください。AIが対応したチャットは、クローズするまでどれくらい開いたままですか。現実的な最長の継続時間は何ですか。その数字が、新しいAIがすべての新規会話を引き受けた後、既存のチャットのために旧AIをオンにしておく期間です。
ステップ7:最初の本番稼働日の前にチームに周知する
問題に最初に気づくのはエージェントです。また、知らせなければ、切り替えを怒った顧客から知らされる可能性が最も高いのも彼らです。シャドウを始める前に、1ページのプレイブックを渡してください。私のものは6行です。
- 何がいつ変わるか。 フェーズのカレンダーを平易な言葉で、各チケット種別が移る日付とともに示します。
- その中での役割。 彼らはレビュアーです。1日15分、前日のAIの会話を読み、誤ったものにタグを付けて報告します。
- 見え方がどう変わるか。 Zendeskでは、AIエージェントチケットはほとんどのユーザーに読み取り専用で、エスカレーションされたものはNewとして戻ります。ほかのヘルプデスクでは、新しいAIが残すラベルやメモです。
- 引き継ぎ時にすること。 誰が引き取るか、コンテキストはどこにあるか、「ボットと話していたのですか?」と尋ねる顧客に何と答えるか。
- 悪い回答の報告方法。 タグ1つ、チャネル1つ、当日中に返答。
ai_oldとai_newのようなタグの規則があると、ステップ5の比較が可能になります。命名のアイデアはAIサポートのタグ付けにあります。 - 誰がいつ一時停止できるか。 各シフトに1人を指名します。
営業通話で最もよく聞くパターンは、チームがまずコパイロットを望み、完全な自動化は後にしたいというものです。AIがエージェント向けに返信を下書きし、信頼ができてから昇格します。これは切り替えにぴったり合います。シャドウモードがまさにそれだからです。レビューの手順をサポートのSOPに書き込み、ポリシー変更のプロセスをそれに結び付けておけば、新しい返品期間が、3週目に新AIの誤った回答に気づかないうちに変わってしまうことを防げます。
ロールバックの発動条件。開始前に書き出す
誰も動揺していないうちに、何をもって失敗とするか決めておきましょう。インシデントの最中に発動条件を書く人は、自分を納得させて発動しないことが多いものです。私が出発点にする表がこちらです。しきい値は私自身の出発点なので、ご自身のボリュームに合わせて調整してください。
| 発動条件 | どう気づくか | 対応 |
|---|---|---|
| 誤ったアクションが顧客に届く(返金、キャンセル、アカウント変更) | 毎日のレビュー、または顧客からの苦情 | そのアクションを当日中に停止し、修正されるまでそのレーンは下書きのままにする |
| AIが存在しないポリシーや価格を述べる | 毎日のレビュー | そのトピックを停止し、元の記事を直して再テストする |
| 担当者への要望が旧AIのベースラインを超えて急増する | 引き継ぎ率、または「エージェント」「人間」といった表現 | 割合を絞り、引き継ぎのトピックを確認する |
| 7日以内の再問い合わせが、旧AIのベースラインを3ポイント以上上回る状態が2日続く | 再問い合わせレポート | その割合を旧AIに戻し、エラーを分析する |
| AI対応の会話のCSATが旧AIの割合と比べて大きく低下する | タグ別のCSAT | 拡大を止め、低評価の会話を読む |
「ロールバック」は、設定を切り替えることを意味するべきで、何かを作り直すことではありません。だからこそ、旧AIはロールバック期間中も設定したままにします。停止のレバーは1つのトグルです。Zendeskならチャネルのチェックを外す、Freshdeskなら1日あたりの会話上限、Gorgiasならチャネルのトグル、HubSpotならカスタマーエージェントをオフにする、といった具合です。HubSpotには知っておくべき癖が1つあります。カスタマーエージェントは、一度作成すると削除できず、一時停止しかできないため、必要になれば旧エージェントはそのまま残っています。停止はすべて、日付と理由とともに記録してください。停止は切り替えの失敗ではなく、仕組みが機能している証拠です。
契約の重複期間と解約のタイミング
切り替えで最も安上がりな方法は、数週間、2つのAIの料金を払うことです。無駄に感じますが、それでも別の道よりは安く済みます。別の道とは、パイロット開始時に旧AIを解約し、3週目に引き返せないと気づくことです。
お金の面では、3つのルールを守ります。
- ロールバック期間中は旧プランを維持する。 契約がそれより早く終わる場合は、重複期間のために月単位への変更を依頼します。上のプランナーが、何日足りなくなるかを正確に示します。
- 解約予告は自分の注文書で確認する。 自動更新と解約予告期間は契約条件であり、製品ドキュメントではないため、御社のベンダーの条件を私が言うことはできません。ただ、60日の解約予告期間がパイロットのgo/no-goより前に来ることがあり、それは交渉する価値のあるケースだとは言えます。
- 重複期間中の課金単位を把握する。 Zendeskは、サードパーティのボットの会話には自動解決の課金が発生しないとしているため、サードパーティのボットと重複させる費用は、Zendeskの解決ごとの料金ではなく、そのボットのプラン分です。HubSpotのエージェントは、クレジットが尽きると新しい会話に割り当てられなくなります。これは障害のように見える課金上の出来事です。
何かを解約する前に、残したいものをエクスポートしてください。旧ベンダーに、どのデータ(会話ログ、分析、設定)を、解約後どれくらいの期間渡せるかを書面で確認します。そのうえで、プランナーで確認して締めくくってください。解約予告日は、パイロットのgo/no-goの後で、ロールバック期間の内側か後ろに来るのが目安です。
避けたい失敗
- 最も忙しい週に切り替える。静かな時期を選びましょう。5月から運航表が埋まるフェリー会社のNorden-Frisiaは、2月にeeselを試し、その後、季節ごとのボリュームに合わせてプランの規模を決めました。
- 会話の途中でチャットを移す。
- 2つのことを同時に変え、どちらが数値を壊したかで議論する。
- 新しいAIを、旧AIの同時期の割合ではなく、前四半期と比較する。
- パイロットが「順調そう」だからと、開始時に解約する。
eeselが切り替えにどう対応するか
私は当事者なので、eeselが向いている点と向いていない点を率直に書きます。eeselは、すでにお使いのヘルプデスクに接続するAIヘルプデスクのチームメイトなので、切り替えのためにチケットをどこかへ移す必要はありません。ヘルプセンター、マクロ、過去のチケットをヘルプデスクから直接読み取るため、旧AIから何もエクスポートする必要がありません。最もよく有効にされる連携は次のとおりです。
これは上のステップに対応しています。
- 移行しやすさ: マクロは、お持ちの資産の中で最も持ち運びやすいものです。Freshdeskを使うスイスのスーツケース販売店Koffer.chは、まずマクロを読み取り、顧客が書いた4言語のどれであっても、一致するマクロを一語一句そのまま使います。すべての返信は、人が送信する下書きです。
- 学習とテスト: ドイツのフェリー会社Norden-Frisiaは、2025年2月の1週間のトライアル中にZendeskを接続し、マクロと直近3か月のチケットを取り込み、数日以内に契約しました。本番稼働の前に、シミュレーションが過去のチケットを再現するため、差分を先に確認できます。
- 段階的な導入: eeselを、社内メモでの@eesel メンションのときだけ起動する設定から始め、その後すべての顧客チケットメッセージに広げ、レビュー中は下書きのままにできます。これが、組み込みのシャドウの1週間です。
- 重複期間中の料金: eeselは解決ごとの従量課金ではなく、月額固定のクレジットプランです。チケットまたはチャット1件は、長さにかかわらず1クレジットで、100クレジットのカード不要の無料プランがあり、Teammateは500クレジットで月額299ドルから、すべての連携、エージェント、シートが含まれます。
限界もはっきり述べておきます。eeselは、他ベンダーのフロー、インテント、チケットにならなかった会話ログはインポートしないため、それらは指示として作り直すことになりますが、多くのチームにとって、元の構築よりも時間はかかりません。また、ヘルプデスクがすでに備えているAIだけで十分なら、レイヤーはまったく不要です。トレードオフの所在は、Freddy、Gorgias AI Agent、HubSpot Breezeの比較ページで確認できます。
eeselを試す
Zendesk AI agents、Freddy、Gorgias AI Agent、HubSpot Breeze、またはサードパーティのボットから移るなら、まずご自身のキューでeeselを試してください。ヘルプデスクを接続し、過去のチケットから学習させ、シミュレーションを実行し、現在のAIが回答を続ける間、下書きで開始します。これがこのガイドのシャドウの1週間にあたり、無料プランでまかなえます。
