システム組立ちゃんねるを運営している、株式会社フライクの大瀧です。

「Salesforceの商談をうまく使いこなせていないけどどうしたらいいかわからない」

「失注管理を効果的に行いたい」

と考えてはいませんか？

本記事では、商談の基本情報と商談管理を効率的に行うために必要な考え方について解説します。

Salesforce標準機能「商談」

Salesforceのメインのオブジェクトが商談です。

非常に機能が充実している一方で、充実しすぎてうまく使いこなせていない人が多いのも事実です

英語にはなりますが、Sales Cloud Data Modelという資料があります。

その資料から抜粋したSalesCloudの商談のデータ構造がこちらです。

商談は英語で「Opportunity」となっています。

引用元：Sales Cloud Data Model

ここからは弊社が使っているセールス領域における機能について、わかりやすく詳しく説明します。

• レコードタイプ
• フェーズ管理と必須項目
• 取引先責任者の役割
• 失注管理

レコードタイプ

「商談」を使用するうえで避けては通れないのが「レコードタイプ」です。

「レコードタイプ」だけですと、一見「どんな機能？」というのが分かりづらいので、ここでは例をあげてご説明します。

例えば、「カレーライス」と「ハンバーグ」という異なる料理を両方作る場合、

「ご飯を食べる」という最終目標は同じですが、レシピの段取りはもちろん、使う食材や切り方など、細部が異なります。

（ex. カレーはにんじん、玉ねぎ、じゃがいも、肉。ハンバーグはミンチ肉、玉ねぎ…等）

これを「商談」に置き換えると、以下のようになります。

• カレーライス・ハンバーグ（料理）：提案するサービス
• レシピ：提案するサービスによって異なるヒヤリング内容
• ご飯を食べる：売上をあげる

そして、肝心の「レコードタイプ」は何に該当するのかというと、

「提案するサービスによって異なるヒヤリング内容」です。

フライクは、主に「①コンサルティング」と「②ライセンス」をして利便性をあげています。

まず「①コンサルティング」をクリックします。

「①コンサルティング」を選んだあとに出る画面がこちら。

そして画面をひとつ前に戻して「②ライセンス」を選ぶと、以下の画面が表示されます。

画像を見ていただくと分かりますが、①と②の違いは「入力項目が異なる」ことです。

先ほどの「カレーライスとハンバーグでのレシピ（作り方）が異なる」という例のとおり、

提案するサービスが異なるとヒヤリングする項目が変わるからです。

ですので、弊社ではレコードタイプを分けて入力や管理をしやすくしております。

 つまり、1つのオブジェクトをタイプごとに分けて、商談項目入力画面での表示方法を変更するということです。

フェーズ×必須項目

次に「フェーズ」についてご説明します。

突然ですが、セールス・営業の役割とは何か、ご存知でしょうか。

• 売上を上げること
• お客さまに会社のことを知ってもらうこと

など、たくさんの意見が出てきそうですが、

私は「営業マンが商談を前に進めること」だと考えております。

そのためには「商談」を前に進める方法や、進め方を会社の中で共通化する必要があります。

たとえば「これは絶対にいけます！受注できます！」と意気込む営業マンがいたとしても、100％受注できることは残念ながらありません。

しかし、企業は狙ったタイミングで狙った売上をあげないとキャッシュフローが読めなくなります。

だからこそ、セールス組織は同一のものさしで商談を管理していき、狙ったタイミングで狙った金額を受注するために、一歩ずつ着実に「商談を前に進める」ことが重要です。

その物差しが、本章のタイトルにもなっている「フェーズ」と「必須項目」です。

フェーズとは、商談化〜受注の状態になるまでのステップと捉えてください。

山登りでいうと、頂上への到達＝フェーズの最終段階ですので、その経過（フェーズの段階）は「今は3合目くらいかな？」というような感覚です。

フライクでは、商談を以下のようなフェーズに分けております。

具体的なフェーズ定義は以下のとおりです。

このようにして受注という「山」を登っていきます。

前章でご説明した「レコードタイプ」とはどう違うのか？と思う方がいらっしゃるかもしれませんが、たとえば先ほどの「①コンサルティング」のレコードタイプは、以下のような商談フェーズ×必須項目を設定しています。

このように、各フェーズと必須項目を連動することによって

商談の進め方をわかりやすくし、読みを外さないようにしています。

また、この表の中の「フェーズ06：提案」に移行する場合、下記項目が必須項目になります。

そのため、必須項目を入れていない状態で「フェーズ06：提案」の状態にすることはできません。

つまり、今から提案しようしている顧客における

• ビジネス課題
• 問題点
• 解決策
• 効果

が記載されていないと、「フェーズ06：提案」はできないということになります。

商談を前に進める上で絶対に必要になる項目を、入力必須化することで、商談の属人化を防ぐ効果があります。担当者がその商談から外れても、必要な情報が蓄積されているので、円滑に引き継ぐことができます。

取引先責任者の役割

次に「取引先責任者の役割」についてご説明します。

こちらも、わかりやすくお伝えするために例を用いてお話しましょう。

例えば、ゲームソフトを買いたいと思っている小学1年生の男の子がいたとします。

しかし、自分のお小遣いでは買いたいゲーム（5,000円ほど）は買えません。

それでもゲームがほしい男の子は、自分が持っているお小遣い（1,000円）と、

残り4,000円をどうにか工面する方法を考えました。

そこで、夏休みに帰省した際に祖父母に買ってもらおうと相談したところ、無事買って貰えるところまで成功しました。

その後、祖父母が両親に

「孫にゲームを買ってあげたいんだけど、いいと？」

（※大瀧が最も得意とする博多弁でお送りします）

と、確認を入れてきたのです！

両親が承諾したため男の子は最終的にゲームを購入できましたが、ここで両親が承諾していなければ、あと一歩のところでゲームは購入できないところでした。

ここまでの例を「取引先責任者の役割」に置き換えてみましょう。

まず「商談＝5,000円のゲームソフト」となります。。

そして、

• 購入推進者＝祖父母
• 最終意思決定者＝両親

ということになります。

どちらも商談を前に進めるには、欠かせない存在です。

では、フライクでは取引先責任者の役割をどのように設定しているかをご紹介いたします。

こちらがフライクの商談×取引先責任者の役割です。

大企業、中堅企業に対する商談をする場合、稟議を書くというプロセスが生じます。

そのプロセスを進める際「誰にどのようなアプローチをすればいいか？」を、 商談に関わらずすべてのメンバーが把握するためにも、この「商談における取引先責任者の役割」を使いこなすことが重要と考えております。

実際のセールスフォース環境がこちらです。

このように、商談の中に「取引先責任者の役割」をもたせることによって

この商談におけるお客さまの担当者の役割（責任範疇等）が分かりやすくなります。

失注管理

最後に「失注管理」について説明します。

すべての商談を受注することができればこの管理は不要ですが、完璧な人が世の中にはいないのと同様に、失注は必ず発生します。

「失敗は成功のもと」と言うように、失敗をそのままにせず、次に活かすための糧とするためにも「失注管理」をしていきます。

フライクでは「失注」というフェーズにすると、必須入力項目があります。

まず、失注理由です。失注理由は大きく分けて3つに分類しています。

さらに、フライクでは失注の掘り起こしをするために、このような入力画面を設けています。

まとめ：商談を使いこなして売り上げを最大化しよう

本記事では商談の基本的な考え方を解説してきました。

今回解説したのは商談の次の機能です。

• レコードタイプ
• フェーズ管理
• 取引先責任者の役割
• 失注管理

商談管理がなかなかうまくいかない、仕組みをうまく作って欲しいなどの要望がありましたら、ぜひフライクに一度お問い合わせください。

また、SalesforceやBox、freeeといった他のITツールについても知りたい！という方は
「システムスタータープログラム」の特設ページも併せてご覧ください。
必ず皆さまのお役に立てるコンテンツが見つかります。

SSP 特設ページはこちら

他にもSalesforceを活用した事例をご紹介。

セールス領域におけるSalesforceの徹底利活用〜リード編〜
セールス領域におけるSalesforceの徹底利活用〜取引先編〜
セールス領域におけるSalesforceの徹底利活用〜活動履歴編〜
セールス領域におけるSalesforceの徹底利活用〜見積編〜
セールス領域におけるSalesforceの徹底利活用〜契約管理編〜

株式会社フライク　代表取締役　大瀧　龍