パーセプションフロー・モデルに基づくSalesforce設計

　顧客体験を通じた目標設定によって全体最適が導かれると論じてきたが、もちろん設計しただけでは日々の活動には反映されない。Uniposでは、設計した顧客体験を各チームが日々の業務を通じて実現し、チームの協働が強まるようにSalesforceの設計を工夫しているので、その内容をご紹介しよう。

　下記は、パーセプションフロー・モデルで設計した「パーセプション」を軸とした、Salesforceにおけるフェーズ設計のイメージである（わかりやすさを重視してリードのワークスペースのみ紹介している。そのためパーセプションが途切れているが、商談でも同様の設計が続いて全顧客体験が構成されている）。

　加えて、ある顧客が各パーセプションに至ったと判断されたときに、Salesforce上の「成功へのガイダンス」欄を活用し、下記の3つの情報がセットで表示されるようになっている。

　このように、顧客を自社の行動ではなく顧客の状態で管理し、各パーセプションに応じた知覚刺激が一律に表示されることで、メンバーの習熟度にそれほど依存せず、適切な顧客対応が提供できる。また、業務の中で新たなノウハウが生まれた際もこの段階ごとに整理できるので、情報の流通が促進されセールスイネーブルメントとしても機能する。

　加えて、各段階で判定基準をクリアしなければ、次のパーセプションに進むことも、次のチームに申し送ることもできなくなっている。この判定基準は顧客体験全体から逆算の上で設計されているため、この基準に則って各メンバーが活動すれば全体最適がもたらされる構造だ。また、もしチーム間で問題が発生しても、「どのように判定基準や前述のパーセプションを設計し直せばよいか」という議論の基礎（共通言語）としても機能する。

　この判定基準について、MQL・SQLの一般的な定義づけと比較してみると、2つの大きな違いがありそうだ。1つ目の違いは、顧客体験の全体像を描いてから各パーセプションの条件を定めていること。各チーム間でMQL・SQLの定義を決めたとしても、最終的に顧客満足と継続利用につながる設計になっていない限り、第1回から述べている「部分最適」につながるリスクは消えないため注意したい。

　2つ目の違いは、前述の通り「自社の行動」ではなく「顧客の状態」をもとにした顧客管理を志向している点だ。たとえば、過去のメールの送信数・開封数などに基づいてスコアリングしたとしても、結局は自社の行動を起点とした管理でしかない。

　本来、何通のメールを送って何通開封されたからといって、顧客のパーセプションが適切に変わっているかは別の話であるし、また第3回で述べたようにパーセプションこそが顧客対応のあり方（知覚刺激）を決定づける要因なので、この視点の違いにも注意を要する。また逆にいえば、これらの要件を満たしたMQL・SQLの定義づけを各社が行っていれば、それとはよく似た基準だといえる。

　また、Uniposのマーケティングチームはこのパーセプションの情報を活用し、広告運用においても媒体指標ではなくパーセプション指標に対する最適化を図っている。これは、申し込みフォーム上で顧客のパーセプションに関する情報を取得し、それを各媒体・各クリエイティブのデータと突き合わせることで比較的容易に実現できる。またオンラインメディアに限らず展示会などであっても、パーセプション判定を行う設問を用意しておけば同様のスキームは構築可能だ（オンラインメディアと比較すると、展示会のほうがデータの整理とアップロードの工程が増えるため少し手間はかかる）。

　同じ発想で、パーセプションではなく「商談」や「受注」に対して最適化をかけることも技術的には可能だが、タイムラグが生じることと母数が少なくなることを鑑みると、各リードにパーセプション情報を付与して最適化を行うことが最も簡便かつ有用になるケースが多いだろう。

　このように、Uniposではパーセプションフロー・モデルを通じて一貫した顧客体験の構築と目標設定を行い、さらには各メンバーの日常業務につなげるためにSalesforceの活用を工夫している。他にも各チーム内での細やかな工夫が多く積み重なり、それが同社の隠れた競争優位性にもなっているが、その中でも本連載で説いた思想を最も顕著に体現し、核となっている工夫を紹介した。