kintoneでリード管理＆再アプローチ先の自動生成で業務改善した事例
kintoneを用いてリード先の管理をしている、福島県二本松市の弊社お客様の事例です。
kintoneリードアプリにより新規問い合わせがあったお客様を管理
新規お問合せを管理するために、kintoneで問い合わせ管理用のアプリを作り、問い合わせから受注・失注までのステータス管理をされています。
お問い合わせには様々な情報が絡みますが、このアプリでは主に次の内容を管理しています。
- 受付日時
- 事業
- 対応店舗
- 担当者
- お客様の名前（漢字名とかな名）、住所、電話番号
- 問い合わせの経緯（新聞、チラシ、HP、SNS、紹介 など）
- 連絡事項（問い合わせ内容）
- フェーズ（アプローチ中、ヒアリング中、提案中、見積提示中、受注、失注、など）
- 対応結果（定期契約、スポット契約、お試しのみ、見積のみ、など）
- 対応履歴（テーブルにて管理）
業務の流れですが、問い合わせは電話で来ることが多いため、
- 事務の方が受付をし、その内容をアプリに登録する。その際、担当者も合わせて入力して登録する。
- 担当者にkintoneで自動通知される。
- 担当者がお客様に連絡し、進捗を随時アプリに登録する。
- 結果を登録する。
といった流れで運用をしています。
営業担当は基本的に外にいるため、アプリに登録されたタイミングで通知するようにしてタブレットでその内容を閲覧するような形としています。問い合わせがあった都度、事務から担当者へ電話連絡する必要もなくなり、データもkintoneに残るため、状況がこれまでに比べて把握できるようになりました。
リードアプリの工夫
フィールドの幅と並びをタブレットに最適化
kintoneをタブレットで使用することが多いことから、フィールドの幅と並びをタブレットに最適化するようにしています。当初はフィールドの幅や並びは特に意識していませんでしたが、メインユーザである営業担当のタブレット利用を考慮し、アプリ作成後に改良を重ね、現在は次のような形となっています。主にアプリのメンテナンスは社長が行われており、色々なアイディアをアプリに入れて形にされています。
お客様名の読みがな用フィールドの定義
電話受付が多いため、漢字が正しいかわからない点と、表記ゆれが発生するケースを考慮して、ひらがな項目を追加しています。これは、データ登録後の検索性を考慮してです。
（例）わたなべ → 渡辺・渡邊・渡邉・・・となべの字が色々とあるため
事業年度用のフィールドの定義
受付日時から年度を自動設定するようにしています。このフィールドは後でグラフ化して集計する際の情報として利用することを目的に用意しています。「日付変換プラグイン」を用いて、受付日時の値を元に事業年度と月のそれぞれのフィールドに値を設定しています。
住所の入力簡略化
住所は当初、文字列（1行）フィールドを用いていたのですが、電話越しだと漢字がわからないケースも多く入力間違いにつながる可能性もあったため、プラグインを用いて入力作業の簡略化を行うように今は改善しています。
「kintone 都道府県/市区町村/町名/郵便番号変換プラグイン」を用いて、リストから選択して住所入力できるような形としています。
実際には、まずお客様に郵便番号を確認しkintoneの郵便番号フィールドに入力します。郵便番号を入力すると都道府県・市区町村・町名が自動設定されるため、そのあとの番地以降を入力するような流れができあがりました。
再アプローチ先への課題
新規問い合わせの受付から受注・失注まで流れはアプリで一通り形ができていたのですが、失注になったお客様への再アプローチの方法が課題でした。
この事例のお客様では、季節に関わるお悩みを解決する事業を行っています。そのため、問い合わせされる方は毎年同じ時期に同じようなお悩みが発生します。仮に今年失注になったとしても来年も同じお悩みが発生する可能性があるため、それを見越して自社からプッシュ営業するような形を行っていきたいという社長の考えがありました。
（例）去年の1月にお問い合わせ → 失注 → 今年の1月頃に自社から再アプローチして営業をかける
再アプローチ先を抽出する処理をカスタマイズで実装
失注したデータはアプリ内にあるため、そのデータを編集して毎年使っていくというのも1つの方法でしたが、それだとデータが「新規問い合わせ」なのか「再アプローチ」なのかの判別がつかなくなってしまいます（別途年度や月別にグラフ集計しているため）。そこで、再アプローチ先としてレコードを一括生成するようなカスタマイズ処理を実装しました。
再アプローチ判断用フィールドの追加
まず、アプリ内に「再アプローチ判断」というフィールドを追加し、新規問い合わせが失注または受注になったタイミングでそのフィールドに翌年「再アプローチする」のか「再アプローチしない」のかを営業担当者に入力してもらうようにしました。
すべての問い合わせについて再アプローチする必要はなく、場合によっては再アプローチが不要な場合もあります。その判断をまず受注・失注した段階で営業担当者に入れてもらう形としました。
再アプローチ先データの一括生成処理の追加
次に、再アプローチ先を別レコードとして一括生成するカスタマイズを追加しました。
レコード一覧画面に一括生成用ボタンを表示し、ボタンをクリックするとダイアログが表示されて、いつ受付したデータに対して再アプローチ先としてデータを生成するかを選択し、実行すると再アプローチ先データが出来上がるような動きです。
上記はアプリの一覧画面に「一括生成」ボタンを表示し、クリックした際に表示されるダイアログです。
毎月1回、前年同月頃に受付したリード（再アプローチ対象としたリード）に対して再アプローチを行っていくような運用です。再アプローチ時は過去のやり取りや問い合わせ内容を見ながらコンタクトを取っていきます。
再アプローチ業務の効果測定はこれから
再アプローチについては運用をこれから開始していくため、行っていくうちに改善要望が色々と出てくると想定されます。
再アプローチ選任の担当者が一括生成で作られたデータに対してアプローチをしていく運用をしようとしていますが、もしかすると前年にやり取りをした担当者が再アプローチをしたほうがいい、という要望が現場から出てくるかもしれません。
実際に使って運用しながら課題を出しつつ改善を続け、より効率的な形に持っていけるようにサポートしていきたいと思います。
