Freddy AIのお礼検知機能とは:「ありがとう」でチケットが再オープンするのを防ぐ方法

Freddy AIのお礼検知機能が実際に行うこと

通常のサポートチケットの最後を思い浮かべてみてください。あなたがチケットを解決すると、顧客から「本当にありがとう、それで直りました!」という短い返信が届きます。すると、ヘルプデスクは律儀にチケットを再オープンに戻し、誰かのキューに放り込みます。忙しい1週間でこれが積み重なると、キューは仕事の顔をした感謝の言葉でいっぱいになってしまいます。

お礼検知機能は、この課題に対するFreshworksの答えです。Freddy AIを活用し、解決済みまたはクローズ済みのチケットに届く返信を1件ずつ読み取り、そのメッセージが本当のヘルプ要請なのか、単なるお礼の表現なのかを判断します。FreshworksはFreshdeskのセットアップ文書で、Freddyは「『解決済み』または『クローズ済み』のチケットに対する顧客および共同担当者の返信の意図を理解し、再オープンすべきかどうかを判断できる」と説明しています。お礼であれば、チケットはクローズのままです。本当のフォローアップのように見える場合は、これまで通りチケットが再オープンされます。

対象範囲は正確に理解しておく価値があります。この検知機能が制御するのは、すでに解決済みまたはクローズ済みのチケットに関する再オープンの判断だけです。デフレクション用のボットではなく、新規チケットを自動解決するものでもないため、Freddy AIスイートの他の機能を置き換えるのではなく、それらと並んで動作します。これにはAI Agent、Copilotの返信ドラフト作成、Insightsなどが含まれます。

「ありがとう!」でチケットが再オープンするのが本当に問題である理由

レポーティングへの影響を見るまでは、これはささいな煩わしさに聞こえるかもしれません。しかし誤った再オープンは1件ごとに、完璧に解決されていたはずのチケットがデータ上では失敗として記録されてしまうことを意味します。

最も大きな打撃を受ける指標が再オープン率です。ManageEngineの分析チームは、あるライブ顧客ダッシュボードで「過去30日間、毎日おおよそ30〜60%の受信リクエストが再オープンされている」ことを記録しており、健全な水準は「組織の規模にもよるが、おおむね10〜20%程度」だとしています(ManageEngine PitStop)。謝辞の返信が再オープンとしてカウントされると、チームはノイズだけでその健全な範囲を軽く超えてしまいます。同じ記事では、再オープンされたチケットが「日次の解決目標に悪影響を及ぼし、SLA遵守に重大な脅威をもたらす」とも指摘されています。

Freshworks自身のドキュメントでも、そのコストについて率直に語られています。すべての返信で自動再オープンすると「チケット指標が歪み、大量の『ありがとう』メッセージによってサービスデスクの効率維持が大きな課題になる」とされています(Freshservice)。この悪影響は、チームが実際にレポートする数値にも及びます。初回解決率は低く出て、対応時間はじわじわ伸び、解決してお礼を言われたチケットも失敗したチケットと見分けがつかなくなるため、CSATのレポートも不透明になります。(CSATが気になる場合は、解決確認後にのみアンケートを送るのもうまい併用策です。)

そしてこれはFreshworks特有の癖ではありません。サポート担当者はどのプラットフォームでも何年も前からこの問題に不満を漏らしてきました。

"This may be one of those basic/funny/stupid things, but my ticket system reopens a ticket if it gets a new email after being marked as resolved. The problem I'm having is people saying 'thanks!' after I mark a ticket as resolved... has anyone found a solid recipe for tackling this?"

u/orion3311, r/sysadmin, "Support tickets and 'thanks'"

そのスレッドには211件のコメントが付き、ZohoやAtlassianのコミュニティでもほぼ同じような不満が見られます。問題自体は普遍的なもので、違うのはそれぞれのヘルプデスクがどれだけきれいに解決しているかという点です。

お礼検知機能の仕組み

Freddyのバージョンを単なる高機能キーワードフィルターと一線を画すものにしているのが、この確信度のしきい値です。FreshdeskとFreshserviceのドキュメントはどちらも明確に述べています。「Freddyに設定されている高確信度のしきい値は90%超です。つまり、Freddyが極めて高い確信を持っている場合にのみ、チケットをクローズのままにします」(Freshdesk)。

このしきい値はあえて高く設定されており、Freshworksがこの機能をどう調整したかがよく分かります。本当のフォローアップを誤って握りつぶすくらいなら、お礼を誤って再オープンする方を選んでいるのです。サポートチームにとっては、これが正しい既定値です。余計な再オープンのコストは数秒程度ですが、本当に助けを必要としている顧客を静かに見逃してしまうコストは、解約リスクにつながります。

Freshdeskはさらに、ほとんどのルールベースのシステムには真似できない層をもう一つ加えています。それが自己学習型のフィードバックループです。Freddyがチケットをクローズのままにしたのに、エージェントがそれでも再オープンした場合、次回は似たようなチケットをクローズのままにしないようモデルが学習します。逆にFreddyが再オープンしたものをエージェントがクローズした場合も、その逆方向に学習します(Freshdesk)。文字通りの「thanks」という単語ではなく意図で判断するため、Freshdeskがサポートするすべての言語を標準でカバーします。これはまさにキーワードトリガーが苦手とする部分です。

Freddy AIのお礼検知機能の設定方法

ここでつまずく人が多いポイントがあります。設定方法は、利用しているFreshworks製品によって本当に異なるのです。

Freshdeskの場合:Freddy Insightsアドオン内のトグル

FreshdeskとFreshdesk Omniでは、この検知機能は自分で組み立てるものではなく、あらかじめ用意されたスイッチです。Freddy AI Insightsの配下にあり、Freddy AI Insightsアドオンの一部として提供されるため、プランの階層が重要になります。セットアップ文書の対応表によると、FreeプランやGrowthプランではなく、ProプランとEnterpriseプランで利用できます。アドオンにその価値があるか検討中なら、Freshdesk Freddy AIの料金の内訳でエージェント単位の計算を解説しています。

Freshserviceの場合:自分で構築するWorkflow Automatorの条件

Freshserviceではより細かい制御ができる一方、その分セットアップの手間も増えます。単一のトグルはなく、代わりにAdmin Settings配下でWorkflow Automatorのルールとしてこの検知機能を構築します。オートメーターの一覧は管理画面のエリアにあります。

ルール自体はシンプルです。イベントを「依頼者による返信送信」に設定し、実際の判定を行う条件を追加します。条件フィールドに入力し始めると、通常のチケットプロパティと並んでFreddy Suggestionという選択肢が表示されるので、それを「Thank you a message」に設定します。

そこからアクションを設定していきます。条件が満たされた場合(お礼メッセージである場合)はステータスをクローズに設定し、そうでない場合はステータスをオープンに設定して担当エージェントにメール通知し、本当のフォローアップを見逃さないようにします。

ゼロから構築したくない場合のよりシンプルな近道は、Freshserviceの既定のオートメーター「Reopen tickets when the requester responds」を編集し、Freddy Suggestion is not Thank you Messageという条件を1つ追加することです。こうすると、既存の再オープンルールがお礼メッセージだけをスキップし、それ以外はそのまま処理してくれます。

有効化する前に知っておくべき制限

公平なガイドは注意点もきちんと挙げるべきものであり、この機能にもいくつか重要な注意点があります。

まず1つ目は依頼者に関するルールです。この検知機能は「チケットの依頼者がエンドユーザー(ヘルプデスク内の連絡先)またはCollaboratorである場合にのみ機能します。依頼者がヘルプデスクのエージェントである場合は機能しません」(Freshdesk)。エージェントがスタッフに代わってチケットを起票する社内ITデスクにとっては、これは実質的なギャップになります。

2つ目は、設計上、見逃し(偽陰性)が起こり得るという点です。90%というしきい値のため、あいまいな返信は再オープンされます。これは安全ではありますが完璧ではありません。Freshworksは妥当な保険策として、「Requester replies to ticket」のエージェント通知をオンにし、顧客からの返信のたびに人間にメール通知が届くようにし、Freddyの微妙な判定が誤っていた場合には手動で再オープンできるようにすることを推奨しています。

3つ目は、必ずしもすぐそのまま使えるわけではないという点です。Freshworks Communityでは少なくとも1つのチームが、検知機能を有効にして再オープンルールも調整したにもかかわらず、「それでも動かない…検知すらされていない」と報告しています。有効にしても何も変わらない場合は、再オープンの自動化の順序が正しいか、依頼者がエージェントではなくエンドユーザーになっているかを確認してください。Freddyの自動化がどこで力不足になるかをより広く知りたい場合は、Freshservice AIの制限ガイドも参考になります。

他のヘルプデスクはお礼の返信をどう扱っているか

Freshworksはこの点で確かに一歩リードしていますが、それを決め手と判断する前に全体像を見ておくのは有益です。ほとんどのヘルプデスクは、同じ問題により大まかな手段で対処しています。

特に参考になるのがZendeskのケースです。ネイティブの検知機能がないため、コミュニティで最も支持されている対処法は複数トリガーによる回避策です。解決時にチケットにタグを付け、どんな返信でも自動的に再度解決済みにし、本当に再オープンするには顧客が貼り付けなければならない「秘密の」キーフレーズをメールで送るというものです。投稿者自身も「この方法ではレポート上の再オープンチケット指標は改善しない」と率直に認めています。Zohoの解決策は、クローズ時にすべての返信で再オープンしないようにする「Fall-Back to Default」トグルで、これはかなり大まかな方法です。一方Help Scoutが提供するのは時間ベースのConversation Lockのみで、遅れて届いた「ありがとう」が全く新しい会話になってしまうという、水増し問題のもう半分を抱えています。

パターンははっきりしています。標準で本物の、言語を問わないAI意図検知を行っているのは、FreshdeskのFreddyだけです。他はすべて、キーワード一致(遠回しな表現や英語以外の「ありがとう」を見逃す)、ステータストグル(すべてをブロックしてしまう)、あるいはサードパーティ製の追加機能に頼っています。

eeselを試す

このガイドを通して伝えたかったこと(感謝の言葉を仕事としてカウントすべきではない、再オープン率が実態を偽ってはいけない)に共感するなら、本質的な課題は1つのトグルよりもずっと大きなものです。eeselは、FreshdeskやZendesk、Gorgiasなど、あなたが今使っているヘルプデスクにそのままつながるAIサポートレイヤーで、自律的なチームメイトのように動作します。届いたチケットをトリアージし、返信を作成・送信し、繰り返し発生する問い合わせは最初から最後まで解決するので、お礼のノイズもtier-1の問い合わせ量も、人間の手元に届かなくなります。

強調しておきたい差別化ポイントは、eeselが特定のプラン階層に縛られたり、特定ベンダーのAIに固定されたりしていないことです。新人スタッフを教育するときのように平易な言葉で指示を与えられ、自分でコントロールできる支出上限も設定できます。ヘルプデスクごとにバラバラの対応をするのではなく、あらゆるチャネルで一貫したクリーンな指標が欲しいなら、eeselを試してみてください。数分で稼働を始められます。