これから始める人や始めたばかりの人に届けたい、Salesforce こうやっておけばよかったなリスト

Salesforceは2014年から導入しているのですが、今となってはこうしときゃよかったなというものもあります。今日はそんな話。

名前の登録について

Salesforceを使い始めて最初に驚いたのが、FirstNameとLastNameの入力欄が別れていることです。LastNameが必須情報になっていてそこは外せません。

実はSalesforce導入前までは、姓名一緒になっていたので、わざわざmecabで分かち書きスクリプトを使って姓名を分けました。おかげで、ちゃんと別れていないものもいくつか存在しています。

5年経って思ったことなのですが、世の中には姓名だけじゃ収まらない名前があるのです。姓なんてなくて全部名だという国もある。ミドルネームがあったりする。

結果的に言うと、自分で入力したそのままがName項目に入ればそれで事足りるのです。LastName欄だけ使っていればそれでOK。余計なことに時間を使うのはやめましょう。多大な時間を使ってきましたがはっきり言ってどうでも良いことです。

できる限り手動入力しない

特に名刺は、サードパーティを使うべし。自分で入力するのは時間の無駄だし、正確性を担保できない。リバネスの場合は、半期に一度の面談で、これまでに交換した名刺がどんな感じだったのかを見るフローが組み込まれているので、読み込みムラみたいなものはありません。(以下の定着部分にも記載)

承認フローについて

これはなかなか難しい事かもしれないのですが、承認フローについてはできる限り作らないほうが良い思っています。例えば稟議承認なんかは最たる例だとは思うのですが、それすらも承認フローなしに成り立つように仕組みを作ったほうが良いだろうと考えています。リバネスの場合は導入以前にあったものを慣習的に受け継ぐ為に設定をしましたが、あれによって無駄な承認フローが組織に残ることになりました。

やるなら、承認が必要であろうフローで確認したかったことを自動的に発見できるような仕組みに留めた運用にこだわるべきだと思う(めちゃくちゃセンスが必要だと思うけど)。稟議承認をきちんとやりたいという場合であっても、じゃぁガバガバだったらどうなるのかを見守って比較すれば良い。経費がかさむようになるのであれば、経費に対する意識がつくような画面構成を作ればよいだろうし、常に全社的な経費率がわかるような状態を作っても良いだろう。心配なことがあるのであれば、一定期間の運用期間を決めて振り返りを行い反省をする。何でもかんでも承認申請というプロセスで縛るのは、効率を著しく下げる。僕は今一度このあたりをやり直したいと思っている。

取引先の登録について

導入時は、同じ取引先でも部署が違ったら別の取引先を作っていたのですが、これは運用がつらくなるので非推奨。一つの取引先に、全員のコンタクトをぶら下げ、部署等についてはコンタクト側に書き込む形のほうが運用が楽。名刺読み込みアプリやFORCAS等のサードパーティが自動的にコンタクトの情報を書き換えてくれますので、人力でやらずに自動化しましょう。取引先の住所や電話番号というのは基本的には一番代表のものが入る形になりますがそこについてはあまり重視せず、取引先責任者(コンタクト)の情報を使うのが良いと思います。

リードとコンタクトについて

Salesforceには未取引の名刺情報をリードとして登録するという文化があります。リードを育成して、取引を開始すると、取引先レコード(アカウント)と取引先責任者(コンタクト)が作られる形になります。

きちんと運用されていればよいのですが、大抵の場合は、同じ会社のリードが複数名いて、その中のひとりを窓口にして商談が始まるという形になるでしょう。その際に、その他の人はリードレコードに滞留することになり、結果として取引は始まっているにも関わらずリードに残り続けることになります。非常にツラいですね。ということでこれについてはすでに解決策がこちらにありますのでご参照ください。

リードとコンタクトについてその２

この2つのレコードはPardotを使っていたりすると重要です。デフォルトでは、Pardotに関する情報はリードorコンタクトにしか同期しません。つまりカスタムレコードで顧客管理をしようとしても普通は無理なのです。

一方で、リバネスではリバネスIDオブジェクトというカスタムオブジェクトを作り、そこから関連レコードとしてリード/コンタクトにリンクが貼ってあります。もし、PardotスコアをリバネスIDから参照しようとすると、数式項目でリバネスID>リード>Pardotスコア という参照をすれば読めます。便利。

Einsteinも基本的には1オブジェクトにデータを纏めなければなりませんので、弊社ではリバネスIDにまとめて、それを分析するようにしています。

CommunityCloudについて

2年前に、会員サイト運用を始めようと思ってCommunityCloudを利用しました。あっという間に会員サイトのローンチが完了し、ITリテラシーのさほど高くない人でも管理が可能です。CommunityCloudで作られたデータは当然Salescloud側でオブジェクトを指定すれば見れます。これまで、Wordpressに作ったフォームに溜まったデータで申込状況を管理するなんてことをやってきたのですが、データのExport→整形→分析→開示というフローが長すぎて嫌になってしまうんですよね。その点、CommunityCloudを使えばユーザが必要な情報を自分で変更してくれます。なんという革命。

一方で、CommunityCloudで登録されたユーザーは、ある特定の取引先に全部ぶら下がることになります。所属が特定の取引先に固定されます。これが意外と辛くて、弊社では使わなくなったCommunityのユーザをわざわざ正しい取引先に付け替える作業を行っているのですがこれが面倒臭い。なぜそんな仕様にしてしまったのだCommunityCloudよ…

CommunityCloudはライセンス数課金ということで、人数が増えるとそのままコストに跳ね返ります。CommunityCloudを使ったことによってオンライン上でのコミュニケーションがうまくいくことが分かったので今はCommunityCloudを卒業して、Heroku上に作った会員サイトで運用をしています。

Salesforceの定着について

ここはめっちゃ聞かれるのですが、定着もなにも弊社の場合は使ってないと、自分の実績を残せません。↑にも書いたのですが、半期の面談にはSalesforceのデータが使われます。Salesforce上のダッシュボードを見て色々な話をするというフローになっているので、何もやってないと真っ白ということになります。やらないインセンティブがないんですね。

定着しないんですという会社の話を聞くと、今までのワークフローはそのままにSalesforceをとってつけましたみたいなスタイルであることが多い印象があります。会社のワークフローの見直しを含めてSalesforceの導入だと思うのですが、それがなければやはり定着は難しいですよねということになってしまうと思います。→詳細についてnote追加しました

報告書等の、書いても読まれないみたいな話

週報なんて誰も読んでやしないみたいな話は会社への不満の代表格みたいなものだと思うのですが、弊社にも週報は存在しています。昔はメーリングリストに流すみたいな運用になっていたのですが、いちいちメールに返信入れるのも面倒ですし、読んでるかどうかなんて分かったもんじゃありません。それはリバネスも一緒でした。

現在は、Salesforce上に週報登録フォームがあり、かんたんに登録することができるようになっているのですが大事なのはそこじゃありません。

登録された週報は、slackの週報チャンネルに自動的に流れるようになっています。Chatterでも同様のグループを作って展開してもいいでしょう。

コメント入れたり、スタンプつけたりと、人によってレスポンスは様々ですが、読まれちゃいないよねという感覚にはなっていない気がします。

有効化/無効化が発生する選択リストの運用について

リバネスの場合でいうと、リバネス研究費というカスタムオブジェクトがあって、その中に申請先研究費というカスタム項目があります。これは選択リストになっています。

去年までCommunityCloud上でユーザーが申請書を記入するという活動をしていました。今はHeroku上で同様のことをやっています。

さて、申請先研究費という選択リストを作ると何が起きるのかというと、例えば申請書の締切が終わったとき、該当する研究費項目を無効化することで選択肢に出なくなるという運用になるのですが、これをしてしまうともし該当する申請書に修正が入った時に思いっきりエラーになるんですよね。「そんな研究費はありません」みたいな感じで。仕様としてはそのとおりなのですが、ちょっと面倒です。

実は弊社のデータはそんな構造になっているのですが、これからは以下の構成にするつもりです。

研究費<-申請書->リバネスID
->は主従関係

こうすることで、研究費オブジェクトのカスタム項目で有効無効を選択すれば良くなります。本来は申請書オブジェクトにあった申請する研究費項目は、選択リストではなく親カスタムオブジェクトへの参照項目となるのです。エラーが起こらない形での運用ができるようになります。

言語設定を英語のみにすべきだった

グローバルに採用を行うことを想定しているのであれば、最初から英語環境のみでの運用をおすすめします。日英両方のSalesforce用語を知っていなければならないのは、負荷でしかないのです。

Pardotのプロスペクト運用について

Pardotはプロスペクト数がある程度を超えると1万件ずつ課金される仕様なのですが、それもあって、活性の低いプロスペクトを削除したりしていませんか。少なくとも弊社では昔はやっていました。

ある程度本当に無駄というところまでいったら削除しても良いと思うのですが、昨今のPardot Advancedで実装されたEinstein行動スコアのおかげで、削除するのはやめようという形になりました。

リバネスではPardotの各種情報を、他のデータと組み合わせてEinstein予測ビルダーを使って解析しているのですが、プロスペクトを削除してしまうと最新のアクティビティログが入らなくなってしまうんですよね。

百歩譲ってNever Activeの人は削除しても良いかなとは思いますが、少しでもアクションがある人については、おいといたほうが良いと思います。

ーーーーーーーー

眠くなってきたのでこのへんで。