メカニズムデザイン（経済学）で「利用者がFAQ見てくれない問題」を考える
システム運用などの現場でよくある「利用者がFAQを見ずにとりあえず問い合わせてくる」問題。この記事ではこの問題を経済学の一分野であるメカニズムデザインの観点から考え、また現在問合せ最適化のデファクトスタンダードになっているチャットボットが果たす役割について考えます。
結論:
利用者がFAQを見ないのは、利用者の「素早く困りごとを解決したい」という欲求が、担当者にとって好ましい状態である「FAQを自分で調べてから問合せをする」に繋がらず、好ましくない状態である「とりあえず問い合わせる」に繋がる"メカニズム"になってしまっているから。これが一致するように"メカニズム"をデザインすればよく、その代表例がチャットボット。
FAQが見られない理由
まず、FAQが見られない理由は、質問が自らの「素早く困りごとを解決したい」という欲求を満たすための最も効果的な方法が「FAQを見てから問い合わせること」ではなく「とりあえず問い合わせること」だと認識しているからです。これには様々な背景となる要因が考えられます。
・問い合わせ対応への反応が早いことがわかっているので、FAQを見る前に問合せた方が早いと思っている
・実際に過去FAQを見たが解決できなかった経験から「FAQは見てもしょうがないもの」という考えを持っている
FAQの場所を繰り返し周知することは事態を悪化させる？
この問題に対し、よく聞く解決策が「利用者にFAQの場所を繰り返し周知しよう」です。しかし、仮にFAQの場所を知っていても、FAQを見るより問い合わせた方が早いと思っている質問者は、FAQを見ることはないのです。
むしろ、個人的には事態を悪化させることすらあるのではないかと考えています。FAQの場所を繰り返し周知することは「担当者は利用者の不便を解決するために何でもしてくれるんだ」という印象を与え、利用者の甘えを助長させる可能性があります。
メカニズムデザイン
この問題に対してメカニズムデザインを使って考えてみたいと思います。
メカニズムデザインとは？
メカニズムデザインとは、経済学の一分野で、実現したい目標が与えられたとき、プレイヤーがその目標ではなく自らの欲求を優先して行動したとしても結果としてその目標が実現されるような仕組みを設計することを目指す学問分野です。
代表的な事例が、ロンドンで導入された交通渋滞緩和・大気汚染抑制のための混雑税（渋滞税）です。自動車が集中するエリアの、集中する時間帯の通行に対して課金を行うことで、代替ルートや他の移動手段の利用を促進しようとするものです。
通勤電車の混雑緩和を目的としてJRが行っている、ピーク時間帯を避けて電車に乗った場合にポイントを付与する「オフピークポイント」キャンペーンもメカニズムデザインを応用した取り組みと言えます。
混雑税は「好ましくない行動に対しコストを設定する」ことで、オフピークポイントは「好ましい行動に対して報酬を設定する」ことで、プレイヤーが自らの欲求を優先して行動したとしても、結果として「混雑緩和」という目的が達成されるためのメカニズムをデザインしているわけです。
メカニズムデザインでFAQを考えると？
では、メカニズムデザインでFAQを考えてみましょう。
FAQの問題の場合、実現したい目標は「担当者の負荷を減らすため、質問者が自身でFAQを検索し解決を試みた上で、それでも解決しなかった場合のみ問合せをする状態を作ること」です。定量的なKPIとしては、FAQによる問合せの解決率、問合せに対する応答・回答時間、問合せにかかった工数、などになるでしょう。
そして、これを質問者が「FAQだろうが担当者だろうがどちらでもよいので、素早く困りごとを解決したい」という欲求を優先して動いた結果、満たされるようにデザインしなくてはなりません。
チャットボットは何をしている？
問合せ最適化においてデファクトスタンダードになりつつあるチャットボットは、この問題に対し、綺麗なデザインを提供しています。
チャットボットは質問者が利己的に動いた結果担当者にとっても好ましい結果になるように誘導している
チャットボットでは、下記の様な流れで問い合わせが行われるようになっています。
① 質問者がチャットボットに対して問合せを行う
② チャットボットが自動でFAQを検索し、関連性の高いと思われるものがあれば提示する
③ 質問者は提示されたFAQを確認し、解決できない場合のみ担当者への問い合わせを行う
この流れにおいて、質問者は「担当者の負荷を減らすために自分で調べてから問い合わせるかー」などとは考えていません。とにかく自分の困りごとを解決してほしいという欲求のみに従っているにもかかわらず、結果として担当者にとっても好ましい状態になっているのです。
FAQの場所を周知する代わりにすべきこと
チャットボットを導入できればそれでよいのですが、実際には導入・維持コストを考えると、大規模なシステムなどでないとROIが出せず、厳しいと思います。そんな場合に、メカニズムデザインの視点でできることを考えてみます。ここからは色々な考え方ができると思いますが、私は次のように考えました。なお、そもそも「FAQには役に立つ情報が載っておらず問い合わせた方が早い」状態であれば、意味がありませんので、FAQのコンテンツが充実している、検索性が工夫されている、コンテンツの質を改善する活動がされていることは当たり前として、それに加えてやるべきことを考えます。
質問者を誘導する
チャットボットに学び、質問者が意識せず好ましい状態に向かうよう誘導するアプローチです。
・問い合わせフォームにFAQへのリンクを張っておく
・問い合わせフォームでカテゴリを選択すると、当該カテゴリのFAQのリンクを自動表示する
・問い合わせ内容を入力すると、問合せフォーム上にFAQの検索結果を表示する
質問者にリフレーミングさせる
質問者の「問合せ方が早い」という考えを改め「FAQを調べた方が早い」にリフレーミングすることで、質問者の欲求と好ましい状態を一致させるアプローチです。
・FAQによる問合せの解決率を周知（当然十分高いことや、向上していることが前提）
・FAQを見た場合と、問合せ場合の問題解決までの平均所要時間を周知（FAQが十分なカバー率があれば、圧倒的に前者が短くなるはず）
・問い合わせ対応のサービスレベルを下げる（これはFAQが十分なクオリティに達していないと利用者の不満を招く可能性があります）
まとめ
今回はFAQを例にしましたが、これに限らず好ましい結果に誘導するために「人々が快を求めた結果、気づいたら自分たちの好ましい結果に向かっている状態を作るための仕組みをデザインできないか？」という考えたは様々な場面で応用可能だと考えます。
以上です。