JP2002183603A - 顧客サービスシステム - Google Patents

Abstract

(57)【要約】 【課題】 顧客の転居の有無に関わらず顧客が容易に知
り得る公益事業対象顧客の識別子を用いて、サービスに
係るあらゆる情報参照を行ない得る顧客サービスシステ
ムを形成する。 【解決手段】 上記顧客サービスシステムは以下の顧客
データベースファイルを備える。該ファイルには、個々
の顧客に係るデータを識別するために付される第１の識
別子と第２の識別子とが格納され、個々の顧客に対し、
第１の識別子は不変で、第２の識別子は１回又は複数回
変更され得る。第１の識別子は、時系列上１番目の第２
の識別子と関連付けられ、続いて第２の識別子は、時系
列上次の順番の第２の識別子と関連付けられ、それらの
第２の識別子の内にて、時系列上１番目の第２の識別子
は１番目であることを示すデータを備え、且つ、時系列
上最終番目の第２の識別子は最終番目であることを示す
データを備える。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、公益企業における
顧客サービスシステムに関する。

【０００２】

【従来の技術】情報通信技術によって、企業収益を直接
支える営業活動全般の改革を目指す動きが高まりつつあ
る。

【０００３】ＣＴＩ（Ｃｏｍｐｕｔｅｒ Ｔｅｌｅｐｈ
ｏｎｙ Ｉｎｔｅｇｒａｔｉｏｎ；コンピュータ電話統
合）技術を駆使して企業における様々な電話関連業務を
行う設備である「コールセンタ」も、そのような改革の
動きの中で登場してきた。図６は、その「コールセン
タ」の構成例のブロック図である。

【０００４】図６のコールセンタ２には、複数のオペレ
ータ４が配置され、各オペレータ４には、端末用計算機
６と電話機８が配布される。個々の端末用計算機６は、
適切な回線１０を介して顧客サービスシステム１２を含
んでいるホストコンピュータ１４と接続している。端末
用計算機６からの操作により、顧客サービスシステム１
２に含まれる任意の顧客２０に係るデータを参照・更新
し得るように、ホストコンピュータ１４、個々の端末用
計算機６、及び通信回線１０が設定されている。ホスト
コンピュータ１４は、コールセンタ２から遠隔した地点
に設定されていてもよい。

【０００５】更に、コールセンタ２には、電話通信用サ
ーバ１６が備わる。該電話通信用サーバ１６は公衆回線
１８と接続しており、数多くの顧客２０からコールセン
タ２への通信（通話）は、まず、この電話通信用サーバ
１６に入力される。この電話通信用サーバ１６は、ＰＢ
Ｘ（Ｐｒｉｖａｔｅ Ｂｒａｎｃｈ ｅＸｃｈａｎｇ
ｅ；構内交換機）やＡＣＤ（ａｕｔｏｍａｔｉｃ ｃａ
ｌｌ ｄｉｓｔｒｉｂｕｔｉｏｎ；自動着信分配器）な
どの機能を実現するサーバ・ソフトウエアを搭載してお
り、かかってきた電話呼び出しを、受付のオペレータ４
に均等に分配している。

【０００６】上記のコールセンタ２で扱う一般的な業務
としては、受注処理、問い合わせ対応、販売促進対応な
どがある。上記のコールセンタ２は、オペレータ４が直
接対応するほか、夜間などに音声応答システムが電話を
受け付ける無人対応の機能を備えることもある。

【０００７】上記コールセンタ２の機能には、次のよう
な限界が存在する。ＩＶＲ（Ｉｎｔｅｌｌｉｇｅｎｔ
Ｖｏｉｃｅ Ｒｅｓｐｏｎｃｅ；自動音声応答装置）を
利用して上記のように夜間（即ち、営業時間外）に無人
応答を行なっていることもあるとはいえ、そこでの応答
音声は、「営業時間外であるから、営業時間内に再度か
けること」を要請することが大半である。従って、顧客
２０の側からすれば、結局、コールセンタ２の営業時間
内に電話をすることが必要になる。一方、コールセンタ
２の側からみれば、１日のうちでも営業開始直後や昼休
憩直後に電話受信が集中することが多く、更に１年のう
ちでも電話受信数が集中する時期と閑散となる時期とが
存在する。

【０００８】即ち、費用対効果を参酌しつつ、人員や設
備を適切に配置することが非常に困難である。特に、通
話要請があるからといって、夜間に受付体制を敷くこと
により十分な営業上の効果が得られるというものでもな
い。更に、電話受信集中時期を意識して集中時期に人員
・設備を適切に集中させること自体困難であり、仮に可
能であるとしても、そうするとどうしても通常時期にお
いてまで人員・設備の過剰が生じてしまいがちである。

【０００９】情報通信技術による企業収益を直接支える
営業活動全般の改革を目指す動きとして、「ｅＣＲＭ
（ｅｌｅｃｔｒｏｎｉｃａｌ Ｃｕｓｔｏｍｅｒ Ｒｅ
ｌａｔｉｏｎｓｈｉｐ Ｍａｎａｇｅｍｅｎｔ；電子顧
客関係管理）」による取り組みも、挙げられる。このｅ
ＣＲＭは、上記のコールセンタ２の機能に内在する限界
をある程度克復するものである。そのｅＣＲＭの一つの
仕組みとして、図７に示されている、企業の有する顧客
サービスシステム１２と顧客２０保有の計算機２２をイ
ンタネット網２４を介して接続する形態が挙げられる。
図６と比較すると明白なように、ここではコールセンタ
２に係る設備が除かれており、よってオペレータ４も介
在しない。

【００１０】図７の形態において、顧客２０保有の計算
機２２は、インタネット網２４を介し、ファイアウォー
ル（ゲートウェイ）装置２６の監視制御を受けつつ、ホ
ストコンピュータ１４に格納される顧客サービスシステ
ム１２の一部とデータの入出力を行なう。顧客２０の計
算機２２に対し開示するように設定されたデータは、略
常時（即ち、１日当り略２４時間）開示されている。顧
客サービスシステム１２内の開示データの（検索）開示
以外の対処が必要な場合、例えば、各種苦情のように営
業部門担当者による個別具体的対応が必要な用件である
ならば、電子メールによる入力が利用され得る。従っ
て、顧客２０がインタネット網２４に接続する計算機２
２を保有する限り、苦情申し入れ等を含む問い合わせを
常時行なうことが可能になる。加えて、電子メールの一
次担当者は別として、上記のような人員・設備に係る問
題点も、図７の形態においては略解消される。

【００１１】さらに、ｅＣＲＭにおける取り組みにおい
ては、顧客２０の電子メールアドレスを顧客２０に関す
る重要なデータとして収集することが望まれている。こ
のことが実現されると、電子メールによって、顧客２０
から企業に対する上記の問い合わせのようなインバウン
ド情報伝達が実現されるだけではなく、収集された電子
メールアドレスにより企業から顧客２０へのアウトバウ
ンド情報伝達も可能となる。

【００１２】上記のコールセンタ２においても、電話８
を用いてアウトバウンド情報伝達は可能である。しか
し、対象となる顧客数に比例したコストを要するという
大きな問題点が生じる。情報のインバウンド伝達及びア
ウトバウンド伝達において電子メールを利用することに
より、対象の顧客数に影響されずに任意のアウトバウン
ドの情報伝達が可能となる。そのことにより、企業の顧
客管理戦略に新たな広がりが生まれることになる。但し
その前提として、できる限り数多くの顧客２０により、
インタネット網２４に接続される計算機や携帯電話
（等）が保有されることが不可欠になる。

【００１３】さて、上記の顧客サービスシステム１２に
おいて、個々の顧客２０に関するデータを包含する顧客
レコードの各々に対しては、「識別子」（ＩＤ；Ｉｄｅ
ｎｔｉｆｉｅｒ）が割り振られる。即ち、よく知られて
いるように、顧客２０に関するデータを参照したり更新
したりする際には、入力情報内に設定された識別子（Ｉ
Ｄ）と同一のＩＤを備えるレコードが検索されて当該レ
コードの同定が行なわれる。

【００１４】ここで、電力供給、ガス供給、水道などの
所謂公益事業における顧客２０を想定する。上記の公益
事業は、事業エリア内に張り巡らされたネットワークイ
ンフラストラクチャを介して顧客サービスが実施される
という共通の事業特性を備える。よって、伝統的に、顧
客２０が実際にサービスを受ける（地理上の）ロケーシ
ョンに対し番号（又は記号など）が割り振られその番号
（又は記号など）を「識別子」としている。従って、顧
客２０が公益事業者に対して、前に説明したような「問
い合わせ」を行なう際には、このロケーションと密接に
関連する「識別子」が必要とされることが多い。

【００１５】上記のようなサービス供給地点（ロケーシ
ョン）と密接に関連する「識別子」の体系を採用する
と、転居などにより顧客２０がサービスを受ける地点を
変更するとそれに伴い「識別子」も自ずから変更され
る。実際上は同じ人がサービスを受けていても、「識別
子」が変更されてしまうと、顧客サービスシステム１２
は「識別子」変更前後の顧客レコードが同一の顧客２０
に関するものであることを最早把握できなくなってしま
う。

【００１６】図７に示されているｅＣＲＭの一つの形態
を、公益事業者が導入した場合、例えば、ある顧客２０
が当該公益事業者サービスエリア内で転宅したときであ
っても、その顧客２０の転居前の「識別子」に係るデー
タを参照しようとすると勿論その「識別子」は旧い（即
ち、転居前のロケーションの）「識別子」でなければな
らないことになる。転居後において顧客２０が転居前の
「識別子」を把握しているということは想定しにくい。
このことは、図７に示されるｅＣＲＭの一つの形態が導
入されていない状況、例えば、上記のコールセンタ２の
みが実現されている状況においても、同様に生じ得る問
題点である。

【００１７】更に、後述の「発明の実施の形態」で詳し
く説明するが、同一の「識別子」が、別の顧客によって
再利用されるような事態も想定され得る。「識別子」が
サービス供給地点に割り振られているのだから、（例え
ば、賃貸アパートのように）同じ地点（でのサービス）
を異なる顧客が別の時期に利用すると、上記のような事
態が発生する。この場合、上述のように旧い識別子を把
握していても、旧い情報には最早アクセスできない可能
性が生じる。

【００１８】

【発明が解決しようとする課題】本発明は、顧客２０の
転居の有無に関わらず顧客２０が容易に知り得る公益事
業対象顧客の「識別子」を用いて、サービスに係るあら
ゆる情報参照を行ない得る顧客サービスシステム１２を
形成することを目的とする。加えて、複数の互いに離れ
た地点においてサービスを提供されている顧客２０に関
する情報を、容易にアクセスし得る顧客サービスシステ
ム１２を形成することを目的とする。

【００１９】

【課題を解決するための手段】本発明は、上記の目的を
達成するためになされたものである。本発明に係る請求
項１に記載の顧客サービスシステムは、磁気媒体に格納
された顧客データベースファイルを備え、該顧客データ
ベースファイルには、個々の顧客に係るデータを識別す
るために付される第１の識別子と第２の識別子とが格納
され、個々の顧客に対して、第１の識別子は不変であ
り、第２の識別子は時間の経過と共に１回又は複数回変
更されることがあり、第１の識別子は、時系列上１番目
の第２の識別子と関連付けられ、続いて、第２の識別子
は、時系列上次の順番の第２の識別子と関連付けられ、
上記の１つ又は複数の第２の識別子の内において、時系
列上１番目の第２の識別子は時系列上１番目であること
を示すデータを備え、且つ、時系列上最終番目の第２の
識別子は時系列上最終番目であることを示すデータを備
える。

【００２０】本発明に係る請求項２に記載の顧客サービ
スシステムは、磁気媒体に格納された顧客データベース
ファイルを備え、該顧客データベースファイルには、個
々の顧客に係るデータを識別するために付される第１の
識別子と第２の識別子とが格納され、個々の顧客に対し
て、第１の識別子は不変であるが、第２の識別子は時間
の経過と共に１回又は複数回変更されることがあり、更
に、第２の識別子の各々は、他の顧客から再利用される
ことがあり、第２の識別子に対して、個々の顧客が利用
する利用開始時に係るデータと利用終了時に係るデータ
とを備えさせ、第１の識別子は、時系列上１番目の第２
の識別子及びその利用開始時と関連付けられ、続いて、
第２の識別子及びその利用開始時は、時系列上次の順番
の第２の識別子及びその利用開始時と関連付けられ、個
別の顧客と関連する上記の１つ又は複数の第２の識別子
の内において、時系列上１番目の第２の識別子は時系列
上１番目であることを示すデータを備え、且つ、時系列
上最終番目の第２の識別子は時系列上最終番目であるこ
とを示すデータを備える。

【００２１】本発明に係る請求項３に記載の顧客サービ
スシステムは、第１の識別子を入力データとし、上記の
入力された第１の識別子と１つ又は複数の第２の識別子
との、上記顧客データベースファイルにおける関連付け
を利用して、該第１の識別子と関連する第２の識別子を
確定して出力データの一部とする、請求項１又は請求項
２に記載の顧客サービスシステムである。

【００２２】本発明に係る請求項４に記載の顧客サービ
スシステムは、第１の識別子が、顧客識別子である、請
求項１乃至請求項３に記載の顧客サービスシステムであ
る。

【００２３】本発明に係る請求項５に記載の顧客サービ
スシステムは、第２の識別子が、場所識別子である、請
求項１乃至請求項４に記載の顧客サービスシステムであ
る。

【００２４】本発明に係る請求項６に記載の記録媒体
は、請求項１乃至請求項５に記載の顧客サービスシステ
ムを稼動させるコンピュータプログラムを記録したこと
を特徴とする記録媒体である。

【００２５】

【発明の実施の形態】以下、図面を参照して、本発明に
係る好適な実施の形態を説明する。

【００２６】本発明に係る顧客サービスシステム１２
は、 ・図６に示されている「コールセンタ」の構成の形態、 ・図７に示されている「ｅＣＲＭ」の一つの形態 のいずれにおいても、利用することができる。

【００２７】≪第１の実施の形態≫先ず、本発明に係る
顧客サービスシステム１２に含まれる顧客データベース
３０の構成について説明する。図１は、具体的なデータ
を格納している顧客データベース３０のレイアウト図で
ある。

【００２８】図１の顧客データベース３０は、（１）顧
客ＩＤテーブル３２と（２）場所ＩＤテーブル３４から
構成される。顧客ＩＤテーブル３２における各エントリ
（図における１行）は、各顧客（に係るデータ）を表
す。該テーブル３２の「顧客ＩＤ」はキー（識別子）項
目である。

【００２９】従来の技術として前に示した公益事業にお
ける顧客サービスシステム１２では、顧客２０がサービ
スを受けるロケーションに対し割り振られる番号を「識
別子」（即ち、ＩＤ）としているが、本発明における
「顧客ＩＤ」は、従来の「識別子」とは異なる番号（体
系）である。この「顧客ＩＤ」の番号体系は、顧客に割
り振られる番号が「顧客を一意に特定する」というもの
であればよい。例えば、図１（１）に示すように、それ
は、連続して採番されるシリアル（ｓｅｒｉａｌ；連
続）番号体系を備えるものでもよい。また、それは、
（自動車）運転免許証の免許証番号のようなものでもよ
い。

【００３０】場所ＩＤテーブル３２における各エントリ
（図における１行）は、サービス供給場所（に係るデー
タ）を表し、このテーブルにおけるキー（識別子）項目
である「場所ＩＤ」は、（上記の）従来技術の顧客サー
ビスシステム１２における、ロケーションに割り振られ
る「識別子」である。

【００３１】顧客ＩＤテーブル３２における「顧客Ｉ
Ｄ」は、顧客２０の転居などによるサービス供給場所の
移動（変更）が生じても、変更されることは無く一定で
ある。また、顧客ＩＤテーブル３２において各エントリ
は、「場所ＩＤテーブルへのポインタ」のデータ項目を
有しており、このポインタは顧客サービスシステム１２
に該顧客２０が最初にデータ登録された際のサービス供
給場所の「場所ＩＤ」である。

【００３２】一方、場所ＩＤテーブル３４の各エントリ
は、キー項目の「場所ＩＤ」が示す場所においてサービ
ス供給を受けている（又は、受けていた）顧客２０の、 ・転居前（移動前）のサービス供給場所（前の場所）の
場所ＩＤと、 ・転居先（移動先）のサービス供給場所（次の場所）の
場所ＩＤと へのポインタ｛前場所ＩＤ、次場所ＩＤ｝を持つ。即
ち、当該顧客２０の移動（例えば、転居）に伴うサービ
ス供給場所の場所ＩＤの変更に関して、時間に沿って又
は時間を遡って、双方向に手繰れるように設定されてい
る。ここで、「前場所ＩＤ」に格納すべき場所ＩＤがな
い場合、即ち、「場所ＩＤ」が示す場所にてサービス供
給を受けていた（又は、受けている）顧客２０にとっ
て、その場所が最初のサービス供給場所である場合、そ
のエントリのデータ項目は「Ｎｕｌｌ」となる。同様
に、「次場所ＩＤ」に格納すべき場所ＩＤがない場合、
即ち、「場所ＩＤ」が示す場所にてサービス供給を受け
ている顧客２０にとって、その場所が現在のサービス供
給場所である場合、そのエントリのデータ項目も「Ｎｕ
ｌｌ」となる。従って、「次場所ＩＤ」のデータ項目が
「Ｎｕｌｌ」であるエントリのみを抽出すれば、現在サ
ービス供給が行なわれている「場所」を把握することが
できる。図１の場所ＩＤテーブル３４においては、テー
ブルの下部（場所ＩＤ；８、９、１０、１１）にそのよ
うなエントリ（データ）がまとめて示されている。

【００３３】図１の具体的データを辿ってみる。顧客Ｉ
Ｄ（１）の顧客２０は、最初に「２」の場所にてサービ
ス供給され、続いて「１」で供給され、そして「１０」
にて現在供給されている。同様にして、顧客ＩＤ（２）
の顧客２０は、 ・「６」→「８」 顧客ＩＤ（３）の顧客２０は、 ・「７」→「３」→「４」→「５」→「９」 顧客ＩＤ（４）の顧客２０は、 ・「１１」 にて、順にサービス供給されていることを示す。

【００３４】図１の顧客データベース３０を利用して、
（１）顧客ＩＤから、現在の（サービス供給場所の）場
所ＩＤを確定する処理と、（２）現在の場所ＩＤから、
顧客ＩＤを確定する処理とを、夫々フローチャートによ
り示す。まず、図２（１）は、（１）顧客ＩＤから現在
の（サービス供給場所の）場所ＩＤを確定する処理のフ
ローチャートである。

【００３５】ステップＳ０２；「Ｘ」に顧客ＩＤを設定
する。さらに、顧客ＩＤテーブル３２にて、その「Ｘ」
をキー項目に持つレコードを特定し、そのレコードの場
所ＩＤ（テーブルへのポインタ）を「Ｙ」に設定する。

【００３６】ステップＳ０４；場所ＩＤテーブル３４に
おいて「Ｙ」をキー項目に持つレコードを特定し、その
レコードの「次場所ＩＤ」を「Ｚ」に設定する。

【００３７】ステップＳ０６；「Ｚ」が「Ｎｕｌｌ」か
否かを確認する。「Ｎｕｌｌ」でないならば、ステップ
Ｓ０８へ進む。「Ｎｕｌｌ」であるならば、ステップＳ
１０へ進む。

【００３８】ステップＳ０８；「Ｚ」の値を「Ｙ」に設
定し、ステップＳ０４に戻る。

【００３９】ステップＳ１０；前に説明したように、こ
こでの「Ｙ」の値が、現在の場所ＩＤである。

【００４０】以上で、（１）顧客ＩＤから現在の場所Ｉ
Ｄを確定する処理が終了する。

【００４１】続いて、図２（２）は、（２）現在の場所
ＩＤから顧客ＩＤを確定する処理のフローチャートであ
る。

【００４２】ステップＳ２２；「Ｘ」に現在の場所ＩＤ
を設定する。さらに、場所ＩＤテーブル３４にて、その
「Ｘ」を次場所ＩＤ項目に持つレコードを特定し、その
レコードの場所ＩＤ（キー項目）を「Ｙ」に設定する。

【００４３】ステップＳ２４；顧客ＩＤテーブル３２に
おいて、「Ｙ」を場所ＩＤ（テーブルへのポインタ）に
持つレコード「Ｚ」が存在するか否かを、確認する。存
在すればステップＳ２６へ、存在しなければステップＳ
２８へ、進む。

【００４４】ステップＳ２６；レコード「Ｚ」のキー項
目が、求める顧客ＩＤである。

【００４５】ステップＳ２８；「Ｙ」の値を「Ｘ」に設
定する。

【００４６】ステップＳ３０；、場所ＩＤテーブル３４
にて、「Ｘ」を次場所ＩＤ項目に持つレコードを特定
し、そのレコードの場所ＩＤ（キー項目）を「Ｙ」に設
定する。そして、ステップＳ２４に戻る。

【００４７】（２）現在の場所ＩＤから顧客ＩＤを確定
する処理は、ステップＳ２４でレコード「Ｚ」が確定さ
れその顧客ＩＤが抽出されしだい、終了する。

【００４８】上記の図２（１）（２）のフローチャート
に示される処理を利用することにより、顧客２０に対
し、 ・場所ＩＤ ・顧客ＩＤ の何れか一方のみが通知されているとしても、顧客２０
は、図７に示されている「ｅＣＲＭ」の一つの形態にお
いて、自らに対するサービス供給に係るデータを正しく
抽出することができる。しかも、顧客ＩＤが判明してい
る場合には、場所ＩＤの継承関係を順に辿ることによ
り、また、場所ＩＤが判明している場合には、場所ＩＤ
の継承関係を逆順に辿ることにより、同一顧客２０が使
用した場所ＩＤの変遷を把握することができる。

【００４９】図６に示されている「コールセンタ」２の
構成の形態においても同様に、オペレータ４は「場所Ｉ
Ｄ」、「顧客ＩＤ」の何れからでも、任意の顧客２０に
対するサービス供給に係るデータを正しく抽出すること
ができ、同一顧客２０が使用した場所ＩＤの変遷を把握
することができる。

【００５０】≪第２の実施の形態≫第１の実施の形態に
おいては、現在使用中の場所ＩＤから顧客ＩＤを確定す
ることができ、且つ、顧客ＩＤから現在使用中の場所Ｉ
Ｄを確定することができる。但し、第１の実施の形態で
は、一度使用された場所（システム上では、場所ＩＤ）
は、そこからの移転が発生すると、再度使用されること
はない、という前提が設定されている。

【００５１】しかしながら、現在多くの公益事業者が採
用している場所ＩＤの体系（但し、従来技術の構成例で
は、顧客ＩＤの体系）においては、場所ＩＤが再使用さ
れることがある、という点を考慮する必要がある。

【００５２】例えば、賃貸のアパートにおいて、ある住
居者がある期間にて居住し、また別の住居者が別の期間
にて居住する、ということは、当然に発生する事象であ
る。すると当然に、公益事業者の備える顧客サービスシ
ステム１２においては、前に説明した従来技術のもので
あっても、本発明の第１の実施の形態に係るものであっ
ても、同じ場所ＩＤが複数の異なるサービス被供給者
（需用者）により使用されることになる。即ち、多くの
公益事業者が採用する場所ＩＤの体系においては、同一
顧客２０が、時期によって異なる場所ＩＤを付されるこ
とがあるのみならず、同一の場所ＩＤが、時期によって
異なる顧客２０に付されることが生じ得る。

【００５３】例えば、顧客ＩＤ（１００）の顧客２０
が、「２」→「１」→「３」と場所ＩＤが変遷し、顧客
ＩＤ（１０１）の顧客２０が、「４」→「１」→「５」
と場所ＩＤが変遷する例（例α）を考える。この例αに
関して、顧客データべース３０［（１）顧客ＩＤテーブ
ル３２、（２）場所ＩＤテーブル３４］を作成すると、
図３のようになるが、これらテーブル（だけ）では、図
２に示される、（１）顧客ＩＤから現在の場所ＩＤを確
定する処理や、（２）現在の場所ＩＤから顧客ＩＤを確
定する処理を、行うことは不可能である。何故ならば、
例えば顧客ＩＤ（１００）の顧客２０が、「２」→
「１」→「３」と場所ＩＤが変遷したのか、それとも
「２」→「１」→「５」と場所ＩＤが変遷したのか、確
定不能だからである。

【００５４】上記の問題点を解消するために、本発明の
第２の実施の形態においては、顧客サービスシステム１
２に含まれる顧客データベース３０’の場所ＩＤテーブ
ル３４の構成に、「場所通し番号」、「開始日」、「終
了日」などの項目が付加される。図４は、具体的なデー
タを格納している顧客データベース３０’のレイアウト
図である。

【００５５】図４の顧客データベース３０’は、前に説
明した図１の顧客データベース３０と同様に、（１）顧
客ＩＤテーブル３２’と（２）場所ＩＤテーブル３４’
から構成される。顧客ＩＤテーブル３２’が「顧客Ｉ
Ｄ」をキー項目として「場所ＩＤテーブルへのポイン
タ」を含み、場所ＩＤテーブル３４’が「場所ＩＤ」を
含むことも、図１の顧客データベース３０と同様であ
る。

【００５６】ところで、本発明の第２の実施の形態に係
る顧客サービスシステム１２の顧客データベース３０’
の場所ＩＤテーブル３４’は、「場所通し番号」を新た
なキー項目とし、「開始日」「終了日」のデータ項目が
新たに付加され、「前場所ＩＤ」「次場所ＩＤ」のデー
タ項目が「前場所通し番号」「次場所通し番号」に変更
されている。

【００５７】「場所通し番号」は、従来の「場所ＩＤ」
と次に説明する「開始日」との組合せの各々に対して一
つずつ採番されるシリアル（ｓｅｒｉａｌ；連続）番号
である。即ち、場所ＩＤテーブル３４’においては、 ・同一の場所が、時期によって異なる顧客２０により占
められることはあり得るが、同時に複数の顧客２０によ
り占められることはない。という前提を置き、 ・「場所ＩＤ」＋「開始日」 をシステム上の管理単位とするものである。

【００５８】場所ＩＤテーブル３４’の各エントリの
「開始日」と「終了日」には、各場所での各顧客２０毎
へのサービス供給「開始日」とサービス供給「終了日」
との日付が格納される。公益事業においては、各顧客２
０のサービス供給開始の日とサービス供給停止の日が、
コンピュータシステム上にて管理されるのが通例である
から、これらデータ項目の実データを採取することは困
難な作業ではない。但し、現在使用中の場所に係る場所
ＩＤを備える（場所ＩＤテーブル３４’の）各エントリ
においては、「終了日」に具体的な日付が設定され得な
い。この場合、「終了日」は「Ｎｕｌｌ」となるように
構成されている。

【００５９】さらに、場所ＩＤテーブル３４’の各エン
トリは、当該エントリに係る顧客２０の、 ・転居前（移動前）のサービス供給場所（前の場所）の
場所通し番号と、 ・転居先（移動先）のサービス供給場所（次の場所）の
場所通し番号と へのポインタ｛前場所通し番号、次場所通し番号｝を持
つ。即ち、第１の実施の形態と同様に、当該顧客２０の
移動（例えば、転居）に伴うサービス供給場所の場所通
し番号の変更に関して、時間に沿って又は時間を遡っ
て、双方向に手繰れるように設定されている。ここで、
第１の実施の形態と同様に、「前場所通し番号」に格納
すべき場所通し番号がない場合、即ち、「場所ＩＤ」が
示す場所にてサービス供給を受けていた（又は、受けて
いる）顧客２０にとって、その場所が最初のサービス供
給場所である場合、そのエントリの「前場所通し番号」
のデータ項目は「Ｎｕｌｌ」となる。同様に、「次場所
通し番号」に格納すべき場所通し番号がない場合、即
ち、「場所ＩＤ」が示す場所にてサービス供給を受けて
いる顧客２０にとって、その場所が現在のサービス供給
場所である場合、そのエントリのデータ項目も「Ｎｕｌ
ｌ」となる。

【００６０】従って、顧客ＩＤテーブル３２’における
「場所ＩＤテーブルへのポインタ」は、該顧客２０が顧
客サービスシステム１２に最初に登録された際のサービ
ス供給場所の「場所通し番号」が設定されている。

【００６１】図４の具体的データを辿ってみる。顧客Ｉ
Ｄ（１）の顧客２０は、場所通し番号では、 ・「４」→「６」→「８」 の順にサービス供給されている。これを場所ＩＤで表す
と、 ・『２』→『１』→『１０』 となる。同様にして、顧客ＩＤ（２）の顧客２０の移動
状況は、場所通し番号、及び場所ＩＤで表すと、 ・「１」→「２」→「３」、及び、 ・『６』→『１』→『８』 となり、顧客ＩＤ（３）の顧客２０の移動状況は、場所
通し番号、及び場所ＩＤで表すと、 ・「７」→「９」→「１０」→「１１」→「１２」→
「１３」、及び、 ・『７』→『３』→『６』→『４』→『５』→『９』 となり、顧客ＩＤ（４）の顧客２０の移動状況は、場所
通し番号、及び場所ＩＤで表すと、 ・「５」、及び、 ・『１１』 となる。

【００６２】第１の実施の形態と同様に、図４の顧客デ
ータベース３０’を利用して、（１）顧客ＩＤから、現
在の場所ＩＤを確定する処理と、（２）現在の場所ＩＤ
から、顧客ＩＤを確定する処理とを、夫々フローチャー
トにより示す。まず、図５（１）は、（１）顧客ＩＤか
ら現在の場所ＩＤを確定する処理のフローチャートであ
る。

【００６３】ステップＳ４２；「Ｘ」に顧客ＩＤを設定
する。さらに、顧客ＩＤテーブル３２’にて、その
「Ｘ」をキー項目に持つレコードを特定し、そのレコー
ドの場所ＩＤテーブルへのポインタを「Ｙ」に設定す
る。

【００６４】ステップＳ４４；場所ＩＤテーブル３４’
において「Ｙ」をキー項目に持つレコードを特定し、そ
のレコードの「次場所通し番号」を「Ｚ」に設定する。

【００６５】ステップＳ４６；「Ｚ」が「Ｎｕｌｌ」か
否かを確認する。「Ｎｕｌｌ」でないならば、ステップ
Ｓ４８へ進む。「Ｎｕｌｌ」であるならば、ステップＳ
５０へ進む。

【００６６】ステップＳ５０；「Ｚ」の値を「Ｙ」に設
定し、ステップＳ４４に戻る。

【００６７】ステップＳ５０；「Ｙ」をキー値に持つレ
コードの、「場所ＩＤ」が現在の「場所ＩＤ」である。

【００６８】以上で、（１）顧客ＩＤから現在の場所Ｉ
Ｄを確定する処理が終了する。

【００６９】続いて、図５（２）は、（２）現在の場所
ＩＤから顧客ＩＤを確定する処理のフローチャートであ
る。

【００７０】ステップＳ６２；「Ｘ」に現在の場所ＩＤ
を設定する。さらに、場所ＩＤテーブル３４’にて、そ
の「Ｘ」を場所ＩＤ値に持ち「次場所通し番号」が「Ｎ
ｕｌｌ」であるレコードを特定し、そのレコードの「前
場所通し番号」を「Ｙ」に設定する。

【００７１】ステップＳ６４；「Ｙ」が「Ｎｕｌｌ」で
あるか否かを確認する。「Ｎｕｌｌ」でないならばステ
ップＳ６６へ、「Ｎｕｌｌ」であればステップＳ７０へ
進む。

【００７２】ステップＳ６６；「Ｘ」に「Ｙ」の値を設
定する。

【００７３】ステップＳ６８；場所ＩＤテーブル３４’
にて、「Ｘ」をキー項目に持つレコードの「前場所通し
番号」を「Ｙ」に設定し、ステップＳ６４に戻る。

【００７４】ステップＳ７０；顧客ＩＤテーブル３２’
にて、「Ｘ」の値を「場所ＩＤテーブルへのポインタ」
に持つレコードのキー項目が、求める顧客ＩＤである。

【００７５】以上で、（２）現在の場所ＩＤから顧客Ｉ
Ｄを確定する処理は終了する。

【００７６】上記の図５（１）（２）のフローチャート
に示される処理を利用することにより、顧客２０に対
し、 ・場所ＩＤ ・顧客ＩＤ の何れか一方のみが通知されているとしても、顧客２０
は、図７に示されている「ｅＣＲＭ」の一つの形態にお
いて、自らに対するサービス供給に係るデータを正しく
抽出することができる。しかも、顧客ＩＤが判明してい
る場合には、場所ＩＤの継承関係を順に辿ることによ
り、また、場所ＩＤが判明している場合には、場所ＩＤ
の継承関係を逆順に辿ることにより、同一顧客２０が使
用した場所ＩＤの変遷を把握することができる。

【００７７】図６に示されている「コールセンタ」の構
成の形態においても同様に、オペレータ４は「場所Ｉ
Ｄ」、「顧客ＩＤ」の何れからでも、任意の顧客２０に
対するサービス供給に係るデータを正しく抽出すること
ができ、同一顧客２０が使用した場所ＩＤの変遷を把握
することができる。

【００７８】本発明の実施の形態に係る顧客データベー
ス１２へのアクセス方法は、コンピュータ制御に適うよ
うにコンピュータ・プログラム化され、ホストコンピュ
ータ１４に付属するメモリ部に搭載されており、必要に
応じて稼動する。上記のプログラムは、例えば、ハード
ディスク（図示せず。）に格納されていてもよい。その
場合、当該ハードディスクをホストコンピュータ１４と
適宜接続し、所定のプログラムをホストコンピュータ１
４のＲＡＭ又はメモリ等にロードした後、稼動すること
になる。

【００７９】上記のハードディスクに限らず、本発明の
実施の形態に係るコンピュータ・プログラムを、磁気テ
ープ、ＤＶＤ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＭＯなどの他の
記録媒体に記録してもよい。

【００８０】

【発明の効果】これまでの説明により、特に公益企業の
有する顧客サービスシステム１２において、本発明は以
下のような効果が得られることが明白である。

【００８１】まず、上述したように、本発明に係る顧客
サービスシステム１２においては、 ・顧客ＩＤが判明していれば、場所ＩＤの履歴を辿るこ
とができるし、更に、 ・現在の場所ＩＤが判明していれば、場所ＩＤの履歴を
辿ることができる。 従って、顧客２０が、サービス供給を受ける場所を移動
（転宅など）したとしても、顧客サービスシステム１２
上にて過去のサービス情報に、適宜、アクセスすること
ができる。

【００８２】また、第１の実施の形態、及び第２の実施
の形態のいずれにおいても、顧客ＩＤテーブル（３２、
３２’）にて、単一の顧客（ＩＤ）が複数の「場所ＩＤ
テーブルへのポインタ」を有することができる。そうす
ると、単一の顧客２０に対し、複数の場所でのサービス
供給の情報を備えさせることができる。即ち、単一の顧
客２０が複数の場所でサービス供給を受ける場合であっ
ても、単一の顧客ＩＤにより、サービス関連情報に適宜
アクセスすることができる。

【図面の簡単な説明】

【図１】 第１の実施の形態に係る顧客データベースの
レイアウト図である。

【図２】 （１）顧客ＩＤから現在の場所ＩＤを確定す
る処理と、（２）現在の場所ＩＤから顧客ＩＤを確定す
る処理とを示す、第１の実施の形態に係るフローチャー
トである。

【図３】 第１の実施の形態に係る顧客データベースの
例である。

【図４】 第２の実施の形態に係る顧客データベースの
レイアウト図である。

【図５】 （１）顧客ＩＤから現在の場所ＩＤを確定す
る処理と、（２）現在の場所ＩＤから顧客ＩＤを確定す
る処理とを示す、第２の実施の形態に係るフローチャー
トである。

【図６】 「コールセンタ」の構成例のブロック図であ
る。

【図７】 ｅＣＲＭの構成例のブロック図である。

【符号の説明】

２・・・コールセンタ、４・・・オペレータ、６・・・
端末用計算機、１２顧客サービスシステム、１８・・・
公衆回線、２０・・・顧客、２２・・・（顧客保有の）
計算機、２４・・・インタネット網、３０、３０’・・
・顧客データベース、３２、３２’・・・顧客ＩＤテー
ブル、３４、３４’・・・場所ＩＤテーブル。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 鈴木 隆 大阪府大阪市中央区平野町四丁目１番２号 大阪瓦斯株式会社内 (72)発明者 西久保 充哉 大阪府大阪市中央区平野町四丁目１番２号 大阪瓦斯株式会社内 (72)発明者 木田 泰司 大阪府大阪市中央区平野町四丁目１番２号 大阪瓦斯株式会社内 Ｆターム(参考） 5B075 ND16 ND23 NK54 PQ02 UU40

Claims (6)

【特許請求の範囲】
1. 【請求項１】 磁気媒体に格納された顧客データベース
   ファイルを備え、 該顧客データベースファイルには、個々の顧客に係るデ
   ータを識別するために付される第１の識別子と第２の識
   別子とが格納され、 個々の顧客に対して、第１の識別子は不変であり、第２
   の識別子は時間の経過と共に１回又は複数回変更される
   ことがあり、 第１の識別子は、時系列上１番目の第２の識別子と関連
   付けられ、 続いて、第２の識別子は、時系列上次の順番の第２の識
   別子と関連付けられ、 上記の１つ又は複数の第２の識別子の内において、時系
   列上１番目の第２の識別子は時系列上１番目であること
   を示すデータを備え、且つ、時系列上最終番目の第２の
   識別子は時系列上最終番目であることを示すデータを備
   える、 顧客サービスシステム。
2. 【請求項２】 磁気媒体に格納された顧客データベース
   ファイルを備え、 該顧客データベースファイルには、個々の顧客に係るデ
   ータを識別するために付される第１の識別子と第２の識
   別子とが格納され、 個々の顧客に対して、第１の識別子は不変であるが、第
   ２の識別子は時間の経過と共に１回又は複数回変更され
   ることがあり、更に、第２の識別子の各々は、他の顧客
   から再利用されることがあり、 第２の識別子に対して、個々の顧客が利用する利用開始
   時に係るデータと利用終了時に係るデータとを備えさ
   せ、 第１の識別子は、時系列上１番目の第２の識別子及びそ
   の利用開始時と関連付けられ、 続いて、第２の識別子及びその利用開始時は、時系列上
   次の順番の第２の識別子及びその利用開始時と関連付け
   られ、 個別の顧客と関連する上記の１つ又は複数の第２の識別
   子の内において、時系列上１番目の第２の識別子は時系
   列上１番目であることを示すデータを備え、且つ、時系
   列上最終番目の第２の識別子は時系列上最終番目である
   ことを示すデータを備える、 顧客サービスシステム。
3. 【請求項３】 第１の識別子を入力データとし、 上記の入力された第１の識別子と１つ又は複数の第２の
   識別子との、上記顧客データベースファイルにおける関
   連付けを利用して、該第１の識別子と関連する第２の識
   別子を確定して出力データの一部とする、請求項１又は
   請求項２に記載の顧客サービスシステム。
4. 【請求項４】 第１の識別子が、顧客識別子である、請
   求項１乃至請求項３に記載の顧客サービスシステム。
5. 【請求項５】 第２の識別子が、場所識別子である、請
   求項１乃至請求項４に記載の顧客サービスシステム。
6. 【請求項６】 請求項１乃至請求項５に記載の顧客サー
   ビスシステムを稼動させるコンピュータプログラムを記
   録したことを特徴とする記録媒体。