営業の案件と進捗を、スプレッドシートで管理している。行が増え、人によって書き方が違い、いまどの案件がどうなっているのかが分からなくなってくる。そろそろちゃんとしたものを入れよう、という話になります。
ところが、入れても定着しないことがあります。そして多くの場合、次に出てくる答えは「別のツールを探す」です。 ここが分かれ目だと考えています。
ある中小のSaaS企業を支援しました。営業の進捗管理をGoogleウェブアプリで内製化した事例です。スプレッドシートで管理していて、kintoneでの管理にも取り組んだけれど、うまく定着しなかった。既製のツールを入れれば解決する、という状態ではなくなっていたところから始まりました。
「合わなかった」は、ツールが悪いということではない
先に書いておきます。kintoneが悪いという話ではありません。 合う会社ではきちんと回っています。SalesforceをはじめとするCRMも同じで、入れて成果が出ている会社はいくらでもあります。
私自身、Salesforceをユーザーとして10年使ってきました。 営業マネージャとして、現場で回るように運用を工夫してきたほうです。そのうえで書いています。
問題は、良し悪しではなく、合うかどうかです。 そして合うかどうかは、機能の比較表からは読み取れません。定着しなかった会社が次に見るべきなのは、より高機能な製品ではなく、自社の営業の進め方のどこが製品の前提と違っていたのかのほうです。
ここを飛ばすと、ツールを替え続けることになります。費用も、移行の手間も、現場の「またか」という反応も、毎回かかります。
定着を決めるのは、変えられるかどうか
営業のやり方は動きます。扱う商材が変わる、担当の持ち方が変わる、見たい単位が変わる。管理の仕組みは、この変化に追いつけたときだけ使われ続けます。
だから見るべきは、導入時にどれだけ自社に合っているかよりも、合わなくなったときに誰がどこまで変えられるかです。
- 項目を1つ足したいとき、自社で足せるのか、依頼が要るのか
- 依頼が要るなら、どれくらいで返ってくるのか
- 見たい切り口が変わったとき、作り直しになるのか
入れた直後は、どの選択肢もそれなりに動きます。差が出るのは半年後です。
小さく作って、自社で変えられる形にする
先の事例では、既製ツールに業務を合わせるのではなく、いまの営業の進め方に合った小さな仕組みを、普段使っているGoogle環境の中に作りました。 案件の状況と次の行動を管理するものを、GASでGoogleのウェブアプリとして実装しています。
肝は、作って渡さなかったことです。 管理する項目や運用の変更を、開発者に頼まず自社で行えるようにしました。ツールの入れ替えで終わらせず、内製化できる状態にすることが目的でした。
同じ作り方を、大学でもしています。予算・収益ダッシュボードのウェブアプリ開発は、スプレッドシートや各システムからのCSVを集約して、GASでGoogleのウェブアプリとして実装したものです。普段使っている環境の中で開けるという点も同じです。
この「毎年変わるものを、プログラムの外に出しておく」という考え方は、Excelマクロは、直せる人を探しても止まるにも書きました。作り替えが止まる会社と止まらない会社を分けているのは、そこです。
仕組みだけ入れても、営業のやり方は変わらない
もう一つ、大事な点があります。管理の仕組みを整えることと、営業が前に進むことは、別の話です。
案件の状況が見えるようになっても、次に何をするかの判断が変わらなければ、入力の手間が増えただけになります。先の事例で仕組みを入れたうえで営業研修まで行ったのは、この二つを別々に扱わないためでした。
「管理ツールを入れたのに、数字が変わらない」と言われる状態は、たいてい仕組みの側ではなく、ここで起きています。
まとめると
- 入れても定着しないことはある。次に探すべきは、別の製品ではなく、合わなかった理由
- Salesforceにせよkintoneにせよ、製品の良し悪しの話ではない。自社の営業の進め方との距離の話
- 「合わない」は製品の良し悪しではない。自社の営業の進め方と、製品の前提のずれ
- 定着を決めるのは、合わなくなったときに自社でどこまで変えられるか。 導入時の適合度ではない
- 小さく作って、項目や運用の変更を自社で行える形にしておく
- 仕組みと、営業の進め方は、あわせて見る。 片方だけ整えても数字は動かない
コントランでは、企業の業務改善・内製化支援として、この判断からご一緒しています。いまのツールを使い続けるという結論も含めて、何が合っていないのかを整理するところからご相談ください。