ITエンジニアがインサイドセールスの白本読んでみた②
こんにちは。のんです。
今回から、スマレジの営業さんからお貸しいただいた「インサイドセールス」を読んでいこうと思います。
いえーい！
— のん🐘夜型言語 (@nonz250) August 2, 2021
インサイドセールスについて呟いたら、 @Mar_Cyyy さんが本を貸してくれました！😊
スマレジはインサイドセールスにも力を入れています！ pic.twitter.com/ejVLBxvAaM
あくまでも私主観での「感想」に近い感じで書きたい。
やはり本である以上、そのまま丸写し、よくない。良いか悪いかは置いておいて私主観の感想を述べる感じになります。
エンジニアがインサイドセールスについて知ったらこういう事考えるんだなぁ...くらいに考えてください。
具体的な内容が知りたい方は実際に購入しましょう！
Amazonのリンクです。アフィではないので安心して踏んでください。
前回の記事はこちら
今回は前回の続きから見ていきましょう。
なぜ今インサイドセールスが必要なのか
この白本の目次から抜粋すると、このくらいあるそうです。
- 顧客の購買行動の変化
- サブスクリプションモデルの対等によるビジネスモデルの変化
- 生産年齢人口現象による働き方の変化
- テクノロジーの進化による働き方の変化
- ゼネラリストからスペシャリストへ。キャリア志向の変化
この中から気になったところをエンジニアの私目線で書いてみます。
顧客の購買行動の変化
「最初に検索し、情報収集を繰り返して出会ったときには購買の57%の購買プロセスが終了している」が気になりました。もちろん、普段私は上記のようなプロセスでやはりモノを購入しています。何ならECサイトでポチーですね。100%終了してしまいます。
BtoBでも同じことが言えそうです。前職もエンジニアだったのですが、外部システムを導入するにあたって、そのシステム関連の営業さんに色々なソリューションを紹介していただきました。
まずググって評判を見たり、お試し機能を利用してみたりした後、心の中ではほぼ購入確定のレベルになって最終確認の意味を込めて営業さんを通して購入します。
営業さんを通して狙うのは
- 直接交渉の値引き
- 社内の同意を更に深く取るために味方になってもらう
- 何かあったときのフォローの期待
ですね。ネットからの申し込みより、優位性がある気がして営業さんを通すことはあるかもしれません。
この時すでに私はある程度の商品知識があるので、初見ではないんですよね。そのときにインサイドセールスというスペシャリストに対応してもらうことができればスムースに購入まで到達できるかもしれません。
テクノロジーの進化による働き方の変化
これはもはや言うまでもありません。
最近ではTwitterやFacebookで営業活動や採用活動をしているアカウントすら見かけます。
こういうのを見ると足で数を稼ぐ「だけ」が正義では無くなったように思えます。
むしろ、SNSやYoutubeで有名になって、向こうから来てくれる仕組みを作り、インサイドセールスが捌く方が効率的なまであります。
ゼネラリストからスペシャリストへ。キャリア志向の変化
別の業界の「キャリア」について考えたことがなかったので、結構ゆっくり読み込みました。
エンジニアやデザイナーでキャリアと言えば、ポートフォリオなどを思い浮かべます。
現に私もどんなものを作ったことがあるのか、どんなコードが書けるのかをGithubなどにアップロードして公開しています。
セールスにも似たような成果共有プラットフォームがあると良いかも？と思いました。
また、オンラインで商談が可能になるということなので、働き方に柔軟性が出ますね。
オンラインということは商談のための資料作りも充実させなければなりませんし、PRの間に15秒くらいのCMを流すのも良いかも。
学会とかではスポンサーのCMをセミナーの間に流したりしますよね。
オンラインということは画面を見ているはずなので、なんかうまくいきそうかもしれません。
資料を充実させるために教育の資料も充実するという良いスパイラルを作ることもできそう。このへんは開発者である私たちや、お客様に説明する部署であるサポートとも連携を取れれば相乗効果が生まれそうですね。
インサイドセールスの立ち上げ
この章を読むと更にエンジニアの考えに近いなぁ。と思いました。
組織論の話なので、やはり共通するものが多いのでしょうか？
- やっぱり。と共感
- インサイドセールスの本質はカスタマーサクセス
- 完成形は常に変化できる組織（アジャイル？と認識）
- ここは勉強になった
- 量の時期から質の時期への変化
この辺について書いていきます。
インサイドセールスの本質はカスタマーサクセス
そうですよね。エンジニアと同じです。というかどの職種も同じです。
営業は売ることが目的ではありませんし、
エンジニアは作ることが目的ではありません。
結局は利用者のためというのが結論です。
これが崩れるとしたらこの世から仕事が消えるでしょう。
ただ、この思考を持ち続けるのは非常に困難です。
私もプログラミングしているときに、利用者のためとか考えている余裕はありません。
だから要件定義や、設計フェーズを作って段階的に作成していくのです。
セールスではどのように利用者のことを忘れないようにしているのか、目の前の数字に囚われないようにしているのか結構気になります。
完成形は常に変化できる組織
インサイドセールスがテクノロジーの進化を基盤に成立しているのなら、テクノロジーが日進月歩であることを是非とも頭に入れておいていただきたいです。去年の非常識が今年の常識になることもあります。
ということは、アジャイル開発のように短いスプリントを区切ってPDCAサイクルを短く繰り返し回していく他ありません。
是非セールスの方にも、スクラム開発について知っていただきたいと思った章でした。
もはや縦割り組織は化石と同義です。一人一人がプロジェクトメンバーであり開発者であるセールスです。
量の時期から質の時期への変化
大変勉強になりました。
開発においても同じようなことが言えそうです。
コードの内容が...というわけではありませんが、最初期は機能実装優先のミニマムリリースして、徐々に増員をしていき、安定稼働を目指すリリースプランは考えるべきかもしれません。
また、バグ数や、PV数などを数値化して、量から質への変換期というのを設ければスムースにチームビルディングができるかも...とも思いました。
最後に
今回は2章と3章の内容について書きました。
この本読んでいると、違う職種の人から開発手法のアドバイスをもらっている気分になってきますね。
最近忙しいので読むスピードが遅いですが、このままお付き合いいただければ幸いです。
その時はよしなに。
.
