Salesforceのケース統合は最大3件の重複ケースを1件のマスターケースにまとめ、統合は元に戻せない。管理者はSetupでこれを有効にし、重複をMergedステータスで残すか削除するかを選び、Merge Casesアクションとリストボタンを追加する。関連リスト、フィード項目、子レコードはマスターに移る。milestone、Case Share、Case Teamは移らず、添付ファイルは失われることがある。予防は後片付けより重要だ。重複のほとんどはメールのthreadingに原因がある。eeselのようなAIチームメイトは可能性の高い元のケースを見つけてメモを残すので、担当者はすでにある文脈を見ながら統合できる。
私はeeselのサポートキューで働いているので、重複は私にとって抽象的なデータ品質の話ではなく毎日の悩みだ。同じ問題についての2件に1件のケースが、1人の顧客の履歴を2つのレコードに分け、1つの質問に2人が答える羽目になる。このガイドのためにSalesforceの統合とメールのthreadingのドキュメントを最初から最後まで読んだ。eesel CLIを使えば、コーディングエージェントが承認済みの統合・重複対応ポリシーをナレッジとしてアップロードし、本番公開前にテストの質問を投げて答えを確認できる。Salesforceのorg自体を接続するには、やはり管理者権限を持つ誰かの承認が必要だ。
Salesforceのケース統合は実際に何をするのか?
最大3件のケースを1件にまとめ、マスターとして選んだものを残す。Salesforceの統合に関する記事では、フィールド値を比較してマスターに残したい値を選ぶとされ、「すべての関連リスト、フィード項目、子レコードはマスターに追加される」とある。
残りのケースがどうなるかは管理者の判断による。orgが重複を削除する設定なら、ソフト削除されて15日間ごみ箱に残る。残す設定なら、Highlights panelの件名に「Merged」という語が追加され、重複側のリンクから主ケースに移動できる。
Salesforceは今もこれをService Cloudに分類しているが、新しいブランド名はAgentforce Serviceだ。Caseオブジェクトと統合機能自体は同じなので、ドキュメントを探すときは両方の名前で検索するとよい。オブジェクト自体に不慣れなら、Salesforceのチケット管理システムのガイドでケースが届いて動く仕組みを解説している。
重複ケースをステップごとに統合するには?
入り口は3つあり、どれも選択できるのは3件までだ。Salesforceはそれぞれを同じ統合ページで説明している。
- Casesリストビューから。 最大3件のケースを選択し、Merge Casesをクリックし、Compare Casesウィンドウでマスターを選び、フィールド値を選んでからNextとMergeをクリックする。
- Caseの詳細ページから。 ケースを開き、Highlights panelのメニューを使い、Merge Casesをクリックして統合したいケースを検索する。重複が今のリストビューにない場合はこちらを使う。
- 標準オブジェクトの関連リストから。 アカウントを開き、CasesパネルでView Allを選び、最大3件のケースを選択してMerge Casesをクリックする。
担当者にはケースに対するRead、Create、Edit、Delete権限が必要だ。そのページの権限表に書かれている。ボタンが見当たらない場合、まず疑うべきは下記の管理者設定で、担当者のプロファイルではない。
Lightningでケース統合を設定するには?
設定をオンにし、重複をどう扱うか決め、担当者が見つけられる場所にアクションを置く。Salesforceの設定記事によれば、Manage CasesとCustomize Applicationの両方が必要で、手順は次の通りだ。
- SetupでQuick Findに
Case Mergeと入力し、Case Mergeを選ぶ。 - Merge Casesを切り替えて設定を開く。
- Delete duplicate cases after mergeを選ぶか、重複を残してMerged Case Statusピックリストからステータスを割り当てる(またはAdd a Case Statusで専用のステータスを追加する)。
- Merge Casesアクションをケースの詳細ページに、Merge Casesボタンをリストビューに追加する。
- 任意で、Object Managerから他の関連リストと同様にMerged Cases関連リストをケースのレイアウトに追加する。
このスクリーンショットではKeepオプションが推奨とラベル付けされている。私も同意する。プロセスを信頼できるようになるまでは、重複をMergedステータスで残しておこう。削除された重複は15日後にごみ箱から消え、統合は元に戻せないので、担当者が間違ったマスターを選んでしまった場合、残しておいた重複だけが唯一の証跡になる。
統合で失われるもの、残るものは?
かなりの部分がドキュメント化されているが、見落としやすいものもある。設定記事はこれらの制限を挙げている。
| 制限 | あなたへの意味 |
|---|---|
| 統合は元に戻せない | Mergeをクリックする前に、比較画面でマスターとフィールドの選択を確認する |
| Case Milestones、Case Share、Case Teamは統合されない | マスターは自分自身のSLAクロックとチームしか保持しない |
| 添付ファイルはサポートされておらず削除される場合がある | 重複から必要なファイルを先に保存しておく |
| Compare Casesウィンドウはレイアウト上の最初の35個のlookupフィールドしか表示しない | それを超えるlookupは統合時に選べない |
| 主ケースのActionsとRecommendationsは重複する | 統合後は提案が二重になると想定しておく |
| Omni-Channelのキューで保留中、またはOpenedかAssignedのステータスで割り当てられているケースは統合できない | 下のOmni-Channelの節を参照 |
このうち2つは、私がマスターを選ぶ基準を変える。milestoneは移らないので、entitlementとSLAクロックが本物のケースを選ぶ、たいていは最も古いケースだ。entitlementsとmilestonesのガイドで、entitlementのないケースにクロックがまったく付かない理由を解説している。添付ファイルはリスクがあるので、統合のタイミングでファイルを手動で移すようにしよう。統合されたケースはフィードが長くなりがちなので、AIによるケースの要約が次の担当者のキャッチアップを助ける。
メールに関する注意点もある。Salesforceのthreadingに関する注意事項によれば、2件のケースが統合された後に届くメールはすべてparent caseに紐づき、たとえchild側についての内容でも、どちらがparentになるかは統合した担当者が決める。
Omni-Channelのキューで待っているケースは統合できますか?
デフォルトではできないが、ベータ設定で未開封のケースについてはそれが変わる。デフォルトの制限では、Omni-Channelのキューで保留中、またはOpenedかAssignedのステータスで担当者に割り当てられている重複はブロックされる。Salesforceのベータの記事は、Case Merge設定にPending RoutingとAssignedのケースを許可するチェックボックスを追加するが、Openedは引き続きブロックする。
この重複は統合できますか?
ベータ設定と、重複がOmni-Channelのどこにあるかを選んでください。回答はSalesforceが文書化しているルールに従います。
この境界線の理由はルーティングのライフサイクルにある。担当者が作業項目を受け入れた時点でそのケースは進行中になり、別の人が統合するとその担当者のセッションを上書きしてしまう可能性がある。エラーは「We couldn't merge these cases. One or more of the duplicate cases is currently being worked on」と表示され、解決策は担当者がタブを閉じるか作業項目を解放することだ。Salesforceはこの機能をBeta Services Terms下のベータと位置づけているので、まずサンドボックスで試すべきだ。Omni-Channelルーティングのガイドで、これらの状態の裏にあるpending routingとassignmentのレコードを解説している。
重複ケースはどこから来るのか?
ほとんどは既存のケースと一致しないメールからだ。SalesforceのEmail-to-Caseのthreadingページが照合の順序を説明している。Lightning threadingでは、届いたメールはまず件名か本文にある23文字のトークンで照合される。それが失敗すると、SalesforceはIn-Reply-To、References、Thread-Indexのヘッダーを確認する。両方失敗すると新しいケースを作る。
制限事項のページは照合が崩れるパターンを挙げている。
- 顧客が件名を編集する。 メールクライアントによっては、件名を変えるとthreadingトークンが失われ、新しいケースの原因になる。
- ルーティングアドレスが複数ある。 Salesforceは顧客に1つのアドレスだけにメールするよう案内することを勧めており、複数宛てに送ると予期しない結果になり、サポートされていないとしている。
- ヘッダーに触れるリレーやメールサーバー。 SalesforceのMessage-IDを変更するリレーは、元の値をReferencesヘッダーに移す必要があり、ReferencesやIn-Reply-Toを除去する独自のメール転送エージェントは新しいケースの原因になりうる。
- 古いRef ID threading。 Lightningまたはヘッダーベースのthreadingがないと、Ref IDを欠いた返信は新しいケースを作る。SalesforceはRef ID threadingを保守専用と位置づけ、切り替えを推奨している。
- 更新されたサンドボックス。 org IDが変わると、古いorg IDに紐づいたトークンは機能しなくなる。
threadingが対象にするのはメールだ。Webフォームとメッセージングチャネルについては、読んだSalesforceのドキュメントの中で同等の照合メカニズムを見つけられなかったので、2回送信した顧客や2回目のセッションを始めた顧客は2件目のケースになりうると想定しておく。実際にそうなるかは自分のorgで確認してほしい。複数の人が1つの受信箱を見ていることが重複の原因なら、チケットのswarmingが関連する課題になる。これらのチャネルがどこに届くかについてはEnhanced Messagingのガイドを参照。
Salesforceは担当者が見つける前に重複を提案できますか?
できる。Enhanced Case Mergeというベータ機能だ。SalesforceのEnhanced Case Mergeの記事は、「手動・事後対応のクリーンアップから、事前の予防へ」という移行を3つのステップで説明している。
- Case Merge設定でMerge cases with Enhanced Case Mergeにチェックを入れる。
- Duplicate Rulesの下で各ルールに名前を付け、重複をどう識別するかを決めるmatching ruleを選び、ルールが実行される前にケースが満たすべき条件を設定する。
- Duplicate CasesコンポーネントをLightning App Builderでケースの詳細ページにドラッグする。
このコンポーネントは、ケース番号・件名・コンタクト・オープン日とともに可能性の高い重複を一覧表示し、現在のケースを主ケースとして事前選択した統合ウィンドウを開くボタンも備える。これもベータなので、同じくサンドボックスで先に試すべきだ。それでも統合自体は人の手に残るので、私はそこを人に任せたい。
AIはどうやって重複ケースを減らせるのか?
自分で統合するのではなく、より早く答え、元のケースを指し示すことによってだ。統合は元に戻せないので、エージェントに無人で統合をやらせることは絶対にしない。エージェントが安全にできるのは、新しいケースを読み、他のケースを検索し、「これは今朝同じコンタクトが開いたケースに似ている」といった非公開のメモを残すことだ。eeselのSalesforce連携はこのようにorg内で動く。ケースとKnowledge記事を読み、内部のケースコメントとして返信を下書きし、先にアカウントを調べて他のケースを検索できる。詳しくはドキュメントを参照。あなたのエージェントが見えるのは認可されたSalesforceユーザーが見られるものだけなので、オブジェクトとフィールドの権限が実際の境界線のままだ。
この境界線は、すでに実施しているAIガバナンスのレビューにも合う。Salesforce自身のAIの制限も、どの層を選ぶか決める前に読む価値がある。
他のヘルプデスクでも同じパターンが2つの顧客事例に表れている。RúngneはGorgias上で3体のエージェントを動かしており、メール、チャット、ソーシャルのコメントが1つのキューを共有している。ある1か月で、そのエージェントは約2,100件のチケットを処理し、約880件にタグを付け、約580件の返信ドラフトを内部メモとして残し、約7件に1件を直接回答した。広告コメント、自動応答、スパムのようなノイズはタグ付けされてクローズされるので、片付けるべき2つ目のレコードになることはなく、これは統合よりもチケットの分類に近い仕事だ。SamCartでは、まだ担当者が割り当てられていないときだけFreshdeskのエージェントが最初の返信を送る。私の見方では、素早い最初の返信が「何か進展はありましたか?」というフォローアップを減らし、それがしばしば重複の原因になっているが、どちらの事例も重複を直接測定しているわけではない。
より速い返信については最初の返信の自動化のガイドを参照。チケット全体を減らすにはチケットのdeflectionを参照。
他のスタックでも同じ発想についてはチケットの重複排除のガイドを参照。Freshdeskでのこの作業についてはFreshdeskのチケット統合を参照。
重複する前からキューがノイズだらけなら、スパムフィルタリングから始めよう。共有受信箱の比較のガイドで受信側を解説している。
最初に何を整えるべきか?
まず予防し、それから後片付けを安全にする。Service Cloudのorgで私が使う順番はこうだ。
- threadingの方式を確認する。 Setupに「Insert thread ID」設定が表示されるなら、Ref ID threadingを使っている。Lightning threadingに移行し、トークンとヘッダーの両方のオプションを有効にする。
- ルーティングアドレスを減らす。 顧客向けの受信箱ごとに1つのアドレスにし、複数に同時送信しないよう顧客に伝える。
- Keepを選んでCase Mergeを有効にする。 明確なMergedステータス、アクション、リストボタン、Merged Cases関連リストを追加する。
- マスターケースのルールを書く。 私のルールは、有効なentitlementを持つ最も古いケースを選び、添付ファイルは先に手動で移すというものだ。
- 担当者にOmni-Channelのルールを教える。 Openedのケースは統合できないので、統合の前に作業項目を解放する。
- サンドボックスでEnhanced Case Mergeを試す。 まずは絞り込んだ1つのduplicate ruleから始める。
- AIによるメモの層を追加する。 エージェントに可能性の高い元のケースにフラグを立てさせ、統合のクリックは担当者の手に残す。本当に難しいケースはAIによるエスカレーションに引き継ぐ。
こうしたアドオンが積み重なってService Cloudがいくらかかるか気になるなら、料金の内訳でエディションを解説している。Caseオブジェクトで他に何を自動化できるかについてはSalesforceのケース自動化を参照。より広い視点についてはヘルプデスクAIから始めよう。
Salesforce Service Cloud向けのeeselを試す
重複ケースが担当者の時間を奪っているなら、eeselはあなたのService Cloudのorgに組み込まれる新しいメンバーのように働く。新しいケースをアカウントの履歴とともに読み、内部コメントとしてドラフトや「possible duplicate of」のメモを残す。統合の判断は担当者のもとに残り、エージェントが見られる範囲の管理も管理者のもとに残る。無料で試せる。
