「カスタマーサービス」はユーザーエクスペリエンスの機能と見なす必要がありますか？
UIとUXの専門家の努力にもかかわらず、ユーザーは時々行き詰まったり、ソフトウェアを使用してバグを経験したりします。彼らの欲求不満がユーザーエクスペリエンスの低下の指標であることに同意できると思います。それでも、カスタマーサポート担当者との有意義で役立つ会話により、問題が発生した後、そのユーザーは製品についてさらに良い気分になることができます。
顧客と製品を代表する人々との関係が彼らの意見に大きな影響を与えることを何度も目にしました。
では、CSとUXがまったく関係のない部門であるのはなぜですか？ CSがUXに報告している会社はありますか？あるべきですか？
絶対に！
Intuit（Quickenを製造している会社）には、まさにこの理由のために、製品設計者にカスタマーサポートラインを配置しています。
サラリーマンの高い製品設計者によるフィールドサービスコールにより、将来の製品、特に現在の製品設計に関する顧客の問題が顧客から直接通知されます。
（出典：ハーバードビジネスレビュー、「サービスビジネスが正しくなければならない4つのこと」、フランシスX.フライ。）
カスタマーサービスは、統計と実際のユーザーエクスペリエンスの貴重な情報源です。製品が技術的にまたはユーザーエクスペリエンスで失敗すると、即座にフィードバックが得られます。適切に処理すると、ユーザーがタスクの完了に失敗するUX問題のトップリストが表示されます。このトップリストをUX部門に渡せば、実際のユーザーが失敗した場所と理由を喜んで読んでくれるでしょう。
このプロセスは、組織の問題ではないと思います。このプロセスは、マトリックスの組織（機能とプロセス）で簡単に設定でき、カスタマーサービスがUX部門と週に1度会ってUXの問題を確認するためです。しかし、その通りです。カスタマーサービスとUX部門の間に関係があるはずです。
UIとUXの専門家の努力にもかかわらず、ユーザーは時々行き詰まったり、ソフトウェアを使用してバグを経験したりします。彼らの欲求不満がユーザーエクスペリエンスの低下の指標であることに同意できると思います。
完全に同意します。バグが発生します。これはユーザーエクスペリエンスの低下を示していますが、それを分析してみましょう。バグは必ずしも設計が不十分なエクスペリエンスの結果ではありません。バグは設計に関連している可能性がありますが、ソースコードまたはコンパイラに関連している可能性もあります。
では、CSとUXがまったく関係のない部門であるのはなぜですか？
これは、ソフトウェアを作成する組織の規模と規模に大きく依存します。小さなチームの場合、従業員はおそらくUXやCSを含む複数の帽子をかぶっています。大企業の場合、ソフトウェアの作成とそのソフトウェアのサポートには、何十もの組織、部門、チームが関与する可能性があります。典型的なソフトウェアソリューションの例と、ソフトウェアを入手するときに顧客が経験する可能性のあるものを取り上げます。
- 製品を研究する
- 製品の事前注文（利用可能な場合）
- 製品を注文する
- 注文の払い戻し
- ソフトウェアをダウンロードする（デジタルの場合）またはソフトウェアを受信する（物理ディスクの場合）
- ソフトウェアをインストールする
- ソフトウェアを使用する
- ソフトウェアをアンインストールする
- サポート問い合わせ先
さて、これは一般化を超えていますが、これらは顧客がソフトウェアを入手するためにとるステップです。会社の規模に関係なく、顧客サポートチームがこれらすべての手順に関連する連絡先を担当しますだけでなく、関連するハードウェア、サードパーティベンダーなども担当します。
大企業では、これらのステップごとに複数のUXチームが設計している可能性があります。マーケティング、オンラインストア、請求、製品、カスタマーサポートに取り組んでいる設計チームがあります。これらすべてのチーム（特にカスタマーサポートUXチーム）は、内部向けの設計にも取り組んでいます。 CS UXチームは、ナレッジマテリアルを提供する効果的な方法、サポートチームへの連絡方法、CSRが顧客にサポートを提供するために使用する内部ツールなどを設計しています。 つまり、CSを単にUXチームに投入するのではなく、おそらくCSがUXチームを持つことがより重要です。そのUXチームは、他のUXチームと連携して、よりシームレスな製品を提供する必要があります。エンドツーエンドのエクスペリエンス。
CSがUXに報告している会社はありますか？あるべきですか？
Msanfordが述べたように、CSチームは顧客の問題に対処する効果的な方法がありますが、CSチームは多くの場合、それらのバグが何であるかをチーム/組織/会社に通知するためにユーザーに依存します。主題の専門家が顧客と直接バグについて話し合う機会を与えることは、顧客が製品についてどのように感じるかに影響を与えるだけでなく、バグ自体の解決へのはるかに速い道を提供することもできます。詳細を述べることはできませんが、他社はIntuitと非常によく似た戦術を持っているだけでなく、顧客に製品の将来の状態を案内する手助けをする能力を提供しています。
「ユーザーエクスペリエンス」には、エンドユーザーと会社、そのサービス、および製品との相互作用のすべての側面が含まれます。模範的なユーザーエクスペリエンスの最初の要件は、煩わしさや煩わしさなしに、顧客の正確なニーズを満たすことです。次に、所有する喜び、使用する喜びである製品を生み出すシンプルさとエレガンスがあります。真のユーザーエクスペリエンスは、顧客が望むことを提供したり、チェックリスト機能を提供したりすることをはるかに超えています。企業が提供するサービスで高品質のユーザーエクスペリエンスを実現するには、エンジニアリング、マーケティング、グラフィックおよび工業デザイン、インターフェースデザインなど、複数の分野のサービスをシームレスに統合する必要があります。
カスタマーサービスはUXの大きな部分を占めています。組織によっては、製品との相互作用の開始点になる場合があります。何かがうまくいかなかった場合、それは単に何かがあるのではありません。 Zapposのような企業を見ると、カスタマーサービスは実際にユーザーエクスペリエンスを向上させ、そのおかげで非常に成功しています。
カスタマーサポートのビジョンは一般にUXの設計から始まるため、UXとCSは相互に排他的ではありません。 UXの専門家として、UXをアプリケーションのみに制限している場合、エクスペリエンスに大きな人間的要素が欠けていることになります。カスタマーサービスの測定基準を収集することは決して困難ではありません（または珍しくありません）。
したがって、あなたの質問に答えるために、UXには多くのことがあり、カスタマーサービスはユーザーと会社、サービス、および製品との相互作用に間違いなく影響を与えます。
ユーザーエクスペリエンスの観点から、製品またはサービスをどのように定義しますか？そのユーザーとそのユーザーとの間のタッチポイントのコレクションを確認します。これらのタッチポイントは、サービスのユーザビリティに与える影響によって優先順位を付けることができます。
上記のロジックによると、カスタマーサービスがユーザーと対話する方法は、ユーザーエクスペリエンスの重要な部分です。「サービスソーンズは大丈夫でしたが、カスタマーサービスに電話する必要があったときこんなにひどい時間があったので、もう使いません」.
現実的には、どういう意味ですか？
カスタマーサービスのプロセスと標準は、ソフトウェアを設計する同じ人々によって設計および評価される必要がありますか？答えはおそらくイエスです。製品またはサービスには明確に定義された値のセット（適切に管理されている場合）があり、これらの値は製品/サービスとユーザーの間の重要な接点であるため、カスタマーサービスチームが反映する必要があります。これらの値が適切に表現されていることを確認できるのは、製品マネージャーに勝るものはありません。
カスタマーサービスチームは、ユーザーエクスペリエンスを通じて組織に報告する必要がありますか？おそらく違います。 CSは通常、より広い権限を持つ他の部門のサブセットになるにはあまりにも重要であると見なされます（または、悪い会社では、他の部門に負担をかけるにはあまりにも重要ではありません）。会社。カスタマーサービスには、ソフトウェアベースのユーザーエクスペリエンスデザインとは明らかに異なる実用的なスキルセットも必要です。電話に出たり、特定の問題を抱えた人間にメールを送ったりします。
したがって、このスレッドですでに述べたように、UXサービス担当者をカスタマーサービスに入れて、ユーザーに提供される専門知識のレベルを上げ、UXチームの直接的なフィードバックデータを増やすことを試みる企業があります。しかし、最初にカスタマーサービスをどのように構築するかについては、最も賢明なアプローチは、採用する人のタイプとプロセスの設計とレビューの方法ではなく、UXチームとの緊密なコラボレーションを自然に促進することだと思いますCSチームとソフトウェアUXチームの構築/管理の現実が非常に異なるため、レポート構造を通じてこのコラボレーションを人工的に構築しようとすると、会社のパフォーマンスにとって最適ではない可能性があります。
ベニーは、カスタマーサービスは、システムを理解する上でイライラしたユーザーの最初の連絡窓口となることが多いため、統計とユーザーエクスペリエンスの問題の優れた情報源であると述べています。
また、カスタマーサービスはシステムのパワーユーザーであることが多く、ユーザーがタスクを実行するために実行できるさまざまなプロセスフローを十分に認識しており、UXデザイナーと組み合わせて作業する場合、プロセスフローをより明確にする方法や、プロセスをやり直すために必要な労力を削減する方法について、貴重な情報を提供します。さらに、これらはパワーユーザーであり、リアルタイムユーザーにとっての重要な参照ポイントでもあるため、最もアクセスしやすく、簡単に利用できる必要がある機能や、セカンダリレベルのナビゲーション内に非表示にできる機能に関する貴重な入力を提供できます。
UXデザインサイクルへの統合に関しては、それらを導入するのに最適な場所は、
- 初期分析フェーズ中：これは、サイトのユーザーが直面しているユーザビリティとUXの問題の一部に貴重な情報を提供できるためです。
- 設計およびプロトタイピングのデモンストレーションフェーズ中：これにより、サイトの潜在的な変更を評価し、どの機能をより目立つように表示し、どの機能を非表示にするかに関する入力を提供できます。
事例の観点から見ると、DocusignでのUXインターンシップ中の要件の1つは、UX設計チームがユーザーサービスの担当者と会ってユーザーの問題を理解することでした。カスタマーサービスチームの代表は、設計の説明会に参加して、プロセスフローに関する入力と、最も要求された機能と浮上する必要のある機能に関する優先アクションを提供することも求められました。
企業がCSを真剣に受け止める場合、CS部門に寄せられる批判の苦情には、それに伴うコストが伴うはずです。したがって、たとえば、誰かが赤いSquidgetを注文する方法を見つけることができず、CSを呼び出す必要がある場合、彼らは彼らにRed Squidgetを無料で送信します。これにはコストがかかるため、顧客が経験した問題には明確な最終コストがかかります。
その後、他の顧客が赤いSquidgetを注文できないと不満を言わないように、改善を促す必要があります。 CSからのフィードバックは、必要に応じて、顧客が溶接が破損しているやかんを報告した場合と同様に、それを修正できるようにサプライヤーに報告する必要がある場合、それ以上のコストを軽減する必要があります。
さて、すべての問題にUXの修正が必要なわけではありませんが、UXの問題に明確な経済的コストがある場合は、優れたUXを提供するインセンティブがあります。
これは、あなたが顧客に提供している製品/サービスの性質によって異なると思います。問題は、顧客という用語は、会社が提供する製品/サービスを購入した人はすべて顧客であることを意味しますが、実際には製品/サービスのエンドユーザーではない可能性があります（たとえば、マネージャーがソフトウェアを購入します）チーム）。
以前、プライマリと セカンダリカスタマー の違いについて質問しました。これは、購入者とユーザーを区別するための私の試みです（同じ人物である可能性があります）。
あなたは顧客とユーザーになることができますが、ユーザーと顧客になることはできないため、カスタマーエクスペリエンスはより包括的な用語である必要があると思います。製品を扱う経験はUX風味が多く、顧客サービスの部分は顧客満足度/経験と関係があります。