顧客管理とは

今回のテーマ「顧客管理」です。
顧客管理は、顧客情報と、顧客ごとの売上高や購入頻度などの販売データなどを統一的に管理すること。とweblioには書かれています。
例えば、名刺情報、企業情報、案件情報、商談履歴、購買履歴、問合せ履歴、売上推移、クレーム情報、導入商材などなど、とても広い範囲をカバーするお話です。

ですので、問い合わせをいただいても何を管理するのかによって、必要な項目も異るため「このアプリがいいです」と言えないわけです。orz

本当にいいものを提供しようと思うと、業務のヒアリングをしてからでないと何も言えないわけです。弊社では、コンサルティング事業は行なっていないため、いつも返答に困っております……..。

kintoneの強みを活用しよう！kintoneの特徴とは？

では、顧客管理アプリの構成を考える前に、kintoneの特徴を知る必要があります。

kintoneの特徴は、以下の３点です。

・データベース
・プロセス管理
・コミュニケーション

データベース

kintoneの最大の特徴は、誰でも簡単にデータベース（kintoneではアプリと言います）を作れることにあります。
管理項目の変更や追加、削除も簡単にできますので、業務の状況に合わせてスピーディに対応することができます。

データベースとして、以下の項目（kintoneではフィールドと言います）を管理できます。

文字列（1行）
リッチエディター
文字列（複数行）
数値
計算
ラジオボタン
チェックボックス
複数選択
ドロップダウン
日付
時刻
日時
添付ファイル
リンク
ユーザー選択
組織選択
グループ選択
関連レコード一覧
ルックアップ

一般的な業務を管理するには、十分なフィールドが用意されています。

ただ、ここで注意！！
kintoneでは、１つのアプリに対して、１つの詳細画面（kintoneではフォームと言います）しか作ることが出来ません。

プロセス管理

一言で言うと、ワークフローです。
複数のユーザーでレコードの編集や確認、承認などをするためのプロセスを管理することができます。

この部分は、顧客管理アプリの構成を考える上では重要でないため今回は割愛します。

コミュニケーション

データベースで、「kintoneの最大の特徴」と言ってしまいましたが、「kintoneの２大の特徴の一つ」に修正します…….
コミュニケーションも、kintoneの最大の特徴の1つです。

kintone以外にもデータベース製品は数多くありますが、kintoneを利用して一番便利になるのはこの部分でもあります。

kintoneアプリに保存された、一つのデータ（kintoneではレコードと言います）に対して簡単にコミュニケーションをとることができます。
上司の判断が必要な場合やイレギュラー情報など、日常的に発生する共有した方が良い事象を簡単な設定で利用できるようになります。

 

では、いよいよこれからが本題の顧客管理アプリの作り方になります。

業務単位にアプリを作れ

kintoneでは、最初にアプリ（データベース）を作ります。
どの範囲の情報を管理するデータベースを作るのか？　のお話になります。

kintoneでは、「業務単位にアプリを作る」ことが最も便利な利用法です。

ここで言う「業務単位」とは、同じ業務をするメンバーを一つの単位としてアプリを作ると言うことです。

例えば、顧客管理システムに、請求系情報などの管理業務と追加販売など営業系業務、問い合わせなどサポート系業務があるとします。
業務内容は違いますが、同じお客様に対して活動をしているケースのアプリはどう作るのか？を考えます。

kintoneでは、以下のように全ての情報を一つのアプリに詰め込んで作らない！と言うことです。

あえて以下のように、各業務に分散させてアプリを作ると便利なんです。

「必要な情報」を「必要な人」に「必要なタイミング」で届ける

なぜ、アプリを分散させるのか？

理由としては、管理業務において重要なポイントは、ミスを減らし、効率を高めることです。
簡単にいうと、利用頻度の高い項目は一目でわかりやすくすることが重要になります。
また、ミスを少なくするためには、必要な情報だけをしっかりと確認できるようにするべきです。

kintoneでは、一つのアプリに対して、１つの詳細画面（kintoneではフォームと言います）しか出来ません。
業務が異なれば、確認したい項目も異なります。
一目で確認できるようにするには、アプリを分けるのが最も効率的な方法となります。
そのため、各業務に合わせてアプリを作ると確認したい項目が一目でわかり便利になります。

さらに業務単位でアプリを作成することで、kintoneの最大の特徴であるコミュニケーション機能を
最大限活用することができるようになります！

いやいや、どんな情報でも共有した方が良い！という、思想家の方もいますが、

それは、 間　違　い　で　す　。　私個人としては言い切ります！

自分に関係のない情報がたくさん届くとどうなるでしょうか？

読まなくなるだけです。
スパムメールと同じ。システム通知に、ゴミが混じってくると言うことです。

大切なことは、「必要な情報」を「必要な人」に「必要なタイミング」で届けること！
業務単位にアプリを構築することで、これが可能となるわけです！！！

システムは、使われてナンボ！

アプリの作り方の次は、管理項目（フィールド）のお話です。

管理とは、ある規準などから外れないよう、全体を統制すること。と言われています。

管理する項目の自由度をどの程度にするべきなのでしょうか？

ガチガチに統制すると、イレギュラーを管理できなくなります。
逆にイレギュラーまで管理できるようにすると登録する項目や選択肢が増え、使い勝手の悪いシステムになります。

ここで重要な考え方は、「システムは、使われてナンボ」と言うポイントです。

kintoneの特徴として、誰でも簡単にアプリが作れるため、
最初から全てを満たす複雑なアプリを作らない！
とにかく、管理項目を少なく始めることがオススメです。

まず、全員が簡単に利用できる。ここから始めましょう。

なので簡単でシンプルなアプリが最高なんです。

例えば、住所情報を管理するとします。

都道府県だけ確実に登録させたければ、都道府県だけ、ドロップダウンで管理するべきです。
その他は、文字列（1行）でいいでしょう。
この情報を活用して郵送などに利用しているのであれば、ビル名などは別の文字列（1行）を用意した方が良いでしょう。

くどくなりますが最後のチェックポイントは、都道府県だけ、ドロップダウンで別に管理する必要ありますか？
管理項目は少ない方が利用するメンバーは便利になるので注意が必要です。一つ一つ吟味して、少なく作りましょう。

フィールドタイプについては、使い勝手を考えて柔軟にしながらも統一性を取りたい部分だけを最小限に制限するべきでしょう。
このバランスこそが、心地よい人間らしいシステムにするセンスの部分で重要となります。

個人的には、重要な部分を絞り込むこと。重要な部分だけ、運用に任せず確実に登録するように設計しましょう。

kintoneは後からでも、簡単にアプリ内の管理項目（フィールド）を追加、変更、削除できるので

利用頻度に合わせて、徐々に進化させるのがkintone流です。

分散したアプリを便利に使いこなす

アプリを分散させると情報がバラバラになると心配されるので、そうさせないための工夫を紹介します。

分散されたアプリ間を融合させるために、ルックアップと関連レコード一覧の２つのフィールドが重要となります。

ルックアップとは

ルックアップは、アプリに入力するデータを他のアプリから取得できるようにする機能です。
データ入力の手間を省き、入力ミスも防げます。

顧客管理においては、お客様の会社名や郵便番号、住所、電話番号、また担当者の氏名、部署名、メールアドレスなど共通の情報をマスター情報として管理します。
各業務アプリはマスター情報からデータを取得してデータの整合性を保つようにします。

注意点としては、ルックアップの操作をしたタイミングのマスター情報を各アプリに取り込みます。マスター情報を更新すれば自動的に全てのアプリの情報も更新されるリレーショナルデータベースとは違いますので、注意が必要です。

このシステムの利用頻度が高まるのでしたら、カスタマイズしたJavaScriptを登録することで、マスター情報を更新すると自動的に各業務アプリの情報を更新することも可能です。ですので、リレーショナルデータベースと同様の利用方法もできるようになります。

関連レコード一覧とは

分散アプリでは最も重要なフィールドと言えます。
「関連レコード一覧」は、指定した条件にあてはまるレコードをフォームに表示するフィールドです。
同じアプリのレコードだけでなく、他のアプリのレコードも表示できます。
そのため、マスター情報を共通にしておくことで、各業務アプリケーション間をワンクリックで同じお客様の情報にアクセスできるようになります。

さいごに

顧客管理というテーマでしたが、kintoneアプリの作り方という哲学的な感じになってしまいました。(^-^;
ちなみに、１つのアプリで複数のフィールドが設定できるようにkintoneの機能が追加されたとしても、この考えは変わらないと思っています。
コミュニケーション量の少ないアプリは統合して運用できると思います。
重要なのは、「必要な情報」を「必要な人」に「必要なタイミング」で、これが目指すべきシステムだと思っているからです。

かなり長々と書きましたが、最後まで読んで頂きありがとうございました。

(※この記事はワイワイが執筆したものを加藤が編集・アップロードしました。)