(57)【要約】【課題】ユーザ等に依存して選択される両立しないＦＡＱエントリを活用し、ユーザがＦＡＱホームページに到達した事情に基づいて検索結果を変動させ、メール等による問い合わせをも効率化するＦＡＱシステムを提供すること。【解決手段】ＦＡＱデータを２以上のカテゴリに分類し、検索対象のカテゴリを決定する検索対象選択機能が選択したカテゴリのみのＦＡＱエントリを対象に検索することによって、ユーザ等に依存して選択される両立しないＦＡＱエントリを活用し、ユーザがＦＡＱホームページに到達した事情に基づいて検索結果を変動させることができる。問合せホームページにおいて、ユーザが入力した質問の要約に基づいてＦＡＱエントリを検索することで、問合せへの人手による回答を行わない、回答を担当する担当オペレータを適切に決定するといった効率化を実現する。【選択図】図１
2013054413.tif 000002
【特許請求の範囲】
【請求項１】
ユーザがホームページにおいて検索文字列を入力してＦＡＱエントリを閲覧することができるＦＡＱシステムであって、
ＦＡＱデータを２以上のカテゴリに分類し、
検索対象のカテゴリを決定する検索対象選択機能を備え、
前記検索対象選択機能が選択したカテゴリのみのＦＡＱエントリを対象に検索した結果のＦＡＱを表示する、又は、前記検索対象選択機能が選択したカテゴリのＦＡＱエントリを検索結果リストの上位に表示することを特徴とする、ＦＡＱシステム。
【請求項２】
前記検索対象決定機能は、少なくとも、ＦＡＱホームページへのナビゲーション元のホームページに基づいて検索対象のカテゴリを決定することを特徴とする、請求項１に記載のＦＡＱシステム。
【請求項３】
前記ナビゲーション元のホームページは、ＦＡＱホームページを運営する企業がその企業の提供する商品又は役務を紹介するホームページであることを特徴とする、請求項２に記載のＦＡＱシステム。
【請求項４】
前記検索対象決定機能は、少なくとも、ユーザの属性に基づいて検索対象のカテゴリを決定することを特徴とする、請求項１〜３のいずれか１項に記載のＦＡＱシステム。
【請求項５】
前記ユーザの属性は、そのユーザがＦＡＱホームページを運営する企業から購入した商品又は役務に関する情報を含むことを特徴とする、請求項４に記載のＦＡＱシステム。
【請求項６】
ＦＡＱエントリの検索結果を表示した状態において、ユーザが結果に満足したか否かを入力することができ、
不満足との入力であった場合には問合せホームページにナビゲートすることを特徴とする、請求項１〜５のいずれか１項に記載のＦＡＱシステム。
【請求項７】
前記問合せホームページは、ユーザが質問の要約と詳細とを入力するものであり、要約を入力しない場合には詳細を入力することができず、
要約に入力された情報を詳細のみに入力された情報よりも高いウエイトとして前記ＦＡＱエントリの検索を行ってその結果を表示し、
その表示においてユーザが結果に満足したか否かを入力することができ、
不満足との入力であった場合には問い合わせを受け付けることを特徴とする、請求項６に記載のＦＡＱシステム。
【請求項８】
前記問合せホームページは電話番号を入力するものであり、
前記要約に基づいて回答を担当する担当オペレータを決定し、
前記電話番号から着信した電話を前記担当オペレータに転送することを特徴とする、請求項７に記載のＦＡＱシステム。
【請求項９】
前記ＦＡＱホームページは、ユーザが入力した検索文字列を含むＦＡＱ状況データを前記オペレータに送信するＦＡＱ状況通知機能と、前記オペレータからのメッセージを表示するメッセージ表示機能とを備えることを特徴とする、請求項１〜８のいずれか１項に記載のＦＡＱシステム。
【請求項１０】
前記ＦＡＱ状況通知機能は、前記ＦＡＱ状況データに基づいてユーザのヘルプ必要度を計算し、前記ヘルプ必要度の高いユーザに係るＦＡＱ状況データを前記オペレータに送信することを特徴とする、請求項９に記載のＦＡＱシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＦＡＱ（Frequently Asked Question）を検索して表示し、ユーザからの質問を受け付けるＦＡＱシステムに関するものである。
【背景技術】
【０００２】
企業のホームページには、ＦＡＱを含むことが多い。ＦＡＱには、以下の効果が期待される。（１）商品を購入したユーザに対して情報を提供してユーザが電話、メール等によって企業に質問をしなくても済むようにする。（２）商品を購入しようとするユーザに対してそのユーザの興味に合わせた情報を提供して商品の購入を促す。
ＦＡＱは、質問と回答の組み（以下「ＦＡＱエントリ」と言う。）から構成されるが、ＦＡＱの情報を効率的に提供するために、ＦＡＱエントリをテーマ等に基づいて階層化することや、ユーザが入力するキーワード等を用いてＦＡＱエントリを検索させることが行われている。
ユーザの立場では、ＦＡＱについて、メールや電話による問合せよりも便利に感じることが多い。メールのように説明文を入力する必要がなく、電話の問合せと異なり自己の都合の良い時間に使用できるからである。
【０００３】
ここで、階層や検索結果を工夫してＦＡＱによってユーザの求める情報を提示する可能性を高める方法が開示されている。特許文献１には、検索結果のＦＡＱエントリを表示する際に、そのＦＡＱエントリによって問題が解決したか否かについての入力をユーザに求め、その回答に基づいて問題を解決する可能性の高いＦＡＱエントリを検索結果の上位にする方法が開示されている。特許文献２には、ユーザがＦＡＱデータ内をナビゲートした履歴に基づいて階層構造を最適化する方法が開示されている。特許文献３には、そのユーザの過去の質問履歴に基づいて階層及び検索結果の順位を調整する方法が開示されている。
ＦＡＱによってユーザの求める情報を提示することにより、ユーザは電話、メール等によって企業に質問をせずに済み、企業の立場では電話、メール等の応答に要するコストが軽減される。
【０００４】
ＦＡＱエントリは、電話、メール等による質問に回答する際にも活用できる。企業において電話、メール等による質問に回答する担当者がＦＡＱデータ（全てのＦＡＱエントリの集合）を参照することは当然に行われている。ＦＡＱホームページと、電話、メール等による質問への回答とを一体化してＦＡＱデータを運用することも行われ、特許文献４には、電話、メール等を含む応答記録に基づいてＦＡＱデータを構築する方法が開示されている。
【０００５】
以上のように、ＦＡＱデータを効率的に作成、運用して、サービスを向上し、ユーザの満足度を向上させつつ、質問対応のコストを削減する方法が、各種開示されている。しかし、以下に述べる問題及び要望を解決するものは知られていなかった。
同じ質問であっても、ユーザに依存して２つ以上の回答が考えられ、これらの回答が両立しない場合がある。例えば、ソフトウェアの使用法の質問に対し、オプション機能を購入したユーザにはそのオプション機能の使い方を回答し、その他のユーザには他の機能による迂回手順を回答する場合である。この場合に両方のＦＡＱエントリが検索結果に並存するとユーザを惑わしかねず、これらのＦＡＱエントリはＦＡＱホームページにおける検索対象とすることは困難であった。
ユーザがＦＡＱホームページに到達することとなった何らかの事情があり、その事情に依存して検索結果を変動させたい場合がある。例えば、ある商品の説明のためのホームページからＦＡＱホームページにナビゲートした場合には、その商品に関するＦＡＱエントリを上位に表示したい。このように、ＦＡＱホームページにおいてユーザが入力する情報でもユーザ個人を特定する情報又は特定されたユーザに関する情報でもないような情報のみに基づいて検索結果を変動させることは、知られていなかった。
ＦＡＱによって満足な結果を得ることができずにメール等で問い合わせることとしたユーザについて、そのメール等での問合せ内容によって、そのユーザが満足するＦＡＱエントリが判明する場合がある。この場合、メール等の問い合わせに対して人手で回答しなくてもそのＦＡＱエントリをユーザに提示することで企業にとってはコスト削減になる。しかし、これを実現する具体的な方法は開示されていなかった。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１１−０９５８１１号公報
【特許文献２】特開２００９−１８７１８７号公報
【特許文献３】特開２００２−０２４２９１号公報
【特許文献４】特開２００６−１１９９９１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
解決しようとする課題は、ユーザ等に依存して選択される両立しないＦＡＱエントリを活用し、ユーザがＦＡＱホームページに到達した事情に基づいて検索結果を変動させ、ＦＡＱ利用時のユーザの満足度を向上させつつ、メール等による問い合わせをも効率化するＦＡＱシステムを提供することである。
【課題を解決するための手段】
【０００８】
本発明のＦＡＱシステムは、
ユーザがホームページにおいて検索文字列を入力してＦＡＱエントリを閲覧することができるＦＡＱシステムであって、
ＦＡＱデータを２以上のカテゴリに分類し、
検索対象のカテゴリを決定する検索対象選択機能を備え、
前記検索対象選択機能が選択したカテゴリのみのＦＡＱエントリを対象に検索した結果のＦＡＱを表示する、又は、前記検索対象選択機能が選択したカテゴリのＦＡＱエントリを検索結果リストの上位に表示することを特徴とする。
検索対象選択機能によって、適切なＦＡＱエントリのみの検索対象にする若しくは適切なＦＡＱエントリを検索結果リストの上位に表示する。ユーザ等に依存して選択される両立しないＦＡＱエントリについてはそのユーザに適したもののみを検索対象にすることができる。ユーザがＦＡＱホームページに到達した事情に基づいて検索対象のカテゴリを絞り込むことができる。
【０００９】
本発明のＦＡＱシステムは、
前記検索対象決定機能は、少なくとも、ＦＡＱホームページへのナビゲーション元のホームページに基づいて検索対象のカテゴリを決定することを特徴とする。
多くの企業のホームページにおいて、その中のどのホームページからもＦＡＱホームページへのナビゲーションが可能となっている。ＦＡＱホームページにアクセスする直前にどのホームページを見ていたかに係る情報は、ＦＡＱの検索において有効である。例えば、ある商品の説明のためのホームページからＦＡＱホームページにナビゲートしたユーザに対しては、その商品に関するＦＡＱエントリを上位に表示させることができる。
【００１０】
本発明のＦＡＱシステムは、
前記ナビゲーション元のホームページは、ＦＡＱホームページを運営する企業がその企業の提供する商品又は役務を紹介するホームページであることを特徴とする。
検索対象のカテゴリを、企業の商品又は役務に基づいて定めることが考えられる。この場合、ＦＡＱホームページにアクセスする直前に見ていたホームページに係る商品又は役務のカテゴリのみを検索対象とすること、そのカテゴリのＦＡＱエントリを上位に表示させることができる。
【００１１】
本発明のＦＡＱシステムは、
前記検索対象決定機能は、少なくとも、ユーザの属性に基づいて検索対象のカテゴリを決定することを特徴とする。
ここで「ユーザの属性」とは、過去の検索履歴、問合せ履歴、購入した商品又は役務、その他ユーザを同定することによって獲得される情報を言う。ユーザの属性に基づいて、そのユーザに適したカテゴリに検索対象のカテゴリを絞り込むことができる。
【００１２】
本発明のＦＡＱシステムは、
前記ユーザの属性は、そのユーザがＦＡＱホームページを運営する企業から購入した商品又は役務に関する情報を含むことを特徴とする。
購入した商品又は役務に関する情報は、そのユーザに対する回答を確定させる。例えば、ソフトウェアの使用法の質問に対し、オプション機能を購入したユーザにはそのオプション機能の使い方を回答し、その他のユーザには他の機能による迂回手順を回答する場合である。そのユーザに適した回答のみを検索結果として表示することができる。
【００１３】
本発明のＦＡＱシステムは、
ＦＡＱエントリの検索結果を表示した状態において、ユーザが結果に満足したか否かを入力することができ、
不満足との入力であった場合には問合せホームページにナビゲートすることを特徴とする。
ＦＡＱエントリの検索結果に不満足なユーザのみを問合せホームページに誘導することにより、ＦＡＱホームページを介して問合せ数を減少させ、企業にとってのコスト削減を図ることができる。
【００１４】
本発明のＦＡＱシステムは、
前記問合せホームページは、ユーザが質問の要約と詳細とを入力するものであり、要約を入力しない場合には詳細を入力することができず、
要約に入力された情報を詳細のみに入力された情報よりも高いウエイトとして前記ＦＡＱエントリの検索を行ってその結果を表示し、
その表示においてユーザが結果に満足したか否かを入力することができ、
不満足との入力であった場合には問い合わせを受け付けることを特徴とする。
ＦＡＱエントリの検索結果に不満足なユーザであっても、問合せホームページにおいて入力される問合せ内容によって、そのユーザが満足するＦＡＱエントリが判明する場合がある。この場合、メール等の問い合わせに対して人手で回答しなくてもそのＦＡＱエントリをユーザに提示することができる。企業にとっては、問合せへの人手による回答を行わないことができ、コスト削減になる。
この際、平文のテキストデータであることが多いユーザによる質問を分析してＦＡＱエントリの検索条件式を生成することになる。テキストデータから形態素解析等によって名詞を抽出しそれを検索のキーワードとすることが多い。ユーザによる質問の詳細には、背景事情の説明など必ずしも検索のキーワードとしては適切でない名詞を含む部分も多い。そこで、ユーザに質問の要約を入力させ、要約に現れる名詞のウエイトを高くして検索すると効率がよい。このために、要約を入力しない場合には詳細を入力することができないようにする。なお、名詞を抽出せずに他の処理によって検索条件式を生成する場合にも、要約に入力された情報を詳細のみに入力された情報よりも高いウエイトとすることで効果が期待できる。
【００１５】
本発明のＦＡＱシステムは、
前記問合せホームページは電話番号を入力するものであり、
前記要約に基づいて回答を担当する担当オペレータを決定し、
前記電話番号から着信した電話を前記担当オペレータに転送することを特徴とする。
問合せホームページおいて、ユーザは、メールによる回答を求める場合も電話による回答を求める場合もある。メールによる回答の場合又は電話による回答であって企業側からユーザに発信する場合には、企業側は質問内容に対応して適切な担当オペレータが回答することができる。電話による回答であってユーザから企業側に発信する場合には、企業に着信した際の発信者番号によって適切な担当オペレータを選定することができる。これは、ユーザによる質問の要約によってＦＡＱエントリを検索することで可能となる。検索結果のＦＡＱエントリに基づいて担当オペレータを決定することができるからである。
【００１６】
本発明のＦＡＱシステムは、
前記ＦＡＱホームページは、ユーザが入力した検索文字列を含むＦＡＱ状況データを前記オペレータに送信するＦＡＱ状況通知機能と、前記オペレータからのメッセージを表示するメッセージ表示機能とを備えることを特徴とする。
オペレータが、電話による対応をせずにＦＡＱ状況データに基づいてユーザに対するガイダンスを行うことができ、オペレータの作業量を削減しつつユーザの満足度を向上させることができる。
【００１７】
本発明のＦＡＱシステムは、
前記ＦＡＱ状況通知機能は、前記ＦＡＱ状況データに基づいてユーザのヘルプ必要度を計算し、前記ヘルプ必要度の高いユーザに係るＦＡＱ状況データを前記オペレータに送信することを特徴とする。
例えば、検索を繰り返しているユーザは、ＦＡＱにおいて有効な情報を得ることができておらず、オペレータからのメッセージによってそのユーザをガイドし、ユーザの不満を解消して満足度を向上させられる可能性が高い。このようにオペレータからのメッセージが有効であるか否かの予測値を「ヘルプ必要度」として定量化する。限られた人数のオペレータによって、オペレータからのメッセージが有効なユーザに対し集中的にサポートすることができる。
【発明の効果】
【００１８】
本発明のＦＡＱシステムは、ユーザ等に依存して選択される両立しないＦＡＱエントリを活用し、ユーザがＦＡＱホームページに到達した事情に基づいて検索結果を変動させ、メール等による問い合わせをも効率化する。
ＦＡＱデータを２以上のカテゴリに分類し、検索対象のカテゴリを決定する検索対象選択機能が選択したカテゴリのみのＦＡＱエントリを対象に検索することによって、ユーザ等に依存して選択される両立しないＦＡＱエントリを活用し、ユーザがＦＡＱホームページに到達した事情に基づいて検索結果を変動させることができる。
問合せホームページにおいて、ユーザが入力した質問の要約に基づいてＦＡＱエントリを検索することで、ＦＡＱ利用時のユーザの満足度を向上させつつ、問合せへの人手による回答を行わない、回答を担当する担当オペレータを適切に決定するといった効率化を実現する。
【図面の簡単な説明】
【００１９】
【図１】図１は、ＦＡＱシステムの構成を示す図である。
【図２】図２は、ＦＡＱシステムの主要なフローを示す図である。
【図３】図３は、検索機能のフローを示す図である。
【図４】図４は、表示順位決定のフローを示す図である。
【図５】図５は、問合せ入力機能の画面を示す図である。
【図６】図６は、ＦＡＱホームページの表示の例を示す図である。
【図７】図７は、検索結果リストの表示の例を示す図である。
【図８】図８は、個別のＦＡＱエントリの表示の例を示す図である。
【図９】図９は、ＦＡＱ状況通知機能のフローを示す図である。
【図１０】図１０は、メッセージ表示の例を示す図である。
【発明を実施するための形態】
【００２０】
以下に、本発明のＦＡＱシステムの実施例を示す。システムの構成及び主要なフローは各実施例で共通であるので、実施例に先だって説明する。
【００２１】
図１は、ＦＡＱシステムの構成を示す図である。ＦＡＱホームページ１及び問合せホームページ２が運用され、ユーザに公開されている。検索処理部３は、ＦＡＱホームページ１及び問合せホームページ２における入力に基づいてＦＡＱの検索を実行する。問合せ対応処理部４は、ＦＡＱホームページ１及び問合せホームページ２においてＦＡＱでは十分に対応できないことが判明した問合せに対応するための問合せデータ４２を保存する。ＦＡＱホームページ１は、オペレータ向け処理部５との間で情報の送受信を行う。ここで、ＦＡＱホームページ１、問合せホームページ２、検索処理部３、問合せ処理部４及びオペレータ向け処理部５は１つのホームページサーバに配置することができる。ユーザの端末装置がＦＡＱホームページ１及び問合せホームページ２にアクセスし、オペレータの端末装置がオペレータ向け処理部５にアクセスする。
【００２２】
ＦＡＱホームページ１には、検索条件設定機能１１、検索結果表示機能１２、ＦＡＱ状況通知機能１３、メッセージ表示機能１４及び満足度取得機能１５が設けられている。
問合せホームページ２には、問合せ入力機能２１及び問合せ処理機能２２が設けられている。
検索処理部３には、検索機能３１が設けられている。検索機能３１がＦＡＱデータ３２を検索するが、ＦＡＱデータ３２は、カテゴリ３３ａ、３３ｂ、３３ｃに区分されており、各カテゴリにＦＡＱエントリが含まれている。なお、図ではカテゴリの数が３つであるが、２つ以上のいくつであってもよい。また、ＦＡＱエントリは１つのみのカテゴリに属さずに２つ以上のカテゴリに属してもよい。このため、ＦＡＱエントリのデータをカテゴリに区分して保存するのでなく、各ＦＡＱエントリに１つ又は２つ以上のカテゴリを表すプロパティを付してもよい。
問合せ処理部４には、問合せ対応機能４１が設けられている。問合せ対応機能４１は、問合せデータ４２を作成、更新、削除する。
オペレータ向け処理部５には、ＦＡＱ状況監視機能５１及びメッセージ送信機能５２が設けられている。
【００２３】
ＦＡＱホームページ１及び問合せホームページ２における機能の実装は、ｊａｖａｓｃｒｉｐｔ、ｐｈｐ等によることができる。検索機能３１及び問合せ対応機能４１についても、これらのホームページから呼び出される機能であり、ｊａｖａｓｃｒｉｐｔ、ｐｈｐ等による実装が可能である。ＦＡＱ状況監視機能５１及びメッセージ送信機能５２についても、オペレータの端末装置がアクセスするホームページを作成すればｊａｖａｓｃｒｉｐｔ、ｐｈｐ等による実装が可能である。全ての機能がｊａｖａｓｃｒｉｐｔ、ｐｈｐ等による実装が可能である点につき、以下、本明細書において同様である。
【００２４】
図２は、ＦＡＱシステムの主要なフローを示す図である。ここでは、ＦＡＱホームページ１、問合せホームページ２及び検索処理部３のフローについて説明する。問合せ処理部４及びオペレータ向け処理部５のフローについては、実施例の中で説明する。また、ＦＡＱホームページ１のフローのうち、ＦＡＱ状況通知機能１３及びメッセージ表示機能のフローについても実施例の中で説明する
図において、問合せホームページ２及び検索処理部３における処理は、点線で囲んで示してある。点線に囲まれていない部分は、ＦＡＱホームページ１における処理である。
【００２５】
ユーザが他のホームページからＦＡＱホームページ１に移動することによって、処理が開始される。
最初に検索条件設定機能１１が起動される。検索条件設定機能１１は、ナビゲーション元情報（ＦＡＱホームページ１に移動する直前にブラウズされたホームページが何であるかを表す情報）を取得する。ナビゲーション元情報は、例えばｐｈｐのパラメータとしてＦＡＱホームページに送信することができる。検索条件設定機能１１は、図示しない画面においてユーザＩＤの入力を受付ける、アクセスしているＩＰアドレスに基づいて求める、その他の方法によってユーザＩＤを取得する。ナビゲーション元情報及びユーザＩＤの取得は、必要に応じて行えばよく、必ずしも行われなくてもよい。
検索条件設定機能１１は、ユーザの入力する検索文字列を取得する。その後、検索ボタンのクリックにより、検索機能３１を呼び出す。検索機能３１へは、検索文字列、ナビゲーション元情報及びユーザＩＤが送信される。
【００２６】
図３は、検索機能のフローを示す図である。検索機能３１は、検索文字列、ナビゲーション元情報及びユーザＩＤに基づいて検索を実行する。検索においては検索条件式を作成するが、その際、ＦＡＱエントリに含まれるべき文字列及び検索対象のカテゴリを指定する。
ＦＡＱエントリに含まれるべき文字列については、ユーザによる入力から文字列を導出するための通常の処理を用いればよい。例えば、ユーザの入力した検索文字列が単語の羅列である場合にはそれらの単語をＦＡＱエントリに含まれるべき文字列とし、単語の羅列でない場合にはユーザの入力した検索文字列を形態素解析して名詞を抽出し、抽出された名詞をＦＡＱエントリに含まれるべき文字列とすることができる。
検索対象選択機能によって検索対象のカテゴリを指定することが、本発明の特徴である。検索機能３１は、検索対象カテゴリを規定値に設定し、それに対してナビゲーション元情報及びユーザＩＤに基づく検索対象カテゴリの調整を行う。最初に検索対象カテゴリを既定値に設定するが、これにより、ユーザが購入済みの商品に依存する等の全てのユーザに提示することが好ましくないＦＡＱエントリを検索対象から除外することができる。その上で、ナビゲーション元情報によるカテゴリ限定（例えば、ナビゲーション元のホームページが特定の商品に関する情報を提供するページであった場合に、その商品に関するカテゴリに限定する）、及び、ユーザ固有のカテゴリの追加（例えば、そのユーザが購入した商品が判明した場合に、その商品に依存するカテゴリを追加する）を行う。カテゴリの指定は、検索条件式（例えばＳＱＬ）に反映される。
【００２７】
検索条件式を用いて検索し、検索結果の表示順位を決定する。図４は、表示順位決定のフローを示す図である。検索条件式決定におけるカテゴリの限定・追加に替えて、ＦＡＱエントリのカテゴリに対応した点数を用いて表示順位を決定してもよい。
以上が、検索機能３１のフローである。
【００２８】
図２に示すとおり、検索機能３１による検索の結果は、検索結果リストとして表示される。この表示は、検索結果表示機能１２によって行われる。検索結果表示機能１２は、検索結果リストからユーザが選択した個別のＦＡＱエントリを表示する。
【００２９】
個別のＦＡＱエントリを表示する画面においては、ユーザがＦＡＱの結果に満足したか否かを入力することができる。この入力は、満足度取得機能１５により提供される。
満足度取得機能１５は、ユーザが不満である旨の入力を行った場合には問合せホームページ２へのナビゲートを実行する。
【００３０】
問合せホームページ２では、ナビゲートされた際に、問合せ入力機能２１が起動される。図５は、問合せ入力機能の画面を示す図である。要約６１、詳細６２、メールアドレス及び電話番号の入力欄が設けられている。メールアドレス及び電話番号は、ＦＡＱによらない処理のために問合せ処理部４に送られるためのデータである。
問合せ入力機能２１は、要約６１に入力がない場合には詳細６２の入力を受け付けない。要約又は詳細のいずれか一方に入力しなければ問合せの質問が入力できないため、ユーザにとって、要約６１の入力が必須となる。
ユーザが送信ボタンをクリックすると、問合せ入力機能２１は、要約６１及び詳細６２に入力された文字列を、検索機能３１に送信する。問合せ処理機能２２は、問合せ対応機能４１を起動してその問合せに係る問合せデータ４２を作成する。この際、問合わせデータ４２としては、「問合せがあった」旨が記録され、「メール、電話等による対応を行うべき」旨は記録されない。
【００３１】
検索機能３１は、問合せ入力機能２１から送信された文字列に基づいてＦＡＱデータを検索する。この際、要約に入力された文字列に基づく検索結果を詳細のみに入力された文字列に基づく検索結果よりも高いウエイトで取り扱う。具体的には、（１）要約に入力された文字列のみに基づく検索を行う、（２）要約に入力された文字列に基づく検索と詳細に入力された文字列に基づく検索とを行い、前者の検索結果に対して後者の検索結果よりも高い点数を与える、その他の方法とすればよい。
【００３２】
検索機能３１は、問合せ入力機能２１から送信された文字列に基づいてＦＡＱデータを検索する際に、そのユーザが検索条件設定機能１１によって設定した条件（カテゴリ、ユーザＩＤ）を用いてカテゴリの限定、追加又は点数の調整を行ってもよい。
また、そのユーザが以前に検索して表示したＦＡＱエントリを記憶しておき、これらのＦＡＱエントリを検索結果から削除してもよい。
以上は、問合せ入力機能２１から送信された文字列に基づくＦＡＱデータの検索が、ユーザ自身が設定した検索文字列では不満であったことに起因して、新たな検索結果をユーザに提示する目的であるための措置である。
【００３３】
上記新たな検索結果は検索結果表示機能１２に送信され、表示される。これにより満足度取得機能１５が起動される。この際、問合せ入力機能２１から送信された文字列に基づく検索結果である旨が合わせて送信されている。
満足度取得機能１５は、問合せ入力機能２１から送信された文字列に基づく検索結果である場合には、「満足」又は「不満」の入力を問合せ処理機能２２に送信する。問合せ処理機能２２は、「満足」の場合には問合せ対応機能４１を起動してその問合せに係る問合せデータ４２を削除する。「不満」の場合には問合せ対応機能４１を起動してその問合せに係る問合せデータ４２についてメール、電話等による対応を行うための処理を行う。
メール、電話等による対応は、オペレータが行うが、問合せの内容やユーザＩＤに基づいて担当のオペレータを決定することができる。この決定は、オペレータのスキル等のデータを利用する従来から知られた方法によって行えばよい。また、入力された電話番号から着信した電話を担当するオペレータに転送することも、従来から知られた方法によって実行できる。
【実施例１】
【００３４】
本実施例は、ナビゲーション元情報に基づくカテゴリの限定を行うものである。
【００３５】
パスタ、うどん、ラーメンの麺類及びこれらと共に食する食材を販売する会社のホームページにおいて、本発明のＦＡＱシステムを活用する。
図６は、ＦＡＱホームページの表示の例を示す図である。左側にはカテゴリとして「パスタ」「うどん」及び「ラーメン」が表示されている。ユーザは、表示されたカテゴリをクリックして検索対象のカテゴリを限定することができる。
【００３６】
ユーザは、その会社のパスタを紹介するホームページ（図示しない）において、「よくある質問」のボタンをクリックしてＦＡＱオームページに移動した。その後、右上の検索文字列入力エリアに「辛い」との検索文字列を入力し、検索ボタンをクリックした。
【００３７】
検索条件設定機能１１は、ナビゲーション元情報として「パスタを紹介するホームページ」を表す情報を取得する。
検索は、「パスタ」「うどん」及び「ラーメン」の３つのカテゴリのうちの「パスタ」に限定して行われる。
図７は、検索結果リストの表示の例を示す図である。パスタに関するＦＡＱエントリである「アラビアータ・ソース」及び「ペペロンチーノ・ソース」が表示されている。「辛い」との検索文字列にヒットする「カレーうどん」「タンタン麺」は、カテゴリが限定されるために表示されていない。
このように、ユーザは、自分の欲する検索結果を得ることができ、そのために追加的な入力を行う必要がない。
【００３８】
図８は、個別のＦＡＱエントリの表示の例を示す図である。検索結果リストの表示においてユーザが「アラビアータ・ソース」をクリックすることで、この画面が表示される。
画面下部には、満足度取得機能１５による表示がされており、ユーザは「満足」又は「不満」をクリックする。「不満」がクリックされた場合には問合せホームページ２に移動し、上述のとおりの処理が行われる。
【実施例２】
【００３９】
本実施例は、ユーザＩＤに基づくカテゴリの限定を行うものである。
【００４０】
会員に対して低価格の宿泊サービスを提供する会員制ホテルチェーンにおける、会員向けのホームページにおいて、本発明のＦＡＱシステムを活用する。
ＦＡＱエントリは、各々のホテルについて設けられている。カテゴリは、ＦＡＱエントリのプロパティとして、以下のものが設定されている。（１）室の種類（シングル、ダブル、トリプル等の別）、（２）各ホテルに併設されているレストランの種類（和食、中華、フレンチ、イタリアン等）。
【００４１】
ユーザは、図示しない画面においてユーザＩＤを入力する。その後、ＦＡＱホームページに移動する。
検索条件設定機能１１は、入力されたユーザＩＤに基づいてそのユーザに適したカテゴリを探す。本実施例においては、そのユーザの過去の宿泊履歴に基づき、室の種類がトリプルであるカテゴリを優先すべきことを発見する。
【００４２】
ユーザは、検索文字列として「中華料理」を入力し、検索ボタンをクリックする。
検索機能３１は、カテゴリの限定を行わずにＦＡＱデータを検索し、室の種類がトリプルであるカテゴリのＦＡＱエントリに高い点数を与えて表示順位を決定する。
トリプルの室を有し、中華料理のレストランが併設されているホテルが上位に表示されるので、ユーザが満足する可能性が高い。また、トリプルの室を有さず中華料理のレストランが併設されているホテルについても、下位には表示されるので、ユーザの状況の変化にも対応できる。
【実施例３】
【００４３】
本実施例は、ＦＡＱ状況及びメッセージの処理を行うものである。
【００４４】
コンピュータ周辺機器及びソフトウェアを販売している会社における、購入者向けのホームページにおいて、本発明のＦＡＱシステムを活用する。
コンピュータ周辺機器及びソフトウェアについては、互換性やバージョン間の差異の問題があり、ユーザが効率的にＦＡＱを活用できない場合があると考えられる。
この問題に対応するため、ＦＡＱデータは、各製品の機能によってカテゴリに分けられている。検索機能３１は、ユーザが購入した製品が提供する機能に係るカテゴリのＦＡＱエントリを上位に表示する。ユーザは、自己が所有する製品の機能について効率的にＦＡＱを活用することができる。
【００４５】
ユーザは、図示しない画面においてユーザＩＤを入力する。その後、ＦＡＱホームページに移動する。
図９は、ＦＡＱ状況通知機能のフローを示す図である。
図の左側のとおり、ＦＡＱの操作をユーザが開始した時刻及び検索を行った回数のデータが、ユーザ毎に保存される。
図の右側の処理を、定期的に、所定の時間間隔（例えば１分間隔）で実行する。各ユーザについて、滞在時間（ＦＡＱを使用し続けている時間）ｔ及び検索回数ｓを求め、そのユーザのヘルプ必要度を計算する。ヘルプ必要度の高いユーザについては、担当オペレータを決定し、その担当オペレータに係るＦＡＱ状況監視機能５１を起動して、担当オペレータがそのユーザのＦＡＱの状況を把握し、必要に応じてメッセージを送信できるようにする。なお、担当オペレータの決定は、ユーザＩＤに基づいて、ユーザ毎に予め決められた担当オペレータとする、ユーザが購入した商品についての知識を持つオペレータを担当オペレータとする、その他の方法によることができる。
【００４６】
ヘルプ必要度は、ｓ及びｔの値に基づいて計算する。ｓ、ｔ共にその値が大きいほどユーザが困惑していると考えられる指標である。ここで、ヘルプ必要度ｆ（ｓ，ｔ）を計算するに当たり、ｓ及びｔをどのように斟酌するかについては、各会社の事情に対応して設計すればよい。例えば、（１）検索を繰り返すユーザは困惑しているとしてｔの値をヘルプ必要度とする、（２）長時間にわたってＦＡＱを使用しているユーザは困惑しているとしてｓの値をヘルプ必要度とする、（３）上記（１）及び（２）を総合的に考慮してｓ及びｔに重みをつけて加算した値をヘルプ必要度とする、（４）検索の頻度の高いユーザは困惑しているとしてｓ／ｔの値をヘルプ必要度とする、ことができる。
【００４７】
ユーザは、以前のバージョンのＦＡＸ付きプリンタを購入した者である。送信先の一覧をファイル形式で保持し一括で送信する「ＦＡＸ一括送信」機能についての情報を得ようとしてる。しかし、ユーザが購入したプリンタにはＦＡＸ一括送信機能がないため、ＦＡＸ一括送信機能に係るカテゴリのＦＡＱエントリは上位に表示されない。
担当オペレータは、ＦＡＱ状況監視機能５１でユーザが検索を繰り返していることに気づく。また、そのユーザが購入したプリンタにはＦＡＸ一括送信機能がないことを知っている。担当オペレータは、メッセージ送信機能５２を起動し、そのユーザが購入したプリンタにはＦＡＸ一括送信機能がない旨のメッセージを送信する。
図１０は、メッセージ表示の例を示す図である。メッセージ表示機能１４により、困惑しているユーザの画面にメッセージが表示される。ユーザは、結論を容易に知ることができる。
【産業上の利用可能性】
【００４８】
ユーザ等に依存して選択される両立しないＦＡＱエントリを活用し、ユーザがＦＡＱホームページに到達した事情に基づいて検索結果を変動させ、メール等による問い合わせをも効率化するＦＡＱシステムであり、多くの企業による活用が期待できる。
【符号の説明】
【００４９】
１    ＦＡＱホームページ
１１  検索条件設定機能
１２  検索結果表示機能
１３  ＦＡＱ状況通知機能
１４  メッセージ表示機能
１５  満足度取得機能
２    問合せホームページ
２１  問合せ入力機能
２２  問合せ処理機能
３    検索処理部
３１  検索機能
３２  ＦＡＱデータ
３３  カテゴリ
４    問合せ処理部
４１  問合せ対応機能
４２  問合せデータ
５    オペレータ向け処理部
５１  ＦＡＱ状況監視機能
５２  メッセージ送信機能
６１  要約
６２  詳細
【図１】
2013054413.tif 000003
【図２】
2013054413.tif 000004
【図３】
2013054413.tif 000005
【図４】
2013054413.tif 000006
【図５】
2013054413.tif 000007
【図６】
2013054413.tif 000008
【図７】
2013054413.tif 000009
【図８】
2013054413.tif 000010
【図９】
2013054413.tif 000011
【図１０】
2013054413.tif 000012