重複チケットは、同じ顧客から近い時刻に届いたという理由だけで統合せず、対象の注文・契約・Issueと、requester・CC・公開範囲を確認します。AIは候補を並べ、一致・衝突・未完作業を整理する役に限定します。関連付けだけで足りる場合と、実際に一つへmergeする場合を分け、残すチケットと引き継ぐ内容を人が決めてください。
この記事は重複候補を確認する運用手順です。実際のチケット取得、統合、通知、顧客情報の変更は実施していません。製品ごとに統合の副作用や権限が異なるため、以下の例だけで本番操作へ進まないでください。
目次
元チケットを保ったまま候補を作る
受付ID、顧客ID、受信時刻とその基準、窓口、対象取引、件名、必要な本文範囲を作業表へ出します。顧客IDの対応が確認できていない別メールアドレスを、名前の類似だけで同じ顧客へ寄せないでください。代理問い合わせや共有アドレスでは、契約上の顧客と返信を受ける人が異なる場合があります。
時間範囲は候補を探す条件です。同じ顧客が同日に別の注文を問い合わせた場合も、同じ障害について数日後に続報した場合もあります。「何時間以内なら重複」という値を共通の正解にせず、業務で想定する再送や再問い合わせの例から決めます。時差やシステムの作成時刻と実際の受信時刻の違いも確認します。
類似本文より対象と矛盾を確認する
表は横にスクロールできます
| 比較するもの | 一致候補 | 統合を止めて確認する例 |
|---|---|---|
| 顧客・requester | 確認済みIDと連絡元の関係 | 代理人、別法人、本人確認未完 |
| 対象取引 | 同じ注文・契約・請求 | 別注文、別アカウント |
| Issue | 同じ事象と求める対応 | 症状は似るが依頼が違う |
| 時刻・履歴 | 再送や続報の関係が説明できる | 過去解決後の新しい発生 |
| 状態・担当 | 同じ仕事が重なっている | 片方に未実行の約束や別承認 |
| 可視性 | 同じ相手へ共有可能な情報 | CC、ブランド、内部メモの相違 |
AIへは候補ペア、同じ対象と考える根拠、矛盾、元チケットへの参照、不足情報を返させます。似た文章であることを根拠へ含めても、それだけでmergeを確定しません。添付だけに対象番号があるなど、本文にない条件は推測せず確認待ちとします。
架空の例では、同じ顧客の「配送が遅い」という二件でも注文番号が違えば別対応です。同じ注文番号でメールとフォームへ届いた再送なら重複候補ですが、片方で住所変更を依頼している場合はその作業を失わないようにします。同じIssueへ関連付けて二件を残す判断もあります。
残すチケットと引継ぎ表を作る
統合前に、残すID、閉じる候補ID、採用理由、残す担当、顧客への約束、未完作業、添付の必要性を確認します。単に新しい方へ寄せると、古い方の重要な回答や承認が見えなくなる可能性があります。どの記録を正本とするかは、サポート運用と製品仕様から決めます。
Zendeskの統合仕様（新しいタブで開く）では、統合は取り消せず、閉じる側の各fieldがそのまま移るわけではありません。また、CCの設定によりrequesterやCCが移り、最新のpublic commentを含む統合コメントの扱いにも注意が必要です。統合前に宛先・コメントの公開範囲・引き継ぐ作業を確認します。これはZendeskの仕様例で、別製品で同じ動作とは限りません。
同資料はSolved側への統合で自動的に再開されない条件や、AI agent ticketを統合できない制約も示しています。統合先を選んだだけで未完作業が再開したと判断せず、状態と担当を確認してください。権限や制約により統合できないときは、設定を緩める前に関連付けによる管理で足りるかを検討します。
実操作の前後を別の確認にする
表は横にスクロールできます
| 段階 | 確認内容 |
|---|---|
| 候補確認 | 同じ対象・Issueか、矛盾・別依頼がないか |
| 操作前 | 残すID、requester/CC、公開コメント、未完作業 |
| 操作後 | 状態、担当、参照関係、必要な作業・期限 |
| 集計 | 統合元と先をどう数えるか、除外した記録 |
操作権限がある担当者が統合した場合も、成功表示だけで終えず、統合先を読み直します。旧IDからたどれるか、顧客へ見せるべきでない情報が露出していないか、片方の約束が落ちていないかを確認します。通知や連携先への影響は環境に依存するので、事前に確認した範囲で点検します。
誤統合は「元に戻せる」と決めつけない
誤りが見つかったら、追加の統合や自動返信を止め、対象ID、見えた情報、残る作業、実行時刻を記録して管理者へ渡します。不可逆な製品では、バックアップがあるだけで簡単にunmergeできるとは限りません。情報共有の影響確認と、作業を別案件として再開する対応を分けて判断します。
候補生成の確認には、同顧客・別注文、別顧客・同文面、続報、同報メール、公開範囲の相違、片方だけの未完作業を含む架空例を使います。統合件数の多さではなく、誤って一つにしなかったか、必要な作業を残せたかを評価してください。候補の精度と、merge操作の安全性は別々に確認します。