SFAを活用してSaaSのマーケティングからセールスまでのデータを一元管理。KPIのリアルタイム監視を可能に。

おはようございます。

SUPER STUDIO COOの花岡です。

弊社では、法人向けECプラットフォーム「ecforce」をSaaSとして事業展開しておりますが、非常にありがたいことにクライアント様の口コミで伸びてきたサービスでして、2020年ぐらいまで王道なマーケティングを行ってきませんでした。

そのため、マーケティングからセールスまでのデータが一元管理されておらず、KPIの予実確認に時間を要したり、まともなデータ分析もできていない状態でした。

先日の資金調達にて大型マーケティングを実施していくにあたり、マーケティングからセールスのKPI設計をしっかり行い、データをリアルタイムで把握できる仕組みをSFAを活用して構築しましたのでnoteでその内容を公開したいと思います。

SaaSのマーケティングからセールスの組織構築に苦戦している、データに信頼性がなかったり、データ分析に膨大な時間を要しておりリアルタイム性がない、そういった状況でお困りの方の参考に少しでもなれば幸いです。

※前半はそもそもKPIについてのお話ですのでSFA周りの話に興味のある方は4章からお読みください。

1.マーケティングからセールスのKPI設計で意識しておいたほうが良いこと

僕はCOOとしてSUPER STUDIO全体のKPI設計を行っておりますが、マーケティングやセールスに限らず、そもそも組織全体のKPI設計で必ず意識しなければいけないことがあると思っています。

①KPIは管理下におけるものにすること
②組織間のKPIが利益相反になっていないこと
③KPI達成をハックできない仕組み

①KPIは管理下におけるものにすること

当たり前なのですが、KPIは個人にしろ、チームにしろ管理下におけるものを主要KPIにしなければなりません。管理下におけるとは、個人やチームの努力だけで達成することが可能な状態を意味します。

マーケティングからセールスまでのKPIの要素として、リード数、案件数、受注数などがあります。

例えば、マーケティングチームはマーケティングで創出するリード数は管理下におけますが、リードを案件化していくのはインサイドセールスのため案件数は管理下におけません。もちろん、受注数も管理下におくことはできません。

しかし、事業としては受注数を伸ばすためにリード数も案件数も必要なわけなので、リード数や案件数が達成していても、受注数が達成していなければ微妙だよねということになりますのでチームとして連帯責任にはなる。

②組織間のKPIが利益相反になっていないこと

セールスとサクセス間で発生しがちなことですが、契約後のアップセルはサクセスのKPIではあるのですが、契約前に信頼されているのがセールスなので、セールスが契約後のアップセルを獲得できてしまうこともあります。

そうすると、本来サクセスの見込み案件がセールス側に取られてしまうため、会社主語でみたときには良いことのはずなのに、現場では利益相反関係が発生してしまいます。

可能な限りこういったことがおきない、もしくはおきてもセールスやサクセスも納得できる仕組みを導入しておく必要があるかと思います。

これはSaaSの営業活動に限らず規模が大きくなると、一定発生してしまうのは仕方がないものでもあります。

③KPI達成をハックできない仕組み

優秀なチームほどKPIをハックしようと考えます。（良い意味で。）

マーケティングであればリード数が主要KPIなので質を無視して量を取れば、とにかくKPIは達成できます。ただし、質の悪いリードを大量に獲得してもインサイドセールスが案件化できず、結果、案件数が未達に終わります。

アンチパターンとして、マーケティングチームはKPI達成し、インサイドセールス・フィールドセールスはKPI未達となり、マーケティングチームだけが評価されるという劣悪な環境が生まれます。

そのため、管理下における主KPIのほかに、より本質的に価値のある数字を達成するための副KPIを持つようにしています。

マーケティングチームの例だと主KPIにはリード数をもった上で、量だけでなく質にも目を向けるため、副KPIに、案件数を持ったりします。

2. 完璧にはならないKPIの矛盾は文化で埋める

SUPER STUDIOのバリューでもあるINSIGHT（本質を見極めよう）でもあるのですが、規模の拡大や施策の数が増えると、どれだけ精密にKPIを設計しても多少の矛盾が生じることは避けられないと思います。

そこを最終的に埋めるのは会社の文化であり、メンバーひとりひとりのマインドだと僕は考えています。

SUPER STUDIOでは「会社を主語に考えよう」という文化を常々メンバーに伝えています。

なので、マーケティングからセールスまでグループは別れていますが、１つのプロジェクトとして共通認識を持っており、本質的に受注数を伸ばさなければ意味がないということを各グループが理解しています。

マーケティングがどれだけリードを取っても、インサイドセールスがどれだけ案件数を取っても、最後の受注数が伸びなければ意味がありません。

それをマーケティングもインサイドセールスも理解しているため、量だけでなく質というものにも責任を持ち、互いを信頼しつつも、お互いプロフェッショナルとして牽制し合う。

そういう文化がチームを本質的な目標達成に導くと僕は信じています。

3. 具体的なマーケティングとセールスのKPI

ここまでKPIに関する概念的なことを整理してきましたが、結果的にはマーケティング・インサイドセールス・フィールドセールスの主なKPIは以下のようになっています。

●：主KPI　　○：副KPI

上記のKPI設計のルールでも記載したとおり、主KPIには自チームの努力だけで達成することが可能なものをおきつつ、本質的に営業活動として達成すべきKPIは受注数ですので、受注数につなげるための質に目を向け、副KPIに品質観点を入れているような設計です。

基本的に受注数の達成のためにマーケティングからインサイドセールスは案件を供給し、フィールドセールスが受注数達成のために全力を尽くすというイメージ。ここでフィールドセールスのマインドが素晴らしいのが、たとえ受注数達成のために商談数が理論上足りないという状態に陥ったときも、だったら自分たちで商談を生み出すというマインドでやってくれています。

組織が持っているKPIについては上記の通りですが、新規顧客獲得に向けた施策数が多くなってくると組織を横断したプロジェクトチーム単位のKPIが発生するため、現在は以下のようにプロジェクトチーム単位でチームKPIを追っています。

4. マーケティングとセールスのデータが一元管理されていないことで起きる問題

冒頭にも書いたとおり、お恥ずかしながらマーケティングデータやセールスデータが一部SFAを活用し、一部スプレッドシートで個別管理しているようなアンチパターンに陥っていました。

これによって以下のような問題が発生していました。

・マーケティング・インサイドセールス・フィールドセールスが認識している数字と微妙にずれることにより、チーム間で無意味な議論が発生し、不信感が積もる

・流入経路やCTA毎の案件化率、受注率がわからないため、リードの質が把握できず、マーケティングの厳密な費用対効果が計測できない

・あらゆるデータにリアルタイム性がなく、手動が多かったためレポーティングの工数が非常にかかっていた

などなど

SUPER STUDIOは口コミ主体だったので、今まで正直なところ致命的な問題にはなっていなかったのですが、これから大型マーケティングを実施する上で、最優先課題として考え、約1ヶ月でマーケティングからセールスまでのデータ管理をSFAで一元管理するように整備しました。

結果、SFAなしにはマーケティングからセールスが活動することが困難なレベルに活用することができました。

現状では、マーケティング・インサイドセールス・フィールドセールスの全員が同じダッシュボードを見ることで数字の認識齟齬などもなく、リアルタイムでデータを確認することができ、週次、月次のKPI進捗管理にかける工数もほとんどなくなりました。

加えて、データをあらゆるセグメントで分析できるようにしているので、リードの質を確認するために流入経路ごとの案件化率や、リードから商談、商談から受注までのプロセスにおけるボトルネックの特定などを行うことで、プロセスの改善PDCAやROIの高いマーケティング施策に選択と集中ができる意思決定が可能になったことが非常に大きいです。

5. マーケティングとセールスのデータの一元管理及び、KPIリアルタイム監視に向けて実際にやったこと

1ヶ月でSFAに対して無数の修正を加えた気がしますが、大きくやったことをいくつかピックアップしようと思います。

①リード・商談オブジェクトにマーケティング情報をカスタム項目で追加

上記のようにリードオブジェクトにカスタム項目で「流入経路（大）」、「流入経路（中）」、「流入経路（小）」などを追加し、リードが何経由で生まれたものなのかを区別できるようにしました。

例）ブランドサイトから資料請求
流入経路（大）：オンライン
流入経路（中）：ブランドサイト
流入経路（小）：資料請求

例）クライアントに紹介されたパターン
流入経路（大）：オフライン
流入経路（中）：紹介
紹介元会社：xxx（取引先参照）

他にもオンラインであればリファラ情報を取得し、SFAに自動連携されるようにしたり、CTAごとにPardotのキャンペーンに自動追加されるようにし、MAができるようにしたりしています。

オフラインは流石に手動になりますが、紹介が多い弊社では、どういった業種・具体的にどの企業様が多くの紹介をいただいているか、などをデータ分析し、より良い関係を築けるような取り組みを実施しています。

②手動入力を極限まで減らすため、変数やプロセスビルダーを活用

オンラインリードの情報など自動で入力することのできるデータについては自動化しています。

ただ、どれだけ作り込んでも、セールスのメンバーにはSFAにデータ入力を手動で行ってもらうケースが必ず発生します。そんな中で、正確なデータを入力してもらうためにも入力項目を極力減らすために変数やワークフローやプロセスビルダーを活用し、ほとんどの項目が極力自動で入力されるように作り込んでいます。

変数例）リードから案件化までのリードタイム

DATEVALUE(AnkenDate__c)- DATEVALUE(CreatedDate)
※案件化日（カスタム項目） - リード作成日（標準項目）

プロセスビルダー例）案件化日の自動入力
※リードのステータスが「案件化」に変更されたら、自動的に案件化日に日付が入るように自動化。

②データの正確性を担保するために、セールスチームのSFA運用を整理

どこまで仕組みを作り込んでも必ず手動でのデータ入力は発生してしまいます。そのため、運用上のオペレーションをトリガーにデータ入力されるため、分析したいこと（目的）から逆算し、運用を作り込む必要があります。

以下のようなイメージで、フローをしっかり作り込み、運用していく。

例えば、オンラインリードとオフラインリードでリードから商談化するまでのリードタイムは全く期間が異なりますので、各リードタイムについて分析できないと中々営業活動のボトルネックを見つけることができません。

ボトルネックを見つけられないと、セールスチームも受注までのプロセスを改善することができず、マンパワーで解決するしかなくなります。

リードタイムを図るためには、商談の作成日が必要なので、セールスがどのタイミングで商談を作成するのかの運用をしっかり整理しておかないと、正確なデータを図ることができません。

これはほんの一例ですが、運用を徹底し、正しいデータ分析を行えるようにチームとして協力する必要があります。

④手動入力漏れを監視するアラートダッシュボード

どれだけ立派な運用を構築しても、人は必ずミスします。特にセールスのトッププレイヤーであってもSFAへの入力作業が苦手な人が多いです。笑

なので、マネージャーはデータの正確性を担保するために常に入力漏れを検知できる仕組みが必要です。

その仕組としてアラートダッシュボードを作成し、リードや商談に関わるデータの論理チェックを行い、日々データの正確性を担保しています。

他にもたくさんのことをやりましたが、大枠こういったことを実施し、SFAをしっかり活用していけるようになりました。

6. SFA構築時に注意しなければいけないこと（情シス・エンジニア視点）

僕自身、この改善を通してSFAをはじめてガッツリ触ったので、学びながらではあったのですが、SFAの設計思想を理解していくと気をつけないといけないいくつかの点があったので、メモ書き的にかければと思います。

※間違ってる情報もあるかもしれないので、正確な情報は公式窓口に問い合わせてください。笑

6-1. オブジェクトを正規化しすぎない

僕のように0からシステム設計できるスキルセット持ちだと性能面などを意識してオブジェクトを正規化してしまいがちなのですが、これはSFAの魅力を壊してしまう恐れがあります。

SFAは仕様上、オブジェクトを結合してレポートとして表データを出力することができます。レポートをもとにダッシュボード機能を用いてグラフ化します。ノーコードでこういったことを実現できるのが最大の魅力です。

しかし、レポートで結合できるオブジェクトの数には制限（確か３つ？）があります。

なので、正規化しすぎていると、結合しても分析の軸に使いたいデータが足りず、思うようにダッシュボードを構築できなくなります。

APEXを使ったり、Tableauなどの外部システムを駆使すれば、正直なんでもできるのですが、コードを書くことになりますので、SFAを使う意味が半減するので個人的には推奨しません。

正規化しすぎるとSFAの優れた標準機能であるレポートやダッシュボードが活用できなくなりますので注意してください。

6-2. リードから商談・取引先・取引先責任者への継承設定はしっかりやるべき

SFAの基本的な活用方法として、最初にお客様との接触をリードとして管理し、そこから商談に発展する際に「取引開始」を行うことでリードを商談・取引先・取引先責任者に昇格させ、セールスプロセスを管理することになります。

このときに、リードオブジェクトから商談・取引先・取引先責任者オブジェクトにあらゆる情報を継承しておかないと、リード段階で入っているデータを再入力しないといけなくなったり、リードにしかないデータがあると、データ分析時に困ったりすることが多々あります。

そのため、必ずデータ分析に必要なデータはすべて継承しておくことをおすすめしておきます。

6-3. 基本的に標準オブジェクトを活用すべきだが、変な挙動をするオブジェクトもあるので注意。

SFAにはSFAが用意してくれている標準オブジェクト（リード・商談・取引先・取引先責任者・請求など）と自身で作成するカスタムオブジェクトという2種類のオブジェクトがあります。

勘の良い方ならお気づきだと思いますが、SFAの連携しているアドオンツール（freee for salesforceなど）を活用するためにも基本的には標準オブジェクトをきっちり使っていないと機能させられなかったりします。

ですので、基本的には標準オブジェクトがあるものは標準オブジェクトを活用しましょう。

ただ、標準オブジェクトの標準項目にはSFAが提供していますので、思想に基づいて想定外の挙動をする項目があったりします。

なぜそんな動きをするのかはSFAの思想を理解すれば理解できるのですが、その思想が必ずしも、その会社の運用にハマっているとは限りません。

ものによっては標準オブジェクトを使わずにカスタムオブジェクトで構築したほうが良いシーンもあるので注意したほうがよいかと思います。

6-4. その他にも超基本的なことですがメモ

・項目の選択リストは基本グローバル設定で持たせる（メンテが大変。）

・API参照名は極力後から変更しなくて済むよう設計する（エンジニアが大変なんで。）

・APEX利用前提のデータ設計時はガバナ制限を考慮しておく

・プロセスビルダーやAPEXで使用されている項目の修正や削除は思っている以上に手間がかかるため安易に項目追加してエンジニアリングしない

7. さいごに（SFAに対しての感想）

KPIやSFAについて長々と語ってきましたが、今回の施策の裏目的としてSaaSを経営するエンジニアとして、世界1位のSaaSといわれるセールスフォースというプロダクトに触れておきたかったというのも個人的にはありました。

ぶっちゃけたお話ですが、セールスフォースって初見だと非常に使いづらく学習コストがすごいという印象が強かったです。

実際に使ってみた結果、確かにわかりづらく「あの画面にどうやっていくんだっけ・・・」「SFA用語知ってる前提のUIじゃん・・・」と感じることもありました。

ただ、リード・商談といったオブジェクトという概念や、オブジェクトごとに細かい設定ができたり、オブジェクト間の主従関係を自由に組めたり、ワークフローやプロセスビルダーで自動処理を構築できたり、セールスフォースの設計思想を理解していくと、なぜこういうUIになっているのかも理解できますし、ノーコードでオブジェクトを生成し、あのレベルのダッシュボードが自由に作れたりするのは素晴らしいと素直に感じました。

初日、導線がよくわからないのでURLをメモ帳にコピペしながら作業していたのですが、1ヶ月後にはUIにも慣れていました。笑

プログラマーではなくても、上流工程をこなせるシステムエンジニアであれば、かなり自由度の高いことができるんじゃないかと思います。

SaaSプロダクトを設計する一人として、非常にこの設計思想は参考になりましたし、まさにSaaSとSIの共存を可能にしているプロダクトなんじゃないかなとリスペクトも持てました。

僕たちも良いところは取り入れて、自身のプロダクトに磨きをかけていければと思います！

最後までお読みいただき、ありがとうございました。