JP2002329033A

JP2002329033A - 顧客のニーズを分析するコンピュータ・システム

Info

Publication number: JP2002329033A
Application number: JP2001129792A
Authority: JP
Inventors: Takashi Takakura; 敬司高倉; Tatsutada Kameoka; 達忠亀岡; Masato Honjo; 真砂人本庄
Original assignee: Honda Motor Co Ltd
Current assignee: Honda Motor Co Ltd
Priority date: 2001-04-26
Filing date: 2001-04-26
Publication date: 2002-11-15
Also published as: US20020194055A1

Abstract

(57)【要約】【課題】顧客のニーズ特性を把握するに必要な基本属
性データが不足していても、信頼度を著しく下げること
なくシステムを運営することができる営業支援システム
を提供する。【解決手段】顧客に関する情報を分析するコンピュー
タ・システムであって、顧客を理解するための基本因子
のデータを蓄積する顧客データベースと、基本因子に基
づいて顧客のニーズ特性を分析する顧客理解エンジンと
を備え、顧客データベースは、基本因子のデータがない
とき該基本因子に代えて使用する補間因子を記憶してお
り、顧客理解エンジンは、ニーズ特性を演算する際、演
算に必要な基本因子のデータがないときは、基本因子に
対応する補間因子を用いてニーズ特性の演算を行うよう
プログラムされている。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、商品購入につい
ての理解因子を含む顧客の属性をデータベースに蓄積
し、その分析に基づいて営業を支援するコンピュータ・
システムに関する。

【０００２】

【従来の技術】特開平5-101108号公報には、個人顧客そ
れぞれの潜在的なニーズに基づいて提案型の営業活動を
行うため、顧客データベースに格納された顧客の属性デ
ータ項目間の相関関係を調べ、この相関関係に基づいて
顧客に対応した商品を選択して顧客への営業活動を行
い、その実績に基づいて属性データを更新することが記
載されている。

【０００３】特開平10-83427号公報には、任意の顧客か
らの問い合わせに際して、その顧客が要求しそうなキャ
ンペーンについての情報を即座に提供できるようにした
営業支援システムが記載されている。このシステムは、
営業項目ごとに、顧客の条件と、その条件を満たす顧客
のうち当該営業項目に関わる顧客の割合に対応したポテ
ンシャル値との関係を示すテーブルを格納したデータベ
ースを備えており、顧客情報からこのテーブルを参照し
て該当する項目を表示ユニットに表示させるものであ
る。

【０００４】サイクルが長い商品については、企業にと
って顧客それぞれの個性を把握し、個性に応じた営業活
動が必要である。インターネットが普及した今日、顧客
はインターネット上で商品情報を収集する傾向が見られ
る。このような顧客の積極的な動きは営業促進の見地か
ら極めて重要であるが、従来の営業支援システムは、こ
のような顧客の積極的な動きを営業支援データに十分取
り込んでいない。

【０００５】

【発明が解決しようとする課題】本願出願人による特許
出願第2000-396577号では、顧客に関する情報を蓄積し
管理する営業支援システムが提案されている。このシス
テムは、商品購入に関して顧客を理解するための因子を
含む顧客の基本属性データを蓄積する顧客データベース
と、企業ホームページをインターネット上に公開するウ
ェブサイトと、前記企業ホームページのログ情報に基づ
いて顧客ごとのウェブ行動履歴を蓄積するウェブ行動履
歴データベースと、前記顧客データベースに含まれるデ
ータに基づいて顧客のニーズ特性を分析し、前記ウェブ
行動履歴から顧客に対する働きかけタイミングを判断す
る顧客理解エンジンと、を備えている。

【０００６】この先願発明の実用性を高めるためには、
顧客のニーズ特性を適正に把握することが重要である。
本願発明は、このような顧客のニーズ特性を把握するに
必要な基本属性データが不足していても、信頼度を著し
く下げることなくシステムを運営することができる営業
支援システムを提供することを目的とする。

【０００７】

【課題を解決するための手段】この発明は、顧客に関す
る情報を分析するコンピュータ・システムであって、顧
客を理解するための基本因子のデータを蓄積する顧客デ
ータベースと、前記基本因子に基づいて顧客のニーズ特
性を分析する顧客理解エンジンとを備え、前記顧客デー
タベースは、前記基本因子のデータがないとき該基本因
子に代えて使用する補間因子を記憶しており、前記顧客
理解エンジンは、前記ニーズ特性を演算する際、演算に
必要な前記基本因子のデータがないときは、該基本因子
に対応する補間因子を用いて前記ニーズ特性の演算を行
うようプログラムされているコンピュータ・システムを
提供する。

【０００８】この発明によると、顧客のニーズ特性を分
析するに必要な基本因子の一つまたは複数が不足してい
る場合でも、不足している基本因子に対応する補間因子
を用いてニーズ特性を演算することができるので、デー
タ不足によってニーズ特性の演算を不可能にしたり、演
算の信頼度を著しく下げることを防止することができ
る。

【０００９】また、この発明の一形態においては、前記
ニーズ特性は、情報ニーズ、サポートニーズ、現物確認
ニーズ、サービスニーズ、および人物依存度のうちの１
つまたは複数を含んでおり、顧客理解エンジンは、前記
補間因子のデータがないときは、データを取得するため
の働きかけを実行するプロセスを起動させるようプログ
ラムされている。

【００１０】さらに、この発明の一つの形態において
は、前記プロセスは、所与の顧客について好感度の高い
接触チャンネルを選択することを含む。

【００１１】この発明は、一面において、顧客に関する
情報を分析するコンピュータ・システムであって、顧客
を理解するための基本因子のデータを蓄積するデータベ
ースと、前記基本因子に基づいて顧客のニーズ特性を分
析する顧客理解エンジンとを備えるシステムを提供す
る。このシステムは、ニーズ特性を演算する際、演算に
必要な基本因子のデータがないときは、関連するデータ
を取得するため顧客への働きかけを実行するプロセスを
起動させるようプログラムされている。

【００１２】この発明の一形態では、働きかけの実行に
よっても関連するデータが得られないときは、基本因子
のデータに代えて補間因子のデータを用いてニーズ特性
を演算する。

【００１３】

【発明の実施の形態】次に図面を参照してこの発明の一
実施形態を説明する。図１は、この発明のシステムの一
実施例の全体的な構成を示すブロック図である。この例
は、自動車の製造販売を行う企業ＡＢＣの営業支援シス
テムを示す。顧客11と企業ＡＢＣとの間の接触手段、す
なわちインターフェイスとしては、企業ＡＢＣのホーム
ページがあるウェブサイト13、Ｅメール15、電話17およ
び企業ＡＢＣの営業スタッフまたはサービススタッフと
顧客との対面19がある。

【００１４】企業ＡＢＣのホームページには、ＩＤおよ
びパスワードを必要とすることなく誰でも閲覧すること
ができるページと、予め企業ＡＢＣにＩＤおよびパスワ
ードを登録しておき、このＩＤおよびパスワードの認証
を経て閲覧することができるページとが設けられてい
る。ＩＤおよびパスワードを登録する際には、ユーザ
は、ホームページ上の入会フォームに氏名、年齢、性
別、家族構成、住居形態、年収、現有車情報、カーライ
フのステージ、車の用途、趣味、運転スタイルなどの項
目を記入して送信する。

【００１５】ウェブサイト13のサーバのＣＧＩプログラ
ムは、送信されてきた入会フォームを点検し、必須記入
項目が記入されていれば登録を認可し、ＩＤおよびパス
ワードをデータベースに格納する。こうして得られる潜
在的な顧客の個人データは、ウェブサイトのデータベー
スから顧客データベース30に転送されて格納される。

【００１６】ＩＤおよびパスワードの認証（ログインと
呼ぶ）を経て閲覧することができるページには、企業Ａ
ＢＣの製品の詳細な案内が階層構造で含まれている。個
々のページをコンテンツと呼び、関連のあるコンテンツ
は一方向または双方向にリンクが張られている。一般的
にはメニュースクリーン上で任意の項目を選択してクリ
ックすると、その項目の最上位のページにゆき、このペ
ージに含まれる複数の項目のうちの一つをクリックする
と、次の階層のページに移る。さらにこのページに含ま
れる任意の項目をクリックすると、さらに次の階層のペ
ージに移ることができる。こうして下位の階層に移るほ
ど詳細な情報にアクセスすることができる。

【００１７】行動履歴サーバー27は、ログインを顧客別
に検出し、それぞれの顧客がアクセスするコンテンツの
記録（ログ）をとる。このログは、Web行動履歴データ
ベース40に格納される。行動履歴には、閲覧した回数、
頻度、アクセス時刻、クリック数、ログアウト時刻を含
むそれぞれのコンテンツの閲覧情報のほかにコンテンツ
遷移情報、Ｅメールトランザクション情報、およびＥメ
ールからの誘導率が含まれる。

【００１８】ホームページのコンテンツは、コンテンツ
マスタ・データベース61に格納されており、コンテンツ
サーバ59によって取り出され、顧客に送信される。後述
するところから明らかになるように、顧客別コンテンツ
生成エンジン57は、顧客理解エンジン20による演算に基
づいて、それぞれの顧客に固有のコンテンツを生成して
顧客に送信することができる。

【００１９】図１に示すシステムは、全体的に分散デー
タベースシステムを構築しており、顧客理解エンジン20
は、行動履歴サーバー27によって管理されるWeb行動履
歴データベース40、顧客サーバ35によって管理される顧
客データベース30、応対履歴サーバ43によって管理され
る応対履歴50、サービス用サーバによって管理されるサ
ービスデータベース60、および車載情報サーバ47によっ
て管理される車載情報データベース70をアクセスするこ
とができ、任意の顧客についてこれらの複数のデータベ
ースから関係するデータを検索して利用することができ
る。

【００２０】顧客データベース30には、それぞれの顧客
に固有の顧客番号、企業ＡＢＣの車を所有する顧客につ
いてはその車の車体番号、この顧客を受け持つ営業拠点
およびサービス拠点のコード、顧客がウェブサイトに登
録する際に入力された顧客に関する基本属性が格納され
ている。

【００２１】コールセンター21、およびサービススタッ
フ、営業スタッフ23から入力部37で入力される顧客との
応対結果に基づいて、応対履歴サーバ43がそれぞれの顧
客についての応対の記録を応対履歴データベース50に格
納する。具体的には、応対スタッフＩＤ、応対日時、応
対目的、応対内容、応対時間、応対結果ステータス、次
回応対予定日時、次回応対目的、日報編集などが格納さ
れる。さらに応対履歴データベース50には、企業ＡＢＣ
から顧客に働きかけた記録も格納されている。具体的に
は、働きかけスタッフＩＤ、働きかけ日時、働きかけ時
間、働きかけ内容、働きかけ結果ステータスなどが格納
されている。

【００２２】応対履歴サーバー43は、サービススタッフ
からのサービスデータの入力に応じて、サービス履歴サ
ービス用サーバー55を介してサービスデータベース60に
サービスデータを格納する。サービスデータには、顧客
ごとにサービススタッフＩＤ、入庫日時、入庫目的ステ
ータス、点検整備情報、代車の有無、引き取りの有無、
作業時間、作業内容、売上げなどが含まれる。

【００２３】車載情報サーバー47は、車載の電子制御ユ
ニット（ＥＣＵ）からのダウンロードデータを車載情報
データベース70に格納する。このデータベースには、顧
客ごとにVinナンバー（車体番号）、日時走行距離、燃
費情報、オイル汚れ情報、速度情報、アクセル情報、ブ
レーキ情報、ロックアップ情報、サイドブレーキ情報、
ウィンカー情報、ガソリンゲージ情報、故障診断情報な
ど運転履歴を表す情報が格納される。

【００２４】顧客理解エンジン20は、後に説明するアル
ゴリズムに従ってそれぞれの顧客のニーズ特性を算出
し、働きかけタイミングを決定し、働きかけメッセージ
を生成する。顧客理解エンジン20による演算結果は、行
動履歴サーバー27を介して顧客別コンテンツ生成エンジ
ン57に送られる。顧客別コンテンツ生成エンジン57は、
これに応答し、コンテンツサーバー59を介してWeb行動
履歴データベースおよびコンテンツマスタデータベース
を参照して、働きかけをすべき顧客のニーズ特性に適合
したコンテンツを生成する。

【００２５】働きかけ対象の顧客に対してはＥメールで
コンテンツの電子ファイルが送信される。この電子ファ
イルは、顧客のパーソナルコンピュータ上で開くとブラ
ウザが起動され、ブラウザ上で閲覧することができる。
他の実施形態では、電子ファイルを対象となる顧客に直
接送信する代わりに、顧客に特化したコンテンツをホー
ムページに用意したので閲覧していただきたい旨のメッ
セージをＥメールで送り、このＥメールに特化コンテン
ツのＵＲＬへのリンクを張る。このＥメールを受信した
顧客は、Ｅメールに記載されているＵＲＬをクリックす
ることによって企業ＡＢＣのホームページに入り、特化
コンテンツを閲覧することができる。

【００２６】また、もう一つの実施形態では、顧客理解
エンジン20の演算結果は、応対／働きかけ画面生成部31
でディスプレイ画面として生成され、営業スタッフ部門
23に送られる。営業スタッフは、端末装置でこの画面を
閲覧し、画面から得られる情報および指示に従って対象
顧客に接触する。

【００２７】図２は、顧客理解エンジン20が実行するプ
ログラムの全体的な流れを示す。図３から図５を参照し
て後に詳細に説明するアルゴリズムにより所与の顧客に
ついてのニーズレベルを算出する（201）。図６から図1
0を参照して後に詳細に説明するアルゴリズムにより所
与の顧客について働きかけのタイミングを検出する（20
3）。こうして検出されたタイミングにより顧客のニー
ズ特性に応じた働きかけを実施し（205）、その結果の
トランザクションを分析し（207）、分析結果に応じて
ニーズレベルの算出アルゴリズムおよび働きかけタイミ
ングの検出アルゴリズムに含まれる変数および係数の補
正およびチューニングを実施し（209）、その結果をア
ルゴリズムに反映させて（211）、プログラムを進化さ
せる。

【００２８】図３は、任意の顧客について複数のニーズ
のそれぞれについてのニーズレベルを表すランク変数を
算出するプロセスを示す。図１を参照して説明したよう
に各種のデータベースに顧客の基本属性、前有車属性、
現有車属性、カーライフ行動などのデータを蓄積する
（301）。これらのデータは、基本因子セットと、複数
の拡張因子セットに分類され、基本因子セットと拡張因
子セットとの組み合わでニーズ特性の識別する。

【００２９】一実施例では、基本因子セットは、対象者
全員について用意され、表１に示す因子を含む。

【００３０】

【表１】基本因子セット契約書から得られる因子・氏名・性別・年齢・現有車関連情報・自動車保険情報・未払い情報成約時アンケートから得られる因子・家族情報・職業関連情報・運転歴情報システム等から得られる因子

【００３１】この実施例では、拡張因子は、拡張因子セ
ット、拡張因子セット、および拡張因子セットに
分類される。拡張因子セットは、前有車ありの対象者
について用意され、拡張因子セットは、前有車ありの
対象者および前有車はないが車両をサービスのため入庫
させた人について用意され、拡張因子セットは、成約
時のアンケートでこの項目に回答した対象者について用
意される。これらの因子の例を表２に示す。他の実施例
では、拡張因子セットは基本因子セットに含まれる。

【００３２】

【表２】拡張因子セットシステム等および成約時のアンケートから得られる因子・前有車情報拡張因子セット成約時および入庫時のアンケートから得られる因子・車検場所・１２ヶ月点検実施状況・１２ヶ月点検
場所・引き取り納車・代車・オイル交換場所・オイル交
換頻度・オイルの銘柄・洗車の頻度・洗車方法拡張因子セット成約時アンケートから得られる因子・自身の年収・世帯年収

【００３３】顧客のニーズ特性として、図３のブロック
303に示すものを設定し、予め定めた基本因子セットと
拡張因子セットの組み合わせモデルに基づいてそれぞれ
のニーズタイプを判別し、順序付けする（305）。図23
は、判別分析のプロセスの流れを示す。これ自体は、統
計分析においてよく知られた手法なので詳細な説明は省
略する。判別は、１本の直線で２つのグループを分離す
る線型判別関数を用いた判別、または２次曲線で２つの
グループを分離するマハラノビスの距離を用いた判別を
使用することができる。

【００３４】図２３の例では、人物依存度の高い人Ａ１
と低い人Ａ２とを判別している。アンケート調査その他
から得られた多数のサンプルに関するデータ231を入力
し(233)、これらのサンプルをＡ１のグループとＡ２の
グループに分ける（235）。統計分析手法を用いてＡ
１、Ａ２のグループの境界を定める判別関数を求める
（237）。この判別関数が求まると、それぞれの判別対
象者のデータ値がこの判別境界（判別曲線）のどちら側
にあるかによって、どのグループに属するか判別する
（239）。単にどちらのグループに属するかの判別にと
どまらず、対象者の変数を判別関数に代入して得られる
判別得点にしたがって、ニーズ特性の順位付けをするこ
とができる。

【００３５】図14は、アンケート調査を分析して得られ
た「営業活動に積極的に反応する（人物依存度ニー
ズ）」というニーズタイプを識別する因子を示す。図15
は、アンケート調査を分析して得られた「試乗すること
が重要（現物確認ニーズ）」というニーズタイプを識別
する因子を示す。また、図16は、アンケート調査を分析
して得られた「商品情報の提供を求める（情報ニー
ズ）」というニーズタイプを識別する因子を示す。これ
らの因子を用いて判別分析手法を用いてニーズタイプを
判別し、それぞれの個人のデータを判別関数に代入した
値、すなわち判別得点に基づいてデータの集合の中での
順位付けを行う（305）。こうしてステップ309において
それぞれの顧客の順位を決定する。このプロセスの詳細
を図５を参照して説明する。

【００３６】いま、ニーズタイプは、図５のＡさんのニ
ーズ順位テーブルに示すように、「情報ニーズ」、「サ
ポートニーズ」、「現物確認ニーズ」、「サービスニー
ズ」、「人物依存度」の５つであるとする。図14に示し
たニーズタイプは、「人物依存度」に該当し、図15に示
したニーズタイプは、「現物確認ニーズ」に該当し、図
16に示したニーズタイプは、「情報ニーズ」に該当す
る。

【００３７】企業ＡＢＣのウェブサイトに登録したＡさ
んについて見ると、Ａさんに関し前述の複数のデータベ
ースに蓄積したデータから上述のそれぞれのニーズに影
響する因子を取り出してＡさんのニーズを判別し、デー
タ集合の中での順位を決定する（309）。

【００３８】図５の上部に示すＡさんのニーズ順位テー
ブルは、このようにして決定された順位を示す。このニ
ーズごとの順位をデータ集合の母数（全顧客数）に対す
るパーセントに変換し、その値にＡさん用の補正係数を
かけてニーズレベルX’を算出する（311）。この補正係
数は、このシステムの運用結果のフィードバックに基づ
いてそれぞれの顧客の個性に応じて設定する係数であ
る。Ａさんの例で見ると、過去のトランザクション結果
を参照すると情報ニーズが購買に及ぼす影響が強いの
で、補正係数が0.8に設定されている。ニーズレベルは
先に述べたようにニーズ順位の百分率なので、その値が
小さいほどニーズレベルが大きい。

【００３９】こうして算出された５つのニーズのそれぞ
れについてのニーズレベルを判定基準値に基づいて１か
ら５までの５段階にランク付けする（313）。ニーズご
との判定基準値の例が、図５のランク付けテーブルに示
されている。ランク１が影響度が最も大きいことを示
し、ランクの値が大きくなるほど、影響度が小さくな
る。こうしてＡさんについて判定されたランク変数が図
５の最下部のテーブルに示される（315）。

【００４０】図６は、企業ＡＢＣから所与の顧客に対し
て働きかけを行うタイミングを判断する処理のフローを
示す。顧客が企業ＡＢＣのホームページにログインを完
了すると（401）、コンテンツ選択のメニュースクリー
ンが顧客のブラウザに表示される。顧客は、車種選択40
5からイベント情報419までの複数のコンテンツから一つ
を選択することができる（403）。メニューページに
は、トップページ421にもどるための項目も含まれてい
る。車種選択405からイベント情報419までの実質的な内
容のあるコンテンツが選択されると、選択されたコンテ
ンツを示すフラグがセットされる(425)。

【００４１】この顧客がこのホームページに初めてログ
インしたのであれば（427）、ブロック429に進み、アク
セス開始時刻をセットし、クリック数をクリアし、購買
ステージステータス定数を取得し、コンテンツ深度係数
を初期化する。初めてのログインでなければ、ブロック
431に進み、閲覧回数、クリック数、日次閲覧数をそれ
ぞれインクリメントさせ、コンテンツ深度係数を取得す
る。

【００４２】次いで図７に示すテーブルを参照してコン
テンツ影響度を算出する。影響度係数マスターテーブル
に格納される値Ｚは、図７の最上部のテーブルに示すよ
うにコンテンツの内容分類ごとに与えられた係数であ
る。たとえば、車種選択は0.5であり、車種レコメンデ
ーションは0.4である。コンテンツ深度係数Ｚ’は、前
述したホームページの階層構造においてどの深度のコン
テンツにアクセスしたかを表す係数で、たとえば車種選
択の分野においては、モデルのページは深度が１で、タ
イプ（グレード）のページは深度が1.5であり、外装色
のページは深度が1.5であり、見積もりのページは深度
が2.5である。顧客ごとの補正係数Bは、このシステムの
運用結果を反映して顧客の個性に応じて影響度係数を補
正する係数である。購買ステージステータス定数Cは、
所与の顧客が車の購入に関してどの段階にあるかを示す
定数である。たとえば、車を購入するための情報を収集
する段階にある顧客の購買ステージステータス定数は、
0.4である。コンテンツ影響度Mは、次式で定義される。

【００４３】

【数１】コンテンツ影響度 M =（Z×Z’） × B ＋ C

【００４４】次いで次式により、所与の顧客Ａによる企
業ＡＢＣの所与のコンテンツがＡさんの車購入行為に与
える影響を数値化した閲覧影響値を算出する(435)。

【００４５】

【数２】閲覧影響値 = （閲覧回数 + 日次回数+ クリッ
ク数）× M

【００４６】こうしてＡさんについて得られた閲覧影響
値を歩進（インクリメント）基準値と比較し（437）、
基準値を超えていればこの顧客の該当するコンテンツ影
響値をインクリメントさせる。たとえば、図７のチャー
トで、Ａさんが車種選択（影響度係数Z=0.5）のメニュ
ーからコンテンツ深度Z’=2.5の見積もりのコンテンツ
まで進んだとする。車種選択コンテンツに関するＡさん
の補正係数Bは、テーブルに示されるように0.8である。
Ａさんの購買ステーシ゛ステータス定数Ｃが、情報収集C=0.5
の段階にあるとすると、Ａさんのコンテンツ影響度M
は、数１に従って1.5 になる。

【００４７】Ａさんの閲覧回数＋日次回数＋クリック数
が18であるとすると、Ａさんの閲覧影響値は、数２に従
って27になる。Ａさんの閲覧影響値が車種選択に対する
歩進基準値25を超えているので、車種選択に関係する
「車種選択」、車種レコメンデーション」、「車種間比
較」、「第三者評論情報」、および「展示試乗車情報」
のコンテンツについてのＡさんのコンテンツ影響値がイ
ンクリメントされる（439）。

【００４８】こうして更新されたＡさんのコンテンツ影
響値が働きかけ判断基準値と比較される（441）。働き
かけ判断基準値の例は、図８の最下部のテーブルに示さ
れている。任意のコンテンツのコンテンツ影響値が対応
するコンテンツの働きかけ判断基準値を超えると、基準
値を超えたコンテンツに応じて企業ＡＢＣから顧客Ａさ
んに対する働きかけを実施するための処理に移る。いま
の例では、Ａさんの「車種選択」コンテンツにおけるコ
ンテンツ影響値が13になり、この項目の働きかけ判断基
準値12を超えている。また、「展示試乗車情報」コンテ
ンツにおけるコンテンツ影響値が16になり、この項目の
働きかけ判断基準値15を超えている。その結果、Ａさん
について図９の働きかけ処理が開始される。

【００４９】図９および図１０を参照して、図６のプロ
セスに続いて企業ＡＢＣから顧客に対する働きかけを実
施するためのプロセスを説明する。まず図10の最上部に
示されるＡさんのコンテンツ影響値を参照する。ここで
は任意の顧客であるＡさんを例に説明するが、同様の処
理がデータベース上のすべての顧客について実行され
る。図10のテーブルに示すようにコンテンツは、働きか
けのトリガーになるものと、働きかけのメッセージを生
成するためのものとに分類される。Ａさんの例では、前
述したように「車種選択」コンテンツのコンテンツ影響
値が働きかけ判断基準値を超えたことによって働きかけ
の処理が開始される。そして、「展示試乗車情報」コン
テンツのコンテンツ影響値が働きかけ基準値を超えてい
るので、展示試乗車情報をＡさんに提供するためのメッ
セージを生成するプロセスに入る。

【００５０】この実施例では、図５を参照して説明した
Ａさんのニーズ識別結果ランク変数を利用して働きかけ
メッセージを組み立てる。「展示試乗車情報」コンテン
ツの影響値に基づいて、働きかけメッセージを組み立て
る際、関連の強いニーズ項目は、「情報ニーズ」、「現
物確認ニーズ」、および「人物依存度」である。図10の
中央のテーブルは「展示試乗車情報」の列に１を表示す
ることによって、このコンテンツと強い関連性をもつニ
ーズ項目を示している。

【００５１】いま、現物確認ニーズに着目すると、Ａさ
んのニーズ識別結果変数は、１である。この実施例で
は、システムはこの場合、メッセージテーブルのa番を
選択するようプログラムされている。このことが図10の
中央から下部にかけて示されている。すなわち、現物確
認ニーズが１または２のときは、メッセージテーブルの
a番を選択し、３または４のときは、b番を選択し、５の
ときはc番を選択する。

【００５２】図９にもどると、こうして働きかけメッセ
ージ番号が決定される（502）。続いて「展示試乗車情
報」コンテンツ以外のコンテンツについて影響値が増加
しているかどうかを判断する（503）。影響値が増加し
ているならば、「車種選択」コンテンツについて、Ａさ
んが選択した車種名をWeb行動履歴データベース40（図
１）から検出し（505）、「車種レコメンデーション」
コンテンツについて、同じくWeb行動履歴データベース4
0から勧められた車種名を検出する（507）。同様に「車
種間比較」コンテンツについて、Web行動履歴データベ
ース40から比較元の車種名を検出し（509）、「第三者
評論情報」コンテンツについて、評論情報の車種名を検
出する（511）。また、Web行動履歴データベース40から
Ａさんが閲覧した展示試乗車情報を検索し、閲覧された
車種名を検出する（513）。

【００５３】こうして検出された車種名に同じものがあ
れば（515）、図10のプロセスで生成された働きかけメ
ッセージにその車種名を挿入する（517）。検出された
車種名に同じものがなければ、働きかけメッセージの車
種名にブランク文字を挿入する（519）。こうして働き
かけメッセージテーブルの文字データと車種名文字を結
合し（523）、働きかけコンテンツが用意される（52
5）。

【００５４】図11を参照すると、こうして完成したコン
テンツが図１に関連して前述したような形態でＡさんに
送信され、または通知される（701）。働きかけは、ウ
ェブサイトおよびＥメールを利用した形のほか、営業ス
タッフによるコンタクト、郵便による案内状の送付など
さまざまな形をとることができる。

【００５５】図９までの処理の流れで働きかけをするこ
とが決定された顧客に対しては、図１の顧客理解エンジ
ン20からの指示に従って顧客別コンテンツ編集エンジン
57が対象となる顧客のコンテンツ影響値に適合した顧客
ごとのコンテンツを編集する。こうして働きかけ対象の
顧客は、それ以後に企業ＡＢＣのホームページにログイ
ンすると、その顧客用に編集されたページを閲覧するこ
とになる。企業ＡＢＣは、そのような特別なページが用
意されたことをＥメールで対象となる顧客に通知して、
閲覧を促すことができる（701）。

【００５６】この発明のシステムに従って顧客への働き
かけがなされると、それに対する顧客の反応を検出し、
それぞれの顧客についてのデータベース上のデータを修
正し、将来的により適切な働きかけができるようにシス
テムを適合させる。

【００５７】行動履歴サーバー27（図１）は、働きかけ
実行後、対象となる顧客によるホームページへのログイ
ンがあるかどうかを検出し（703）、予め定めた期間、
たとえば２週間以内、にログインがないときは、働きか
けの再送信がされていないときは、たとえば１週間後に
顧客に誘導メールを送信するよう設定する（707）。働
きかけ後に対象となる顧客によるホームページへのログ
インがあると、メニューページにそれぞれの顧客用に用
意されたメッセージが表示される。メニューページで
は、特別に編集されたコンテンツのメニュー項目をブリ
ンクさせる、またはそのようなメニュー項目に特別なマ
ークを付けるなどして顧客の注意をひくようにする。

【００５８】これまでに説明してきたＡさんの例では、
図10に示した働きかけメッセージが表示され、図11に示
すメニュー項目、車種選択711からイベント情報725のう
ち、展示・試乗車情報721がＡさん用に特別に編集され
ており、このメニュー項目がブリンクするよう設定され
ている。Ａさんがいずれかのメニュー項目を選択し、ク
リックすると、選択コンテンツ判別フラグがセットされ
る（731）。働きかけ後の１回目のアクセスであれば（7
33）、アクセス開始時刻をセットし、クリック数をクリ
アする（735）。２回目以降のアクセスであれば、閲覧
回数、クリック数、日次閲覧数を１ずつインクリメント
する（737）。

【００５９】Ａさんの例では、ホームページ上で試乗予
約がなされると（739）、まず予約車種をデータベース
に記憶し、Ａさんの購買ステージステータス（データベ
ース上）を「意思形成」ステージに変更し、Ａさんのコ
ンテンツ影響値に対する補正値に0.1を加算し、Ａさん
のコンテンツ影響値を今後の演算のためにクリアする
（741）。試乗予約は、電話、Ｅメールなどの手段によ
ってなされてもよい。この場合、営業スタッフまたはコ
ールセンターがシステムに試乗予約のデータを入力す
る。今回の働きかけで試乗予約がなされなかったとき
は、コンテンツ影響値から１をひく（743）。

【００６０】次いで図12のデータベース更新処理に移
り、対象となるそれぞれの顧客、いまの例ではＡさんの
ウェブ閲覧に関する事実情報をデータベースから取得し
（802）、ログおよび顧客属性の分析結果をデータベー
スから取得し（803）、応対スクリプト情報を取得し（8
05）、営業スタッフの携帯端末の表示データを編集し
（807）、営業スタッフの携帯端末表示用のデータベー
スを更新する（811）。

【００６１】ブロック813は、このようなステップを経
て営業スタッフの携帯端末または営業所の端末装置に表
示される情報を示している。ウェブ閲覧の事実情報とし
ては、試乗予約がなされた車種名、試乗予約の時間、Ａ
さんが比較している車種名、試乗車のカタログは発送済
みであること、用品（アクセサリ）カタログが発送済み
であることなどがある。

【００６２】ログ、顧客属性を分析したニーズ情報とし
ては、Ａさんについて、情報ニーズが高いこと、第三者
の意見を気にすること、サポートに対するニーズは低い
こと、現物確認、試乗ニーズが高いこと、人物依存度
（営業スタッフなどとの接触に関する依存度）が低いこ
となどがある。

【００６３】Ａさんに対する応対のスクリプトとして営
業スタッフの携帯端末に表示される情報としては、訴求
ポイントはエンジン特性、燃費、乗り心地であること、
Ａさんが気にする第三者情報は既納客ユーザの声である
こと、試乗後は商談をすることなどがある。

【００６４】システムから提供されるこれらの情報に基
づいて営業スタッフがＡさんの試乗に応対した後、営業
スタッフは、ブロック830に示すような項目について応
対結果をシステムに入力する（815）。営業スタッフ
は、商談の進捗度として、現物確認、試乗、査定、見積
もり、交渉、与信、成約、納車のどの段階にあるかを入
力する。次いで、営業スタッフは、顧客識別情報として
の「情報ニーズ」、「サポートニーズ」、「現物確認ニ
ーズ」、「サービスニーズ」、「人物依存度」について
システムが示すものを、Ａさんとの応対結果に基づいて
補正する。また、営業スタッフは、Ａさんとの次回の接
触予定日をシステムに入力する。

【００６５】営業スタッフによる入力に基づいて顧客デ
ータベース30に補正変数を記憶する（817）。顧客理解
エンジン20は、Ａさんへの応対後に顧客識別値に変更が
あるかどうか判断し（819）、変更があれば顧客識別因
子影響度を補正し（821）、顧客ごとの影響度係数を補
正する(823)。こうしてシステムは、システムの演算に
よる働きかけの結果に基づいて更新され、より精度の高
い演算を実行することが可能になる。

【００６６】図13は、図12のステップ821および823にお
ける補正を行う具体例を示す。図12のブロック830に示
す営業スタッフからの顧客Ａさんとの応対結果に基づい
て、それぞれのニーズについてＡさん用の補正係数を修
正する。たとえば、情報ニーズについて見ると、Ａさん
の情報ニーズは、顧客理解エンジンの演算結果による
と、ブロック830の白抜きの三角マークで示す位置にあ
るが、Ａさんとの応対結果に基づいて営業スタッフが黒
い三角マークで示す位置に修正した。これに基づいて顧
客理解エンジンは、Ａさんの情報ニーズの影響度を小さ
くするよう、すなわちＡさんの％順位（トップからの順
位で、数値が大きいほど順位は低い）を大きくするよう
修正する。図の例では、情報ニーズの補正係数が0.8か
ら0.9に修正される。同様にサポートニーズ、現物確認
ニーズ、サービスニーズ、および人物依存度についても
図12のブロック830に示される結果に基づいてＡさん用
の補正係数が修正される。修正後の、それぞれのニーズ
の影響度X’は、順位％X ×補正係数αで示される。

【００６７】基本因子の補間および不足因子の自動取得上に述べたように、表１および表２に示した基本因子と
拡張因子との組み合わせを用いて対象者のニーズ特性を
識別するので、特定のニーズタイプの識別に用いる因子
に欠落があると、ニーズタイプ識別の信頼性が低下す
る。この発明の一実施形態では、あるニーズタイプの識
別過程において必要な因子が不足しているときは、その
不足因子を自動的に取得する処理が起動される。また、
もう一つの実施形態では、あるニーズタイプの識別過程
において必要な因子が不足しているときは、その不足因
子に替えて補間因子を使用してニーズタイプ識別の演算
を行う。

【００６８】図17を参照して説明すると、顧客理解エン
ジン20は、たとえばニーズタイプ「人物依存度」の識別
演算を実行するために必要な基本因子および拡張因子を
取得するために顧客データベース30をアクセスする。こ
のときこの演算に必要な因子ｘのデータが顧客データベ
ース20に入っていないならば、顧客データベース20は、
因子ｘが不足していることを顧客理解エンジン20に伝え
る。これに応答して顧客理解エンジン20は、不足因子を
取得するためのチャネルを決定し（85）、不足因子を取
得して(87)、顧客データベース30の該当する因子セット
に補充する。

【００６９】図18は、この不足因子の取得処理および補
間処理の詳細を示すフローチャートである。顧客理解エ
ンジン20は、たとえばニーズタイプ「人物依存度」を識
別するリクエスト（901）に応じて顧客データベース30
をアクセスする（903）。顧客サーバ35（図１）は、こ
のニーズタイプの演算に必要な基本因子および拡張因子
のデータがすべてそろっているかどうか調べ、不足因子
を検出する（907）。不足因子がないときは、必要な因
子のデータを顧客理解エンジン20に渡し、顧客理解エン
ジン20は、ニーズタイプの識別分析を実行する（91
7）。

【００７０】ブロック911でデータが不足している因子
が存在すると判断されると、その因子を補間する因子の
うち識別精度の高いものを検出し（913）、この補間因
子のセット（補間因子が複数の因子からなるときは、こ
れらをセットとして扱う）を分析対象にセットし（91
5）、顧客理解エンジン20に渡す。顧客理解エンジン20
は、渡された基本因子、拡張因子および補間因子を用い
てニーズタイプの識別分析を実行する（917）。

【００７１】図20は、基本因子、拡張因子、基本補間因
子、拡張補間因子の例を示す。この例では、年収は基本
因子となっている。いま、ニーズタイプの識別演算に基
本因子の年収が必要であるにもかかわらず、対象者の年
収データが顧客データベース30にないならば、年収が不
足因子となる。顧客データベース30には、年収を補間す
る基本補間因子として「ゴールドカード」、「購入金
額」、「ブランド志向」からなる基本補間因子セット
１、「オーダースーツ」、「海外旅行回数」、「マイレ
ージ」からなる基本補間因子セットｎ（ｎは任意の数）
が用意されている。

【００７２】図20は、基本因子「年収」および拡張因子
「来店回数」に基づいてニーズタイプ「人物依存度」を
演算すると、全顧客対象では75%の精度、すなわち当て
はまり率で人物依存度を得ることができることを示して
いる。基本補間因子セット１および拡張補間因子セット
１（拡張因子「来店回数」のデータがないときこれを補
間する因子セット）に基づいて「人物依存度」を演算す
ると、全顧客を対象とするとき、68%の精度で結果が得
られる。これを特定のＡさんについて演算すると、たと
えば65%の精度で結果が得られる。

【００７３】図18にもどると、判断ブロック923は、図1
9のブロック963で因子取得失敗フラグがセットされたか
どうかを見るブロックで、フラグがオンになっていれば
ブロック925に進む。ブロック925は、図19のブロック96
5でセットされた失敗後に因子の再取得処理を実行する
までのインターバル時間の値が経過したかどうかを見る
ブロックである。インターバル時間が経過していれば、
ブロック928に進み不足因子の取得を実施する。ブロッ
ク923で因子取得失敗フラグがオンになっていなけれ
ば、ブロック927に進む。ブロック927では、図19のブロ
ック957で設定された対象者への接触インターバルが経
過したかどうかを点検する。接触インターバルが経過し
ていれば、ブロック928に進み、不足因子の取得プロセ
スを開始する。

【００７４】まず、ブロック931で因子データの入手先
テーブルを参照する。このテーブルは、たとえば図22に
示すような構成をしており、因子「年収」についてのデ
ータは、与信データベースまたは購買履歴データベース
から取得することができることが示されている。また、
因子「海外旅行回数」についてのデータは、アンケート
により取得する。

【００７５】こうしてテーブルを参照してデータの取得
先を決めると、ブロック933に進み、対象者について接
触チャネルの選好度（選り好みの度合い）識別データが
データベースに格納されているかどうかが調べられる。
所与の対象者についての接触チャネルの選好度の例が図
21に示される。Ａさんについては、Ｅメールによる接触
が最も好まれているので、Ｅメールを接触チャネルとし
て検出し（935）、働きかけスクリプトを準備する（93
7）。接触チャネルの選好度識別データがないときは、
自動Ｅメール送信に設定される（934）。こうして働き
かけスクリプトが用意されると、働きかけが実施される
（939）。いまの例では、Ｅメールが送信される。

【００７６】図19を参照すると、こうして不足因子に対
するデータが取得されると（951）、データを顧客デー
タベースの中の因子データベースに記憶する（955）。
このデータは、以後のニーズタイプ識別のための演算に
使用される。不足因子が取得されないときは、次に高い
選好度の接触チャネルを選択し（953）、あまりに頻繁
に特定の対象者に接触がなされないように接触インター
バルを、たとえば30日に設定する（957）。予め定めら
れたリトライの上限値を超えていなければ、図18のブロ
ック927にもどり、不足因子の取得処理を実施する（92
8）。リトライの上限値に達していれば、因子取得失敗
フラグをオンにし、再取得実行までのインターバルを、
たとえば３ヶ月に設定する（965）。

【００７７】以上にこの発明を具体的な実施例について
記述したが、この発明は、このような実施例に限定され
るものではない。

【図面の簡単な説明】

【図１】この発明の一実施例のシステムの全体的な構成
を示すブロック図。

【図２】この発明の一実施例における全体的な処理の
流れを示すフローチャート。

【図３】この発明の一実施例における識別結果ランク変
数を決定する処理の流れを示すフローチャート。

【図４】この発明の一実施例における利用識別情報の分
類を示す図。

【図５】この発明の一実施例におけるニーズ識別結果ラ
ンク変数の算出例を示す図。

【図６】この発明の一実施例における働きかけ判断処理
の流れを示すフローチャート。

【図７】この発明の一実施例におけるコンテンツ閲覧影
響度の算出例を示す図。

【図８】この発明の一実施例におけるコンテンツ閲覧影
響値と働きかけ判断基準値の例を示す図。

【図９】この発明の一実施例における働きかけコンテン
ツを生成するプロセスを示すブロック図。

【図１０】この発明の一実施例において働きかけメッ
セージの生成過程を示す図。

【図１１】この発明の一実施例における、働きかけ実施
処理の流れを示す図。

【図１２】この発明の一実施例における、働きかけ結果
に基づくデータベース更新処理の流れを示す図。

【図１３】この発明の一実施例における応対トランザク
ション結果に応じて影響度を補正する係数の算出方法を
示す図。

【図１４】働きかけ型のニーズを持つ人を識別する因子
の一例を示す図。

【図１５】働きかけ型のニーズを持つ人を識別する因
子のもう一つの例を示す図。

【図１６】働きかけ型のニーズを持つ人を識別する因子
の他の例を示す図。

【図１７】不足因子の取得、更新の概念を示すブロック
図。

【図１８】不足因子の補間および自動取得を行うための
プロセスを示すフローチャート。

【図１９】図18に続くフローチャート。

【図２０】因子セットテーブルの例を示す図。

【図２１】接触チャネル選好度の例を示す図。

【図２２】因子の取得先を示すテーブルの例を示す図。

【図２３】判別分析の処理の流れを示すフローチャー
ト。

【符号の説明】

２０顧客理解エンジン３０顧客データベース８１基本因子セット８３拡張因子セット

フロントページの続き (72)発明者本庄真砂人東京都港区南青山２丁目１番１号本田技研工業株式会社内Ｆターム(参考） 5B075 ND20 NS10 PQ20 UU40

Claims

【特許請求の範囲】

【請求項１】顧客に関する情報に基づいて顧客のニーズ
を分析するコンピュータ・システムであって、顧客を理解するための基本因子のデータを蓄積するデー
タベースと、前記基本因子に基づいて顧客のニーズ特性を分析する顧
客理解エンジンとを備え、前記データベースは、前記基本因子のデータがないとき
該基本因子に代えて使用する補間因子のデータを記憶し
ており、前記顧客理解エンジンは、前記ニーズ特性を演
算する際、演算に必要な前記基本因子のデータがないと
きは、該基本因子に対応する補間因子のデータを用いて
前記ニーズ特性の演算を行うようプログラムされている
コンピュータ・システム。
【請求項２】前記ニーズ特性は、情報ニーズ、サポート
ニーズ、現物確認ニーズ、サービスニーズ、および人物
依存度のうちの１つまたは複数を含んでおり、前記顧客
理解エンジンは、前記補間因子のデータがないときは、
データを取得するための働きかけを実行するプロセスを
起動させるようプログラムされている請求項１に記載の
コンピュータ・システム。
【請求項３】前記プロセスは、所与の顧客について選好
度の高い接触チャンネルを選択することを含む請求項２
に記載のコンピュータ・システム。
【請求項４】顧客に関する情報を分析するコンピュータ
・システムであって、顧客を理解するための基本因子のデータを蓄積するデー
タベースと、前記基本因子に基づいて顧客のニーズ特性を分析する顧
客理解エンジンとを備え、前記ニーズ特性を演算する際、演算に必要な前記基本因
子のデータがないときは、関連するデータを取得するた
めに顧客に働きかけを実行するプロセスを起動させるよ
うプログラムされているコンピュータ・システム。
【請求項５】前記働きかけの実行によっても前記関連す
るデータが得られないときは、前記基本因子のデータに
代えて補間因子のデータを用いて前記ニーズ特性を演算
するよう構成された請求項４に記載のコンピュータ・シ
ステム。