Frontの共有受信箱では、担当者は割り当て先のメンバーであり、常に1人しかいない。コメントする人、@メンションされる人、サブスクライブする人は、全員ヘルパーに過ぎない。厄介なのは、誰もAssignをクリックしなくても担当が変わること。未割り当ての会話に返信すればあなたが担当者になり、自分をOut of officeにすれば顧客が返信した時点で会話がキューに戻り、放置設定によって静かなスレッドの割り当てが外れることもある。この3つの設定を意図して決め、チームが完全にオフラインになることがあるならround robinよりload balancingを選べば、「これ誰が持ってるの？」という問いは消える。新しい会話がすべて下書き済みの次の一手付きで届いてほしいなら、eeselはFrontの中でAIチームメイトとして動き、他の誰とも同じように会話を割り当てられる。
Frontの共有受信箱で「担当」とは何を意味するか？
Frontでは、担当とは割り当てのことだ。Front自身のヘルプセンターはそれをはっきり述べている。会話を割り当てることは「every message a clear owner」を与え、「a conversation can only be assigned to one user at a time」だと言う。一度割り当てられると、その人のAssigned to meセクションに表示される。
私はFrontのようなヘルプデスクの中で動くAIエージェントを作っているので、それぞれの共有受信箱ツールが会話の責任者をどう決めるかを読み込む時間が長い。Frontの答えはほとんどより明快だ。1人の割り当て先、それに好きなだけのヘルパー。ヘルパーとは次のような人たちだ。
- コメントする（コメントはチームだけに見える）。
- @メンションされる。それで会話が自分のビューに入ってくる。
- サブスクライブする。新しい動きがあると会話が自分のSubscribedセクションに上がってくる。
この区別が重要なのは、Frontのサブスクライブに関するルールが、担当者はアンサブスクライブできないと言っているからだ。「you must unassign or reassign the conversation first」。ヘルパーはいつでも抜けられる。担当者は黙って離れることができない。
ここまでは理論だ。実際には、チームがこのテーマを検索する理由は、割り当てられていたと思っていた会話が実はそうではなかったからだ。それがどこから来るのかを見ていこう。
誰もAssignをクリックしなくても担当が変わるのはなぜか？
Frontの共有受信箱で担当者を動かしたり外したりするものは5つあり、そのうち1つだけが人が意図的に再割り当てするケースだ。
1. 最初に返信した人が担当者になる
FrontのチャンネルにはAssign conversations on first replyという設定がある。これがオンだと、「any time a teammate starts a new conversation or replies to an unassigned conversation from a shared channel, the conversation will automatically be assigned to that teammate」となる。デフォルトでオンになっている。
小さなチームにはこれは良いデフォルトだ。それと同時に、チーム横断の受信箱で、セールスの担当者が「let me check with support」とさっと返信しただけで、3週間も請求トラブルの担当者になってしまう原因でもある。Frontのドキュメントからの2つの詳細。未割り当ての会話にしか発動せず、Frontから送信した場合にしか動かない。
2. Out of officeは会話をキューに戻す
メンバーがOut of officeに設定されると、「any replies they receive to conversations that originated in a shared inbox will automatically get unassigned」となる。新しい返信が来ない会話は、そのまま担当のままだ。自動の割り当ては一時停止するが、メンバーは手動でなら割り当てられる。
Busyは違う。Frontのメンバーステータスガイドによれば、Busyは新しいルールによる割り当てを一時停止するが、新しい動きがあれば会話は割り当てられたままになる。つまり、どのサポートチームの引き継ぎでも実務上のルールはこうなる。昼休みにはBusy、その日の勤務を終えるときはOut of office。グレー、つまり接続されたデバイスがない状態は何も一時停止しないので、ステータスを変えずにノートPCを閉じたメンバーもルールによる割り当てを受け続ける可能性がある。
3. 放置タイマーが静かな会話の割り当てを外す
共有受信箱には、Unassign conversation if inactive forという受信箱の設定がある。期間を決めておき、その期間より長く静かだった会話に新しいメッセージが届くと、Frontはその割り当てを外す。Neverを選ぶこともできる。会社のバンプ設定が送信側のメッセージも数えるなら、それもトリガーになる。数えないなら受信側だけがトリガーになる。詳しくはFrontのバンプ設定に関する注記を参照。
これは多くの人を驚かせるし、SLAの追跡を混乱させることもある。タイマーが切れた瞬間には何も起こらないからだ。担当者は、顧客がついに返信を書いてきたときにだけ消える。
4. 他の誰かがアーカイブする
アーカイブは共有の操作のように見えるが、Frontはビューを別々に追跡している。会話ステータスガイドによれば、「If a teammate who is not the assignee changes a conversation's status from a shared inbox, then the conversation will stay open in the assignee's Assigned to me section」。同僚が共有ビューを整理した後でも、担当者は自分のリストにそれを残しておく。これは安全網であって不具合ではないが、チームの残りが終わったと思っているものを担当者が見ている理由を説明している。
5. ルールか管理者が再割り当てする
意図的なケースだ。他のヘルプデスクのグループ割り当てと同様に、ルールは割り当て、割り当て解除、再割り当てができる。そしてload balancingのルールは、担当者がOut of officeやBusyになったために外れた会話を再割り当てできる。ただし、そのルールにAssignee is removedトリガーがある場合に限る（Frontのload balancingドキュメント）。
これらのほとんどを上書きする唯一のスイッチは、共有受信箱の設定Keep assignments when teammate is out of office or busyだ。これをオンにすると、新しい会話は対応できないメンバーにも割り当てられ続け、既存の会話は新しい動きがあっても保持され、放置による割り当て解除の設定は無効になる。
状況ごとに担当はどうなるのか？
ここでは同じロジックをクイックリファレンスとして示す。チームに説明したい状況を選んでほしい。
ヘルパーは担当を取らずにどう手伝うのか？
最もすっきりしたFrontのチームは「これは自分のもの」と「ここは手伝うだけ」を分けており、Frontはその2番目のためのツールを用意している。ポイントは、ヘルパーは返信ではなくコメントすべきということだ。
Frontのリアルタイム衝突検出はここで役立つ。メンバーが共有受信箱で返信を作成中なら、返信中であることを示すインジケーターが見え、入力中の下書き内容がリアルタイムで共有される。これで二重返信が防げる。ただし、スレッドの担当者が誰かを決めるわけではなく、だからこそ上の設定が重要になる。
G2のレビュアーは、ほぼ同じ言葉でそのメリットを語っている。
"We can assign conversations, jump in when someone needs help, and avoid that awkward moment when two people reply to the same email. It sounds simple, but it saves a surprising amount of time."
知っておく価値のあるサブスクライブの詳細がもう1つある。個人設定のUnsubscribe on unassignは、自分で手動で割り当てを外したときにしか適用されない。ルールによって割り当てが外された場合は、自分でアンサブスクライブするまでサブスクライブしたままになる。だからこそ、Out of officeになっていた人が戻ってきたとき、もう自分のものではないスレッドでいっぱいのSubscribedセクションに出会うことになる。
Round robinとload balancing、どちらが担当を明確に保つか？
ルールが会話を割り当てているなら、誰もいないときに何が起きるかはその方法が決める。Frontの両方の比較は、その違いについて率直だ。
| Round Robin | Load Balancing | |
|---|---|---|
| 次の会話を受け取るのは誰か | 順番で次にオンラインのメンバー | 開いている割り当て済み共有会話が最も少ないメンバー |
| 全員オフライン | 割り当てられず、キューもなし | 誰かに空きができるまでキュー |
| メンバーがオンラインに戻る | スキップされた会話のキャッチアップはなし | 最も古い未返信の会話を最初に受け取る |
| 1人あたりの上限 | なし | ワークスペースごとの上限、最大かつデフォルトは100 |
| スヌーズ中の会話は上限に数えるか | n/a | 数えない |
| プラン | Rules（Starterは最大10） | Professional以上 |
出典：round robinとload balancingの比較、load balancingのルール、Frontの価格。
load balancingの2つの詳細が多くの人を驚かせる。まず、上限はワークスペースごとなので、Front自身の例ではHectorはあるワークスペースで4、別のワークスペースで5、合わせて同時に9件まで持つことになる。次に、Frontのルールエンジンは「does not re-assess rule conditions when a conversation reaches the front of a load balancing assignment queue」。タグが変更された会話でも、最初にマッチしたルールによって割り当てられたままになる。
私の見解はこうだ。round robinは、受信箱の稼働時間中は常に人がいるチームには十分だ。チームが完全にオフラインになることがあるなら（夜間、週末、複数のタイムゾーンに分かれた小さなチームなど）、load balancingのほうが安全な選択だ。round robinはそうした会話を単に未割り当てのまま残してしまうからだ。load balancingには年間契約でProfessionalが1席あたり月65ドル必要で、ステータスを自動で切り替えるshifts機能はEnterprise（1席あたり月105ドル）にある。
同じトレードオフは、Zendeskのround robin、Freshdeskのround robin、Gorgiasのround robinの設定にも現れる。
チームはどの担当モデルを選ぶべきか？
Frontでは3つのモデルが機能する。どれが合うかは、チームの規模と全員が同時にオフラインになる頻度によって決まる。
| モデル | 担当者の決め方 | 確認すべき設定 | 向いているチーム |
|---|---|---|---|
| 返信で確保 | 最初に返信した人 | 最初の返信での自動割り当てがオン、ヘルパーは返信せずコメント | 2〜5人、同じ勤務時間帯 |
| ルールで割り当て | 受信時のload balancingルール | 割り当て上限、Assignee is removedトリガー、Out of officeの規律 | 一定の量、シフトやタイムゾーン |
| トリアージ担当 | 1人が毎朝または毎時間割り当てる | 最初の返信での自動割り当てがオフ、放置による割り当て解除を設定 | 混成チーム（サポートに加えて営業やオペレーション） |
どれを選んでも、3つの決定を文章にしてチームと共有しておこう。「あなたが持っていると思ってた」の原因になるのはこの3つだからだ。
- 返信は会話を確保するか？ しないなら、各共有チャンネルでAssign conversations on first replyをオフにする。
- Out of officeは何をするか？ 割り当てを外すに任せる（デフォルト）か、Keep assignments when teammate is out of office or busyをオンにする。どちらかに決め、シフトの終わりにどのステータスを使うかをチームに伝える。
- 割り当て済みのスレッドはどれだけ静かにしていられるか？ Unassign conversation if inactive forを実際の数値かNeverに設定する。設定時にたまたま選ばれた値のままにしない。
ルールはこれをきれいに整理できるが、ルールが多いほど良いわけではない。あるG2のレビュアーがそのトレードオフをうまくまとめている。
"If you create too many rules, you end up having to check why each message ended up in a different place. We had to simplify the setup so that everyone understood how to work with it."
Frontのモデルがチームに合わないなら、私のFrontの代替ツールのリストと小規模チーム向けチケットシステムのまとめが次のステップだ。
Frontの共有受信箱モデルとチケットキューのどちらが合うかまだ決めかねているなら、私のガイド共有受信箱とチケットシステムの比較とFrontとHiverの比較が構造的な違いをカバーしている。Frontには共有受信箱向けのチケットステータス（Open、Waiting、Resolved）もオプションであり、進捗の追跡には役立つが、誰が会話を担当するかは変えない。
AIチームメイトはFrontの担当のどこに収まるのか？
FrontのAIチームメイトは、チームが監視しなければならない別のシステムとしてではなく、他の全員と同じルールに従うもう1人の割り当て先やヘルパーとして動くのが最も良い。eeselのFront連携はまさにそう作られている。会話を割り当てられ、人が送信するための下書き返信を社内コメントとして残し、タグ付けし、特定のメンバーに割り当て、アーカイブできる。メンバーがコメントで@eeselと書いたときに動くこともできる。これは上で説明した「ヘルパーはコメントし、担当者は返信する」というモデルに合っている。
FrontのネイティブなFront AIスイートは、AutopilotとCopilotを備えており、1社のベンダー内に留まりたいならもう1つの道になる。
eeselのFrontドキュメントからの正直な限界を1つ。eeselは名前を指定した1人のメンバーに割り当てるのであって、チームやグループには割り当てない。グループへのルーティングは引き続きFrontのルール次第なので、load balancingの設定は変わらず機能し続ける。
私が最もよく機能しているのを見るパターンは、XapがFreshdeskで運用しているものだ。誤って送られてきた学生のチケットには、転送用の完全な返信が社内ノートとして下書きされ、人が送信する。eeselが学生に直接返信することはない。Adverscaleは@メンション版だ。スタッフがノートに@eeselと書くと、AIチームメイトが日常的な質問に答え、範囲外のものには、止まった理由を説明するノート（地味で信頼できる方法で行うAIのエスカレーション）と、正しいグループへの割り当てが付く。月に2,400件のチケットのうち、これによってチームには2,700件の社内ノートが残った。どちらも他のヘルプデスクでの話だが、担当という考え方はそのままFrontにも当てはまる。AIが最初のひと手間をこなし、担当者は人のままだ。
チームがターミナルから設定を行うなら、eesel CLIを使えば、Claude Codeのようなコーディングエージェントがnpx @eesel/cli integrations connect frontでFrontを接続し、何が同期されたかを確認し、自動化を本番に出す前にテスト用の会話で社内コメントの下書きを試せる。Frontの接続自体を承認するには、やはりFrontでアプリを許可する権限を持つ人が必要だ。
Frontの共有受信箱でeeselを試す
Frontチームが「これ誰が持ってるの？」と聞き続けているなら、解決は上の3つの設定から始まる。eeselは次の層を追加する。新しい会話はすべて読まれ、下書きされ、望むなら誰かが確保する前に正しいメンバーに割り当てられ、下書きは社内コメントとして待機するので、担当者が何を送るかを決め続けられる。eeselは過去のFrontの会話とヘルプセンターから学習し、下書きだけから始めることもできる。eeselを試すか、Frontに最適なAIのまとめで選択肢を比較してみてほしい。