見出し画像

【Salesforce×Slack連携】営業畑しか知らなかった僕が営業企画に転身しちゃった話②

嶋方 拓人

こんにちは！hacomonoの嶋方です。

前回の記事から1ヶ月以上スパンが空いてしまいました笑
noteを定期で必ず更新している界隈の皆さんて本当にすごいんだなぁと思い知らされてます。。

今回は前回の続編。と言いますか、

・やっちまった話
・良い感じにできたかも？という話

の2本立ててお送りしたいと思います。

やっちまった話

hacomonoでフィールドセールスとして働きながらSalesforceのあれこれ。いわゆるSalesOps的な業務をしていた僕ですが、2021年10月からは営業企画チーム立ち上げとして専任で働くことになりました。

前回の記事でまずはデータ基盤を整える！から始まったOps業務ですが、
・進行中商談のパイプライン
・受注した商談
・受注率
・失注した商談
は可視化され以前よりは前進してました。
また、副次的な作用ですが営業現場からも『Salesforceってこういうことができるのか！！』的なリアクションをもらえて週末の酒が美味しくなっている僕がいました。（現場からの声ってめっちゃ嬉しいですよね）

ここまでだと全然「自慢じゃん」の話でしかないんですが、ここからがやっちまってます。

定着度ゼロの構築

結論は表題の通りです。つまり「作って終わり」の構築をした時期がありました。
今までスプレッドシートだったりnotionにしか無かった案件情報が全部Salesforceで一元化できた、という状態になると欲が出てきますよね。
例えば、
・受注した商談がなんで受注できたのか知りたい
・どんなお客さんなのか知りたい
などなど。

当時の僕の感情を振り返るとそれぞれの部署の声の板挟みになっており
「これがOpsってヤツかぁ…」という洗礼を受けたような気分になってました笑

（当時感じていた、それぞれの部署のキモチ）

当然入力工数がかかれば現場に負担を強いるワケなので、欲しい情報を取るための項目を用意したとて、入力してもらわなければなんの意味もない訳です。
当時、このような状況を作ってしまいました。

ここで僕なりに反省したのですが、そもそも僕自身が営業マンとしてめっちゃSFA活用するタイプだったかと言われると、入力規則かかってる項目で面倒そうなのは全部「あ」で入れとこみたいな営業マンでした笑
つまり自分の営業としての経験・体験を無視して1番現場に刺さらないことを自分でやってしまっていたんですね。

まとめると
・「Salesforce活用」が目的になってしまっていた
・且つ「活用」の中身が曖昧だった
・人を動かす策を打てていなかった

という感じでした。

良い感じにできたかも？という話

改めて自分自身を思考を1人の営業マンに戻して、「どういう状態だったらSalesforce使いたくなるか」から考えました。
そして考えた結果、もっと営業1人1人を称賛するシーンを作ろうと思いました。

営業マンのよくある心情として
・受注したら「取ったどー！！」という気持ちになる
・が、それを自ら組織に対して共有するかどうかは性格によりけり
・粛々と成果を上げるゴルゴ13みたいな営業マンは聞くまで教えてくれないまである

なので、このあたりの成果共有の場をシステムの力でフォローしたいと考えました。

具体的な設計は後述に続けます。

レコードトリガフローを使ったSalesforce×Slack連携

※今回は「商談が受注になったら受注をお祝いするBotをSlackに通知する」という要件を例にして書きます

表題の構築方法はググるといろんなサイトで出てきますが、なるべく詳細まで書きます！！

１）事前に準備すること

・フローの作成権限を持っているか
・通知したいSlackチャンネルのWebhook URL
※取得方法はググったら沢山出ます（例えばこちら）
・Slack通知時に表示させる項目

２）完成図

３）フロー設定

レコードトリガフローを選びます

４）開始設定

・商談を管理しているオブジェクトを選択してください
・トリガを設定：商談レコードがどういう状態で通知させたいか
（インバウンドのアップセルも通知させたい、という要件だと、受注決まってから商談だけ作るみたいなパターンもあると思います。その場合は「作成または更新」でも良いですが、基本的には「更新された」で大丈夫です）

５）新規アクション
「Publish to Slack」を選択

👇👇👇

※「+新規リソース」の中身については後述

「slack Message」の作り方（＋新規リソースの作成方法）

通知される文章の作り方

↓この枠内で文章を作ります

👇👇👇

例）受注Botの場合（一部抜粋）

':tada: :clap: ' + {!$Record.Owner.CommunityNickname}+ 'が契約を受注しました！おめでとうございます！ :clap: :tada: ' + BR() 
+'作成者：'+{!$Record.CreatedBy.CommunityNickname}+BR()
+ '契約社名 : ' + {!$Record.Account.Name}  +BR()
+'商談名：'+{!$Record.Name}+BR()
+ '月額請求開始月 : ' + TEXT({!$Record.Charging_date__c}) + BR()
+ 'MRR : ' + TEXT({!$Record.MRR__c}) + BR()
+ '受注理由 : ' + {!$Record.Won_Reason__c} + BR()

作成のあれこれ

  • 絵文字も使えます

  • 絵文字やテキストは「’’」で囲います

  • 「リソースを挿入」で「$Record」を選択するとそのレコードに入っている任意の項目から情報をひっぱれます

    • 例えば「{!$Record.CreatedBy.CommunityNickname}」は

      • トリガされた対象レコードの

      • 作成者ID（ユーザID）

      • その人のニックネーム

という感じで抽出してます。

  • 絵文字＋リソース挿入＋テキストで文章作成したい場合は

（’絵文字’+リソース挿入+’テキスト’）という風に、「’’」で囲い、「+」で繋げます

  • 「+BR()」で改行できます

設定後の変化

大きな変化としては、
・なぜ受注できたのか、勝因はなんだったのか、どんなお客様なのかという情報を営業マン1人1人が積極的に入力いただくようになりました。

・Salesforceアカウントを持っていない部署まで受注理由が届くようになったことで、開発と営業の一体感も生まれました。

・全営業マンにスポットライトを当てられる場所を作れたことで、称賛文化の醸成に寄与できました。

また…

受注Botには「取ったどー！！」感もあるようで、Bot通知を鳴らすことを楽しんでくれる営業マンも増えました笑

また、この記事では省略しましたが、この取り組みの結果として失注ならIS、受注後ならCSへ繋ぐ際の情報共有も、Salesforceをハブとして活用としてくれることに前向きになってくれました。

最後のまとめ

僕がここまでで思ったこととして

  • リモートワークの文化が増えてきた昨今だからこそ、より一層の称賛シーンが大事

  • 「顧客主語」というスタンスはOpsにも当てはまる（この記事で言う「顧客」とは、実際に情報を入力してくれる営業マン）

  • 背景＋ベネフィットが人を動かす

です。
なんとなく、ゴリゴリの営業畑からシステム管理者になったっていう人は全体の比率としても少なそうな印象を持っています。
なので、この記事がまた同じ境遇の誰かの助けになれば良いなと思いつつ、1人の営業マンとして感じていたシステム活用の不を忘れずに、引き続き「顧客主語」を全うしたいと思います。

この記事が気に入ったらサポートをしてみませんか？