要約

  • 統合で閉じたチケットの過去コメントは参照できるが、項目が統合先へ自動的に引き継がれるわけではない。
  • 統合済みチケットの除外、返信数の計算、CC の追加は別々の判断であり、一覧の整理だけでは対応の改善を示せない。

残すケースを選ぶという判断

同じ問題について届いた二つの問い合わせを、一つの場所で扱う。チケットの統合は、そのための合理的な整理になり得る。ただし Zendesk の公開資料が説明するのは、二つのケースを完全に混ぜ合わせる処理ではない。統合先を選び、元のチケットを閉じ、以後の対応に使う記録を作る操作である。

ここで重要なのは、統合先が何を引き継ぐかだ。Zendesk は、元のチケットのタグ、種別、優先度、ステータスなどの項目は移らず、統合先で入力済みの項目が保存されると説明している。統合先の選択は、作業記録に残る分類の選択でもある。

関連する問い合わせでも、深刻さの評価が異なることは考えられる。仮に二つの優先度が異なるなら、統合したという事実だけでは、高い方が新しいケースに採用されたとはいえない。これは実際の顧客設定を調べた事例ではなく、公開ルールを理解するための例である。

適切な統合先を選ぶ理由があることと、システムがすべての項目を調整することは違う。後から読む人が、統合先の値を元の全ケースの調整結果だと考えるなら、記録の読み方に誤解が生じる。製品は、その調整を自動で行うとは説明していない。

買い手にとっての意味は、未確認の追加料金ではなく、問い合わせの証拠を使い続けられるかにある。記録は繰り返す問題や必要な人員、受けたサービスの評価に使われる。チケットをまとめる機能と、まとめた後の記録を正しく解釈する運用能力は同じではない。

履歴の参照は、完全な移行ではない

Zendesk は、閉じた元チケットで以前のコメントを確認できるとしている。したがって、統合が全履歴を消去するという説明は正確ではない。一方、履歴へ戻れるからといって、統合先に全コメントと全項目が直接複製されるわけでもない。

通常の画面では、元チケットの最新の公開コメントが統合ウィンドウに表示される。担当者は変更や削除を選べる。そうしなければ、その内容は閉じたチケットへのリンクとともに、統合先のコメントに含まれる。他の過去コメントは新しいチケットへ直接並ぶのではなく、以前の記録で参照する。

つまり、残るのは特定の参照経路だ。現在のケースだけを見る人と、リンクから元記録を読む人は、同じ対応経緯の違う部分を見る可能性がある。これは全情報の消失を意味せず、現在の画面が全経緯を平坦に表示するという保証にもならない。

添付ファイルには別の扱いがある。API の資料では、元チケットの添付が統合先へコピーされ、統合先コメントに含まれる場合があると説明されている。コピーされた添付、リンクで参照する会話、引き継がれない項目は、異なる継続の形である。

「データが残る」という一言では、この違いを説明できない。運用の責任者は、後の読者にどの文脈を直接見せる必要があるか、どの相違を理由とともに残すかを判断する必要がある。ボタンを押せることだけでは、その判断は済まない。

集計の母集団も選び直される

統合で閉じた元チケットには closed_by_merge というタグが付く。Zendesk の Explore の手順は、そのタグを使って該当チケットを集計から除く方法を示している。また、統合で閉じたチケットの項目に基づく該当のレポートは作れないと説明している。

この制限を、すべての記録が物理的に消えるという話へ広げてはいけない。独立した監査や分析が一切不可能だという意味でもない。公開資料が示すのは、過去の参照記録と集計に使う単位の役割が同じではないという点である。

重複しない作業ケースを数えるために元チケットを除くことは、適切な場合がある。ただし、それが届いた全問い合わせ数を測るという別の問いに答えるとは限らない。製品は除外の方法を提供する。何を測るための母集団かは、利用組織が説明する必要がある。

返信数に基づく指標では、コメントの扱いも関係する。Zendesk の一回返信に関する FAQ は、返信が二回未満の解決済みまたは閉じたチケットを対象とし、統合コメントが既定で計算に含まれるとする。統合チケットを除外する方法も案内している。

だからといって、すべての統合が率を上げたり下げたりするとはいえない。以前の会話、コメント、抽出条件、計算が方向を決める。今回、顧客の率を測ってはいない。根拠のある結論は、前後比較には同等の母集団とコメント処理が必要だということだ。

短くなった一覧は、ケースの整理方法が変わった結果かもしれない。それだけで、仕事が減った、顧客がよりよい対応を受けた、という結論は得られない。除外自体が誤りなのではなく、結果を語る際にその除外が説明されないことが問題になる。

この対象は、AI の解決課金が本当に完了を表すか、席単価が妥当かという以前の論点とも異なる。ここで問うのは、統合後にどの分類とどのケースが比較の証拠として残るかである。

コメントの非公開化と参加者は別の制御

通常のルールでは、CC を有効にしていれば、異なる依頼者のチケットを統合できる。閉じた元チケットの依頼者は統合先の CC となり、元のチケットの CC も追加される。CC が無効なら、同じ依頼者であることが求められる。

統合コメントを内部メモにすることは、それだけで追加された参加者を外す操作ではない。逆に、CC が追加されたからといって、過去の内部メモがすべて公開されるという説明もできない。会話の参加者と、個々のコメントの公開範囲は分けて確認すべきだ。

通常画面には公開返信と内部メモの選択があり、関連チケットの提案からの統合では依頼者と CC への表示を選ぶ項目がある。実際に使う経路と保存された結果を確かめる必要がある。同じ操作名だからといって、画面や顧客設定に共通の既定値を仮定してはいけない。

入力欄の文字をすべて消す場合にも注意がいる。Zendesk は、そうした場合に元チケットの最新コメントが更新コメントとして使われることを説明している。空にしたという操作だけでは、コメントが出力されないと保証できない。

API は、統合コメントが既定で非公開であり、許された場合に公開範囲のパラメーターで変更できるとする。非公開チケットや資料に記載されたソーシャルチャネルでは別の制限がある。これは API の条件であり、全画面の既定値ではない。今回、情報開示の事故を確認したわけではない。

警告と権限、処理完了と成果

異なる組織、ブランド、依頼者について画面が警告を示しても、すべての境界を越えられるという権限の証明にはならない。現在の API 資料は、ブランド分離が有効なら同じブランド内に統合を限定すると説明している。担当者の役割と Enterprise の統合権限も条件に含まれる。

API はタスク状態を返して統合の作業を処理に回し、資料は完了の確認を求める。最初の応答が必ず待機中だと表現するのは不適切だ。現在の例には完了済みの状態もある。依頼の受理、統合の完了、顧客の問題の解決は異なる結果である。

Zendesk は統合を恒久的で取り消せない操作と説明する。それでも旧コメントを参照できるという二つの事実は両立する。履歴は判断を説明する助けになるが、以前のケース配置を復元する取り消し機能にはならない。

今回の研究は、顧客 API を呼ばず、チケット、役割、CC、添付を変更していない。時間短縮や件数削減、漏えいも測っていない。市場の観点で必要なのは、記録をまとめる能力と、その後の証拠を説明する能力を別々に確かめることだ。

出典