JP2004520644A

JP2004520644A - イベントプロセスハンドリングに関する改良

Info

Publication number: JP2004520644A
Application number: JP2002547060A
Authority: JP
Inventors: バーカー，グレアム; ピルキングトン，ロバート，マーク
Original assignee: エボン−ダックス・リミテッド
Priority date: 2000-11-30
Filing date: 2001-11-30
Publication date: 2004-07-08
Also published as: WO2002044963A3; WO2002044963A9; CA2428605A1; EP1340183A2; AU2002220860A1; WO2002044963A2; GB0029226D0; US20050102185A1

Abstract

複雑なマルチイベント及びマルチユーザーのプロセスの進行を管理及びモニターするためのオンライン多重チャンネルワークフロープロセッシングシステム(10)が記載される。本システムは、標準的なインターネットプロトコル上で作動し、インターネット(16)を介してアクセス可能な(10)を含み、第1のユーザーによりリクエストされたイベントを捕捉するためのデータ捕捉エンジンを含み、該データ捕捉エンジンは各イベントについてイベントレコード(160)をつくり保存するよう構成される。システム(10)は、少なくともいくつかのイベントを自動的に実施する手段(44)、及び完結するのに手動の相互作用を必要とし未だ完結されていない各イベントのイベントレコード(160)をリスティングする手段(32)を含む。システム(10)はまた、第2のユーザーがイベントを完結に向けて手動で進行させた際イベントレコード(160)を更新する手段を含む。
【選択図】図１

Description

【技術分野】
【０００１】
本発明は、イベントプロセスハンドリングに関する改良に関し、より詳しくは、これらに限定されないが、車両等の多次元アイテムの複雑な購入プロセスの一部等の、複雑なマルチイベントプロセスの進行を管理しモニターするための、オンライン多重チャンネルワークフロープロセッシングシステムに関する。本発明はまた、この種のシステムのための、改良された検索エンジンに関する。
【背景技術】
【０００２】
込み入った購入のプロセス、例えば個人による新しいまたは中古の車の購入の管理は、関与する多くの要因及び変数、及び最初の問い合わせから注文及び新しい車の配達を経る取引処理完結に至るまでの長い時間的尺度のため、複雑なタスクとなる。そのようなプロセスは、各々のベンダーについて(購入者として)複数の個人が関与する場合、管理がさらに難しくなる。
【０００３】
過去においてこれらのタイプのプロセスは不連続的に、新しい在庫を見るため何回かショールームを訪問し、おそらくはパンフレットを請求し、下取りのための彼らの既存の車両を評価し、次いで試乗を手配するため電話する顧客により行なわれてきた。典型的には、彼らはまた最新の価格帯と諸費用を求めるであろう。これらの情報の全ては、顧客が持ちかえり彼ら自身の時間において検討するための、印刷されたフォーマットにおいて提供される。これらの文献全ての供給のコストは顕著である。またかなり頻繁に、ショールームがこれらの文献の在庫を切らしたり、また文献が直ぐに古くなってしまったりし、ディーラー及び顧客の双方に困難をもたらす。
【０００４】
顧客が購入に至るまでの様々な訪問において彼らを記憶する販売員の能力は優れたものである。しかしながらこれは、顧客が訪問しようと思った時間に異なる販売員が働いていることがありうるため、しばしば顧客にとって全く不適切となる。このため、顧客の目的、好きなもの及び嫌いなものに新しい販売員がついていけるようになるまで、多くの会話を繰返すという結果になる。販売員の立場からすると、顧客の欲しいもの、過去に考慮されたも及び嫌いだったものを思いだそうとするさらなる負担がある。このことは、顧客がまだ意を決しておらず様々な異なる選択肢を考慮することを求めている場合、顧客がショールームに何度も足を運び、ディーラーにより提供される最新の車のデータベースをサーチすることになるので、特にあてはまることである。
【０００５】
また、この複雑な購入プロセスを管理しようとすることにおける困難もある。イニシアチブの有効性を評価し、ハードセールス以外の何かにおいて会社のパフォーマンスを見ることはマネージャーにとり非常に困難である。顧客の好みがどのように形成されまた変化しているかを分析する定量的な方法は、現在のところ、何もない。既存のどのような分析であっても、照合及び分析するのに数ヶ月もかかり、それまでに市場の状況は大幅に変化しうる。さらに、顧客の振るまい及び態度の微妙な点についての販売店の群の分析は、そのような購入プロセスの複雑さの性質のため、ほとんど不可能である。
【０００６】
従来技術に関連する上記の問題を、克服するか少なくとも実質的に減少させることが求められる。
【発明の開示】
【課題を解決するための手段】
【０００７】
本発明の１つの特徴によれば、複雑なマルチイベントプロセスの進行を管理しモニターするオンラインマルチチャンネルワークフロープロセッシングシステムであって：第1のユーザーによりオンラインでリクエストされたイベントを捕捉する手段であって、各イベントについてイベントレコードをつくり保存するよう構成された手段；少なくともいくつかのイベントを自動的に実施する手段；完結するのに手動の相互作用を必要とし且つ未だ完結されていない各イベントのイベントレコードをリスティングする手段；及び第２のユーザーが手動でイベントを完結にむけて進行させた時に、イベントレコードを更新する手段を含むシステムが提供される。
【０００８】
このようにイベントを捕捉し進行させることにより、有用な情報のログが形成され、それにより詳細な定性的分析を実行することが可能となる。このシステムのオンラインの性質は、ユーザーにとってそれが自宅でもショールームでもアクセス可能であることを意味する。
【０００９】
これは、販売員の負担をいくつか取り除き、且つ購入プロセスの調査的な部分が、ユーザーにより彼の自宅コンピュータから実施しうることを意味する。
【００１０】
期間の複雑なマルチイベントプロセスは、完結するのに数ヶ月かかりうるプロセスであって、典型的にはいくつかの区別しうる段階を有し、追跡する価値が十分あり、状態の問題の価値があるプロセスを意味することが意図される。
【００１１】
好ましくは、実施手段及び更新手段は、イベントの完結に際し、イベントレコードをリアルタイムで更新するよう構成される。これは、進行中の販売促進及び売上の、リアルタイムで正確な展望を得られることを有利に意味する。
【００１２】
システムのこの部門は、好ましくは２つの区別しうる機構となり、容易なプロセスの細分化(システムのプロセッシング単位において実行される)、フロントエンドリクエストディスプレイ(システムの個人ページを介して実施される)及びアウトプット(これもまたシステムの個人ページを介して実施される)を可能とする。それはまた、ビジネスが、各ビジネスイベントについての正確なタイミング及び応答を測定できるようにするリポートのための、共通の構造を与える。
【００１３】
イベントのリアルタイムコントロールは、好ましくは、アプリケーション全体にリンクする分かれたフレームワークユニットである顧客関係コントローラ(Customer Relations Controller, )により実行される。その目的は、適用可能なイベントの要約を、企業内のどこに位置するビジネスユーザーにもルーティングすることである。それはさらに、彼らの許可及び適用可能な位置に応じて、イベントアクセス及び進行コード(BFUの)への彼らのアクセス許可をコントロールする。適切な権利があれば、CRCは続いて、ユーザーに選択後のイベントを続けさせる。したがってそれは、タイムスタンプをつけられたログ及びイベントルーターの両方として働き、それにより本発明に、その独特なマルチロケーションリアルタイム能力を与える。CRCは本質的に、マルチユーザー企業のためのモニタリング能力を提供する。
【００１４】
本システムは、第1のユーザー及び第2のユーザーが異なるイベントにアクセスし更新する許可を決定するためのブローカー論理モジュールをさらに含むことができる。これはそこで、システム上の多くの異なるタイプのユーザーのそれぞれが、イベントのアクセス及び進行において、彼らが何をできるかについて制御されるようにすることを、有利に実現する。動的CRC及びブローカー論理モジュールの組み合わせは、新たな相関関係(イベント)をシステムに追加することを簡単にし、それによりCRCフレームワークのワークフロー及び企業のルーティング能力が即座に継承される。CRCフレームワーク全体は高度に動的であり、これらの方法に書かれた将来の適用における異なるイベントを制御するのに用いることができる。
【００１５】
本システムは好ましくは、各ユーザー及び各タイプのイベントに関連する保存された許可のデータベースをさらに含み、ブローカー論理モジュールは、データベースにアクセスし許可を決定するよう構成される。これは、許可の更新及び維持が比較的容易となる点において好ましい。
【００１６】
本発明はまた、複雑なマルチイベントプロセスの進行を管理及びモニターするための、オンラインの多重チャンネルワークフロープロセスを実施する方法であって：第1のユーザーによりオンラインでリクエストされたイベントを捕捉する工程であって、各イベントについてのイベントレコードをつくり保存することを含む捕捉工程；少なくともいくつかの前記イベントを自動的に実施する工程；完結するのに手動の相互作用を必要とし且つ未だ完結されていない各イベントのイベントレコードをリスティングする工程；及び第2のユーザーが前記イベントを完結に向けて進行させた際に前記イベントレコードを更新する工程を含むシステムに及ぶ。
【００１７】
自動車販売の分野において適用されている本発明の一つの例示的な態様は、以下において、統合ショールームシステムと称され、現在用いられる「古典的システム」に対して、多くの利点を有する。本発明は、全ての顧客の詳細を容易に得て記入することができ、改善されたデータベース管理を有し、有用な自動車情報の実質的な範囲へのアクセスを提供する能力を有するシステムを提供する。また、その重要な属性の一つは、要求の「リアルタイム」のモニタリングを提供することである。システムが販売店の日ごとのタスクを管理するツールとして働くようなリポート設備もまた利用可能である。
【００１８】
本発明を具現化する新しいショールームシステムは、自動車小売の近代的なアプローチを提供する。顧客がリクエストしたイベントの捕捉から、それらが起こるかぎりにおいて、車を探したときに顧客がとったプロセスを追跡しうるようになる。新しいショールームシステムは、発生した全てのイベントを記録する独特のデータベースを含む。
【００１９】
統合ショールームは、完全なリアルタイムの自動車小売のソリューションである。システムは、例えば取締役が、販売促進及び売上がその時点でどれだけ進行しているかの真のスナップショットを見て、実際の「イベント」を掘り下げ、実際に動きはじめたユーザーが実際に何をしているのかを正確に見ることを可能とする。CRCと個人ページの独特の組み合わせは、もともと顧客又はビジネスユーザーにより用いられていたスクリーン及び相関関係への掘り下げを実際に可能とする。
【００２０】
統合ショールームは、「クリックとモルタル」の自動車ショールーム設備である。これは、顧客が彼らの自動車購入プロセスを、新しい技術-オンライン(クリック)-を用いて始めるか、又は販売店に足を運ぶ伝統的な方法-(モルタル)-により始めるかを選択できることを意味する。このことは、顧客が続いて、全部の購入プロセス-対比的な調査から試乗の手配まで、古い自動車の査定、資金調達、購入、新しい自動車の配送から古い自動車の交換にいたるまで-をインターネット上、ショールーム内、又は両方の組み合わせにおいて続けることができることを意味する。
【００２１】
統合ショールームにより、オンライン及び/又は販売店において顧客により行なわれる全ての活動が記録され、ディーラーは、彼らの顧客がどのようなものを本当に探しているのかを知り、最新のやりとりを持ち、専門的な関係を順向的に築くことができるようになる。
【００２２】
顧客とディーラーが、インターネット上及び販売店内のモニター上において同一のインターフェースを見るので、提示及び提案の整合性が得られ、販売店の公共的なイメージが増強される。
【００２３】
より具体的には、顧客、販売店及び自動車製造者にとって、下記の利益がある：
【００２４】
顧客にとっては、全体的な車の購入のプロセスがより容易になり、より多くの顧客のコントロールを提供し、より大きな顧客満足をもたらす。また、強力に顧客中心的な製品がオンライン上に及びショールーム内で同一であるので、顧客が、最良の取引を提案されていると安心する。
【００２５】
ディーラーにとっては、販売成功の重要な因子である、より良いプロセスの組織化及びマネジメントからの利益がある。また、ディーラーは、彼らが最初にコンタクトを取った時点から、彼らの顧客の好みについて以前より多くを知ることになり、より良い顧客サービスにつながる。組織化された現実の顧客情報は、アフターセールス及び再セールスをより容易且つ個別化したものとする。
【００２６】
本システムはまた、例示的なサービス提案を促し容易にする。これは、オンラインのみの会社、並行輸入及びブロックエクセンプションの終焉に対する強力な防御となる。上記のように顧客が訪問することを選択する場所であればどこででもでも、同一のイメージ及び取引構造が提供され、顧客の販売店における信任が増加し、販売店のイメージを向上させる。
【００２７】
製造者にとっては、顧客が本当に求めているもの、購入に影響を与えるもの、及び顧客を購入に至らせるものについての記録された情報は、現在の供給及び将来の車の製造のための、価値の高い生成データである。また、販売店のイメージの向上は製造者のイメージにもよい影響を与える。強力に顧客指向性の製品を通じた販売店の売上の向上は、直接的に製造者によい影響を与える。
【００２８】
本発明の他の特徴によれば、多次元に特定された(specified)物品のサーチを実行するよう構成されたサーチエンジンであって：前記物品の所望の特徴についての多次元データ仕様(specification)を含むサーチリクエストをつくるサーチリクエスト定義手段；応答の特徴が、前記リクエストの所望の特徴に適合する度合いの順に応答をランキングするランキング手段；及びランキングされた応答を前記ユーザーに、選択のために提示するディスプレイ手段であって、リクエストされた物品の特徴の各々についての個々の特徴適合結果を、前記ユーザーが、より低くランクされた応答がより選択に適するかどうかを決定できるように示すよう構成されるディスプレイ手段を含むサーチエンジンが提供される。
【００２９】
この実施態様によるサーチエンジンは、どのようにランキングが達成されるかをユーザーに知らせる利点を有する。ディスプレイされた特徴の適合は、サーチ結果の対比に際して、ユーザーがより深い分析を実行することを可能とする。ユーザーの好みは変化しうるものであり、予期されない多次元データの組み合わせが起こりうる。個々の特徴の適合がディスプレイされるので、それは本発明を用いれば考慮されることができる。車の購入のシナリオにおけるこの一つの例は、ユーザーが、特定のエンジンサイズを有する特定のメーカー及びモデルの車を探している場合である。サーチ結果は、特定された車両に最も近い適合を見出し、それは結果の最上にランクされる。しかしながら、共通の特徴を有する他のメーカー及びモデルの車両もまたディスプレイされ、特徴の適合を示すことができる。このようにして、ユーザーは、要求されたものと同様の仕様を有すると気付かなかった他の車両に気付くことができる。
【００３０】
好ましくは、サーチリクエストイベントから生成された各々のサーチ結果は、車両のイメージと共にディスプレイされる。これは、テキストベースの結果のみの場合と比べて、異なる色及びモデルの車両がより速い速度で明白となるので、サーチ結果のより速い解釈を助ける。
【発明を実施するための最良の形態】
【００３１】
本発明の好ましい実施態様を、添付する図面を参照し、実施例により記載する。
【００３２】
本発明の一つの実施態様による複雑なプロセスの管理及びモニターシステム10が図１に示される。この実施態様のシステムは、車の購入の複雑なプロセスを管理するのに用いられる。システム10は、顧客により、彼らの家庭のコンピューター12又は販売店ショールームのコンピューター14から、広域ネットワーク、この実施態様ではインターネット16を介してアクセスされうる。また、販売店ショールームのコンピューター14で販売員も、システム10にアクセスすることができ、複雑なプロセスにおいて顧客がどのように進捗しているか、及び顧客により生成されたイベントリクエストに応答して実行することが必要とされる手動のタスクがあるかどうかを見ることができ、これは販売のプロセスを有利に助けることができる。
【００３３】
システム10は、システムウェブサイトをホスティングするためのウェブサーバー18を含み、ここで、複雑な購入プロセスに関する情報が、保存され、顧客により家庭のコンピューター12から又は顧客又は販売員により販売店コンピューター14からアクセス及び更新されることができる。システムウェブサイトは、関連するデータのプロセッシングを実行する統合ショールームエンジン20により制御され、複雑な購入プロセスのモニタリング、及びプロセス全体の一部を構成する、顧客により生成されたアクションのリクエスト(「イベント」として知られる)の進行を可能とする。全てのイベントが自動的に完結されうるわけではなく、そのため、試乗の予約等の手動の相互作用を必要とするいくつかのイベントのため、販売員はシステムにより、イベントを手動で完結し、そしてその完結をシステムに登録するよう促される。さらに、統合ショールームエンジン20は、顧客の振るまいについての情報を集め、レポートを生成する。これは、販売店がそれらの顧客に対するサービスを向上させるのを補助する道具として働く。また、システムにインターネット16を介して接続された本部コンピューター15は、その様々な異なるショールーム14の活動を見ることができ、システム10に保存されたパフォーマンスデータにアクセスすることにより、それらのパフォーマンスを評価することができる。これらの機能を実行するために、エンジン20は、販売店及び顧客についての一組のデータベース22へのアクセスを有する。
【００３４】
続いて図２を参照すると、統合ショールームエンジン20は、顧客に面する入力セクションを構成するモジュール及び顧客のリクエスト(イベント)を満たすセクションを構成するモジュールに分けられる。これらのイベントは、後に詳細に記載する、XMLメッセージ内の共通データ構造(tCustomerEvents)のデータベース22内に保存される。
【００３５】
より具体的には、統合ショールームエンジン20は、顧客により特定されたサーチイベント(例えば車両サーチ)またはディーラーショールーム14において販売員により特定されたイベント(例えば顧客のサーチ)を実施するためのサーチエンジン30を含む。サーチエンジン30は、関連する供給可能な車両を見出すのに必要とされる多次元データサーチを実行するよう構成される。要求される車両のタイプを特定するための様々なフィールドがある。例えば、製造者、モデル、モデルのタイプ、価格、ボディの様式、予算、変速機、燃料のタイプ、加速、ドアの数、等である。これらのいずれをも、サーチを狭め所望の車両に至るために特定することができる。サーチエンジン30は、ユーザーにより特定されたサーチリクエストを受けとり、データベース22に保存された車両データのサーチを実行する。結果は、サーチ仕様の多次元因子が車両の仕様に対応する度合いに基いてランキングされる。ランキングされた結果は、図６について後に詳細に記載される態様でユーザーにディスプレイされる。
【００３６】
図示されていないが、サーチエンジン30はまた、統合ショールームシステム上に、人物選択設備を含み、これで販売員は、顧客をその苗字又は郵便番号でサーチすることができる。人物選択設備はまた、販売員に、新しい顧客をシステム上で編集し、顧客の既存のリストをサーチする機会を与える。この設備は、複数の場所において企業全体にわたって設けられ、各々の場所で顧客データベースの透明性を与える。
【００３７】
統合ショールームエンジン20はまた、顧客関係コントローラ(CRC)32を含む。CRC32は、システムの一部であり、ここで販売員は、顧客がシステムウェブサイトを閲覧しながら何をしてきたのか、並びに彼らがその販売員の販売店でどのようなコンタクトをとってきたのかを正確に見ることができる。販売員は、特定の顧客がどの車両をセーブしたか、及びどのような要件、例えば試乗又はパンフレット等、を彼らが特にリクエストしたか、を見ることができる。
【００３８】
CRC32は、システム10により生成され取扱われた全てのイベントを照合し保存する。イベントは車の保存からパンフレットの請求までのいずれかのものである。この用語はまた、現在の、例えば完結される必要のある未処理のイベントを記述するのに用いられる。実際の、販売員とのインターフェースは、図７を参照して後に詳細に記載される。
【００３９】
システム10を使用したい顧客12及び販売店14における販売員を登録するため、登録及び管理モジュール34もまた設けられる。顧客及び販売員は彼ら自身についての特定の個人データ、例えば住所を記入し、それはシステム10により、ユーザーのプロフィールをつくりユーザーのサーチを補助するのに用いられる。モジュール34はまた、この個人データを、それが必要に応じて更新できるよう管理できるようにする。
【００４０】
個人ページモジュール36は、システムのウェブサイト上に登録された各々の顧客について、彼ら自身の個別化されたウェブサイト部分をつくり、これは、彼らの「個人ページ」と呼ばれる。顧客が関心を持った車両及び彼らが行なったイベント(例えば試乗、評価された下取り)を、各々の顧客に対し別々に保存することができる。本実施態様において顧客はインターネットアクセスを有しているので、彼らは、彼ら自身の「個人ページ」に、家庭から及び販売店からアクセスすることができる。個人ページの構成は、図５を参照して後で詳細に説明される。
【００４１】
統合システムエンジン20はまた、システムの活動のレポートを生成するためのレポートモジュール38を含む。レポートモジュール38は、包括的なレポーティング複合体(suite)であり、オンラインシステムアラートと共に働き、重要な管理情報をレポートのフォーマットで送達し、例えば取締役が、どれくらい多くの販売促進及び販売が現時点でなされているかの真のスナップショットを見ることができるようにする。顧客が複雑な購入プロセスとどのように相互作用するかの様々な観点からのレポートを生成することもでき、小売業者および車両製造者にとって非常に有用である。
【００４２】
異なる顧客12及び販売員14による、システム10内の異なるイベントへのアクセスを制御するため、ブローカー論理モジュール40が設けられる。これは、データベース22内に保存された一連の許可に係るユーザーにより実行され、これは更新されることができ、例えば権原者による変更を反映しうる。ブローカー論理モジュールは、生成された顧客リクエスト及びそれらのリクエストの実行との間のインターフェースとして位置し、権原のないイベントプロセッシングを妨げる。ブローカーモジュールの実行のされかたは、後に詳細に記載される。
【００４３】
統合ショールームエンジン20はまた、システム10内で生成された各イベント、及び完結に向けてのイベントの各々の進行の時間スタンプ付けのために特に設けられた時間及び日付のスタンプ付けモジュール42を含む。このモジュール42は、他の多くのモジュールの正確な機能のために非常に重要である。例えば、生成される全てのレポートがパフォーマンスの指標として時間情報を含むことを必要とするわけではない場合、レポート生成モジュール38にとって最も重要である。
【００４４】
最後に、一組の顧客ビジネス相関関係ユニット(CBFUs)44が、顧客により特定されたイベントを実施するため設けられる。生成されうる各タイプのリクエスト(イベント)のためのCBFU44の一タイプがあり、各CBFU44は、システムの活動を制御しイベントを完結させる。
【００４５】
次に図３を参照して、データベース22内に保存されたデータ構造(アレイ)のいくつかを説明する。データベース22は、顧客により生成された全てのイベントを保存するためのtCustomerEventsデータ構造(表)50を含む。tCustomerEventsデータ構造50内に保存されたイベントは、2つのカテゴリに分けられる。即ち手動の相互作用なしにイベントが自動的に完結されうるカテゴリー1、及びこれらのイベントのそれぞれが完結するのにいくつかの手動のアクションをとることを必要とするカテゴリー2である。
【００４６】
2つのさらなるデータ構造、即ちtCEventsHandledbyUsersデータ構造52及びtLocationsHandledbyUserデータ構造54が、ユーザー詳細表(図示せず)と共に設けられる。tCEventsHandledbyUsersデータ構造52は、各ユーザーについての、異なるタイプのイベントを扱う許可を保存する。同様に、tLocationHandledbyUsersデータ構造54は、異なる販売員の、及び他のビジネスユーザーの働く位置を保存し、それにより、ある販売員が、いくつかの手動の相互作用を必要とするイベントと手動で相互作用することの適切さを決定しうる。例えば、ある販売員が、１つの位置において10のイベントに配置されることができ、フォローアップセンターのオペレーターが、20の位置において3つのイベントに配置されることができる。管理者は、全てのサイトについての両方の人物のイベントをモニターすることができる。CRC内のロッキング機構が、複数ユーザーが同時に一つのイベントを進行することを妨げる。ユーザーは、イベント(ビジネス相関関係ユニットBFU上でまたはBFUにより操作されている)を、他のユーザーがそれを継続するために解放しなければならない。許可の提供においてこれらのデータ構造50、52、54の3つ全ての相互作用のし方は、ブローカー論理モジュール40を参照して、後に詳細に説明する。
【００４７】
統合ショールームシステム10と相互作用する方法60を、図4を参照して説明する。方法の開始に先立ち、顧客及び販売員はシステム10に登録しておき、各顧客について個人ページがつくられる。方法60は、工程62において、ユーザー同定及び認証で開始する。この同定は、ユーザーの性質を決定する。彼/彼女は登録された会社の従業員(販売員)又は顧客か？早い段階でのこの決定は、システムがどのようにイベントをつくるか等を支配する。
【００４８】
相互作用プロセス60における次の段階は、サーチ及び位置決めのプロセス64である。これは、顧客及び販売員によって異なる。顧客は、このプロセス64を、個々のディーラー及び新車及び中古車をサーチし位置決めするのに用いることができる。販売員は、このプロセス64を、ユーザーがショールームを訪問しこのシステムを用いることを望んだ際用いる。この場合、システムは、販売員により、既にシステムに登録された顧客をサーチし位置決めし、さらに顧客のために、個々のディーラー及び新車及び中古車をサーチし位置決めするのに用いられる。
【００４９】
サーチの結果は、個人ページプロセス66による将来の使用のために、ユーザーの個人ページ上に保存することができる。個人ページは、CBFUの状態を例証(instantiating)し扱うための中心的な貯蔵所であり、典型的には、相互作用プロセス60における次の段階は、顧客の個人ページから開始されたさらなるイベントを含む。
【００５０】
プロセス66において顧客の個人ページから生成されたイベントは、CRC32との相互作用プロセス68をもたらし、これはビジネス上の従業員に、手動の相互作用を必要とするイベント及び顧客のリクエストを知らせるワークフローへのユーザーインターフェースとして働く。またこのプロセス68において、活動及びイベントの履歴が生成し保存される。
【００５１】
プロセス60全体の最後のプロセッシング段階69は、CBFUを要求し完結するユーザーインターフェースを有するビジネス相関関係ユニット(BFU)において起こる。ビジネスユニットの個々のイベントのそれぞれは、ユニットの状態の管理及び変更を受け持つ、個々のユーザーインターフェースを有する。この最後の段階は、個人ページプロセス66から又はCRC相互作用プロセス68から直接アクセスされうる。同様に、このプロセス69及び相互作用プロセス68の結果は、現在及び将来の使用のため、顧客の個人ページに保存される。
【００５２】
図５を参照して、サーチイベントに応答して生成された典型的な結果ページ70が、詳細に示される。ページ70は、その一側部に、サーチ基準スクリーン、例えば新車、中古車、等へのハイパーリンク72を含む。新しいCRCへのハイパーリンク74も設けられる。ページ70の上部に、ユーザーにより定義されたニュース及び特別提供情報をディスプレイするチケットテープ76がある。最も重要なことに、ページ70は、サーチ基準に最も適合した車両を示す、最も適切なものから順に並んだ、ランキングされた順のサーチの結果78をリスティングする。各サーチリクエスト結果78は、利用可能な場合は車両の写真80、メーカー・モデル記述子82、サーチリクエスト結果78のこの特徴が対応する特定されたサーチリクエスト基準に適合するかどうかを示すチェック又は×を含む、一連の適合した個別の特徴のインジケーター84、及び価格インジケーター86を含む。サーチ結果ページ70はまた、販売員のレコード操作機能へのハイパーリンクとして働く、現在のログインされた販売員名88をディスプレイする。同様に、顧客名90もディスプレイされ、顧客の個人ページへのハイパーリンクとして働く。
【００５３】
図６は、典型的な顧客の個人ページ100を示す。個人ページ100は、登録上に保存されているかもしれないさらなる顧客の詳細へのハイパーリンク102を含む。メーカー・モデル情報及び車両の写真を含む、この顧客にとって好ましい車両のリスト104もある。システムウェブサイトを訪れる間に、顧客がこれまでに保存した車両を通覧することが可能である。顧客又は販売員が「好ましい車」メインメニューの下の、顧客がこれまでにセーブした車両をクリックした場合、図６に示される通り、その価格付け及びオプション108が提示される。
【００５４】
顧客が個人ページ100から生成しうるイベントの候補のリスト106もまた提供される。この場合、イベントの候補は：新車についての価格付け及びオプション、試乗の予約、私の下取り評価、財務計算機、パンフレット請求、注文フォーム及び連絡、並びに中古車についてのパンフレットの請求を除く同一のイベントである。
【００５５】
ページはまた、財務及び保険ツールへのハイパーリンク110、顧客ページに詳細-典型的には、追加された新しい情報-をセーブするオプション112、及びコストをセーブ及び編集するオプション114を含む。
【００５６】
図７を参照して、CRCスクリーン120を示す。前に述べたとおり、CRC32はイベントを照合し保存する。イベントは、車の保存からパンフレットの請求までのいずれかのものとして記述することができる。この用語はまた、現在の、例えば完結される必要がある未処理のイベントを記述するのに用いられる。
【００５７】
CRCスクリーン120は、いくつかのセクションに分けられ、それは以下に詳細に説明される。
【００５８】
CRCスクリーン120の頂部には、統合ショールームシステムに現在ログオンされている販売員の名前(「ユーザー(User)」として記述される)がスクリーン中央に位置している。右側には、「位置(Location)」と記述されるテキストリンクもある。「位置」テキストリンクが選択されると、スクリーン上に、どの販売店問い合わせにユーザーがアクセスしたことがあるかを示すボックスが現れる。
【００５９】
スクリーン右手側上「イベント更新(Update Events)」テキストリンクは、ユーザーが、CRC32を、最後の更新後に起こったいずれのイベントについても更新できるようにする。例えば、ユーザーがCRC32で1時間作業した後に「イベント更新」テキストリンクが選択された場合、CRC32は、前回ユーザーが最後に「イベント更新」テキストリンクを用いた時以来発生したいずれのイベントをも自動的に更新する。
【００６０】
図７は、CRCのデフォルトのスクリーン120を実際に示すものであり、これはユーザーがCRC32をスタートさせる度に現れる。ユーザーがCRCに記入した場合、彼らは、未処理で販売店(販売員)が完結することが必要ないずれのイベントをも自動的に見る。
【００６１】
デフォルトのスクリーンは、多くのセクションに分けられる。ページの中央にある第1のセクションは「顧客イベント」セクションであり、下記の欄に分けられる。
・メッセージ(流出、流入及び内部)
・顧客
・ユーザー
・位置
・入力日付/時間
・イベント名
・経過時間
・ユーザー完結
・編集及び日誌ボタン
【００６２】
3パートのメッセージ欄がある。これらは：
・顧客へのメッセージ(流出)
・顧客からのメッセージ(流入)
・内部メッセージ
【００６３】
メッセージカラムの下の異なる色のチェックは、顧客及び販売店の間のメッセージを示す。メッセージのタイプに応じて、チェックは赤、緑及び黒の色である。
・赤いチェック＝現在のショールームユーザーからのメッセージ
・黒いチェック＝顧客からの未読メッセージ
・緑のチェック＝確認された顧客からのメッセージ
【００６４】
「顧客欄(Customer Column)」は、リストの上端に、最も最近の照会のあった顧客の名字をリストする。「ユーザー(User)」欄はイベントを動かした最後の人物、即ちその特定の顧客に対し、どの販売員が最後のタスクを実行したかをリストする。ユーザーが「ウェブユーザー(Web User)」としてリストされる場合、顧客はウェブベースの顧客である。
【００６５】
「位置(Location)」欄は、ユーザーが情報をリクエストした販売店、即ち彼らにとって最も近いか若しくは最も便利な販売店をリストする。「入力日付/時間(Date/Time in)」欄は、イベントがリクエストされた時間をログする。「イベント名(Event Name)」欄は、どのイベント、例えば試乗、を顧客がリクエストしたかを示す。「経過(Elapsed)」欄は、顧客が彼らの照会をしてから経過した時間量を記録する。「ユーザー完結(User Complete)欄は、イベントが完結されたか否かを「yes」又は「no」の表示によりカラム内に示す。「編集(Edit)」ボタンは、顧客の記録カードに行けるようにする。「編集」ボタンがクリックされると、不正確な又は更新を必要とする顧客の詳細を編集できるようになる。「日誌(Journal)」ボタンは、顧客記録カードの「日誌」ページ(登録時に設定される-図示せず)を見ることができるようにする。
【００６６】
デフォルトのスクリーンは、多くのセクションに分かれている。スクリーン120の頂部左手側に見られる2つのイベントボタン122、即ち全イベント(All Events)ボタン122及び未処理イベント(Outstanding Events)ボタン122がある。
【００６７】
レポートへのリンク126と同様販売員スケジューラー124へのリンクも設けられる。時間、位置及び人物フィルタ128は、その結果を、スクリーン120のメイン顧客イベントウィンドウ130内に提供する。以前のイベント(previous events)のセクション132が、対応するビジネス相関関係ユニットへのリンク134と共に設けられる。
【００６８】
ユーザーがCRCスクリーン120に入ると、彼らは、全イベントボタン122を選択して顧客と販売員の販売店との間において起こっている全てのイベントにアクセスするオプションを持つ。
【００６９】
ユーザーがCRCスクリーン120に入ると、「未処理イベント」ボタン122が自動的に活動化される。「未処理イベント」ボタン122は、販売店により完結されていないいずれのイベントをも強調する。したがって、ユーザー完結欄の「No」が見られることになる。
【００７０】
ユーザーが顧客サーチを狭めたい場合、又は日付範囲又はイベントのタイプ等の特定の何かを探したい場合、CRCスクリーン120上の多くのフィルタリングオプション128を用いることができる。これらは利用可能な3つのフィルター機能でありこれらは必要に応じて同時に用いることができる。
【００７１】
フィルター1は、下記のオプションをサーチできるようにするドロップダウンボックスを含む：
・顧客名
・郵便番号
・ユーザー名
・位置
・経過時間
【００７２】
例えば、「経過時間」が選択された場合、ユーザーは時間を記入し「進む(Go!)：」を押し、その時間より古いイベントだけを返すことができる。例えば、ユーザーが、設けられたテキストボックスに2時間と記入し「進む」ボタンをクリックした場合、２時間以上未処理の全てのイベントを示すページが表示される。
【００７３】
フィルター2は、日付範囲による、より完全なサーチを行なうことを可能とする。ユーザーが、ユーザーがサーチしたい日付範囲を記入して「進む」ボタンをクリックすると、記入した日付範囲内の全ての「未処理イベント」が現れる。
【００７４】
フィルター1及び2を組み合わせて、より高度なサーチを実行することができる。例えば、テキストボックスに顧客名、例えば名字Polsonを記入し、続いて日付範囲をフィルター2に記入した場合、ユーザーは、記入した日付範囲内のその顧客の全ての「未処理イベント」をサーチすることができる。
【００７５】
以前活動化されたフィルターをクリアするための「フィルターのクリア(Clear Filter)」ボタンが設けられる。一旦「フィルターのクリア」ボタンが活動化されると、ユーザーは未処理イベントのスクリーンに戻る。「今日(Today)ボタンは、フィルター2をクリアし今日の日付に戻す。一旦「今日」ボタンが活動化されると、ユーザーは、当日の全ての未処理イベントに戻る。
【００７６】
フィルター3は、スクリーン左側のリスト内のボタン122の使用により、サーチをさらに狭めるために提供される。例えば、「試乗(Test Drive)」ボタンを選択すると、顧客イベントセクション内の試乗のリクエストだけが見られる。これは、フィルター1及び2と組み合わせて又はそれだけで使用することができる。
【００７７】
CRCデフォルトスクリーン120はまた、左手側メニュー内にボタン122を有する。これらは、顧客がウェブを閲覧しているときにリクエストしうるイベントであり、フィルターとして働く。しかしながら、全てのイベントが販売店により完結されるものではない。
【００７８】
顧客が請求しうるイベントは：
・車の保存(Store Car)
・パンフレットの請求(Request Brochure)
・試乗の予約(Arrange Test Drive)
・連絡(Contact Me)
・私の下取りの査定(Value My Part Exchange)
【００７９】
顧客が見ることができるイベントは：
・財務計算機(Finance Calculator)
【００８０】
ディーラーが実行でき販売店において完結されるイベントは：
・車の保存
・試乗の予約
・パンフレットの請求
・私の下取りの査定
・注文フォーム(Order Form)
・連絡
【００８１】
下記のイベントは、顧客が請求したときに自動完結するので、販売員は完結することができない。
・財務計算機
【００８２】
イベントフィルタ122は、下記に記載される。
【００８３】
イベントのタイプをフィルターするフィルター122は、新しいイベントがシステム内に設定された際に動的に利用可能であることが認識される。したがってこれらは変更を受ける。
【００８４】
「全イベント」ボタンが活動化されている場合においてユーザーが「車の保存」ボタンをクリックした場合、販売店から車を保存している全ての顧客がCRCページに示される。
【００８５】
ユーザーが「未処理イベント」モードで「パンフレット請求」ボタンをクリックすると、パンフレットを請求している顧客のリストが示される。
【００８６】
ユーザーが「未処理イベント」モードで「試乗の予約」フィルターをクリックすると、CRCは、その販売店で試乗の請求をしたが試乗の日付の確認を受けていない全ての顧客を示す。
【００８７】
ユーザーが「未処理イベント」モードで「試乗完結」フィルターをクリックすると、試乗の予約を完結したが実際に試乗していない顧客についてのイベントが示される。「全イベント」モードにおいては、完結した試乗も示される。
【００８８】
ユーザーが「全イベント」ボタンが活動化されている際に「私の下取りの査定」ボタンをクリックすると、彼らの車両の評価を請求した全ての顧客をディスプレイするスクリーンが現れる。
【００８９】
ユーザーが「連絡」ボタンをクリックすると、彼らの個人ページを介して販売店へのメッセージを残した顧客リストが示される。
【００９０】
ユーザーが「全イベント」ボタンが活動化されている際に「財務計算機」ボタンをクリックすると、財務計算機を使用した顧客リストがディスプレイされる。
【００９１】
ユーザーが「未処理イベント」モードの際に「注文フォーム」をクリックすると、目下送達されていない車の注文が示される。ユーザーが「全イベント」モードで「注文フォーム」をクリックすると、配達された車両もまた示される。
【００９２】
ある顧客の詳細が最初にシステムに追加されると、「新規顧客」イベントが生成される。このイベントは、その顧客に対して車両が保存されるまで、「未処理」として示される。その顧客に対して車両が保存されると、「新規顧客」イベントは自動的に完結する。
【００９３】
顧客がウェブを介して彼らの個人ページにログインすると、「ログイン」イベントが生成される。このイベントは即座に完結するので、CRC内では、「全イベント」モードである場合にのみ示される。このイベントの目的は、ショールームユーザーに、顧客が彼らの個人ページを見ているがさらなるイベントを何もしていないことを知らせることである。
【００９４】
一旦顧客の個人ページが到達されると、「連絡」テキストリンクが、「できること(Things that you can do)」メニューの元に選択され、販売員は、顧客の「通信」ページに導かれる。ここで販売員は単にメッセージをテキストボックスに記載し「送る(Send)ボタン」を押す。一旦これがなされると、販売員は彼ら自身を自己紹介し、顧客がさらなる情報を求める場合の助けを申し出たことになる。
【００９５】
したがって、「連絡」機能はシステムに登録したどの顧客とも、通信するのにいつでも用いることができる。
【００９６】
未処理の試乗請求を完結するため、まず顧客イベント／以前のイベントからイベントが選択される。CRCページ120の以前のイベントのセクション132中の「試乗」オプション134を選択すると、試乗ページが顧客の個人ページ内に開く。
【００９７】
この特定の時点で、ユーザーはリクエストを「顧客確認」ボタン(図示せず)をクリックすることにより完結するか、「後でスケジュールしなおし(図示せず)」ボタンをクリックすることによりリクエストへの応答を送らせることができる。
【００９８】
一旦販売員が、顧客に送られるメッセージを完成したら、「送る」ボタンが選択され、そのメッセージがスクリーンの頂部のボックス内に現れる。販売員が顧客と交わしたいずれの通信も、そのボックスに現れる。一旦販売員がメッセージを送ってよいと思ったら、「続ける」ボタンを選択し、試乗が予約されたことを確認する新しいスクリーンが現れる。販売員は続いて「続ける」ボタンを選択し、CRCに戻る。
【００９９】
ブローカー論理モジュール40に戻ると、このモジュールは、システム中の2つの異なるタイプのイベントを扱うよう構成される：即ち、関連するCBFU44がないが、データベース記録の目的でtCustomerEventsデータ構造50に書かれる顧客イベント；及び対応するCBFU44があり、且つtCustomerEventsデータ構造50に保存されるが、イベントを完結するため、有効なユーザーによるプロセスの実行を必要とする顧客イベントである。
【０１００】
これら2タイプのイベントは保存され、tCustomerEventsデータ構造50内に保存される2つのイベントカテゴリーとなる：
カテゴリー 1
車の個人ページへの保存(形態を含む)
見積り
カテゴリー 2
試乗請求
パンフレット請求
連絡
購入(Buy Me)
財務
【０１０１】
ブローカー論理モジュール40は単純な実行機能を有する。tCustomerEventsデータ構造50のカテゴリー2の全てのイベント(即ち、試乗日付の確認又は財務的な取引等、人間によるプロセスが必要なもの)について、それは、目下ログインしているユーザーが、イベントを実行する正しい許可を有しているかどうかをチェックする。有している場合、それは対応するCBFU44を呼ぶ。しかしながら、有していない場合、ブローカー論理モジュールは、ユーザーが許可を欠いていることを知らせる即座の応答メッセージをディスプレイする。
【０１０２】
POS(Point of Sales)アプリケーションのシステム機能へ、このアクセスコントロールの度合いを設ける理由を説明する。システム10の2タイプのユーザー：ウェブユーザー12及びショールームユーザー14を考慮する必要がある。ウェブユーザー12は、例えば試乗を請求することはもちろんできても、明らかに、彼ら自身の試乗請求をスケジュールすることができない。また、ウェブユーザー12は、入力リクエストを埋めることはできても、彼らの財務的取引を完結することはできない。しかしながら、同じシステム10はショールームコンピューター14によりアクセスされうるので、これらの限定のいくつかは、ユーザーがあるプロセスの完結を実行できるよう除くことができる。例えば、顧客の前に立つ販売員は、試乗請求を入力することができ、またその権原があるため、試乗の日付と時間を確認することもできる。
【０１０３】
しかしながら、販売員が、顧客との財務的な取引を監督し記入する場合、車の販売店は、彼らに財務的な事項を完結させることを望まない場合がある。そこでシステムは、この機能が、別の財務管理者又は中央事務所によってのみ完結されうることを保証するよう構成することができる。この場合、販売員は、財務的な請求フォームを埋めることができる。しかしながら、システム10は、彼らが財務的なイベントを完結するための適切な許可を有していないと見て、その事実を彼らに知らせる応答メッセージがディスプレイされる。販売員は従って、対応する財務CBFU44へのアクセスを許可されない。
【０１０４】
この時点で顧客関係コントローラー32が用いられる。コントローラー32は、tCustomerEventsデータ構造を、入力リクエストがあったが出力がない、即ち不完全なイベントについて、連続的に分析する。正しい許可のあるユーザーについて、CRC32は、それらが特定のイベントリクエストについて対応するCBFU44を呼び、出力を完結するようにする。これは続いて、顧客の個人ページに反映され顧客にはe-メールで通知される。有効に、本実施例の入力、プロセス及び出力の分断は、システム10が、ユーザーが顧客であっても彼らの担当者であっても、必要に応じてユーザー周辺のプロセスをシフトするようにする。CRCが複数ユーザー、マルチイベント能力を有しているので、他の管理(制御)ユーザーが、彼らの配置されたサイトについてのこれらのイベントの進行を観察し、進行が無い場合は介入する(電話又は設けられた内部メッセージングを介し)ことも可能である。それらは通常、多くのサイトに配置されフィルターを実行させる(例えば、試乗請求が2時間未満で完結されなかった全てのサイト)。
【０１０５】
ブローカー論理モジュール40は、2つの関連するデータ構造、即ちtCEventsHandledbyUserデータ構造52及びtLocationsHandledbyUsersデータ構造54と、ユーザー詳細表(図示せず)と共にリンクされる。ブローカー論理モジュール40上で実行されるメンテナンスアプリケーションは、誰が何を、企業の複数位置のどこからすることができるかを制御する。フロントエンド個人ページ36及びCBFU44は、単に、これらの表52、54により設定された論理に従う。
【０１０６】
tCEventsHandledbyUsersデータ構造52及びtLocationsHandledbyUsersデータ構造54と関連した、ブローカー論理モジュール40の機能のしかたは、単純な実施例によって最良に説明される。
【０１０７】
実施例
Georgeは財務マネージャーであり、User#ID 546を有する
Fredは販売員でありUser#ID 1023を有する
CEvent#id 7は財務リクエストを表す。
CEvent#id 2は試乗リクエストを表す。
George(User#ID 546)は、下記の位置を扱う：
1＝Oxford
2＝Southampton
3＝Brighton
Fred(User#ID 1023)は、1つの支店で働く：
2＝Southampton
【０１０８】
下記の表は、この論理を許容する：
Georgeは、財務イベントCBFU44へのアクセスを有する唯一のユーザーである。Fred(販売員)は入力を埋めることのみができる。対応するCBFU44をクリックすると、彼は、彼がこのプロセスの許可を欠いていることを通知するのみの自動応答で答えられる。
【０１０９】
Fredは、CBFU44を、試乗イベントのために用いることができる。彼はCBFU44へのアクセスを有し、それを進行させることができる。Georgeは、顧客関係コントローラー32を用いることができ、試乗イベントを見ることができる(User#ID 546はCEvent#ID=2についてのエントリーを有する)が、進行可能(CanProgress)フィールドがNoに設定されているので、CBFU44を呼ぶことはできない。そのユーザーについてのCanProgressフィールドがTrueになっていないと、ユーザーはCBFU44を用いることはできないことが認識される。
【０１１０】
この論理のための表エントリーは下記の通りである：
【０１１１】
【表１】

【０１１２】
【表２】

【０１１３】
さらに図８を参照して、ブローカー論理リクエストのフローが示される。カテゴリー2中の各イベント(別々のCBFU44を有する)について、下記の論理が適用される。
【０１１４】
プロセス140は、工程142において、適切なCBFU44の呼出しを始めるボタンをユーザーがクリックすることにより、即ちリクエストを提出することにより開始する。この段階で、ブローカー論理モジュール40は、工程144において、ログオンしたユーザーID及びリクエストされたイベントIDを取得し、そのユーザーID及びイベントID対応するtCEventHandledbyUserデータ構造52中に保存された許可を回収する。回収された許可は、工程146でチェックされ、目下のユーザーがこのタイプのイベントを扱うための適切な許可を持っていない場合、ブローカー論理モジュール40は、工程148において、このユーザーによりこの活動を扱う許可は得られないという、ユーザーに対する即座の応答メッセージをディスプレイするよう、システム10を促す。メッセージは、異なるイベントのための異なるメッセージを含むtBrokerデータ構造(図示せず)を保存する、データベース22に保存されている。正しいメッセージにアクセスするためのフィールドは、イベントIDにより決定される。
【０１１５】
一方、現在のユーザーが、工程146で決定された通りこのイベントを扱う許可を有する場合、工程150において、ユーザーがイベントを完結する許可を有するかどうかを決定するためのさらなるチェックが実行される。これは、このイベント及びユーザーについてのtCEventsHandledbyUserデータ構造52中の進行可能フラグをチェックすることにより行なわれる。フラグがセットされていない場合、ブローカー論理モジュール40は、工程148において、このユーザーによりこの活動を完結する許可が利用不能である旨の即座の応答メッセージをユーザーにディスプレイするようシステム10を促す。そうでなく、フラグがセットされている場合は、プロセス140は工程152における、対応するCBFU44の実行に向かう。
【０１１６】
次に図９〜１２を参照して、個人ページからの(個人ページモジュール36を介した)イベントデータ入力の保存のされかたを説明する。上の記載から、顧客イベントプロセスは入力及び出力から分離されていることが知られる。これが実際に働き顧客関係コントローラー(CRC)32と連関するためには、全てのイベントデータが標準的な様式で書かれている必要がある。これは全て顧客イベントにより取扱われる。要件は、カテゴリー1(バックエンドプロセスなし)及びカテゴリー2(バックエンドプロセスを伴なう)イベントについてよく似ている。それぞれのフロントエンドイベントリクエストは、図９において強調されている、tCustomerEventsデータ構造50内のtCustomerEventsレコード160のフィールドに出力する必要がある。
【０１１７】
入力のリクエストは、データを、図９において強調されるtCustomerEventsレコード160のフィールドに記入する。これは有効に、リクエストしている顧客及び監督するユーザーの詳細を伴なった、時間が記録されたメッセージである(ユーザーIDを有していないインターネットユーザーの場合これはゼロであることに注意)。
【０１１８】
カテゴリー1のイベント(車の保存/見積等)について、システム10は、ユーザーの前でプロセスを実行する。つまりそれはさらなるプロセッシングのリクエストではない。これらの自動化イベントについて、tCustomerEventsレコード160の、特定のフィールドをシステム10により埋める必要がある。これは、バックエンドの顧客関係コントローラ32が、これらのイベントを、成功裡に完結したか未処理であるとして見ることができるようにする。これは、この制御が一般的に全てのイベントにわたって実行され、「イベント未処理」及び「イベント完結」の状態を見るためtCustomerEventsデータ構造50を単に分析するので、重要である。
【０１１９】
個人ページに保存された車及び見積(本実施態様においてはこれらだけがカテゴリー1のイベントである)について、システム10は、図１０において強調されているデータ出力フィールドを、完結に際し(即ち保存コードの最後に)セットする。ここでこのデータは、レコード160からのデータ出力を順当に生成するのに用いられる。
【０１２０】
カテゴリー2イベントに必要なデータ出力は、カテゴリー1のものとは僅かに異なる要件を有する。このタイプのイベントは、出力メッセージがつくられる前に、ユーザーがCBFU44にアクセスし、活動を実行することを必要とする。例えば：
＞CBFU44を用いて試乗イベントを確認し、それにより出力XMLメッセージがつくられる；
＞CBFU44を用いて、財務的取引を形成する。
【０１２１】
図１１において強調されたデータは、CBFU44が成功裡に呼ばれた際に、tCustomerEventsレコード160に追加される必要がある。これは、ブローカーのリクエストのフローが成功しCBFU44が呼ばれた後にのみ適用可能であることに注意。したがって、顧客ID、及び有効なユーザーIDであってそれらのtEventsHandledbyUsers内に関連するCEvent#IDを有し同一のデータ構造においてそれらに対しYesにセットされたCanProgressを有するものがある。また、第1のフィールドはCBFUの開始に際しセットされる必要がある。
【０１２２】
図１１に示されるフィールドは、CBFU44の開始に際してセットされる。続いてユーザーは、CBFUページを用いてプロセスを実行する；単純な例として、これは、試乗リクエストの日付/時間の確認である。多くのCBFU44において、2つの可能性がある：
1)ユーザーはキャンセルし、出力が完結しない
2)ユーザーは作業を完結し出力メッセージがつくられる
【０１２３】
これら2つの状況は、バックエンド制御(CRC32)にイベント状態を知らせるよう取扱われる必要がある。これに関与するコードおよびこのメッセージ自身は、個々のCBFU44に依存する。これら2つの状態における共通のデータ出力は、図12に示すレコード160において開始される。データベース22は、キャンセル又は完結においてイベントがロックされていないことを保証する必要があることに注意。
【０１２４】
したがってこの手順は、(メッセージを伴ない)成功裡に完結したか又はユーザーによってキャンセルされたイベントについてのtCustomerEventレコード160の完結を取扱う。このプロセスは、これまたCBFU44を呼びPOSから遠隔して確認及びプロセスを実行することができるものであるバックエンド顧客関係コントローラとの全一性を保持する。
【０１２５】
これらのイベントは、関連するダイアログを持つこともできる。これは、tCustomerEventsDialogデータベース構造(図示せず)に記入され、同一の固有のイベント番号と関連付けられる。
【０１２６】
本発明の特定の好ましい実施態様を説明したが、かかる実施態様は例示のみのためのものであり、適切な知識及び能力を有する者によりなされるもの等の変更及び修飾が、添付された請求項に記載される本発明の精神及び範囲から逸脱することなしになされることが認識される。例えば、本発明は、車両の購入を管理することに限定されず、詳細な仕様で建築されている新しい家屋又は建築物等の多次元に特定されたいずれの物品をも本発明の主題とすることができる。さらに、本発明は単一ユーザー及び単一販売店に関して説明されたが、複数ユーザー及び位置(販売店、センター、家庭及び全ての外部からの操作)で作動するよう本システムが特に設計されることが認識される。実際、システムが高度に用いられるようになった際、その特性及び利点が最も明らかに認められる。
【図面の簡単な説明】
【０１２７】
【図１】図１は、本発明を具体化するシステムの、概略的なブロックダイアグラムである。
【図２】図２は、図１の統合ショールームエンジンを詳細に示す概略的なブロックダイアグラムである。
【図３】図３は、図１のシステムのデータベース内に保存された表のいくつかを示す概略的なブロックダイアグラムである。
【図４】図４は、図１のシステムの異なるコンポーネント間の相互作用を示すフローダイアグラムである。
【図５】図５は、ユーザーの照会に応答して図２の統合ショールームエンジンのサーチモジュールにより生成されたサーチ結果ページのスクリーンショットである。
【図６】図６は、図２の統合ショールームエンジンの個人ページモジュールにより生成された個人ページスクリーンのスクリーンショットである。
【図７】図７は、図２の統合ショールームエンジンの顧客関係コントローラにより生成された、顧客関係コントローラページのスクリーンショットである。
【図８】図８は、ブローカー論理をリクエストイベントに適用する工程を示すフローダイアグラムである。
【図９】図９は、イベントリクエストが作成された際の、図３のデータベース内に保存されたtCustomerEventsレコードの基本的な組織を示す概略的な表である。
【図１０】図１０は、カテゴリー１(自動)イベントが実行されたときに生成された出力を示す図９のtCustomerEventsレコードの概略的な表である。
【図１１】図１１は、カテゴリー2(非自動)イベントにより要求された顧客ビジネス相関関係ユニットの開始に際してシステムにより生成されたさらなるフィールドセッティングを示す図９のtCustomerEventsレコードの概略的な表である。
【図１２】図１２は、カテゴリー2のイベントの完結又はキャンセルに応じて生成されうる２つのタイプの出力を示す、図１１のtCustomerEventレコードの概略的な表である。

Claims

複雑なマルチイベントプロセスの進行を管理及びモニターするためのオンライン多重チャンネルワークフロープロセッシングシステムであって：
第1のユーザーによりリクエストされたイベントを捕捉する手段であって、各イベントについてイベントレコードをつくり保存するよう構成される捕捉手段；
少なくともいくつかの前記イベントを自動的に実施する手段；
完結するのに手動の相互作用を必要とし且つ未だ完結されていない各イベントのイベントレコードをリスティングする手段；及び
第2のユーザーが前記イベントを完結に向けて手動で進行させた際に前記イベントレコードを更新する手段を含むシステム。
前記捕捉手段が、前記イベントの詳細を前記イベントレコードに入力するためのデータ入力手段を含む請求項１記載のシステム。
前記データ入力手段が、前記第1のユーザーを記述したデータを入力し保存するよう構成される請求項２記載のシステム。
前記実施手段及び更新手段が、実施されたイベントの結果を、対応するイベントレコード内に保存するよう構成される請求項１〜３のいずれか1項記載のシステム。
前記実施手段及び更新手段が、あるイベントの完結に際し、そのイベントレコードをリアルタイムで更新するよう構成される前記請求項のいずれか1項に記載のシステム。
前記リスティング手段が、全てのイベントレコードのリストをディスプレイし、それらが完結されたか否かを示すよう構成される前記請求項のいずれか1項に記載のシステム。
前記リスティング手段が、前記第2のユーザーにより選択された基準にしたがってイベントをフィルタするよう構成される前記請求項のいずれか1項に記載のシステム。
時間及び日付のスタンプ付けモジュールをさらに含み、前記時間及び日付のスタンプ付けモジュールが各イベント及びそのイベントの状態の変更の時間及び日付をスタンプするよう構成される前記請求項のいずれか1項に記載のシステム。
前記リスティング手段が、それぞれのイベントリクエストのつくられた時間及び日付のリストをディスプレイするよう構成される請求項８記載のシステム。
前記リスティング手段が、前記イベントリクエストがつくられてからの経過時間を計算しディスプレイするよう構成される請求項８又は９記載のシステム。
前記リスティング手段が、イベントリクエストを起こしたユーザーの位置をディスプレイするよう構成される前記請求項のいずれか1項に記載のシステム。
前記イベントを、自動化されたカテゴリ及び手動の相互作用カテゴリにカテゴライズする手段をさらに含む前記請求項のいずれか1項に記載のシステム。
前記第1のユーザー及び第2のユーザーが異なるイベントにアクセスし更新する許可を決定するためのブローカー論理モジュールをさらに含む前記請求項のいずれか1項に記載のシステム。
各ユーザー及び各イベントのタイプに関する、保存された許可のデータベースをさらに含み、前記ブローカー論理モジュールが、前記データベースにアクセスして前記許可を決定するよう構成される請求項１３に記載のシステム。
前記システムの個人位置における前記第1のユーザーと前記システムとの相互作用の全てを保存する個人位置管理手段であって、前記保存されたユーザーの相互作用を、後の時点で前記第1のユーザー又は第2のユーザーに提供するよう構成される個人位置管理手段をさらに含む前記請求項のいずれか1項に記載のシステム。
前記個人位置管理手段が、前記ユーザーによりリクエストされたイベントの結果の履歴を保存するよう構成される請求項１５記載のシステム。
前記ユーザーに、そのユーザーが利用可能な、異なるリクエスト可能なイベントのリストを提示する手段をさらに含む前記請求項のいずれか1項に記載のシステム。
前記ユーザーと、広域ネットワークを解して通信するための通信手段をさらに含む前記請求項のいずれか1項記載のシステム。
サーチリクエストイベントを実施するためのサーチエンジンをさらに含む前記請求項のいずれか1項記載のシステム。
複雑なマルチイベントプロセスの進行を管理しモニターするためのオンライン多重チャンネルワークフロープロセスの実施方法であって：
第1のユーザーによりリクエストされたイベントを捕捉する工程であって、各イベントについてのイベントレコードをつくり保存することを含む工程；
少なくともいくつかの前記イベントを自動的に実施する工程；
完結するのに手動の相互作用を必要とし且つ未だ完結されていない各イベントのイベントレコードをリスティングする工程；及び
第2のユーザーが前記イベントを完結に向けて進行させた際に前記イベントレコードを更新する工程
を含むシステム。
多次元に特定された物品のサーチを実行するよう構成されたサーチエンジンであって：
前記物品の所望の特徴についての多次元データ仕様を含むサーチリクエストをつくるサーチリクエスト定義手段；
応答をランキングするランキング手段であって、前記応答の特徴が前記リクエストの所望の特徴に適合する度合いの順にランキングする手段；及び
ランキングされた応答を前記ユーザーに、選択のために提示するディスプレイ手段であって、リクエストされた物品の特徴の各々についての個々の特徴適合結果を、前記ユーザーが、より低くランクされた応答がより選択に適するかどうかを決定できるように示すよう構成されるディスプレイ手段
を含むサーチエンジン。
リクエストをつくり，前記リクエストに対するランキングされた応答を提供するようユーザーとの通信を援助するよう構成される通信手段をさらに含む請求項２１記載のサーチエンジン。
前記ディスプレイ手段が、前記リクエストされた物品の特徴の各々についての個々の特徴適合結果を、ディスプレイされる各特徴に対しての、単純なチェック及びバツの印の使用により示すよう構成される請求項２１又は２２記載のサーチエンジン。
前記ディスプレイ手段が、ランキングされた各応答に関するイメージデータをディスプレイするよう構成される請求項２１〜２３のいずれか1項記載のサーチエンジン。
前記サーチエンジンが請求項２１〜２４のいずれか1項記載のサーチエンジンを含む請求項１８記載のシステム。