サポートチケットシステムを好きな人がいるでしょうか。チケットを扱うサポート担当者からチケットを提出する顧客まで、皆が皆反感を持ちながら使っています。結局のところサポートチケットシステムは対応が遅く、融通がきかず、非人間的なのです。前時代的な手間のかかるコミュニケーション、すなわち無個性でよそよそしいサポートの代表です。なぜいまだに使っているのでしょう？
実は即時支援に慣れたユーザーの数が増えています。ハイテク技術による自助ポータルサイトであれ、すぐに使えるインスタントメッセージであれ、直感的なアプリ内ヘルプ機能であれ、すばやいサポートに慣れてきています。
しかしながら伝統的なサポートチケットシステムはまだ生きながらえています。依然としてサポート機能の常備品であり、いまだにユーザーは皆チケットを作らされ、必要な助けを待たなければならないのが一般的です。このことが次の疑問を投げかけます。現代のユーザーは本当にチケットを提出する必要があるのでしょうか？
サポートチケットシステムの最盛期
伝統的なサポートチケットシステムがもともと約束していたことはすばらしいものでした。洗練された統合環境を作り出していました。すべての問題が一緒に同じ列に入れられ、サポートデスクの全員からアクセスできました。このことはメールで得られるよりももっと協働的な環境づくりに役立ちました。
さらに、サポートチケットシステムは透明性をもたらしました。サポートチケットシステムではサポートデスクは前もって全体量と仕事の種類が一目でわかりました。これによって作業の優先順位が以前よりもつけやすくなりました。
また、比類ない有益性を与えたサポートチケットシステムならではの機能を考えてみましょう。サポートチケットシステムでは、ある種のワークフローと反応について、レポートを入手し、モニターし、自動化することができました。全体として、サポートチケットシステムは現場に登場した当初は歓迎されたテクノロジーだったのです。
何がその後に変わったのでしょうか？
世論の流れの変化
サポートチケットシステムの効率の素晴らしさについてサポートデスクが喜んで話をするのを見ることはほぼありえないでしょう。ネット掲示板の何百ものスレッドがビジネスユーザーがその制度に不満をいだいていることを証明しています。
その実例としてユーザーの日常的なコメントを２、３紹介します。
- チケットシステムはDVDプレーヤーのリモコンのようなものだ。80個のキーのうち４個しか使わないが、その4個を見つけるのが難しい。明らかに、どこにも問題点はないと考えている数名の技術者が作ったもので、すでに不満をいだいていて我慢できなくなっているユーザーテストは全くおこなっていない（Redditユーザー）
- チケットシステムのUIは××の役にも立たない（devRantユーザー）
- チケットシステムを理論的には強く支持するが、ソフトウェアの設計とユーザーのミスが組み合わさって、実用面ではひどい頭痛のタネでしかない（Twitterユーザー）
- ユーザーや顧客はチケットシステムのようなシステムをカスタマイズすることを強く主張している。チケットシステムには、ざっくりと定義され常に変わり続けるワークフロー、優先順位付け、承認、リリース管理システムを盛り込むべきだと誰もが考えているようだ（Hacker Newsユーザー）
- 誰もがチケットシステムを嫌っているか、少なくとも不満をいだいているようだ（StackExchangeユーザー）
もちろん、これは意見のほんの一部ですが、サポートデスクが日々チケットシステムを運用しているときに遭遇する頭痛のタネを浮き彫りにしています。
サポートデスクを悩ませるユーザビリティ
それでは、サポートチケットシステムを頭痛のタネにしている原因はなんでしょう？ 多くの要因が作用していますが、お粗末なユーザビリティということに要約できます。
チケットシステムのほとんどが大きくなり過ぎて、オプション機能をあれこれ満載したインターフェイスは複雑です。このシステムに本来備わっている複雑さが、サポートデスクが作り出そうと努力しているシンプルさを妨げています。機能が多すぎますし、あまりにも多くのことがおこなわれています。必要としていないルールとワークフローを作るはめになります。そしてそのルールとワークフロー存在する理由は、可能だからなのであって、存在すべきだからではないのです。混乱に拍車をかけるばかりです。
David Kaneda氏が書いているように「（サポートチケットシステム）は、あらゆることをおこなうよう設計されている。そして、あらゆることができる能力は理論的にはすばらしく思えるが、実際は、あらゆることを、それがシンプルな作業であっても、おこなうのがはるかに複雑になってしまう」のです。この複雑すぎる状況はユーザーとソフトウェア自体の両方の足かせとなります。
サポートデスクの視点から見ると、サポートチケットシステムは毒を盛られた聖杯のようなものです。すなわち、生産性を約束していますが、ユーザビリティの問題が阻害要因であることがあまりに多すぎます。
顧客を悩ませるユーザー体験
チケットシステムのもう一方の側はサポート要求を提出している顧客です。不幸にも、その体験も幾分不足しているものがあります。
その理由は、チケット制を介した解決へのジャーニーが、長く、よそよそしく、あまりにも段階が多すぎるからです。即時支援ではなく、チケットシステムという門番を顧客は通り過ぎなければなりません。そのために、顧客はサポートチケットを提出します。その後、包括的な自動応答とその対応のためのチケット番号を受け取ります。この手続きは対応順序の決定と追跡のために重要かもしれませんが、会話的な暖かい環境はほとんど生み出しません。
次に、顧客は人間によるサポートを待たなければいけません。そのサポートがいつおこなわれるかの予定については「24時間以内」（またはその企業の時間枠）というざっくりとした約束による大まかな見積もりしか得られません。その間顧客は問題と一緒にほったらかしにされます。
このことが必要以上に何層にも重なった長いジャーニーを作り出します。顧客は数字であり、顧客の問題はどこかへ送られ、顧客の価値は「CASE#053XA70D9FF」のようなオブジェクトのひとつに冷たくコード化されます。
どのユーザーからも嫌われている
どちらの側のユーザーもこれまでのサポートチケットシステムに幻滅しています。サポートデスクにとってチケットシステムは運用の邪魔です。顧客にとってチケットシステムは直接の支援を遅らせて、終わらせてしかるべき作業を積み残したままにします。
ですから、もはやチケット技術ではすぐれたユーザー体験を実現できないとなれば、その代わりにおこなうべきことは何でしょうか？ ひとつであらゆることに対応できる答えはありませんが、チケットの支配権を減らすことから始めるのが良いかもしれません。すなわち、サポートチケットへのルートを強要するのではなく、顧客にサポートの選択肢をもっと多く提供することです。
従来からのサポート方式に安心感をおぼえる顧客もいるかもしれません。しかし、顧客の期待が古いシステムではもはや対応できない場合は、ブランドはもっと良い体験を提供しなければいけません。
それに含まれるものには、サービスデスクへのチャットボットの組み込み、ライブチャットの提供、電話サポートの拡大、オンラインコミュニティーへの支援改善、すべての選択肢のオムニチャネル化などがあるでしょう。
要は顧客に権限を与えることです。サポートチケットは単独のサポートとしては柔軟性がありませんが、そのことは柔軟性のないサポートジャーニーでよしとする理由にはなりません。
対話がチケット制に勝る
サポートチケットの支配権を減らすことによって、もっと自然な対話への道が開かれます。チケット制でコミュニケーションのない、ロボットのようなスタイルが作られました。遅れによって妨げられ、ルールの複雑なエンジンに依存し、「##この線以下には書き込まないこと##」という魅力的なインスタンスによって目印をつけられます。
ユーザーにこのルートを強要するのはお粗末なUXのやり方です。Ruairí Galavan氏は「速度が遅く途切れ途切れで人間味のないコミュニケーションが標準として受け入れられていた時代は過去のものだ」と言っています。企業はプロダクトやデザインにおける滑らかさを得ようと努力していますが、それならばなぜサポートプロセスにおける不便な断絶を押し付けるのでしょうか？
つまりこれが、ブランドがいま伝統的なチケット制という考え方から顔をそむけ始めている理由です。チケット制は取引業務であり、閉ざされたループ内での一度だけのやり取りです。一方、会話の方は開いています。展開します。それはすなわち、会話がブランド擁護にも扉を開いていることを意味しています。
単なるチケット
滑らかなユーザー体験ということでいえば、チケット制はもはや単なるチケットではありません。従来のサポートチケットシステムはビジネスユーザーにとって、ユーザビリティブラックホールであるだけでなく、顧客を遠ざけモノ化する可能性もあります。
ですから、ユーザーをチケットで窮地に追い込むのをやめましょう。代わりに円滑に会話することに注意を集中してください。
会話はすばやく滞りなくなめらかに進みます。親しみやすく人間味があって、さまざまな方法で事情を説明する顧客それぞれに合わせる柔軟性を持ちます。要するに、会話は見落とされがちなすぐれたUXのひとつの側面なのです。
