リバネスでは2014年より本格的なデジタル化を推進してきました。 それまで社内には統合されたデータベースというものは存在せず、エクセルが散在し、情報の集約に時間を要していました。マネージャーは本来やるべきことより情報をまとめることに時間を割くようになってしまったことで、組織のボトルネックが顕在化しつつあったからです。 スプレッドシートは強力なツールで、オンラインで共同編集が出来ることもあって長い間重宝されてきましたが、情報量が増えると処理に時間がかかるようになったり、一人の人が起こしたエラーで全体が使い物にならなくなったりと、やはり時間が無駄にかかるようになってきました。組織が大きくなる事で現れたボトルネックはすべて自社のデジタル化環境によるもので、これを刷新しないことには次のステップへ行くことは出来ないと考えた訳です。 リバネスのDXで重視したのはなにか 情報を扱っていて思う一つの大事な事が何かというと、情報をまとめるというのには時間がかかるということです。この時間を削減する必要がありました。そこでリバネスでは、データの基幹をSalesforceに移すことを決め、あらゆる情報をSalesforce上に統合していくことになります。 最初は取引先や名刺交換で獲られた人の情報、及びそこに紐づく商談の情報のみしかなかったSalesforceに、スタッフの査定情報、勤怠管理、マーケティングオートメーションツールから獲られるWebサイトのアクセス情報、会員サイトの会員が登録した情報などを統合していきました。 そうすることで何が起こるかと言うと、Salesforce上で検索すればあらゆる情報にアクセスできるという状態を作ることができるのです。 もちろんSalesforceのみである必要は無いのですが、1つのプラットフォーム上にあらゆるデータが統合されているという状態は非常に便利です。検索をすれば情報がヒットする訳ですから。 リバネスのDXで達成したこと 最初は商談管理の為に導入したSalesforceですから、当然商談管理については大きなインパクトがありました。それまでは数字を合わせるという作業に時間が取られていたのが、そこにかける時間が0になることで戦略を考える時間が持てるように変化が起こりました。それまでどんぶり勘定と言わざるを得なかった事業計画も、実績を元に算出した数字を達成できるようになっています。2014年当時に危惧していたボトルネックは解消され、売上は当時の3倍を超えて成長しています。 情報を見ることにストレスが無くなるというのは非常にパワーを与えてくれるといえます。 能動的なアクションを必要としない環境へ Salesforceを活用する利点は、Salesforce自体に計算処理能力を持っているという点が挙げられます。つまり、集まった情報をSalesforceの計算資源を使って加工し、出力することが出来ます。情報は定期的に実行されるバッチ処理によってプッシュ配信することも出来ますし、Salesforce上に作ったカスタムページに必要な情報を適宜配置して確認することも出来ます。 自社のみがもつサーチエンジン リバネスの例で言えば、私達のSalesforce上には研究者から寄せられた情報が多数登録されており、これは年々情報量を増しています。 Salesforce上につくった検索エンジンを使って検索することで、特定のキーワードにひっかかる研究者を簡単に抽出することができるという状態が作られています。 これらの情報によって抽出されたリストを使ってメールを配信するというようなアクションも、ほんの数分で実現することができるのです。 DXのゴールはなにか Salesforceを使っていると、高いのではないか？という話になるということはよく聞きます。高い、つまりコストパフォーマンスが悪いのではないかということなのですが、当然使い方によってはコスパが悪いという状態になるでしょう。デジタル化に使うプラットフォームがどこまで使えるのかを把握し、100%以上使い倒す事ができればコストパフォーマンスが気になるということはなくなるはずです。 そのためには、DXの全体像を大きく捉え、将来的にどこまで行きたいのかを想像する必要があります。そこに向けてデジタル化を進めていくのです。 もちろんDXの始めたての頃はコストパフォーマンスが良いとは言えないかもしれません。DXは一朝一夕でなるものではなく、マラソンに近い活動だと言えます。自社のデジタルアセットが統合されることによってどのように変化が起こるのかを共有し、そこに向けて走り続ける事でいつの間にかDXが達成されているのではないかと感じています。 もちろん我々リバネスのDXも道半ばです。これからもっと強力なツールに育て上げることで事業推進に貢献できるようになるでしょう。 リバネスでは2014年より本格的なデジタル化を推進してきました。 それまで社内には統合されたデータベースというものは存在せず、エクセルが散在し、情報の集約に時間を要していました。マネージャーは本来やるべきことより情報をまとめることに時間を割くようになってしまったことで、組織のボトルネックが顕在化しつつあったからです。 スプレッドシートは強力なツールで、オンラインで共同編集が出来ることもあって長い間重宝されてきましたが、情報量が増えると処理に時間がかかるようになったり、一人の人が起こしたエラーで全体が使い物にならなくなったりと、やはり時間が無駄にかかるようになってきました。組織が大きくなる事で現れたボトルネックはすべて自社のデジタル化環境によるもので、これを刷新しないことには次のステップへ行くことは出来ないと考えた訳です。 リバネスのDXで重視したのはなにか 情報を扱っていて思う一つの大事な事が何かというと、情報をまとめるというのには時間がかかるということです。この時間を削減する必要がありました。そこでリバネスでは、データの基幹をSalesforceに移すことを決め、あらゆる情報をSalesforce上に統合していくことになります。 最初は取引先や名刺交換で獲られた人の情報、及びそこに紐づく商談の情報のみしかなかったSalesforceに、スタッフの査定情報、勤怠管理、マーケティングオートメーションツールから獲られるWebサイトのアクセス情報、会員サイトの会員が登録した情報などを統合していきました。 そうすることで何が起こるかと言うと、Salesforce上で検索すればあらゆる情報にアクセスできるという状態を作ることができるのです。 もちろんSalesforceのみである必要は無いのですが、1つのプラットフォーム上にあらゆるデータが統合されているという状態は非常に便利です。検索をすれば情報がヒットする訳ですから。 リバネスのDXで達成したこと 最初は商談管理の為に導入したSalesforceですから、当然商談管理については大きなインパクトがありました。それまでは数字を合わせるという作業に時間が取られていたのが、そこにかける時間が0になることで戦略を考える時間が持てるように変化が起こりました。それまでどんぶり勘定と言わざるを得なかった事業計画も、実績を元に算出した数字を達成できるようになっています。2014年当時に危惧していたボトルネックは解消され、売上は当時の3倍を超えて成長しています。 情報を見ることにストレスが無くなるというのは非常にパワーを与えてくれるといえます。 能動的なアクションを必要としない環境へ Salesforceを活用する利点は、Salesforce自体に計算処理能力を持っているという点が挙げられます。つまり、集まった情報をSalesforceの計算資源を使って加工し、出力することが出来ます。情報は定期的に実行されるバッチ処理によってプッシュ配信することも出来ますし、Salesforce上に作ったカスタムページに必要な情報を適宜配置して確認することも出来ます。 自社のみがもつサーチエンジン リバネスの例で言えば、私達のSalesforce上には研究者から寄せられた情報が多数登録されており、これは年々情報量を増しています。 Salesforce上につくった検索エンジンを使って検索することで、特定のキーワードにひっかかる研究者を簡単に抽出することができるという状態が作られています。 これらの情報によって抽出されたリストを使ってメールを配信するというようなアクションも、ほんの数分で実現することができるのです。 DXのゴールはなにか Salesforceを使っていると、高いのではないか？という話になるということはよく聞きます。高い、つまりコストパフォーマンスが悪いのではないかということなのですが、当然使い方によってはコスパが悪いという状態になるでしょう。デジタル化に使うプラットフォームがどこまで使えるのかを把握し、100%以上使い倒す事ができればコストパフォーマンスが気になるということはなくなるはずです。 そのためには、DXの全体像を大きく捉え、将来的にどこまで行きたいのかを想像する必要があります。そこに向けてデジタル化を進めていくのです。 もちろんDXの始めたての頃はコストパフォーマンスが良いとは言えないかもしれません。DXは一朝一夕でなるものではなく、マラソンに近い活動だと言えます。自社のデジタルアセットが統合されることによってどのように変化が起こるのかを共有し、そこに向けて走り続ける事でいつの間にかDXが達成されているのではないかと感じています。 もちろん我々リバネスのDXも道半ばです。これからもっと強力なツールに育て上げることで事業推進に貢献できるようになるでしょう。 事例に戻る [...]

Salesforceでレポートやダッシュボードを作成すると最新情報による情報を可視化することが出来ることはご存知だと思います。 一方で、事業をやっていると、最新情報のみではなく、これまでの経時変化を見てみたいと思う瞬間が少なからず発生するはずです。Salesforceは何も設定していないと経時変化のような情報を取ることが出来ません。そこで利用するのが「レポート作成スナップショット」です。 この機能を利用することでSalesforce上で、経時変化をデータとして保存することができます。 以下は日次データを保存した結果をレポートにしたものですが、このような形で可視化できるようになります。 データの取得間隔は最短で1日です。 なぜスナップショットという機能が必要なのか 例えば、年間の積算売上であったり、年間のサービス利用者数でも良いと思います。 Salesforceは最新の情報しか見ることが出来ません。去年のデータを取得したいと思っても、最終的な状態を知ることしか出来ません。 データの分析を考える上でそれだけでは物足りないことがままあります。 年間を通して売上がどのように変化してきたのか。利用者数が増加・減少するタイミングや季節はあるのか。こういった情報を後で手に入れようとしても難しいのがSalesforceです。(Salesforceというより、どんなデータベースでも同様です) 利用事例 最も利用価値が高いのは売上推移の情報です。リバネスでは毎日スナップショットを取っており、過去数年間のデータが残っています。いつ頃、どの程度の売上が発生していたのか、季節ごとの傾向がどうなっているかといった情報を取得することが出来るようになっています。 事業計画に対する進捗度合いがすぐに分かるため、その後のアクションに対する意思決定スピードが向上します。 売上推移のように長期的なもの以外にも、あるイベントの参加人数募集がかかっている場合に、申込み人数の推移を可視化することで、短期的なゴールに向けたアクションが可能になったり、問い合わせ件数(ケース件数)の処理数の推移を測っておくことで、対応スタッフ数の適切な人数を割り出すことが可能になります。 それでは実際にどのように作っていくのかを解説します。 レポート作成スナップショットの作り方 Trailheadからなにかちょうどよいものを引っ張ってこようと思っていたのですが意外となかったので書いておきます。 まずはレポートを作成しましょう スナップショットはレポートを元に作られます。 レポートは、集計したいオブジェクトを対象にして作ります。 商談の売上金額の推移を取得したい場合は、商談のレポートを作って下さい。リバネスの場合はこのような形式になっています。 集計レポートですので、何かしらの項目でグループ化する必要があります。商談は会計年度毎に集計することが多いと思いますので、会計年度でグループ化しました(左上)。表示列には、売上系の項目を入れています。 【商談単体】金額がいわゆる金額(Amount)項目です。事業部別売上(集計用)は、数式によって事業部毎の売上金額が入るようになっていて、全社的な売上に加えて事業部別の売上推移もスナップショットで取得するようにしています。 レポートを作ったら正しく集計されているか数字を見て確認しましょう。問題がなさそうであれば、このレポートをもとにスナップショットをつくります。 スナップショットのイメージは、今レポートで表示されている数字がそのまま記録に残ると思ってください。売上推移であれば当然数字は日々動いていきます。その瞬間の数字が記録として残るのがスナップショットなのです。 レポート作成スナップショットを作る レポートを作ったら、次はスナップショットを作ります。 設定画面＞機能設定＞分析＞レポート＆ダッシュボード＞レポート作成スナップショット を開いて下さい。 スナップショット名及び一意の名前は任意です。 実行ユーザは専用のユーザが用意できる場合は専用ユーザ。出来ない場合もできるだけ退職しないアカウントで作りましょう。オブジェクトへのアクセス権限も必要です。 ソースレポートには先程作ったレポートを設定します。 対象オブジェクトはスナップショットのデータを格納するためのオブジェクトです。 存在していませんのでオブジェクトを作成して下さい。 今回は商談の金額を格納する為のオブジェクトですので、商談スナップショットオブジェクトを作成し、金額という項目を一つ作っておけば大丈夫です。上述したように事業部毎の金額も格納したいという場合は、それを入れるためのカスタム項目を追加しましょう。こんなイメージになるはずです。 次に、項目の割当を行います。 今回は特にグループごとの小計を使う予定はありませんので総集計を選びます。 もし会計年度以外の要素でグルーピングした場合は、それらの小計を入れることも可能になります。 下の方が割当項目です。スナップショットの各項目を左側で選択し、右側が格納先オブジェクトのカスタム項目になっていてそこに割り当てていきます。 注意点としては、数値項目はテキスト項目には代入出来ないといった型をあわせる必要がありますので、もし割り当てたい項目のところにほしい項目が表示されないという場合は項目の型をチェックしてみてください。 最後に、実行間隔を決めましょう。以下の条件では、毎朝7時に実行することになっています。 以上が設定方法です。 スナップショットのデータを活用する ここまででスナップショットの設定は出来たと思います。実際にデータが格納され始めたら、それを使って可視化をしましょう。 Salesforceのレポートを使ってグラフ化する所から初めて、Tableauを使ってもっとグラフィカルなグラフを作ることも可能です。 一番大事なのは、データを使ってアクションに結びつけることです。可視化された情報を使って人を動かすことができれば組織のスピードに圧倒的な向上が見込めます。 お気軽にご質問ください！ [...]

リバネスがSalesforceを導入したのは2013年末でした。これまで何度も色々なところで発表してきたことですが、2013年当時リバネスは業務量過多によって事業成長の頭打ちを迎えつつありました。その原因は貧弱なITインフラと適切なワークフローがなかったことに起因します。 2013年当時のリバネスの問題 今でも少なくない組織がやっていることだと思うのですが、営業管理をスプレッドシートを使って行っていました。事業は徐々に成長を始めたタイミングで、これまでのような管理のままだとそもそもデータが重すぎて入力するだけで数分かかってしまうという状態になっていました。スプレッドシートを好む人は少なくないと思うのですがそれはなぜでしょう。答えは簡単で自由度が高いからです。基本的に自由記述欄のみなので簡単に拡張が出来たりと便利な面はたしかにあるのですが、自由記述が故に情報の入力ルールが守られなかったり、誤って他人のデータを変更してしまったり、数値を書かないと数式がエラーになるのに気付かずに全角数字で入力したら集計用のシートがだめになってしまったり。スプレッドシートは脆弱なのです。 こういった問題を解決するための銀の弾丸として選ばれたのがSalesforce社が提供するSales Cloudでした。 ワークフローをSalesforce式に変えていく 一番効果があったのはこれです。それまでのリバネスの商談管理は本当にひどかったと今では思いますが、例えば上述のスプレッドシートですが情報が記述されるタイミングはいつだったと思いますか？答えは「契約が決まったタイミング」です。そのため、今仕掛中の案件が何件あるのかを把握することは出来ませんでした。誰がどこにどんな提案をしていたのかは、本人のみぞ知るところとなり、社内全体で共有するという文化がありませんでした。 Sales Cloudの導入で変わったのはワークフローです。誰かに何かを提案したら商談を立ち上げ、立ち上がった商談を元に現在提案中の金額が把握できるという状態にしました。こうすることによって売上の見通しがつくように変わっていったのです。それまでどんぶり勘定でしかなかった事業計画は、実態を伴った数字によって構成されるように徐々に変わっていきました。そのおかげで事業計画の達成率は100%前後で推移するようになり、計画的に成長していくことができる組織へと変わっていったのです。 副産物 課題はもう一点ありました。実はリバネスでは請求漏れが多発していたのです。せっかく完了した仕事があっても、請求書を送らなかったら入金はありません。そもそもの情報管理がスプレッドシートで信頼性が低いこともあり、請求漏れに気付くのは個人の記憶に頼る以外になく、非常に心もとなかったことを覚えています。これまでに実装してきたように、商談はまだ種状態のころから登録されており、その状態は常に管理され続けるようになりました。しかもそれまでのように、誰かが情報をまとめてレポーティングする必要はなく、ただ特定のURLをクリックすればいいだけで分かるように変わったのです。 請求漏れは、商談についた完了予定日(CloseDate)を使って確認がされるようになり、終わっていなければすぐに指摘できるように変わりました。おかげで請求漏れは二度と発生することはありませんでした。 (別件ですが、請求書を送ったあとに入金を確認するという流れの中にも多大な煩雑さがあり、最大2億円を超える未入金が蓄積したことがあるのですが、それについての解決方法については別途書きたいと思います) 間違いの始まり 日本企業の特性としてよく聞く話としてあげられるのが「自社用カスタムの過剰要求」です。自分の組織はこういうワークフローが組まれているからそれに合うようにカスタマイズして欲しいという話です。もちろん頑張って資金と工数を投入してカスタムすれば出来ないことはないのですが、それはなにか意味がある行為でしょうか。 業務用ツールを導入する場合、そのポテンシャルを100%以上引き出せるような使い方のほうがコストパフォーマンスが良くなるはずです。自社向けカスタマイズに固執していて業務効率向上がおざなりになってしまうと本末転倒。必要なのはツールの思想に自分の組織を寄せていくという柔軟性です。 ありたい理想像をそのツールを導入した上で描くことができるのであれば、ツール導入だけではなく組織変容を合わせて行っていく必要があります。 異文化導入によって組織を強化していく リバネスではこのような方法で組織を強化してきました。Salesforceが顕著ですが、Slackを導入した際には情報のオープン化を大々的に進めています。これまでのように限られた人のみが情報を得られる状態ではなく、誰もが欲しいタイミングで欲しい情報を得ることができる体制を作ったのです。検索すれば情報にありつくことができるということは、情報を残しておくことで誰かの役にたつことができるというインセンティブを与えることができるのです。 このように、ツールの導入とともに組織文化をアップデートし、ワークフローを最適化しながら成長できる組織にしていくお手伝いができればと考えているのが私達リバネスナレッジのチームです。

スケジュール管理、どのように行っていますか？ リバネスではもっぱらGoogleカレンダーを使っています。一方で、Salesforceにもスケジュールという機能が提供されており、活動オブジェクトに予定を入れておくと、その後のトラッキングが容易になるといったオプションがあり、これを使わないというのももったいないというのが現状です。 リバネスでは、Salesforceのスケジュール機能で作られた予定に報告機能を付与し、営業報告等の各種報告事項を記載してもらうようにしています。これの何が良いのかというと、イベントが有った時にわざわざ記録用のレコードを立ち上げる必要がないということです。誰が、いつ、という情報までは入っていますのであとはどこでどんなことをしたかを書いて保存すればよいだけです。 スケジュールの情報をSalesforceでも確認したい そういう事はままあるとおもいます。毎日Salesforceを開くのであればついでにスケジュールチェックもしておきたいということもあるでしょう。 かんたんにスケジュールをSalesforceに連携するのであれば、Einstein 活動キャプチャを使いましょう。GoogleもしくはOffice365と連携し、カレンダー情報を取得してくれます。(これは同製品の別機能ですが、メールのやり取りを商談の取引先責任者の役割に紐付いた人とマッチングさせることで、商談にメールのやり取り履歴を自動的に表示してくれます。これは他の方法では実現がかなり難しいのでおすすめ機能です。) これはSalesCloud Einsteinライセンスが必要ですが、非常にかんたんなソリューションで個人的にはおすすめです。以下の画像のように、Google Calendarとの同期したカレンダーを見ることができるようになります。 かんたんではあるのですが一点注意点があります。このカレンダーレコードはGoogle Calendarの情報をミラーリングしているだけでSales Cloud側にレコードがあるわけではありません。そのため、こちらを編集して情報を追加するといった上述したような使い方は出来ません。あくまでも予定の確認が便利になるよという機能になっています。 Googleカレンダーの予定をSalesforceのEventオブジェクトに同期する これにはアプリケーションの開発が必要になるので少しむずかしいかもしれませんがやる価値は十分にあります。 リバネスの場合はPHPもしくはPythonを用いたアプリケーションを書いて両者を同期するようにしています。 GoogleカレンダーからはGoogle Cloud Platformにアプリケーションを作成しアクセストークンを取得します。これを用いて予定を取得するという方法です。取得した情報はSales Cloud側に作った接続アプリケーションを通してEventオブジェクトに登録します。これを定期的にスクリプトを実行することで実現しています。(リバネスの場合は3分毎に同期) カレンダーの情報は更新されることが多いですので、更新されたレコードについてはその更新情報をSalesforce側のレコードにも伝えるようなスクリプトになってます。 こうすることによって、打ち合わせが終わったにも関わらず報告がなされていないレコードを見つけ出すようなスクリプトを走らせることが出来ます。これを使って報告を促すアラートをSlackに投げ、Slack側から情報を更新してもらうということができるのですが、それについては別の事例で書きたいと思います。 お気軽にご相談ください リバネスナレッジでは、無料相談をSlack上で受け付けています。 こちらのリンクより、Party on Slackというワークスペースにご参加ください。 https://lne.st/gptcom #質問_salesforce チャンネルにご連絡ください。お待ちしております。 Salesforce管理者あるあるを解消したい Salesforce Adminという役割は、Salesforceが進化するに従って拡張しています。それにも関わらず、一人で担当しているという組織も少なくないのではないでしょうか。ある程度運用できても、果たしてそれが効果的な施策になっているかどうか相談できる相手がいない。自分たちがやっている施策について壁打ち相手になってくれる人がいないという声を少なくない数耳にします。リバネスナレッジでは、これまで培ってきたノウハウを元に、皆さんの課題を紐解き解決していく為のチームです。まずはワークスペースよりご連絡ください。(もちろん問い合わせフォームからの連絡も歓迎しています) < 事例へ戻る

Sales Cloudを使い始めて最初にこれはなんだろうと思ったことがあります。 リード(Lead)と取引先責任者(Contact)です。 取引先責任者は取引先オブジェクトに所属する形で存在しています。一方でリードは個人そのもので組織とは関連付けられていません。 リードとは？ リードは見込み顧客のことを指します。これから商談が始まる可能性のあるリストのことで、新規商談を作る際のアプローチ先として活用されます。展示会や問い合わせフォームからの流入で既存顧客ではない場合にそれらのリストをリードとして登録し、ここにアプローチした結果商談化することが出来た場合は、取引の開始ボタンから商談を作成することが出来ます。 取引先責任者とは？ これは取引先を親とする、子のレコードとして存在します。ある組織に所属した人として登録されており、先程リードから取引の開始ボタンを押した際にコンバートされる先のレコードになっています。 商談には取引先責任者の役割という関連リストがあり、そこに紐付けることで、商談に対する取引先責任者がどんな役割を持っているかを確認できるようになっています。 理想的な管理方法について リードを活かすには、リードリストの管理が必要です。なぜかというとそれをやらないと、有用なアプローチ先リストとしてのリードが成り立たなくなってしまうからです。 具体的にはどんなメンテナンスが必要かというと、既存取引先と会社名が同じ場合は取引先責任者にコンバートする必要があります。リードから商談が始まった場合は、同じ組織所属の人を取引先責任者にコンバートして提案が重複しないようにする必要があります。理想的にはそういうことなのですが、これがなかなか徹底できない。なぜかというと、リードの会社名は基本的に自由記述欄ですので、名刺スキャンでのデータ化なら良いのですが、リードの人が自ら情報提供したり、誰かが手打ちで入力したりすると既存の取引先名と違ってしまったりということは往々にしてよくあります。 弊社リバネスでは、ある程度運用期間が経過してからベストプラクティスに気付いたため、リードと取引先責任者がぐちゃぐちゃになってしまっていました。そうなると、あまり効率の良い使い方ができなくなってしまいます。 効率の良い顧客管理方法を求めてプロスペクト方式へ 上述したとおり、リバネスではリード管理が崩壊してしまいましたのでより効率の良い方法が必要でした。個人のリストが２つのオブジェクトにまたがって存在することで情報効率が劇的に下がります。レコードには重複が存在するようになり、レポートやビューを使った単一オブジェクトでの情報のフィルタリングはできません。私達はこれらのリストを元に、さらなる商談可能性の発掘などの情報探索をしたいのですが肝心のリストが分割されていては作業効率が激減してしまいます。 さて、リバネスはPardotというSalesforce社が提供するメールマーケティングシステムを導入しています。PardotはSalesCloudと連携し、リードと取引先責任者をプロスペクトという顧客リストに同期してくれます。結論から言えば、SalesCloudの顧客管理もこのプロスペクト方式でよいではないかと考えました。 結果的には、リードもしくは取引先責任者にリンクを持ったリバネスIDというオブジェクトに統合しました。 こうすることで、全ての個人情報はリバネスIDオブジェクト内で検索すれば出てくるようになりました。その他に顧客に関連する情報はリバネスIDにぶら下げて存在させることにより、どの人がアクティブなのかを常に把握できるように変わっています。 もちろん、リードと取引先責任者にリンクが張ってあることからPardotからくるデータにもアクセスすることができるようになっています。 工夫点 リード・取引先責任者・リバネスIDという3オブジェクトが存在するのですが、これらの情報に乖離があるのは好ましくありません。そのため、リンクされたレコードがあった場合は、修正点を関連するレコード全てに反映しています。 例えば電話番号が変わったり住所が変わったりという事があれば、全てにその情報を反映させています。これらはフローによってSalesCloud上で実現できます。 まとめ 以上のように、人間一人一人に関するレコードはリード or 取引先責任者方式ではなく、プロスペクト方式にしてしまったほうが取り回しがかんたんになります。リードを使った管理方法もよく作られて入るのですが、メンテナンスがされていなかったりで実質機能しなくなった場合にはこのような方法を検討しても良いかもしれません。 気になった場合はお知らせ下さい。 < 事例へ戻る