kintoneで営業管理を作る｜顧客・営業履歴・案件・売上をどう設計する？【実践記②】

前回は、社内に散らばっていたExcelやWordを整理するため、kintoneを導入することになった経緯を紹介しました。

Excel管理をkintoneへ移行｜中小企業で業務改善を始めた理由【実践記①】

最初にkintone化することになったのは、営業管理です。

当時の営業メンバーは3人。

顧客情報や商談内容は、それぞれが自分のパソコンにある

ExcelやWordで管理していました。

誰がどの会社に営業しているのか。

何を提案したのか。

今どんな案件が進んでいるのか。

それを知るには、本人に聞くか、会議をするしかありません。

そこで目指したのが、

「顧客管理を見れば、その会社とのやり取りが分かる状態」

でした。

今回は、プログラミング未経験・kintone初心者の状態から、実際に営業管理の設計を始めたときの話です。

営業管理で最初に欲しかったのは4つだけ

kintoneの作り方は分かりませんでしたが、営業として欲しい情報はある程度イメージできていました。

必要だと考えたのは、大きく4つです。

・■顧客情報■：誰に営業しているのか

・■営業履歴■：これまで何をしてきたのか

・■案件情報■：現在どんな商談が進んでいるのか

・■売上情報■：最終的にどれだけ売れたのか

理想はシンプルです。

ある会社について知りたければ、顧客管理を開く。

そこから、

■顧客情報 → 過去の営業活動 → 進行中の案件 → 売上■

まで確認できる。

これができれば、それぞれのパソコンに保存されている

ExcelやWordを探す必要がありません。

「この会社、今どうなってる？」

と担当者に聞かなくても分かります。

kintoneの営業管理を4つのアプリに分ける

まず、実現したい営業管理についてChatGPTに相談しました。

そこで提案されたのが、次の4アプリに分ける構成です。

■顧客管理■

会社情報・担当者情報など

■営業報告■

訪問・電話・メール・商談などの履歴

■案件管理■

商談内容・進捗・見込みなど

■売上管理■

受注後の売上情報

そして、それぞれのアプリを連携させる。

自分が見たかった情報とも一致していたので、

まずはこの構成で進めることにしました。

ところが、ここで最初の問題が出ます。

項目、多すぎない？

4つのアプリ構成を決めると、

今度は各アプリに必要な項目を考えます。

顧客管理には、

会社名、住所、電話番号、担当者名、メールアドレス、顧客区分……。

営業報告には、

訪問日、担当者、活動内容、商談内容、次回アクション……。

案件管理には……。

売上管理には……。

候補を出していくと、あっという間に項目が増えていきます。

もちろん、情報は多い方が分析できることも増えます。

ただ、ここで考えました。

■本当に全部入力してもらえるのか？■

高機能より「入力が面倒じゃない」を優先した

今回作る営業管理は、私一人だけが使うものではありません。

ITツールに慣れていないメンバーも使います。

入力画面を開いた瞬間に何十個もの項目が並んでいて、

「ここも入力してください」

「これも必須です」

「これも選択してください」

となれば、それだけで入力することが面倒になります。

どれだけ高機能なシステムでも、使われなければ意味がありません。

そこで最初の設計方針を決めました。

■必要最低限から始める。■

最初から完璧な営業管理を作るのではなく、

本当に必要な情報だけ登録する。

必要になった項目は、実際に運用しながら後から追加する。

今振り返っても、この考え方はかなり重要だったと思います。

最初に作ったのは「顧客管理」

4つのアプリを同時に作るのではなく、まず顧客管理から始めました。

ところが、ここから別の問題が発生します。

■営業管理の設計は分かっても、kintoneの作り方が分からない。■

アプリを新しく作るところから始めます。

アプリ名を設定して、フォームを作る。

ChatGPTから、

「文字列（1行）フィールドを配置してください」

と言われました。

……文字列（1行）って何？

本当にそこからです。

kintoneの「文字列（1行）」とは？

kintoneでアプリを作成するときは、フォーム上に「フィールド」を配置していきます。

たとえば、

会社名 → 文字列（1行）

のように設定します。

ほかにも、用途に応じてさまざまなフィールドがあります。

会社名なら文字列。

日付なら日付フィールド。

選択肢から選ばせたいならドロップダウンやラジオボタン。

数字なら数値フィールド。

実際に触れば難しいものではありません。

ただ、初めてkintoneを触る側からすると、

「会社名を入力する箱を作りたいだけなのに、どれを使えばいいの？」

というところから始まります。

会社名を作る。

住所を作る。

電話番号を作る。

メールアドレスを作る。

一つずつフィールドを配置していきました。

そして思います。

■これ、全部一個ずつ作ると？■

テンプレートを使えば早い……と思った

そこで気付いたのが、

kintoneにはアプリのテンプレートが用意されていることでした。

顧客管理用のテンプレートを使えば、

最初から必要な項目がある程度揃っています。

「最初からこれ使えばいいやん」

と思って中を見ると、今度は逆の問題が起きました。

■項目が多い。■

自分たちには必要ない情報まで入っています。

不要な項目を削除する。

配置を変更する。

項目名を変える。

必要なものを追加する。

結局、

「これ、最初から作った方が早くない？」

となりました。

そこでテンプレートを使うのをやめ、

必要な項目だけで顧客管理を一から作ることにしました。

テンプレートを使うべきか、一から作るべきか

これは実際にkintoneを導入するときにも迷いやすいところだと思います。

テンプレートには、すぐに使い始められるメリットがあります。

一方で、自社の業務と合わない項目が多ければ、

使わない項目までフォームに残ってしまいます。

私たちの場合は、

「入力項目をできるだけ少なくしたい」

という方針があったため、一から作る方法を選びました。

どちらが正解というわけではありません。

重要なのは、

テンプレートに業務を合わせるのではなく、

自社の業務に必要な情報を先に考えること。

だと思います。

フォーム設計では「使う人」を基準にする

必要な項目を一つずつ作りながら、配置も考えました。

会社名。

住所。

電話番号。

担当者情報。

上から順番に入力していけば、自然に登録が終わる。

できるだけ迷わない配置にする。

ここでも基準にしたのは、

「自分が分かるか」ではなく「ITが得意ではない人でも分かるか」です。

業務システムは、作る人にとって使いやすいだけでは足りません。

実際に入力する人が、

「これ何を入れると？」

となれば、そこで運用が止まります。

■機能を増やすより、迷わせない。■

この考え方は、その後ほかのアプリを作るときにも基本になりました。

一つの会社に担当者が複数いる場合はどうする？

顧客管理を作っていると、次の疑問が出てきました。

一つの会社に、担当者が一人とは限りません。

営業担当者。

経理担当者。

代表者。

複数人を登録したい会社もあります。

担当者1、担当者2、担当者3……と項目を作ることもできます。

でも、それでは担当者が増えるたびにフォームを変更しなければなりません。

そこでChatGPTに相談すると、

「テーブルを使いましょう」

と言われました。

テーブル？

なんそれ？w

kintone初心者でも、業務から逆算すれば設計できる

この時点の私は、

アプリを作る場所を確認して、

「文字列（1行）」の意味を調べて、

テンプレートを試して、

結局一から作り直して、

ようやく担当者情報までたどり着いたところです。

kintoneに詳しかったわけではありません。

ただ、

「営業として何が分かれば仕事が楽になるか」

「実際に使う人が面倒に感じないか」

この2つは分かっていました。

kintoneを使った業務改善では、

機能を知っていることももちろん重要です。

でも、その前に、

「今の仕事で何に困っているのか」

を整理することが重要だと思います。

機能は後から調べられます。

項目も後から増やせます。

最初から完璧なアプリを作る必要はありません。

■まずは、小さく作って実際に使ってみる。■

私たちの営業管理も、そこから始まりました。

次回：担当者を複数登録したい。「テーブル」を使ってみる

次にぶつかったのが、今回最後に出てきた「テーブル」です。

一つの会社に複数いる担当者を、どうやって顧客管理に登録するのか。

そして、顧客管理から営業履歴や案件をどうつないでいくのか。

実際に作りながら考えていきます。