Front向けAIメール振り分け:実践セットアップガイド

Frontの受信トレイにおける「メール振り分け」の本当の意味

Frontでサポートを運用しているなら、おそらくそう呼んでいないだけで、すでに毎日振り分けを行っています。共有受信トレイがいっぱいになると、誰かが決めなければなりません。これは何についてか、誰が対応すべきか、どれくらい緊急か、そしてすでに書いたものから答えられるかどうかです。1日に数百通のメールをこれを手作業で行うと、シフトの最初の1時間が消えてしまいます。

AIメール振り分けは、これらの判断を単に自動化するものです。段階に分けると次のようになります。

Frontはこの一連の流れをネイティブにカバーしていますが、1つのスイッチを切り替えるのではなく、いくつかの異なる機能から組み立てる形になります。私はここ数年、Frontを含む稼働中のサポートキューにAIを組み込む作業に多くの時間を費やしてきましたが、人々が過小評価しがちなのは分類ではなく、ルーティングと「いつ返信を任せられるか」という部分です。それでは各段階を見ていき、その後でネイティブツールがどこで限界を迎え、何を上乗せできるかを話しましょう。

FrontのネイティブAIが振り分けをどう処理するか

Frontは自社のAIを3つの動詞で表現しています。Automate、Assist、Analyzeです。それぞれが振り分けの1段階にきれいに対応します。

分類:Topics

TopicsはFrontの分類レイヤーです。会話履歴を読み取ってクラスタリングするため、顧客がなぜ問い合わせてきたのかを推測する代わりに、「返金依頼」「配送遅延」「ログイン問題」といった実際のカテゴリーが得られます。Starter以上のすべてのプランに含まれており、設定時に過去30日間の最大1万件の会話を遡って取り込むため、ゼロから始める必要はありません。

頼りにする前に知っておくべき実際の制限がいくつかあります。Topicsは月1,000件を超える会話があるより大量の受信トレイ向けに設計されており、それ以下だと、Frontによれば奇妙な挙動になったり、トピックがまったく生成されなかったりすることがあります。1つのトピックが継続的なタグ付けを開始するには最低5件の会話が必要で、2つのトピックを統合すると元に戻せません。トピック名は英語で出力されますが、Frontは数十の言語で会話を読み取り、対応する英語ラベルを生成します。誤った分類のトピックから別のトピックへ会話を移動させることはできますが、修正例をモデルに与えて再学習させることはできません。

ルーティング:ルールエンジンとPlaybook

分類は、その後メールがどこかへ届くようにしてこそ役立ちます。Frontのルールエンジンはルーティングの主力です。受信トレイ、送信者、キーワード、タグ、SLAに基づいて条件を組み立て、チームメイトへの割り当て、受信トレイへの移動、タグの追加、SLAタイマーの開始といったアクションを設定します。これはほとんどのチームがすでに運用している部分であり、AI振り分けはそれを置き換えるのではなく、その上に構築されます。

AI主導の解決には、FrontはAutopilot Playbookを使用します。特定の受信トレイに限定された、エージェントが従う名前付きの手順セットです。

Playbookはレコードから予約番号を取得し、それをポリシーと照合し、連携ツール内でアクションを実行できます。これは本当にFAQの単純な回避以上のものであり、Frontの本当の強みの1つです。サードパーティのCRMやERPデータを、後付けの照会ではなく一級の入力として扱います。

解決またはアシスト:AutopilotとCopilot

メールが分類され、ルーティングされた後は、誰かが返信しなければなりません。Frontは2つの経路を用意しています。

Autopilotは自律型エージェントです。Frontはこれを、メール、チャット、Slackにわたって最大70%のリクエストをエンドツーエンドで解決するものとして宣伝しています。これは1会話あたり0.05ドルから始まるアドオンで、Enterpriseを含むすべてのプランで利用可能です。公平に言うと、Autopilotには実際にシミュレーションのステップがあるため、「スイッチを入れて祈るだけ」という昔からの批判は当てはまりません。正直な違いは、何をシミュレーションするかです。Frontのシミュレーションは、あなた自身の過去のチケットに対する再生ではなく、あなたが書いたシナリオに対して実行されるため、実際に顧客が送ってきたケースではなく、あなたが思いついたケースをテストすることになります。

Copilotはアシスト経路です。会話履歴に基づいて提案返信を下書きし、連携システム全体からコンテキストを調査し、人間が送信を押す前にエージェントがトーンと長さを調整できるようにします。1シートあたり月20ドル、またはEnterpriseに含まれています。これはFront AIの中で成熟したリスクの低い部分であり、完全な自動化にまだ任せられないチケットに適しています。

Frontで振り分けを設定する手順

ネイティブツールでこれを構築する場合、うまくいく順序は次のとおりです。

1. Topicsをオンにして遡って取り込ませる。 実際の受信トレイで1週間動かし、カテゴリーが顧客の実際の問い合わせ内容を反映するようにしてから、曖昧なものをリネームする。
2. それらのトピックに対してルーティングルールを書く。 「請求」を経理向け受信トレイにルーティングし、SLAキーワードを含むものにはタグを付け、VIP送信者は名前付きキューに割り当てる。
3. 限定的で高頻度の1トピックに対してPlaybookを構築する。 注文追跡や返金依頼は、手順が毎回同じであるため、最初に選ばれることが多い。
4. シミュレーションを行い、その後限定的な範囲でAutopilotを開始する。 その1つのトピックに絞って様子を見て、解決品質が維持される場合のみ範囲を広げる。
5. それ以外すべてにCopilotを設定することで、Autopilotがまだ処理していないチケットについてもエージェントが下書きを得られるようにする。

これらはどれもワンクリックでは済まず、それがFrontのネイティブAIについて公平に言えることです。強力ではありますが、設定には実際の作業が伴います。Topicsの整理、ルールの記述、Playbookの構築、ナレッジの接続はスイッチ以上のものであり、それぞれの部分は別々に課金・設定されます。

FrontネイティブAIの振り分けが限界を迎える場所

FrontのAIは優れています。しかし、本格的な振り分け量をこなすチームがつまずく3つの点があり、それを回避できるようはっきりと名指ししておく価値があります。

請求が断片化している。 完全な振り分けを得るには、シート料金に加えてCopilotに加えてAutopilotを会話ごとに支払うことが多いです。ここには特有の落とし穴があります。1シート65ドルのProfessionalプランで、Copilot(20ドル)、Smart QA(20ドル)、Smart CSAT(10ドル)を追加すると1シート115ドルになり、これら3つがすでに含まれる1シート105ドルのEnterpriseよりも高くなります。アドオンを積み重ねる前に計算しておく価値があります。

テストが実際の履歴を使わない。 前述のとおり、Autopilotのシミュレーションはシナリオベースです。振り分けシステムにとって恐ろしい失敗モードは、想定していなかったメールであり、シナリオベースのテストは定義上そうしたケースをカバーしません。

ナレッジには実際の限界がある。 AutopilotとCopilotは、公開されたFrontのナレッジベース、公開ウェブサイト、そして一連のサードパーティソース(Confluence、Google Drive、Guru、SharePoint、Notion)を読み取ることができます。これは充実したリストですが、ソースは英語である必要があり、それぞれ約3,000ページに上限があり、Slackは接続可能なナレッジソースではないため、Slackのスレッドで生活しているチームにはギャップが生じます。

これらはどれもFrontを悪い選択にするものではありません。振り分けが副次的な機能ではなく本業になったときにぶつかる継ぎ目にすぎません。

eeselでFrontにAI振り分けチームメイトを重ねる

Frontでメール振り分けを行うもう1つの方法は、分類、ルーティング、下書き、解決、エスカレーションという全チェーンを、同じ共有受信トレイの中で処理し、それを1つのものとして課金するチームメイトを追加することです。

それがeeselの形です。隅にあるチャットウィジェットでも、切り替えて使う別のツールでもなく、あなたの共有受信トレイに本物のAIエージェントとしてFrontに参加します。

Front内では、人間のエージェントと同じ操作を行います。会話を読み取り、返信を下書き・送信し、非公開コメントを追加し、タグを更新し、チームメイトへルーティングし、SLAのタイムラインを管理します。メール、ウェブチャット、SMS全体で動作し、顧客が使ったチャネルで返信し、追加設定なしで80以上の言語をそのまま扱えます。

振り分けに特に適している点が2つあります。1つ目はトリガーの制御です。タグ、チャネル、受信トレイ、特定のルールに基づく条件でどの会話を扱うかを決められ、あるいは個々の会話を手動で渡すこともできます。既存のFrontのルーティングルール、割り当てルール、SLAポリシーと対立するのではなく尊重するため、ワークフローを作り直すのではなく、チームメイトを追加する形になります。2つ目は、書き方、対応する会話、エスカレーションのタイミングを、あらゆるエッジケースのためのルールツリーを維持するのではなく、望むことを説明することで自然な言葉で設定できることです。

セットアップは短くテスト可能な道筋をたどります。

振り分けにとって最も重要なステップは3番目です。eeselは自分で考えたシナリオではなく過去の会話でシミュレーションを行うため、本番の顧客に何かが返信される前に、トピックごとの具体的な解決率とギャップレポート(「先週の23件のチケットが日割り返金について尋ねていたが、あなたのドキュメントは全額キャンセルしかカバーしていない」)が得られます。そのうえで下書きのみモードで開始し、チームにレビューさせ、自信が持てたら簡単なトピックから自律モードへ切り替えます。これは、自信たっぷりに聞こえるボットが静かに間違った回答をしているのを目の当たりにして以来、私たちが徹底するようになった「まず履歴でシミュレーションする」という同じ規律です。

これはデモに限った話ではありません。DTCのeコマースチームであるEcosaは、eeselに1会話0.40ドルでTier 1チケットの75%を処理させており、Gridwiseは導入初月でeeselがTier 1リクエストの73%を解決したと報告しています。引用する価値のあるFront特有の顧客の声もあります。

"私たちは販売後の顧客サポートにeeselを使用しています。Frontの受信トレイやShopifyと連携しており、eeselチームによるカスタマーサポートも非常に良好です。"

Raul Sanz Garcia、ITマネージャー、Friscomos

コスト比較:ネイティブFront AI vs eeselレイヤー

ここに、たいてい結論を左右する横並び比較があります。

eeselのモデルは単一の従量課金レートです。処理済みの1チケットまたはヘルプデスク会話あたり0.40ドルで、返信単位ではないため、1つの会話内でのやり取りがすべて1回の課金にとどまります。標準プランではシートもプラットフォーム料金もありません。

eesel自身の料金ページによる具体的な段階:月100チケットで40ドル、500で200ドル、1,000で400ドル、2,500で1,000ドルです。そして、AIにルーティングした分だけ支払うため、チームが月1,000件のチケットを処理していても、そのうち200件をeeselに送るなら、その200件分(80ドル)だけを支払います。50ドル分の利用まで無料で開始でき(カード不要)、デフォルトの月額250ドルの支出上限がエージェントを一時停止させるため、予期しない請求は発生しません。正直な注意点が2つあります。結果が完璧かどうかにかかわらずタスクは課金され、HIPAAとBAAはEnterprise限定です。

Frontに公平を期すために言うと、AI利用量が少ない場合、1会話あたりのコストは近い水準になります。Autopilotの0.05ドルは1会話あたりでは安価であり、ごくわずかしか自動化しないのであれば、ネイティブツールで十分合理的です。eeselの優位性は、振り分けが本業になるにつれて強まります。シートごと、アドオンごとに支払うのをやめ、チェーン全体に対して1つの予測可能な数字を支払うようになるからです。

Front向けにeeselを試す

3つの別々に課金される製品から組み立てることなく、FrontでAIメール振り分けを実現したいなら、eeselは既存の共有受信トレイの中で全チェーンを処理するAIチームメイトです。分類し、タグ付けし、適切な担当者にルーティングし、下書きまたは送信し、確信が持てないときはエスカレーションします。すべてシートなしで1会話あたり0.40ドルです。

まず最初に押しておきたいのがシミュレーションです。Frontを接続し、eeselを過去数千件の会話に向ければ、実際のメールに触れる前に、本当の解決率とナレッジのギャップが見えてきます。無料で試すことができ、接続にかかる時間は30分未満で、すでに構築したあらゆるFrontルールと並行して機能します。実際の履歴によるテストと定額料金という組み合わせこそが、受信トレイがボトルネックになっているあらゆるチームにとって一見の価値があるものにしています。