【ITニュース解説】Ticketing system for customer service: what it must handle

顧客サービスのためのチケットシステムは、システムエンジニアを目指す皆さんにとって、業務効率化と顧客満足度向上に不可欠なソフトウェアの一つである。これは、顧客からのあらゆる問い合わせを「チケット」という形で管理し、その一つ一つに担当者、現在の状況（ステータス）、そしてこれまでのやり取りの履歴を持たせる仕組みを指す。メール、Webフォーム、チャット、電話のメモなど、どのような経路で顧客から連絡があっても、これらすべての情報が一箇所に集約されるのが特徴である。ガートナー社は、この種のシステムを「カスタマーエンゲージメントセンター」と称し、ケース管理を中心としたソフトウェアであり、問い合わせの作成、担当者の割り当て、適切な部署への転送、そして必要に応じた上位者へのエスカレーションを行い、顧客との一連の会話をまとめるものと定義している。

このシステムがなぜ重要かというと、一般的な共有受信トレイやCRMシステムでは対応しきれない課題を解決するためである。例えば、OutlookやGmailの共有受信トレイでは、誰がどのメールに返信したのかが不明確になりがちである。結果として、同じ顧客に二人が返信してしまうか、誰も返信しないまま放置されるという問題が発生する可能性がある。また、チケットごとのステータスや顧客との過去の履歴、統計情報も把握できない。一方、CRM（顧客関係管理）システムは、顧客の基本情報、契約内容、商談状況などを管理するが、個別の問い合わせが現在誰の手にあり、何が約束され、いつまでに解決されるべきかといったチケットの具体的な進行状況を管理する機能は持たない。チケットシステムとCRMはそれぞれ異なる役割を持つため、理想的には連携しつつも、同一のシステムとして扱うべきではない。

「チケット」という言葉が持つ意味は非常に大きい。一つのチケットは、問い合わせの「始まり」から、その担当となる「所有者」、問い合わせの「種類」、そして「解決」という「終わり」までの一連の流れを示す。この明確な構造があるからこそ、顧客サービスのプロセスを具体的に測定し、改善へとつなげることが可能となるのだ。例えば、「先週、どのチャネルからどのような種類の問い合わせが何件あったか」「平均応答時間はどれくらいか」といった具体的なデータを把握できるようになる。

チケットシステムの核心となる機能は主に七つあり、多くのシステムがこれらを基本的な要件として備えている。しかし、その機能がどのように連携し、どれだけ効果的に使えるかがシステムを選ぶ上でのポイントとなる。

まず第一に、「あらゆるチャネルを一つの受信トレイに集約する」機能が挙げられる。これは、顧客からのメール、ウェブサイトの問い合わせフォーム、チャットの会話、電話で受けた内容のメモなど、すべての顧客からの連絡が、まるで一つのメールボックスに入ってくるかのように、同じ画面でチケットとして表示されることを意味する。ここで重要なのは、チャットやフォームが独立したツールとして存在し、それらのログが別々に管理されている状態ではないことである。すべてが一元管理されていることで、担当者は顧客からの情報を探し回る手間が省ける。

次に、「チケットタイプとフィールド」の機能も重要である。これは、問い合わせの種類、その原因、そして最終的な解決結果などを、あらかじめ定義された固定値（例えば「技術サポート」「請求について」「製品要望」といった選択肢）の中から選んで入力できるようにすることである。これにより、問い合わせ内容が正確に分類され、後からデータを集計・分析しやすくなる。システムがチケットをクローズする際にこれらのフィールドの入力を必須にできるか、そしてそのデータに基づいてレポートを作成できるかがチェックすべき点である。勝手にタグを追加できるようなシステムでは、データが乱雑になり、結局分析に役立たない「データのようなもの」を生み出すだけになってしまう。

三つ目は、「担当者とステータス」の管理機能である。これは、それぞれのチケットに担当者（所有者）を割り当て、そのチケットが現在どのような状態にあるか（例：「顧客からの返信待ち」「担当者対応中」「解決済み」など）を明確にすることである。チケットに担当者が割り当てられていない状態をシステムが許さないように設計されていることが望ましい。これにより、問い合わせが放置されることを防ぎ、責任の所在を明確にできる。

四つ目は、「応答時間目標」の設定機能である。これは、特定のチャネル（例えばチャットやメール）やチケットの種類ごとに、顧客に最初に返信すべき目標時間を設定し、その時間が近づいたり超過したりした場合にアラートを出す機能である。この目標時間は、担当者がチケットを割り当てられてからではなく、顧客が最初にメッセージを送ってきた時点から計測されるべきである。これにより、顧客の待機時間を客観的に評価し、サービスレベルを維持・向上させることが可能になる。

五つ目は、「顧客履歴」の確認機能である。これは、担当者が現在対応している顧客の過去のすべての問い合わせ履歴や、可能であれば購入履歴なども含めて、同じ画面で一元的に確認できるようにすることである。これにより、顧客が過去にどのような問題を抱え、どのような製品を購入したのかを瞬時に把握でき、よりパーソナライズされた適切なサポートを提供できるようになる。システムが過去のメールだけでなく、自社の他のシステムから顧客データを取得できるかどうかも重要である。

六つ目は、「テンプレートと推奨返信」機能である。これは、よくある質問に対する回答や定型的な返信文を、あらかじめシステム内で作成し、担当者が迅速に利用できるようにするものである。これらのテンプレートは、内容がレビューされ、承認されたものであることが重要である。そして、ヘルプセンターに公開されている情報とテンプレートが同じ情報源から提供されていることが理想的である。これにより、顧客がヘルプセンターで得られる情報と、担当者から受け取る情報との間に齟齬がなくなり、一貫したサポート体験を提供できる。

最後に七つ目は、「レポート機能」である。これは、チケットの種類別、利用されたチャネル別、時間帯別、担当者別のチケット数や、平均応答時間、解決率といった、顧客サービスのパフォーマンスを示す様々な指標を可視化する機能である。レポートは単に数字を並べるだけでなく、「顧客が何について問い合わせているか」という本質的な問いに答えられる内容であることが重要である。これにより、サービスの課題を特定し、改善のための具体的なアクションを計画できるようになる。

2020年頃のチケットシステムと、2026年頃の最新システムとの間には、大きな違いがある。かつてのシステムは、受信トレイを中心に構築されており、顧客への回答は担当者の知識や個別のテンプレートリストに依存していた。しかし、これからのシステムでは、「ナレッジベースが中核」となる。これは、レビューされ、承認された信頼できる情報源から、同じ情報が三つの形で提供されるべきだという考え方である。具体的には、顧客が自己解決できる「ヘルプセンターの記事」として、リアルタイムの問い合わせに対応する「チャットの回答」として、そして担当者が顧客に返信する際の「受信トレイの下書き」として、一貫した情報が共有される。これにより、顧客も担当者も、常に最新かつ正確な情報にアクセスできるようになり、サービス品質の大幅な向上が期待される。ナレッジベースを中核とすることで、単なるFAQ集では対応しきれない複雑な問い合わせにも対応できるようになるのだ。