分散していた顧客データと
LINEをつなぎ、
販促に使えるCRM基盤へ。

プロジェクト概要

お客様との接点は多いのに、顧客データは接点ごとに分かれていた。

株式会社YOUMEXは、1951年創業、長野県塩尻市に本社を置く地域生活サービス企業です。サービスステーションを中心に、給油・車検・整備・中古車販売・カーライフ関連サービスを提供し、地域のお客様と日常的な接点を持ち続けてきました。給油や洗車、車検、オイル交換といった来店のたびに、お客様とクルマの情報に触れる機会がある事業です。

一方で、その顧客情報は接点ごとに分かれて存在していました。来店時のお客様・車両の情報は既存の顧客・車両管理システムに、LINE公式アカウントで集めた友だちの情報やアンケートの回答はLINE側の仕組みに、それぞれ別々に蓄積されている状態です。LINEの友だちは増えていても、「このLINEユーザーは、既存のどのお客様なのか」を突き合わせる仕組みがなく、顧客データを持っていても販促に使い切れていませんでした。

LINEを通じた販促活動を本格化させるために必要だったのは、新しいツールではなく、まず「誰がどの顧客なのか」を認識できる状態でした。eapはこのタイミングで、その状態を業務から定義し、既存プロダクトを組み合わせた基盤の設計・開発、そしてローンチ後の定着支援までを担当することになりました。

難しさは「データを集めること」ではなく、LINE上のユーザーを既存のどの顧客として認識するか。

ご相談の出発点は「蓄積している顧客データをLINEでの販促に活かしたい」でした。ただ、業務とデータの流れを整理していくと、本質的な課題はデータを一箇所に集めることではありませんでした。

LINE上のユーザーと、既存システムに登録されているお客様は、それぞれ別の識別子で管理されています。この2つが結びついていない限り、LINE公式アカウントからは「誰に送っているのか分からない」まま一斉配信するしかなく、車検やクルマの状況に応じた提案は成立しません。必要だったのは、複数のシステムのあいだで「同じ顧客を同じ顧客として識別できる」状態をつくることでした。同時に、すべての連携を最初から自動化しようとすると、設計も運用も重くなります。自動化すべき箇所と、運用として残す箇所をどこで線引きするかも、この案件で決めるべき論点でした。

ツールの導入からではなく、「誰がどの顧客か」を認識して販促に使うまでの流れから設計する。

eapが最初に手をつけたのは、ツールの設定ではなく、「顧客がLINE公式アカウントをフォローしてから、販促情報が届くまで」に情報がどう流れ、誰が何を行うのかの整理です。ここを決めてからでなければ、システムは「顧客情報を保管する場所」以上のものになりません。

そのうえで、eapが行ったことは3つの段階に整理できます。顧客をどう認識し、何に使うかを業務から定義すること。既存プロダクトを組み合わせ、必要な連携だけを設計すること。そして、現場が販促に使い続けられるよう、運用と定着を支援することです。

業務設計から基盤の構築、現場定着まで、一気通貫で担当した。

eapが担ったのは「ツールを設定すること」ではなく、顧客識別のルールづくりから基盤の設計・開発、現場が使い続けられる状態づくりまでです。開発・支援内容の要点は次のとおりです。

ローンチで終わらせず、勉強会と業務ヒアリングを重ねながら配信につなげる。

システムを作って終わりにせず、ローンチ後も勉強会と業務ヒアリングを繰り返しながら、実際の配信につなげていく進め方をとりました。

集める、統合する、抽出する、届ける。4つの流れをひとつの基盤にした。

システムの全体像：集める → 統合する → 抽出する → 届ける。

実際の設計資料をもとに、公開用に再編集した概念図です。データ項目・連携の仕様・画面は含みません。

本プロジェクトで構築した仕組みは、4つの流れで成り立っています。LINE公式アカウントなどの接点で顧客の情報を集め、既存のお客様・車両の情報と同じ顧客のもとに統合する。そのうえで、保有する情報をもとに対象となる顧客を抽出し、LINE公式アカウントから販促情報を届ける。この流れを、現場の担当者が自分たちで回せる形に整えました。

図が表しているのはシステム構成ではなく、業務としての流れです。どの処理を自動化し、どの処理を運用として残すかは、この流れの中で現場の負荷と精度を見ながら切り分けています。

顧客データが「管理されている」状態から、「販促に使える」状態へ。

本プロジェクトの成果は、顧客データの「状態」が変わったことにあります。分散していた顧客情報がひとつの基盤にまとまり、LINE上のユーザーが既存の顧客・車両情報と結びつき、対象を絞った販促を実施できる基盤が整いました。あわせて、構築範囲の見極めによって開発コストを抑えたことも、本プロジェクトの重要な成果です。

• LINE上のユーザーと既存のお客様を「同じ顧客」として扱えるルールを先に定義し、その状態をつくるための業務と基盤を設計した。
• 顧客・車両・LINE上の接点情報を一元的に扱える顧客データ基盤と、顧客データを確認・抽出できるデータ分析環境を構築した。
• 自動化すべき処理と、手順を定めて運用として残す処理を切り分け、現場で回る構成にした。すべての連携を自動化したものではない。
• ローンチ後は社内向け勉強会と業務ヒアリングを繰り返し、現場の担当者が自分たちで対象顧客を抽出し、配信につなげられる状態まで支援した。

この基盤は、CRM施策を継続的に高度化していくための土台です。取得する顧客情報を増やし、抽出の条件や配信の内容を磨いていくことで、蓄積した顧客データを事業の成果へ変えていく前提で設計しています。

CRMの価値は、システムではなく「同じ顧客を同じ顧客として扱える」ことで決まる。

顧客識別 ─ 「CRMを入れる」ではなく、「誰がどの顧客か分かる状態」を先に設計する

CRMの相談を受けたとき、eapがまず確認するのは製品の機能ではなく、「顧客をどう識別し、どの接点の情報をどこに寄せるのか」です。ここが決まっていないままシステムを導入すると、データは蓄積されても、販促に使う段階で「このユーザーは誰か」が分からず止まってしまいます。

今回は、LINE上のユーザーと既存のお客様を同じ顧客として識別できる仕組みを設計の中心に置きました。識別ができて初めて、保有する情報をもとに対象顧客を抽出し、LINEから届けることができます。システムの構成よりも、この「識別の設計」が本プロジェクトでいちばん重要な判断でした。

構築範囲の見極め ─ 既存プロダクトを活かし、必要な連携だけをつくる

CRMの開発は、やろうと思えばいくらでも作り込めます。ただ、作り込むほど設計も検証も重くなり、ローンチが遠のき、現場が使いこなす負荷も増えます。今回は、既存プロダクトが持つ機能はそのまま活かし、顧客識別に必要な連携と、顧客データを確認・抽出できる分析環境に構築範囲を絞りました。

同じ考え方で、頻度が高く手作業ではミスが起きやすい処理は自動化し、それ以外は手順を定めた運用として残しています。最初からすべてを自動化しようとせず、まず「同じ顧客を識別できる」中核をつくって動かし始め、運用しながら自動化の範囲を広げていける構成にしました。

現場定着 ─ 納品ではなく、現場が販促に使い続けられる状態をゴールにする

基盤ができても、現場が使えなければ販促は動きません。ローンチ後は、操作方法の勉強会と業務ヒアリングを繰り返し、実際の業務に合わせて運用と設定を調整しながら、現場の担当者が自分たちで対象顧客を抽出し、配信につなげられる状態まで伴走しました。

競争力は、ツールをつなぐこと自体にはありません。顧客を同じ顧客として扱い、現場がその情報を販促に使い続けられる業務設計にあります。eapが担当したのは、その業務設計から基盤の構築、定着までの一連です。

つながった基盤の上で、取得する顧客情報と配信の精度を高めていく。

LINE上の顧客と既存の顧客・車両情報がつながったことで、ここからは「どの顧客に、どのタイミングで、何を届けるか」を磨いていく段階に入ります。取得する顧客情報を増やし、抽出の条件と配信の内容を運用の中で改善しながら、運用として残している処理についても、現場の負荷を見ながら自動化の範囲を広げていくことが次の論点です。

eapのCRM・システム開発支援は、ツールの導入だけで終わりません。顧客をどう識別し、何に使うかを業務から定義し、既存プロダクトを組み合わせて必要な範囲に絞って構築し、現場が販促に使い続けられる状態まで定着させるところまでを担当範囲としています。CRMの導入や顧客データ活用の基盤づくりをご検討の際は、お気軽にご相談ください。