JP2007200061A - 顧客情報管理システム、および、顧客情報管理方法 - Google Patents

Abstract

【課題】契約日に受注内容が有効となるサービス、商品を提供するための顧客管理システムにおいて、受注内容を修正する場合であっても、オペレータに労力をかけずにデータベースにおける一貫性を保ちうるようにする。
【解決手段】受注ＤＢの受注レコードの状態を管理し、修正しようとする受注レコードの契約日付より新しい受注レコードを削除せずに、いったん、仮取消にすることで、対象の受注レコードの修正を可能とする。そして、修正後に仮取消にしていた受注レコードを復活させる。
【選択図】 図１

Description

本発明は、顧客情報管理システム、および、顧客情報管理方法に係り、契約日に受注内容が有効となるサービス、商品を提供するための顧客管理システムであって、そのために受注間における矛盾が生じないように相関チェックが必要になる情報処理システムに用いて好適な顧客情報管理システム、および、顧客情報管理方法
に関する。

受注管理システムにおいては、受注データをマスタファイルに登録する構成が一般的である（例えば、以下の特許文献１参照）。この特許文献１では、製品在庫を自動的に引き当てる方法が開示されている。また、顧客情報を管理するために、更新情報である受注レコードを受注ＤＢに作成し顧客情報マスターである原簿ＤＢに更新するシステムがある。更新情報である受注レコードは原簿ＤＢに更新する日付を契約日として指定することが可能であり、契約日が未来の日となっているときには、システムの日付が契約日になった時点で、その受注レコードを反映させ原簿ＤＢを更新することにより、原簿ＤＢを常に最新の状態に保つものである。契約日までの間は、受注レコードは原簿ＤＢへの更新待ち状態である滞留情報として受注ＤＢに格納されている。

更新情報である受注レコードは、オペレータが端末にて顧客情報の変更情報である受注情報を入力することにより、受注ＤＢに格納する。端末では入力項目を受注情報の種類毎にまとめた画面を複数展開しながら更新情報を入力し、受注ＤＢに受注レコードとして作成する。

以下、図７および図８を用いて従来技術に係る顧客情報管理システムにおけるシステム構成と処理の概要について説明する。
図７は、従来技術に係る顧客情報管理システムのシステム構成図である。
図８は、従来技術に係る顧客情報管理システムにおける処理の概要を説明する図である。

従来技術に係る顧客情報管理システムは、図７に示されるようにオペレータが操作する端末１０とサーバコンピュータ２０が接続された構成である。オペレータが操作する端末１０とサーバコンピュータ２０は、インタフェース部３３を介して接続されている。

サーバコンピュータ２０は、オンライン処理部２１とバッチ処理部２２からなり、受注ＤＢ４０と原簿ＤＢ５０の二つのデータベースを管理している。

受注ＤＢ４０は、オペレータが端末１０から入力した更新情報を受注レコードとして格納するデータベースである。原簿ＤＢ５０は、現在の顧客情報のマスターとなるデータベースである。

オンライン処理部２１は、サーバコンピュータのオンライン系機能に関わる部分であり、制御部２３、受注登録部２４、受注チェック部２５、滞留チェック部２６、受注修正部２７、受注削除部２８、進捗更新部２９からなる。

制御部２３は、各処理部を制御する。受注登録部２４は、端末１０から入力した更新情報を受注レコードとして受注ＤＢ４０に登録する。受注チェック部２５は、受注ＤＢ４０の受注レコード間、および、受注レコードと原簿ＤＢ５０の相関関係をチェックする。滞留チェック部２６は、原簿に反映されていない（以下、この状態を「滞留」という）受注レコードの順序性、すなわち、あるレコードよりも契約日付が先のものが存在するか否かをチェックする。

受注修正部２７は、受注ＤＢ４０に滞留している受注レコードを修正する。受注削除部２８は、受注ＤＢ４０に滞留している受注レコードを削除する。

バッチ処理部２２は、制御部２３と原簿更新部３２からなり、バッチ処理によりデータベースを更新する。

図８に示されるように、オペレータが端末１０から注文を投入すると、サーバコンピュータにその注文が送信され、オンライン処理部２１の制御部２３により各処理部が制御されて、受注レコードを受注ＤＢ４０に登録・編集する。

以下では、従来技術の処理について、図８に示される流れでオペレータが入力する例を説明する。

先ず、オペレータにより端末１０から注文としてサービス契約の受注情報を入力する。サーバコンピュータのオンライン処理部２１では制御部２３にて受注登録部２４を呼び出し、受注ＤＢ４０に受注番号Ｊ００１の受注レコードを作成し、作成後の受注レコードの相関関係を受注チェック部２５でチェックする。同様に支払方法変更・商品新設を投入すると、受注ＤＢ４０に受注番号Ｊ００２・Ｊ００３の受注レコードを作成する。作成した受注レコードは契約日付まで滞留情報として受注ＤＢ４０に格納し、契約日付が来るとバッチ処理部の原簿更新部にて原簿ＤＢに反映する。

受注番号Ｊ００２の受注レコードに対して修正をする場合、オペレータは、支払方法変更（修正）を端末１０より投入する。サーバコンピュータ２０のオンライン処理部２１では制御部２３にて受注修正部２７を呼び出し、受注ＤＢ４０の受注番号Ｊ００２の受注レコードを更新する。しかし、この場合滞留チェック部２６により受注番号Ｊ００２の受注レコードより、契約日付が前になっている受注番号Ｊ００３の受注レコードが存在するためチェックエラーとなり、修正することができない。

そこで、受注番号Ｊ００３の受注レコードを、いったん、削除するためオペレータは、注文取消を端末１０より投入する。サーバコンピュータ２０のオンライン処理部２１では制御部２３にて受注削除部２８を呼び出し、受注ＤＢ４０の受注番号Ｊ００３の受注レコードを削除する。その際、受注番号Ｊ００３より新しい（契約日付が前になっている）受注レコードが受注ＤＢ４０に存在するかを滞留チェック部２６によりチェックする。

その後、改めて支払方法変更（修正）を端末１０より投入し受注修正部２７にて受注ＤＢ４０の受注番号Ｊ００２の受注レコードを修正する。そして、修正完了後、再度商品新設を端末１０より投入し、サーバコンピュータ２０のオンライン処理部２１によって、制御部２３から受注登録部２４を呼び出し受注ＤＢ４０に受注番号Ｊ００３の受注レコードを作成する。

このように滞留している受注レコードを修正する場合に、その受注レコードより契約日付が前の滞留しているレコードを削除するのは、修正によって契約日付が先になっている受注レコードに係る契約が履行できなくなる可能性があるからである。

例えば、図８に示される例で、受注番号Ｊ００２の受注レコードの支払い方法を「クレジットカード」から「銀行振込」に変更したとする。そのときに、受注番号Ｊ００３の商品新設の商品支払いが「銀行振込」の支払いを認めていないときには、商品を提供できない。

このように、これまでの顧客情報管理システムではオペレータが端末から顧客情報の更新情報である受注情報を入力して、受注ＤＢの受注レコードを作成し、システムの日付が受注レコードで指定した契約日になってから顧客情報マスターである原簿ＤＢに更新する仕組みを取っていた。契約日までの間に複数の更新情報が原簿ＤＢに更新されずに受注ＤＢに滞留している状態で、古い更新情報を修正する場合それ以降の滞留している更新情報を全て削除してから修正する必要があった。

特開平６−１４９８４８号公報

上記のように、従来の顧客情報管理システムでは更新情報である受注ＤＢの受注レコードを顧客情報マスターである原簿ＤＢに更新する際に受注レコードの順序性を保障し、相互に矛盾がないようにするため、原簿ＤＢへの更新が複数レコード滞留している場合に古い受注レコードを修正する際には、新しい受注レコードをいったん削除してから修正しなければならない。そのため、いったん削除した受注レコードを、受注情報の入力を再度端末からおこなう必要があり、オペレータが２重に作業しなければならないため、作業量が大きくなるという問題点がある。また、再作成するため、受注情報の入力ミスも発生する可能性がある。

本発明は、上記問題点を解決するためになされたもので、その目的は、契約日に受注内容が有効となるサービス、商品を提供するための顧客管理システムにおいて、受注内容を修正する場合であっても、オペレータに労力をかけずにデータベースにおける一貫性を保ちうる顧客情報管理システムを提供することにある。

本発明の顧客情報管理システムでは、受注ＤＢの受注レコードに、契約日付フィールドと進捗状態フィールドとを設ける。

そして、滞留状態の受注レコードをの進捗状態フィールドの値を受付済としておく。受注ＤＢに保持されている受注レコードを修正するときに、修正しようとする受注レコードの契約日付フィールドに格納された契約日より、前記契約日付フィールドに格納された契約日が等しいか後にある受注レコードの前記進捗状態フィールドの値を仮取消とする。

次に、受注ＤＢに保持されている受注レコードの修正が終わったときに、前記進捗状態フィールドの値が仮取消である受注レコードの前記進捗状態フィールドの値を受付済に戻して、再度、進捗状態フィールドの値を仮取消から受付済に変更した受注レコードと修正が終わった受注レコードとの相関関係をチェックするようにする。

このように、受注ＤＢに滞留している更新情報を削除せずに仮取消にすることで、更新情報を再作成する必要がなくなり、オペレータの作業の効率化を図ることができる。また、更新情報を再作成する必要がなくなり、入力ミスを防ぐことができる。顧客情報管理システムでは受注情報の修正が数多く発生するため、更新情報の修正を効率化することで、オペレータの作業効率の向上を期待することができる。

本発明によれば、契約日に受注内容が有効となるサービス、商品を提供するための顧客管理システムにおいて、受注内容を修正する場合であっても、オペレータに労力をかけずにデータベースにおける一貫性を保ちうる顧客情報管理システムを提供することができる。

以下、本発明に係る一実施形態を、図１ないし図６を用いて説明する。

先ず、図１および図２を用いて本発明の一実施形態に係る顧客情報管理システムのシステム構成について説明する。
図１は、本発明の一実施形態に係る顧客情報管理システムのシステム構成図である。
図２は、本発明の一実施形態に係る顧客情報管理システムのサーバコンピュータのハードウェア構成図である。

本実施形態の顧客情報管理システムのシステム構成は、従来技術の欄で説明したシステム構成に、進捗管理部２９が付加された構成である。

進捗更新部２９は、受注レコードの処理の進捗を書き換えるモジュールであり、受注取消部３０と受注復活部３１からなる。受注取消部３０は、受注ＤＢ４０で滞留している受注レコードを、仮取消にする。受注復活部３１は、進捗状態が仮取消の受注レコードを復活して、受付済の状態にする。

本実施形態の顧客情報管理システムの受注レコードの各部における扱いは、以下のようになる。

受注レコードを作成する場合、オペレータが端末１０から受注情報を入力し、インタフェース部３３によりサーバコンピュータ２０のオンライン処理部２１にデータを転送する。そして、転送した受注情報は制御部２３から受注登録部２４により受注ＤＢ４０に受注レコードとして登録する。登録した受注レコードは受注チェック部２５で受注情報の相関関係をチェックする。

登録した受注レコードを修正する場合、オペレータが端末１０から修正情報を入力し、インタフェース部３３によりサーバコンピュータ２０のオンライン処理部２１にデータを転送する。転送された修正情報は、制御部２３から受注修正部２７により、受注ＤＢ４０の受注レコードを修正する。その際に滞留チェック部２６にて滞留情報の有無をチェックする。そして、修正しようとする受注レコードより前の契約日付を持つレコードがあるときには、受注チェック部２５により受注情報の相関関係をチェックする。

受注レコードを取消す場合、オペレータが端末１０から取消ための情報を入力し、インタフェース部３３によりサーバコンピュータ２０でオンライン処理部２１にデータを転送する。転送された取消のための情報は制御部２３から受注削除部２８により受注ＤＢ４０の受注レコードを削除する。その際に滞留チェック部２６にて滞留情報の有無をチェックする。

受注レコードを保留・復活する場合、オペレータが端末１０から保留・復活のために必要な情報を入力し、インタフェース部３３によりサーバコンピュータ２０でオンライン処理部２１にデータを転送する。転送された保留・復活のために必要な情報は、制御部２３から受注取消部３０・受注復活部３１により受注ＤＢ４０の受注レコードの進捗状態を仮取消・受付済に更新する。その際に滞留チェック部２６にて滞留情報の有無をチェックする。

バッチ処理部２２はバッチジョブを制御する制御部２３と、受注ＤＢ４０で滞留している更新情報を契約日になると原簿ＤＢ５０に更新する原簿更新部３２からなる。

受注ＤＢ４０の受注レコードの原簿ＤＢ５０への更新する場合、サーバコンピュータ２０のバッチ処理部２２の制御部２３にて原簿更新部３２により受注ＤＢ４０の契約日から原簿更新可能な受注レコードを抽出し、原簿ＤＢ５０への更新をおこなう。

サーバコンピュータ２０は、図２に示されるようなハードウェア構成を有しており、ＣＰＵ２０１、メモリ２０２、入出力インタフェース２０３、ネットワークインタフェース２０４が、バス２００により接続された形態である。ネットワークインタフェース２０４には、ネットワークを介して端末１０が接続される。また、入出力インタフェース２０３には、ハードディスクドライブ３００などの外部記憶装置やプリンタなどが接続される。

そして、ハードディスクドライブ３００には、ＯＳやデータベース管理プログラムなどの各種プログラムとデータベースのデータが格納されており、実行時には、メモリ２０２にロードされ、ＣＰＵ２０１により実行される。

次に、図３を用いて本発明の一実施形態に係る顧客情報管理システムの操作イメージについて説明する。
図３は、オペレータが情報を入力する端末１０の画面構成の例である。

オペレータは、顧客情報入力画面１１より、顧客名、住所、電話番号などの顧客の情報を入力する。支払方法入力画面１２より、「クレジット」、「銀行振込」、「コンビニ振込」、「電子マネー」などの顧客の料金の支払方法とそれに関連する情報を入力する。商品情報入力画面１３より、商品名や契約期間を入力する。商品情報詳細入力画面１４より、各商品の詳細情報を入力する。請求書送付先情報入力画面１５は、住所、電話番号などの請求書の送付先に関する詳細情報を入力する。利用明細送付先情報入力画面１６より、住所、電話番号などの利用明細書の送付先に関する詳細情報を入力する。オペレータは端末１０からこれらの複数の画面で情報を入力し、画面遷移しながら更新情報を作成していく。

次に、図４を用いて本発明の一実施形態に係る受注ＤＢの受注レコードのフィールド構成について説明する。
図４は、本発明の一実施形態に係る受注ＤＢの受注レコードのフィールド構成を示す図である。

受注レコードは、受注番号４１、契約番号情報４２、請求情報４３、商品情報４４、日付情報４５、進捗情報４６の各フィールドからなる。

受注番号４１は、受注レコードに付けられるシーケンス番号を格納する。契約番号情報４２は、契約番号の番号・契約開始、終了日付を格納する。請求情報４３は、支払いの請求に関する情報を格納する。商品情報４４は、契約している商品・契約開始、終了日付を格納する。日付情報４５は、受注レコードの受付、更新日付を格納する。進捗状態４６は、受注レコードの処理の状態を格納する。

特に、本実施形態では、日付情報４５の契約日付と進捗状態４６が重要な意義を有する。進捗状態４６には、進捗状態を表すステータスとして、受注レコードを受付た状態の受付済、受注レコードの内容を原簿ＤＢに反映した状態の原簿反映済、受注レコードの内容をいったん保留にした状態の仮取消などがある。

次に、図５を用いて本発明の一実施形態に係る顧客情報管理システムの処理の概要について説明する。
図５は、本発明の一実施形態に係る顧客情報管理システムにおける処理の概要を説明する図である。

図５に示されるように、本実施形態では、オペレータが端末１０から注文を投入すると、サーバコンピュータ２０にその注文が送信され、サーバコンピュータ２０のオンライン処理部２１の制御部２３により各機能を制御されて、受注レコードを受注ＤＢ４０に登録・編集する。

本実施形態では、図５に示される流れでオペレータが入力する例を説明する。

先ず、オペレータにより端末１０から注文としてサービス契約の受注情報を入力する。サーバコンピュータ２０のオンライン処理部２１では制御部２３にて受注登録部２４を呼び出し、受注ＤＢ４０に受注番号Ｊ００１の受注レコードを作成し、作成後の更新情報の相関関係を受注チェック部２５でチェックする。同様に支払方法変更・商品新設を投入すると、受注ＤＢ４０に受注番号Ｊ００２・Ｊ００３の更新情報を作成する。その際、受注ＤＢ４０に登録された各更新情報の進捗状態は更新情報を作成した状態の受付済になる。作成した更新情報は契約日付まで滞留情報として受注ＤＢ４０に格納し、契約日付が来るとバッチの原簿更新部３２にて原簿ＤＢに反映する。

受注番号Ｊ００２の受注レコードに対して修正をする場合、オペレータは、支払方法変更（修正）を端末１０より投入する。サーバコンピュータ２０のオンライン処理部２１では制御部２３にて受注修正部２７を呼び出し受注ＤＢ４０の受注番号Ｊ００２の受注レコードを更新する。しかし、この場合に、従来技術においては、滞留チェック部２６により受注番号Ｊ００３の受注レコードがあるためチェックエラーとなり、修正することができなかった。そこで、受注番号Ｊ００３の受注レコードを無効にするために、受注レコードの進捗状態として、注文仮取消を端末１０より投入する。サーバコンピュータ２０のオンライン処理部２１では制御部２３にて受注取消部３０を呼び出し、受注ＤＢ４０の受注番号Ｊ００３の受注レコードの進捗状態を受付済から仮取消に更新する。その後、改めて支払方法変更（修正）を端末１０より投入し受注修正部２７にて受注ＤＢ４０の受注番号Ｊ００２の受注レコードを修正する。修正完了後、注文復活を端末１０より投入し、サーバコンピュータのオンライン処理部２１で制御部２３から受注復活部３１を呼び出し受注ＤＢ４０の受注番号Ｊ００３の受注レコードの進捗状態を仮取消から受付済に更新する。

そして、再度、受注チェック部２５にて修正した受注番号Ｊ００２の受注レコードと受注番号Ｊ００３の受注レコードの相関関係のチェックをおこなう。ここでの相関関係のチェックは、例えば、受注番号Ｊ００２の受注レコードの支払い方法が、受注番号Ｊ００３の受注レコードの商品の支払いに認められているかなどである。

以上のように、仮取消状態にして修正することにより、再度オペレータが端末から同じ受注情報を入力する必要がなくなり、オペレータの作業の効率化が図れる。また、同じ受注情報を再入力する際の投入ミスを防ぐことができる。

次に、図６を用いて受注ＤＢに滞留している受注レコードを修正する際の手順を詳細に説明する。
図６は、受注ＤＢに滞留している受注レコードを修正する際の手順を示すフローチャートである。

先ず、オペレータが修正情報を端末１０から入力する（６０）。端末は、入力された修正情報をサーバコンピュータ２０に送信する（６１）。

サーバコンピュータ２０の滞留チェック部２６では、現在受注ＤＢに滞留している受注レコード（図では、単に「滞留レコード」と表記）から修正対象となる受注レコードの契約日付よりも等しいか後の契約日付となる受注レコード（以下、「新しい契約日付の受注レコード」）があるか否かのチェックをおこなう（６２）。

新しい契約日付の受注レコードがある場合、さらに受注レコードの進捗状態が受付済であるかのチェックをおこなう（６３）。進捗状態が受付済の受注レコードがある場合にはチェックエラーを端末１０に送信し、オペレータに受注レコードの保留するためのコマンドを入力するよう促す（６４）。オペレータが、その受注レコードの進捗状態を仮取消にすることを端末から入力すると（６５）、受注取消部３０にて新しい受注レコードの進捗状態を仮取消に変更する（６６）。

そして、再度、端末から滞留している受注レコードの修正を入力する（６１）。サーバコンピュータ２０の受注チェック部２５では現在受注ＤＢに滞留中の受注レコードから修正対象の受注レコードよりも新しい受注レコードがあるか否かのチェックをおこなう（６２）。新しい契約日付の受注レコードがある場合、さらに受注レコードの進捗状態が受付済であるかのチェックをおこなう（６３）。受注レコードの進捗状態が仮取消に更新されているので、受注修正部２７にて更新しようとする受注レコードの修正がおこなわれる（６７）。

オペレータは、修正後、新しい契約日付の受注レコードの進捗状態が仮取消にされているか否かを判断する（６８）。進捗状態が仮取消の受注レコードがある場合、オペレータが注文復活を端末から入力すると（６９）、受注復活部３１にて新しい契約日付の受注レコードの進捗状態を仮取消から受付済に更新する（７０）。

本発明の一実施形態に係る顧客情報管理システムのシステム構成図である。 本発明の一実施形態に係る顧客情報管理システムのサーバコンピュータのハードウェア構成図である。 オペレータが情報を入力する端末１０の画面構成の例である。 本発明の一実施形態に係る受注ＤＢの受注レコードのフィールド構成を示す図である。 本発明の一実施形態に係る顧客情報管理システムにおける処理の概要を説明する図である。 受注ＤＢに滞留している受注レコードを修正する際の手順を示すフローチャートである。 従来技術に係る顧客情報管理システムのシステム構成図である。 従来技術に係る顧客情報管理システムにおける処理の概要を説明する図である。

符号の説明

１０…端末
１１…顧客情報入力画面
１２…支払方法入力画面
１３…商品情報入力画面
１４…商品情報詳細入力画面
１５…請求書送付先情報入力画面
１６…利用明細送付先情報入力画面
２０…サーバコンピュータ
２１…オンライン処理部
２２…バッチ処理部
２３…制御部
２４…受注登録部
２５…受注チェック部
２６…滞留チェック部
２７…受注修正部
２８…受注削除部
２９…進捗変更部
３０…受注取消部
３１…受注復活部
４０…受注ＤＢ
４１…受注番号
４２…契約番号情報
４３…請求情報
４４…商品情報
４５…日付情報
４６…進捗状態
５０…原簿ＤＢ

Claims (3)

1. 記憶装置に顧客情報の更新情報である受注ＤＢと顧客情報のマスターである原簿ＤＢとを保持し、コンピュータにより前記受注ＤＢの受注レコードの内容を前記原簿ＤＢに反映する顧客情報管理システムにおいて、
   前記受注ＤＢの受注レコードは、契約日付フィールドと進捗状態フィールドとを有し、
   前記受注レコードを受付けたときに、前記進捗状態フィールドの値を受付済とする手段と、
   前記受注レコードを受付けたときに、それまでに保持されていた受注レコードとの相関関係をチェックする手段と、
   前記受注レコードの前記契約日付フィールドに格納された契約日になったときに、その受注レコードを前記原簿ＤＢに反映する手段と、
   前記受注ＤＢに保持されている受注レコードを修正するときに、修正しようとする受注レコードの契約日付フィールドに格納された契約日より、前記契約日付フィールドに格納された契約日が等しいか後にある受注レコードの前記進捗状態フィールドの値を仮取消とする手段と、
   前記受注ＤＢに保持されている受注レコードの修正が終わったときに、前記進捗状態フィールドの値が仮取消である受注レコードの前記進捗状態フィールドの値を受付済とする手段と、
   前記進捗状態フィールドの値を仮取消から受付済に変更した受注レコードと修正が終わった受注レコードとの相関関係をチェックする手段とを有することを特徴とする顧客情報管理システム。
2. 前記受注レコードの前記進捗状態フィールドの値を仮取消とするかを端末を介して問い合わせる手段とを有することを特徴とする請求項１記載の顧客情報管理システム。
3. 記憶装置に顧客情報の更新情報である受注ＤＢと顧客情報のマスターである原簿ＤＢとを保持し、コンピュータにより前記受注ＤＢの受注レコードの内容を前記原簿ＤＢに反映する顧客情報管理方法において、
   前記受注ＤＢの受注レコードは、契約日付フィールドと進捗状態フィールドとを有し、
   前記受注レコードを受付けたときに、前記進捗状態フィールドの値を受付済とするステップと、
   前記受注レコードを受付けたときに、それまでに保持されていた受注レコードとの相関関係をチェックするステップと、
   前記受注レコードの前記契約日付フィールドに格納された契約日になったときに、その受注レコードを前記原簿ＤＢに反映するステップと、
   前記受注ＤＢに保持されている受注レコードを修正するときに、修正しようとする受注レコードの契約日付フィールドに格納された契約日より、前記契約日付フィールドに格納された契約日が等しいか後にある受注レコードの前記進捗状態フィールドの値を仮取消とするステップと、
   前記受注ＤＢに保持されている受注レコードの修正が終わったときに、前記進捗状態フィールドの値が仮取消である受注レコードの前記進捗状態フィールドの値を受付済とするステップと、
   前記進捗状態フィールドの値を仮取消から受付済に変更した受注レコードと修正が終わった受注レコードとの相関関係をチェックするステップとを有することを特徴とする顧客情報管理方法。
   

Images