(57)【要約】【課題】顧客から商品やサービス等に対する改善要求が寄せられたとき、迅速、的確にこれらに対応できる改善状況フィードバックシステムを実現する。【解決手段】顧客端末２０９から苦情等の改善要求情報が寄せられたとき問合せ窓口部２０２の受付部２１２がこれを受け付けて要約と共に対応履歴データベースに格納する。改善計画検討部２０３は要約からキーワード検索で対応部門部２０４を判定する。対応部門部２０４は過去の改善策等を蓄積した改善データベース２４２を照合して情報提供部２３２が一致内容を顧客端末２０９に通知する。一致しない場合は改善策等を作成し通知する。改善策等を公開する場合には対応部門部２０４の担当者を経てＨＴＭＬに変換後ウェブ公開される。キーワードによる自動検索と担当者の対応とで迅速さと的確さが実現される。【選択図】  図１
2004310321.tif 000002
【特許請求の範囲】
【請求項１】
苦情や要望等の改善要求に対する要約を入力する要約入力手段と、
この要約入力手段によって入力された要約と前記改善要求の内容を案件ごとに改善要求情報として格納する改善要求情報格納手段と、
この改善要求情報格納手段に格納された要約を用いて改善要求を処理すべき対応部門を判別する対応部門判別手段と、
過去の改善要求情報とその改善策を改善要求に対する要約と共に格納した改善データベースと、
この改善データベースの要約と前記改善要求情報格納手段に格納された改善すべき案件の要約とを照合することで同一の改善要求の有無を判別する案件照合手段と、
この案件照合手段が同一の改善要求が過去に存在しないと判別したときその改善要求に対する改善策を入力する改善策入力手段と、
この改善策入力手段によって入力された改善策あるいは過去の同一の改善要求に対する改善策を改善要求先に通知する改善要求先通知手段
とを具備することを特徴とする改善状況フィードバックシステム。
【請求項２】
前記改善策入力手段によって入力された改善策の実行を期限を付けて対応部門に指示する改善策実行指示手段と、
前記期限内に改善策の実行が完了しないときこれに対してアラームを発するアラーム発生手段
とを具備することを特徴とする請求項１記載の改善状況フィードバックシステム。
【請求項３】
前記改善策入力手段によって改善策が入力されたときこれをウェブ公開用のファイルに変換するファイル変換手段と、
このファイル変換手段によって変換されたファイルを顧客に公開するコンテンツの一部としてアップロードするアップロード手段
とを具備することを特徴とする請求項１記載の改善状況フィードバックシステム。
【請求項４】
前記案件照合手段は要約同士のキーワードの照合を行う手段であり、キーワードのいずれについても一致を見ることができなかったとき、前記改善要求情報格納手段に格納された要約以外の改善要求情報と改善データベースの内容の照合を行う照合対象拡大手段を具備することを特徴とする請求項１記載の改善状況フィードバックシステム。
【請求項５】
前記案件照合手段は、前記要約から切り出されたキーワードを用いてキーワード同士が一致するかを照合する手段であり、切り出されたキーワードの数が複数のとき照合に使用するキーワードの数を照合によって一致する改善要求の数が所望の値の範囲となるように調整するキーワード数調整手段を具備することを特徴とする請求項１記載の改善状況フィードバックシステム。
【請求項６】
前記改善策実行指示手段による改善策の実行が完了したとき前記改善要求情報格納手段に格納された改善要求情報と改善のために採られた内容を示す情報を前記改善データベースに書き込む改善データベース更新手段を具備することを特徴とする請求項２記載の改善状況フィードバックシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は顧客から寄せられる苦情や要望等の改善要求情報を処理する改善状況フィードバックシステムに係わり、特にインターネットを使用して改善状況を顧客にフィードバックするようにした改善状況フィードバックシステムに関する。
【０００２】
【従来の技術】
顧客に販売した製品や提供したサービスに対して顧客側に何らかの不満がある場合には、その苦情を積極的に受け付けて不備な点を是正することが販売者あるいはサービス提供者（以下、適宜、企業と称する。）のために大切なことである。また、新たな製品やサービスに対する要望についても積極的に受け付けて検討することが需要者の開拓や企業の発展に大変重要である。これら苦情や要望等の改善要求情報を有効にかつ迅速に反映させることは企業の信頼性を高める上でも必要である。
【０００３】
このような改善要求情報は、電話やファクシミリを使用して、それぞれの企業のコールセンタや消費者相談係に寄せられる場合もあるし、所定の宛先に電子メールで寄せられる場合もある。営業や保守で訪れた者に対して直接伝達される場合もある。改善要求情報のうちの苦情処理については、コンピュータを用いて処理することが従来から提案されている（たとえば特許文献１）。
【０００４】
図４は、この提案による苦情処理システムの概要を表わしたものである。このシステムで苦情処理装置１０１は、通信ネットワーク１０２によって複数のアクセス端末１０３１〜１０３Ｎと接続されている。苦情処理装置１０１は、従来から使用されているメモリと入出力ポートとモデム（共に図示せず）を備えている。そして、苦情およびそれに対する応答を受け取って記憶し、検索する。アクセス端末１０３１〜１０３Ｎは、同様にメモリと入出力ポートとモデム（共に図示せず）を備えている。
【０００５】
図５は、この提案の苦情処理方法による処理の流れを示したものである。まず、ユーザが図４に示した通信ネットワーク１０２を介して苦情処理装置１０１をアクセスする（ステップＳ１１１）。この状態で初期メッセージが表示され（ステップＳ１１２）、その１つを選択することで該当する販売業者を特定するための販売業者データの入力が催促される（ステップＳ１１３）。ユーザがこれを入力することでシステム側は該当する販売業者を見つけ出す（ステップＳ１１４）。販売業者が見つかったら苦情登録を行うか他の処理を行うかをユーザに選択させ（ステップＳ１１５）、苦情登録を行う場合には（Ｙ）、苦情の入力を催促する（ステップＳ１１６）。入力された苦情の詳細から解決に要求される行動や苦情を要約する幾つかのキーワード、そのユーザの電話番号や電子メールのアドレスの抽出が行われる。次に苦情を呈したそのユーザと該当する販売業者に対して独自のメールアドレスを生成する（ステップＳ１１７）。これは専用のメッセージの伝達や苦情解決のための専用フォーラムにエントリするためのパスワードとして使用することができる。
【０００６】
次に登録した苦情の検証と確認が行われる（ステップＳ１１８）。ここでは、苦情を呈したそのユーザの電子メールアドレスに苦情内容を電子メールで伝送し、その訂正や確認を行わせる。ユーザに対して苦情の登録処理に必要な料金を請求することもできる。この後、その苦情は苦情データベースに登録される。この後は図１に示した苦情処理装置１０１にアクセスすることで販売業者や他のユーザも苦情の内容やこれに関連した応答を閲覧することができる（ステップＳ１１９）。最後に、システム側は苦情の内容を該当する販売業者に通知する（ステップＳ１２０）。これにより、販売業者は苦情を呈したユーザと苦情の解決のための話し合いを持つことができる。なお、苦情登録を行わない場合には（ステップＳ１１５：Ｎ）、他の処理が行われる。
【０００７】
以上説明したような苦情処理システムでは、大多数の者が苦情を呈するような問題も一部の者が苦情を呈するような問題も一様に登録処理されて公開される。したがって、公開された苦情の内容と回答から他の者が必要とする情報を見つけ出すのが困難である。そこで、ネットワーク上に顧客の問い合せに対応するサーバを配置しておき、類似した問い合せが所定数以上に達したときに、その問い合せと回答とを初めてウェブページに掲載するようにすることが提案されている（たとえば特許文献２）。
【０００８】
また、ネットワークを通じてユーザの質問をテキストデータとして受け取っておき、ユーザへの回答処理が行われた段階でネットワーク上に開示するための開示用データベースにこれらを登録するようにした提案も行われている（たとえば特許文献３）。この提案では、ユーザがネットワークを通じて事例の開示を要求すると、該当する事例を検索するための検索条件を入力させ、検索された事例をユーザ端末に送信するようにしている。
【０００９】
【特許文献１】
特表平１１−５０１１３７号公報（第１２ページ〜第１６ページ、図１、図２）
【特許文献２】
特開２００２−１３２７８７号公報（第００２５段落、図１、図５）
【特許文献３】
特開２００２−３５２０５７号公報（第００３２段落、第００３３段落、図１、図２、図５）
【００１０】
【発明が解決しようとする課題】
ところで、以上説明したような従来の技術では、次のような問題があった。
【００１１】
（１）従来の技術ではホームページ上に顧客の苦情や要望が改善要求情報として反映される。しかしながらこれら改善要求の反映までにかなりの人手を要しており、不特定人がこれらの情報を見うる状態となるまでにかなりの時間を要することになった。これは、従来では顧客から具体的な改善要求情報があっても、ウェブ上に公開する情報は汎用性のある情報に置き変えていたため、そのための処理に人手を要したので、迅速なウェブ公開を行うことができなかったためである。特に、これら改善要求情報を受け付ける部署は、実際の企画部門や開発部門とは異なり、苦情処理のための専用部署である場合が多い。このような部署はコールセンタにも見られるようにそれ自体が専業化し、外部の会社に委託されている場合も多い。このため、１つ１つの具体的な苦情に対して即決してそれらの結果を公表するのではなく、多くの似たような苦情を包括的に解決するための質問と答えを検討して作成し、公表するようにしている。このため、人手と時間が必要になる。
【００１２】
（２）ホームページに掲載する作業自体は人手によって行っていたので、担当者がホームページの制作を行うための工数が必要となる。この結果、人件費がかかるだけでなく、改善要求情報が一度に集中したような場合にはホームページの制作による公開までの遅延が生じるという問題があった。
【００１３】
（３）顧客から寄せられる苦情や要望等の改善要求情報の公表が担当者の判断に委ねられていた。このため、商品やサービスを提供する企業側にとって都合のよい情報しか掲載されない恐れがあった。したがって、改善要求を行ったにもかかわらず公表を差し控えられた顧客だけでなく、公表された内容を検討する多くの顧客にとっても内容が不自然に映ることがあり、これがその企業のイメージや顧客の満足度を低下させることになった。
【００１４】
（４）従来のこれらの手法では同じような苦情や要望が過去に存在したかどうかどうかの判断は行われていたが、過去にどのような改善が採られてきたかまでを照らし合せることがなかった。このため、改善の対象となった苦情や要望が新たなものであっても、過去に他の改善要求情報に対して採られた改善策と同一の改善策を重複した形で採ろうとするような場合が生じた。これにより、そのような改善策がすでに採用されていることが分かると、今回の改善要求情報が出てきた原因が分からずに担当者が混乱する場合があった。また、過去に採られた対策を採ろうとしてその必要がなくなった場合にはそれまでの作業が無駄になり、結果的に不必要な工数を発生させることになった。
【００１５】
そこで本発明の目的は、顧客から商品やサービス等に対する苦情や要望等の改善要求情報が寄せられたとき、迅速、的確にこれらに対応できる改善状況フィードバックシステムを提供することにある。
【００１６】
【課題を解決するための手段】
請求項１記載の発明では、（イ）苦情や要望等の改善要求に対する要約を入力する要約入力手段と、（ロ）この要約入力手段によって入力された要約と改善要求の内容を案件ごとに改善要求情報として格納する改善要求情報格納手段と、（ハ）この改善要求情報格納手段に格納された要約を用いて改善要求を処理すべき対応部門を判別する対応部門判別手段と、（ニ）過去の改善要求情報とその改善策を改善要求に対する要約と共に格納した改善データベースと、（ホ）この改善データベースの要約と改善要求情報格納手段に格納された改善すべき案件の要約とを照合することで同一の改善要求の有無を判別する案件照合手段と、（へ）この案件照合手段が同一の改善要求が過去に存在しないと判別したときその改善要求に対する改善策を入力する改善策入力手段と、（ト）この改善策入力手段によって入力された改善策あるいは過去の同一の改善要求に対する改善策を改善要求先に通知する改善要求先通知手段とを改善状況フィードバックシステムに具備させる。
【００１７】
すなわち請求項１記載の発明では、要約入力手段が苦情や要望等の改善要求に対する要約を入力するようになっている。この要約が改善要求の内容と共に改善要求情報格納手段に格納され、要約を用いて改善要求を処理する対応部門が判別される。したがって、雑多な情報を除去した情報から担当部署が判別されることになる。本発明では過去の改善要求情報とその改善策を改善要求に対する要約と共に格納した改善データベースが用意されており、その中の要約と処理する案件の要約が照合されることで同一の改善要求が過去に存在したかどうかの判別が行われる。同一の改善要求が過去に存在しない場合に改善策入力手段は改善要求に対する改善策を入力することになる。改善要求先通知手段はこの改善策入力手段によって入力された改善策あるいは過去の同一の改善要求に対する改善策を改善要求先に通知する。通知は電子メール等の手段で直接行ってもよいし、ホームページに改善策が掲載されていることを知らせるような間接的なものであってもよい。このように請求項１記載の発明では要約を基準として担当部門を決定したり過去のデータを参照するので、機械的な処理が可能となり、かつ迅速な処理を行うことができる。しかも改善要求が新しいものであるような場合にも担当部門の改善策が入力されることで適切かつ迅速な対応が可能になる。
【００１８】
請求項２記載の発明では、請求項１記載の改善状況フィードバックシステムに、更に（イ）改善策入力手段によって入力された改善策の実行を期限を付けて対応部門に指示する改善策実行指示手段と、（ロ）期限内に改善策の実行が完了しないときこれに対してアラームを発するアラーム発生手段とを具備させている。
【００１９】
すなわち請求項２記載の発明では、改善要求に対して対応部門が改善を行うとき、期限を付けて管理することで確実な対応を行わせると共に、アラームに対応して、たとえば期限内に改善ができない場合の問題点を出すことで改善策に対してもフィードバック制御が可能になる。
【００２０】
請求項３記載の発明では、請求項１記載の改善状況フィードバックシステムに、更に（イ）改善策入力手段によって改善策が入力されたときこれをウェブ公開用のファイルに変換するファイル変換手段と、（ロ）このファイル変換手段によって変換されたファイルを顧客に公開するコンテンツの一部としてアップロードするアップロード手段とを具備させている。
【００２１】
すなわち請求項３記載の発明では、ファイル変換手段がウェブ公開用のファイルに変換し、これを顧客に公開するコンテンツの一部としてアップロードするようにしたので、改善要求に対応した担当者レベルでホームページの更新が可能であり、一般の顧客に対しても必要な改善策等の迅速な対応が可能である。
【００２２】
請求項４記載の発明では、請求項１記載の改善状況フィードバックシステムに、更に、案件照合手段は要約同士のキーワードの照合を行う手段であり、キーワードのいずれについても一致を見ることができなかったとき、改善要求情報格納手段に格納された要約以外の改善要求情報と改善データベースの内容の照合を行う照合対象拡大手段を具備させている。
【００２３】
すなわち請求項４記載の発明では、要約から抽出されるキーワードの数が少ないような場合で改善データベース内の要約との間で一致するキーワードが見つからなかったような所定の場合には、改善要求情報格納手段に格納された要約以外の改善要求情報を照合の対象として照合対象を拡大できることを示している。対応部門であればこのように照合の対象を拡大することで従来の改善要求情報とその改善策の中から必要とするものを見つけ出すことができる確率が高い。また、要約で最初の照合作業を行うことで全体として効率的な処理が可能になる。
【００２４】
請求項５記載の発明では、請求項１記載の改善状況フィードバックシステムで、案件照合手段は、要約から切り出されたキーワードを用いてキーワード同士が一致するかを照合する手段であり、切り出されたキーワードの数が複数のとき照合に使用するキーワードの数を照合によって一致する改善要求の数が所望の値の範囲となるように調整するキーワード数調整手段を具備することを特徴としている。
【００２５】
すなわち請求項５記載の発明では、要約から幾つものキーワードが抽出されたときキーワード同士の照合結果に応じて使用するキーワードの数を調整可能としたものである。これにより、照合結果から適切な過去の改善要求情報とその改善策を選択する対応部門の負荷を減少させることができ、迅速な対応が可能になる。
【００２６】
請求項６記載の発明では、請求項２記載の改善状況フィードバックシステムで、改善策実行指示手段による改善策の実行が完了したとき改善要求情報格納手段に格納された改善要求情報と改善のために採られた内容を示す情報を改善データベースに書き込む改善データベース更新手段を具備することを特徴としている。
【００２７】
すなわち請求項６記載の発明では、改善要求情報格納手段に格納された改善要求情報と改善のために採られた改善策等の内容を改善データベースに取り込むことで、改善データベースを完備させることができる。また、改善策実行指示手段による改善策の実行が完了したときに更新を行うようにすれば、たとえば改善のために採られた改善策でうまくいかなかったようなものをデータベースに組み込むのを排除することができる。
【００２８】
【発明の実施の形態】
【００２９】
【実施例】
以下実施例につき本発明を詳細に説明する。
【００３０】
図１は本発明の一実施例における改善状況フィードバックシステムの概要を表わしたものである。この改善状況フィードバックシステム２０１は、顧客の苦情等の改善要求や要望に対応する問合せ窓口部２０２と、改善計画を検討する改善計画検討部２０３と改善要求情報に対応する複数の対応部門部２０４（ただし、図では１つの対応部門部のみを示す。）とを備えており、これらはインターネット網２０５に接続されている。改善計画検討部２０３はインターネット網２０５を介してウェブ（Ｗｅｂ）サーバ部２０７とも接続されている。ウェブサーバ部２０７はインターネット網２０５を介して一般顧客端末群２０８内の個々の顧客端末と接続されるようになっている。ここでは、一般顧客端末群２０８内のある顧客端末２０９が、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ  Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅ：非対称ディジタル加入者回線）接続ができない苦情を寄せる場合を一例として説明する。
【００３１】
問合せ窓口部２０２は、この顧客端末２０９等の端末から電話あるいは電子メール等の通信手段で改善要求情報を含んだ各種情報２１１を個々に受け付ける受付部２１２と、対応した履歴をデータベース化した対応履歴データベース（ＤＢ）２１３を備えている。
【００３２】
ここで受付部２１２には、苦情や要望を受け付ける専門の担当者がそれぞれ配置されており、図示しないが電話等による各種情報２１１を受信する受信端末と、必要に応じてこれら各種情報２１１をテキスト化する音声認識機能やＯＣＲ（Ｏｐｔｉｃａｌ  Ｃｈａｒａｃｔｅｒ  Ｒｅｃｏｇｎｉｔｉｏｎ／Ｒｅａｄｅｒ）機能を備えた情報処理端末を備えている。この例の場合、顧客端末２０９から顧客が「ＡＤＳＬに加入しているが、現在ＡＤＳＬ接続ができない状態である。」という苦情を受けた受付部２１２では、担当者が苦情の内容を分析して対応履歴データベース２１３に格納する要約を作成したり予め定められた項目の選択を行う。この過程で内容が不明確であったり不十分である場合、担当者は顧客端末２０９に電話、ファクシミリあるいは電子メールによって質問を行う。
【００３３】
図２は、本実施例の対応履歴データベースの内容の一部を示したものである。対応履歴データベース２１３は、要約テーブル２２１とキーワードテーブル２２２の２つのテーブルを備えている。また、問い合せ内容２２３も本文データとして案件ごとに格納されるようになっている。問い合せ内容２２３には、担当者が顧客端末２０９の顧客に対して質問した内容等の顧客の直接伝達した内容以外の情報も含まれてよい。
【００３４】
この例の場合、担当者は要約テーブル２２１における顧客端末２０９から寄せられたこの案件に対応する箇所に「ＡＤＳＬ接続不可」と要約を入力する。また、キーワードテーブル２２２におけるこの案件に対応する箇所に予め用意された「事務問合せ」「要望」等の複数の選択肢の中から「苦情」を選択して入力する。なお要約テーブル２２１に書き込む要約は、その文章から抽出されたキーワードを用いることで、苦情や要望が対応部門部２０４のいずれに送られるかが特定可能となるような内容のものとするようになっている。このような要約は、受付部２１２の担当者が顧客と対応している際に作成するようになっている。
【００３５】
ところで改善計画検討部２０３は処理の対象となる案件に対して各部門が情報の共有を行うための計画データベース（ＤＢ）２３１を備えると共に、情報提供部２３２、キーワード抽出部２３３、送信処理部２３４という各種の機能を実現する部分と苦情等に対する改善策を期限を付けて実施する場合に期限管理のアラームを発信するアラーム部２３５を備えている。この改善計画検討部２０３は問合せ窓口部２０２、対応部門部２０４ならびにウェブサーバ部２０７の管轄や制御を行う部分であり、パーソナルコンピュータあるいはワークステーション等と同様の計算機と大容量の記憶媒体によって構成されている。
【００３６】
この改善計画検討部２０３内のキーワード抽出部２３３は、インターネット網２０５を介して問合せ窓口部２０２内の対応履歴データベース２１３を周期的にアクセスし、未処理データ（案件）が存在するとこれを読み出してその内容を格納するようになっている。対応履歴データベース２１３に新たな案件が格納されるとこれが改善計画検討部２０３に通知されて、改善計画検討部２０３がこれにより対応履歴データベース２１３をアクセスするようになっていてもよい。
【００３７】
キーワード抽出部２３３は、対応履歴データベース２１３から読み出した各案件の要約（要約テーブル２２１）ごとにキーワードを抽出して、その結果から案件ごとに担当する対応部門部２０４を決定する。この例では要約テーブル２２１に「ＡＤＳＬ接続不可」という要約が記されているので、キーワード抽出部２３３は「ＡＤＳＬ」と「接続不可」という２つのキーワードを抽出する。そして、これらキーワードに最も適切な対応部門部２０４を選択する。ここではＡＤＳＬを運用する部門（これを対応部門部２０４Ｂとし、図面上では対応部門部２０４をそのまま使用する。）を対応する部門として決定する。この決定内容は、宛先情報として送信処理部２３４に与えられる。
【００３８】
またキーワード抽出部２３３は、対応履歴データベース２１３に格納された各種情報２１１の中で「苦情」もしくは「要望」等の特定のキーワードを含んだデータ２１６を各対応部門部２０４で共有する情報として抽出し、計画データベース２３１に保存させる。
【００３９】
送信処理部２３４は、要約テーブル２２１から抽出したキーワードに対応する対応部門部２０４（この例の場合には対応部門部２０４Ｂ）に対して新規改善要否を問う新規改善要否案件が届いたことを示す電子メールを送出する。
【００４０】
ところで対応部門部２０４は、それぞれ担当者ごとに対応処理を個々に受け付ける複数の対応部２４１と、過去の改善策や改善した期限等の改善内容をデータベース化した改善データベース（ＤＢ）２４２と、会員顧客情報を格納する顧客データベース（ＤＢ）２４３を備えている。ここで対応部２４１には、図示しないが新規改善要否案件が届いたことを示す電子メールを受信する等の電子メール送受信機能や、改善データベース２４２、顧客データベース２４３ならびに計画データベース２３１にアクセスして必要なデータを参照したりデータの作成を行うための情報処理機能を備えた情報処理端末を備えている。なお、計画データベース２３１および改善データベース２４２内にも、対応履歴データベース２１３と同様に要約を記入したテーブルが用意されている。
【００４１】
対応部２４１の担当者は、送信処理部２３４から新規改善要否案件が届いたことを示す電子メール２１７を受け取る。この時点で対応部２４１では、計画データベース２３１と改善データベース２４２のそれぞれの要約を照合してキーワード検索する。この結果、改善データベース２４２内に、現在、改善を検討中の計画データベース２３１中の案件と同様の改善策が採られたものがあったり改善された期限等があった場合には、照合処理２５１によってこれらを自動的に取り出すようになっている。
【００４２】
この例では「ＡＤＳＬ」、「接続不可」という２つのキーワードを使用して、改善データベース２４２の検索が行われる。これら全部のキーワードを含む要約が「全キーワード一致」として改善データベース２４２から自動抽出され、一部のキーワードのみを含む要約が「一部キーワード一致」として改善データベース２４２から同様に自動抽出される。
【００４３】
ただし、対応部２４１では「全キーワード一致」により抽出される過去の改善策の数が所定の値を超えるときには「一部キーワード一致」の要約の抽出や表示を省略するように設定することができる。また、この例ではキーワードが２つの場合を示しているが、キーワードが３つ以上存在する場合には、「一部キーワード一致」の要約の抽出について、ヒットしたキーワードの数が多いものほど確度の高い要約として抽出するようにすることが可能である。すなわち、ヒットするキーワードの数を自動的に引き上げて、担当者に提示する改善案の要約の量を適正な量に絞ることも可能である。
【００４４】
また、対応部２４１がキーワードによる自動抽出を行った結果、必要とされる数の要約を抽出できないような場合もある。このような場合には、その担当者が対応履歴データベース２１３から得られるデータ２１６における当該案件についての要約文以外の情報を基にして新たにキーワードを作り出してもよい。たとえば受付部２１２の担当者が顧客端末２０９の顧客と電話で会話しているような場合に担当者側が質問した内容を参照してこれから有益と思われるキーワードを作り出すような場合である。この場合には、これら新たに作り出したキーワードを使用して、あるいはこれらのキーワードと自動的に抽出されたキーワードを組み合わせて検索のための論理式を作成し、キーワード検索を行うようにすればよい。
【００４５】
対応部２４１がキーワードによる自動抽出を行った結果として、改善データベース２４２の中に該当するキーワードを有する要約を抽出できないような場合もある。このよう場合には「不一致」と判定される。ただし「不一致」と判定される場合にも、対応部２４１の担当者は自分でキーワードを考えて何らかの関連性のある要約を改善データベース２４２の中から見つけ出すことも可能である。先に説明したと同様に、対応履歴データベース２１３の中における受付部２１２の担当者が顧客端末２０９に質問した内容等を参考にすることができる。
【００４６】
今回の例で「不一致」と判断された場合、「ＡＤＳＬ」、「接続不可」という２つのキーワードの組み合わされた苦情あるいは要望が今までに行われていなかったことを意味する。更にキーワードを追加したが「不一致」と判断された場合も同様である。このような場合には、顧客端末２０９から出されたこの苦情に対する改善策が従来から存在しなかったことになる。そこで、改善データベース２４２は、「ＡＤＳＬ」および「接続不可」の２つのキーワードを組み合わせた検索でキーワードが不一致とされた場合、これに対応する苦情や要望に対する改善案の領域を空白状態のテーブル部分とし、この部分に改善内容を入力可能にしている。これら空白状態のテーブル部分に担当者が改善案を埋め込んでいくことで改善データベース２４２を充実させることができる。他のキーワードを用いて同様に改善データベース２４２との対応ができなかった場合にも、同様に対応する改善案の領域を空白状態のテーブル部分として、この部分に改善策を記入できるようにしている。
【００４７】
対応部２４１の担当者は自身の情報処理端末（図示せず）の同じく図示しない表示画面に表示された検索結果をチェックするようになっている。すでに説明したことから了解されるように、チェックの結果として、表示された内容が今回の苦情の問い合せ内容２２３に対する改善策として一致している場合とそうでない場合がある。一致している場合には、その改善策はすでにウェブサーバ部２０７に格納されており、インターネット網２０５を介して一般顧客端末群２０８に公開されていることを意味する。そこでこの場合、担当者は過去に作成され改善済みの改善策を利用したことをログとして顧客データベース２４３に保存する。この処理を受けて改善計画検討部２０３内の情報提供部２３２はこの案件についての改善策（過去の改善策）を改めてウェブ表示を行うための処理は行わない。すなわち、過去に改善済みの改善策を利用したことを示すこのログを該当する改善策に付記した形のコメントを該当するＨＴＭＬ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）で書かれた改善策に追加して電子メールで該当する顧客端末２０９に送出する。これにより、苦情を呈したその顧客端末２０９の顧客は、その改善策が対応部門部２０４側で実施されたことで、苦情の原因が解消されていることを知るか、顧客自身で不具合を解消するために実施すべきことがある場合にはその改善策を実行することができる。たとえばソフトウェアのバージョンアップを顧客自身が行う場合がそれである。
【００４８】
これに対して、検索の結果として該当する改善策が改善データベース２４２内に見つからなかった場合、対応部２４１は改善策や改善期限等の改善データ２５２を作成してこれをインターネット網２０５を介して計画データベース２３１に記入する。この際、これを新規データとしてその改善データ用テーブルに格納する。
【００４９】
一方、照合処理２５１によって自動的に抽出された改善策や改善期限等の改善データあるいはこのような改善データが改善データベース２４２に見つからずに対応部２４１が新たに改善データ２５２を作成した場合を説明する。この場合、担当者は作成した改善データ２５２を自身の情報処理端末のディスプレイで表示しその確認作業を行う。これによる必要な訂正が終了したら、担当者は送信処理部２３４を使用してこれを顧客データベース２４３に格納すると共に、情報提供部２３２を用いてウェブサーバ部２０７のブラウザで閲覧可能なファイル（以下、更新ファイルという。）に自動変換・生成させる。このようにして得られた更新ファイル２５５は情報提供部２３２がインターネット網２０５を介してウェブサーバ部２０７にアップロードする。
【００５０】
アップロードされた更新ファイル２５５は、苦情を呈した顧客の使用する顧客端末２０９から特別のパスワードを使用してアクセス可能にすることができる。この場合、情報提供部２３２は顧客端末２０９の顧客を宛先として電子メール２１８等の媒体を使用して改善策および改善結果が見られる状態となったことを通知すると共に、必要な場合にはそのホームページへのアクセスのためのパスワードを通知する。もちろん、このようなホームページへのアクセスが可能なことを通知する代わりに、改善策および改善結果を電子メールに直接記入するかこれらの内容を添付書類の形で添付するようにしてもよい。
【００５１】
アップロードされた更新ファイル２５５は、その内容によっては苦情を呈した顧客以外としての一般顧客に公開情報２１９として公開してもよい。特定の商品やサービスを利用する一般の顧客に対して改善策や改善結果を公開する場合には、ウェブサーバ部２０７上のそれらの更新ファイル２５５をホームページ上で一般顧客端末群２０８が自由に閲覧できる状態に置けばよい。
【００５２】
ところで顧客端末２０９から出された苦情に対する改善策は対応部門部２０４で実行する必要がある。この場合には、苦情が続いて発生しないように改善が確実に行われるようにチェックすることが必要である。そこで本実施例では改善を行うための改善期限を設定し、この期限の到来を警告するためのアラーム部２３５が改善計画検討部２０３に備えられている。アラーム部２３５は設定した改善期限が到来しても担当者による改善が完了していない場合、対応部２４１に対してアラーム（警報）を発するようにしている。アラームは予め作成した所定の文章を記載した電子メールの発信であってもよいし、電話をかけて予め録音した音声を流すようなものであってもよい。あるいは予め作成した文書をファクシミリ装置で送信するものであってもよい。アラーム部２３５は単にこのようなアラームを発するだけでなく、次にアラームが発生されるべき日時を電子メール等の媒体を用いて対応部２４１に記入するように通告するものであってもよい。この場合、アラーム部２３５は対応部２４１の記入した日時にアラームを再設定することになる。
【００５３】
以上のようにして所定の案件に関して改善データベース２４２に記入すべきすべての改善策および改善結果等のデータが計画データベース２３１に格納されたら、改善計画検討部２０３は計画データベース２３１内の全データを改善データベース２４２に移動させ、これに保存させる。
【００５４】
図１で破線２６１、２６２は従来採用されたデータの伝達経路を参考のために示している。従来では会員顧客情報を格納する顧客データベース２４３が一般顧客端末群２０８の各顧客と対応付けられており、破線２６１で示すように顧客ごとに苦情処理や要望の対処を行ったり、あるいは破線２６２に示したように専用の苦情や要望についての処理係が検討し作成したデータが一般顧客の見うる状態でホームページ上に公開されたことになる。
【００５５】
図３は、以上説明した本実施例の改善状況フィードバックシステムの処理の流れの概要を示したものである。図１と共に説明する。顧客端末２０９から苦情あるいは要望がこのシステムに寄せられると（ステップＳ３０１：Ｙ）、対応履歴データベース２１３にその内容が要約と共に格納される（ステップＳ３０２）。その内容を基にして改善計画検討部２０３のキーワード抽出部２３３がキーワードを抽出し（ステップＳ３０３）、その苦情あるいは要望を処理する対応部門を決定する（ステップＳ３０４）。対応部門部２０４の対応部２４１には電子メール２１７が送出され、苦情あるいは要望があったことが通知される。
【００５６】
対応部門部２０４では、過去の改善策や改善した期限等の改善内容をデータベース化した改善データベース２４２に苦情や要望に対応する改善策や改善期限等のデータが存在するかを要約を照合することで自動検索する（ステップＳ３０５）。該当する改善策や改善期限等のデータが存在した場合には（ステップＳ３０６：Ｙ）、これらを顧客データベース２４３に格納し（ステップＳ３０７）、その顧客に改善結果をホームページや電子メール等の手段を利用して知らせる（ステップＳ３０８）。
【００５７】
一方、該当する改善策や改善期限等のデータが改善データベース２４２に存在しなかった場合には（ステップＳ３０６：Ｎ）、対応部２４１の担当者がその案件についての改善策や改善期限等のデータを作成する（ステップＳ３０９）。このデータはブラウザで閲覧可能なファイルに変換されて、必要な場合にはウェブで一般の顧客に公開されることになる（ステップＳ３０７、Ｓ３０８）。
【００５８】
このように苦情や要望に対応する改善策や改善期限等のデータが改善データベース２４２に見つかったり新たに作成された場合、対応部門部２０４ではこれらの改善策等を実施することが必要であるかを判断する（ステップＳ３１０）。たとえば改善データベース２４２内にすでに格納されている改善策であっても、ソフトウェアのバージョンアップのように顧客側の対処で不具合を解消できるものですでにそのような不具合解消のためのソフトウェアがホームページで公開されているような場合には対応部門部２０４で改善策を新たに実施する必要はない。改善策等を実施することが必要であると判断された場合には（ステップＳ３１０：Ｙ）、対応部門部２０４で改善策の実施が指示される（ステップＳ３１１）。
【００５９】
この改善策の実施には期限が付けられており、期限内に改善策の実施が終了していなければ（ステップＳ３１２：Ｎ）、アラームが発せられる（ステップＳ３１３）。この場合、ステップＳ３０９に戻って改善期限等のデータの記入が行われる。先に示した改善策に問題があって実施が期限まで終了しなかったような場合には、改善策を見直すことも可能である。以上のようにして改善策の実施が終了したら（ステップＳ３１２：Ｙ）、計画データベース２３１内のその案件についての全データを改善データベース２４２に移動させて（ステップＳ３１４）、その案件についての処理を終了させる（リターン）。ステップＳ３１０で改善実施が必要ではないと判別された場合も（Ｎ）、計画データベース２３１内のその案件についての全データを改善データベース２４２に移動させて（ステップＳ３１４）、その案件についての処理を終了させる（リターン）。
【００６０】
＜発明の変形可能性＞
【００６１】
以上説明した実施例では問合せ窓口部２０２の対応履歴データベース２１３に一度格納された案件ごとのデータを改善計画検討部２０３内の計画データベース２３１に格納することにしたが、問合せ窓口部２０２と改善計画検討部２０３を一体的に構成して、たとえば対応履歴データベース２１３を各部門の共有のデータベースとして用いるようにしてもよい。
【００６２】
また実施例では苦情を呈した顧客の顧客端末２０９に改善計画検討部２０３内の情報提供部２３２が改善策を提示するようにしたが、対応部門２０４の担当した対応部２４１が電子メール等の通信手段を使用してその顧客端末２０９に直接改善策等を知らせるようにしてもよい。
【００６３】
【発明の効果】
以上説明したように請求項１記載の発明によれば、改善要求に対して適切な対応を行うことができる対応部門に改善要求に対する処理を委ねるようにしたので、一種の分散処理としての効果と処理の高品質化を図ることができる。しかも要約を用いて検索処理を行うので、省力化を図ることができ、この意味でも迅速な対応が可能になる。更にこのような迅速な対応によって、顧客に提供する商品もしくはサービス等の改善状況に対する関心を高めさせる効果を生じさせる。また、顧客単位での改善貢献度やコストが従来に比べより明確になり、個々の顧客に対する接客を手助けするものになることが可能となる。
【００６４】
また、請求項２記載の発明によれば、改善策の実行に期限を区切ったので、たとえば期限内に改善ができない場合の問題点を出すことで改善策に対してもフィードバック制御が可能になる。また、担当者に改善策を一定期間内に検討することを習慣化させることが可能になる。
【００６５】
更に請求項３記載の発明によれば、改善要求に対応した担当者レベルでホームページの更新が可能であり、専用のスタッフがホームページを定期的に編集する場合と比べて、必要な改善策等の迅速な開示が可能である。また、作業等が自動化されるため、担当者の工数の削減を図ることができる。
【００６６】
また、請求項４記載の発明によれば、要約から抽出されるキーワードの数が少ないような場合で改善データベース内の要約との間で一致するキーワードが見つからなかったような所定の場合には、たとえば担当部門の判断で改善要求情報格納手段に格納された要約以外の改善要求情報を照合の対象として照合対象を拡大できるので、蓄積した資産を効率的に活用することができる。また、要約で最初の照合作業を行うことで全体としての処理の効率化を図ることができる。
【００６７】
更に請求項５記載の発明によれば、要約から抽出したキーワードを使用する数を調整可能としたので、過去の改善要求情報とその改善策を選択する対応部門の負荷を減少させることができ、迅速な対応が可能になる。
【００６８】
また、請求項６記載の発明によれば、改善策実行指示手段による改善策の実行が完了したときにデータベースの更新を行うようにしたので、改善のために採られた改善策でうまくいかなかったようなものをデータベースに組み込むのを排除することができ、信頼性の高いデータベースを構築することができる。
【図面の簡単な説明】
【図１】本発明の一実施例における改善状況フィードバックシステムの概要を表わしたシステム構成図である。
【図２】本実施例の対応履歴データベースの内容の一部を示した説明図である。
【図３】本実施例の改善状況フィードバックシステムの処理の流れの概要を示した流れ図である。
【図４】従来提案された苦情処理システムの概要を示したシステム構成図である。
【図５】提案の苦情処理方法による処理の流れを示した流れ図である。
【符号の説明】
２０１  改善状況フィードバックシステム
２０２  問合せ窓口部
２０３  改善計画検討部
２０４  対応部門部
２０７  ウェブサーバ部
２０８  一般顧客端末群
２０９  顧客端末
２１２  受付部
２１３  対応履歴データベース（ＤＢ）
２２１  要約テーブル
２２２  キーワードテーブル
２２３  問合せ内容
２３１  計画データベース（ＤＢ）
２３２  情報提供部
２３３  キーワード抽出部
２３４  送信処理部
２３５  アラーム部
２４１  対応部
２４２  改善データベース（ＤＢ）
２４３  顧客データベース（ＤＢ）
【図１】
2004310321.tif 000003
【図２】
2004310321.tif 000004
【図３】
2004310321.tif 000005
【図４】
2004310321.tif 000006
【図５】
2004310321.tif 000007