見出し画像

#Salesforce 上のデータの重複管理について #SFKT に参加したので振り返ってみる

Salesforce 活用分科会に初めて出席してみました。
テーマが「重複データ、みんなどうしている?」だったので。

過去にいくつか僕らの実践についても紹介してきたので、他の組織でどんなふうに取り組んでいるのかが単純に興味があったという訳です。

重複データってなんだっけ?

Salesforceでいうと、標準オブジェクトのリード、取引先責任者、取引先の3種類ではよく重複データが作られがちです。
取引先でいうと、取引先名で重複チェックを走らせても、株式会社と㈱で別物として認識されたり、スペースが半角か全角かという違いがあったり、会社名の英字が全角と半角があったり。そんな風にして、同じ対象物にも関わらず複数のレコードが存在してしまうというのが重複データです。
今回の分科会では、Web-to-リードのフォームを使って、外部からユーザーが自分で入れてきたレコードが結果的にリードの重複を生んでいるという話が結構出ていたような気がします。
以下では、リバネスでやってきた重複管理についての実践事例を紹介していこうと思います。

外部からの情報収集はPardotフォームを使う

かつてはweb-to-リードを使っていた事もあったのですが、弊社では1年使ったあとにPardotを導入しました。Pardotのフォームは、既存ユーザーの場合は既存のプロスペクト(メアド単位で発行される個人レコードのこと)に紐付けてくれるので、無限にリードが作られるということはありません。Web-to-リードで実現したかったフォームはPardotでも作れるということで、あっという間に移行してしまいました。
ただ、今回の分科会で紹介された事例では、既にSalesforceを使い倒して様々な自動化処理を組み込んだあとであり、PardotとSales Cloudを連携することで起きる様々なコンフリクトの検証が難しいという課題があったので、Pardotに移行すれば幸せになれるのかというと、組織に依るとしか言えないのかという気付きがありました。
そんな訳で、自分の組織の現状にとって一番リーズナブルな方法を選ぶことが幸せへの第一歩だなと。それと、SalesforceのAEの皆さんにおかれましては、将来起こりうるデータ処理の煩雑化についてもしっかりと認識にいれていくことによって、こういったコンフリクトや場合によっては二度手間が発生するみたいな状況を回避して頂ければみんなハッピーなのではないかと思っております。最初から投資がかさむという話にはなるのですが、Pardotはライセンス数契約ではないため比較的コンパクトな料金体系で利用可能なので強く推して頂けると助かります。

手入力をしない

Sales cloudで重複を生むのは誰なのかという話ですが、人間のパターンが多いのではないかと思います。先程のPardotのフォームもそうなのですが、人間が入力すると一定のエラーを生じさせます。間違えるつもりはなくても間違ったデータが入ってきたりするものです。
我々もご多分に漏れずそんな状態になりました。そこでできる限り顧客情報については手入力を控えましょう。そもそも手入力面倒だし。ということになるわけです。最初はSansanを使っていましたが、その後にPhoneAppliさんに乗り換えています。名刺はスキャナで読み込んで自動的に電子化されてSalesforce内に入るという仕組みです。シンプルですが、非常に効果のある方法で、これを使わずにリードのリストを作るというのは今では考えられません。最初にこの仕組を考えた人は天才だと思う。
手入力をしないので間違いが減ります。かつて起こっていたtypoは一掃あれ、不良データがそもそも生成されなくなってきました。

リードの取引先責任者へのコンバート

これは上に貼った記事にも書きましたがFORCUSさんを使いました。
非常に便利な機能だと思うので、自前でも開発してみようかなと思っています。FORCUS自体は要らんのだけどという場合もあるだろうしね。

発生してしまった重複データのマージをどうするか問題

これも上の記事に書いたとおり、Duplicate Checkが便利です。ただ、プライシングが対象オブジェクトのレコード数によって変更されるので、大量データがあるオブジェクトに利用しようとするとそれなりのお値段になるので注意しましょう。弊社の場合はマージ用のバッチ処理とマージ画面を作ってしまいました↓。レコード数が増えすぎたんですよね。

PardotからHerokuへ

これは完全に弊社事情なので参考にならないかもしれませんが、リバネスIDという会員向けサイトをHeroku上に作成し、Heroku Connectを使ってSales Cloudと同期しています。
問い合わせフォームなんかもHeroku上のアプリに生成させて受け付ける事によって、既存ユーザの場合はレコードがすべてその人に紐づくようになっています。
そうしておくことで、誰がいつどんなアクションを行ったのかが1ページの中にすべて網羅されることになり、データの解析も非常に容易になるという仕組みになっています。

データの重複がなくなると何が嬉しいんだい?という話

これはそもそも論で、ここについて考えずにデータの重複管理のことを考えるのは無意味です。重複しなくなることによってどんなメリットがあるのかについてしっかり考えましょう。
弊社の場合でいうと
①取引先の重複がなくなると、すべての商談が、取引先ページを開くことで把握することができるようになります。年度ごとの提案金額、成約金額が分かるようになりますし、それによってホワイトスペースを見つけることが容易になります。取引先が重複して分散していると、その組織に対してどの程度の提案が出来ているのかの見通しが立たなくなるので非常に困る訳です。
②取引先責任者の重複がなくなると、これも①と連動するのですが、その人に対してどんなアクションをとったのかが集約されますので、過去のやりとりを確認しながらアプローチを考えることが出来ます。直接対面する人が事前にレコードを見ておくことですべてのアクションが把握できるようになるため、提案がやりやすくなるというメリットがあります。
③リードの重複がなくなるとどうなるかというと、これも②と同じです。弊社の場合はコンバートしなくても、リバネスIDというオブジェクトを作ってそこに紐づくようになっている為、リードとコンタクトが重複していても実質影響はありません。

ということで、色んな実践のやり方があるなと思うとともに、データの管理方法はビジネスモデルやシステムの実装具合によってベストプラクティスはまちまちであるということも認識出来た良い機会だったなと思いましたとさ。

noteにはこれまでの経験を綴っていこうかと思います。サポートによって思い出すモチベーションが上がるかもしれない。いや、上がるはずです。