(58)【調査した分野】(Int.Cl.,DB名)
前記顧客の基本情報が前記会員マスタDBになく、前記顧客が新規顧客と判断された場合に、前記キーワード抽出部は、前記新規顧客の氏名及び/又は住所に含まれる漢字を特定させるための漢字候補リストを前記オペレータ端末に表示させることを特徴とする請求項1又は2に記載のオペレータ本人確認支援システム。
前記キーワード抽出部は、手続き毎の確認項目を定めた手続きリストを有し、前記本人確認項目の確認後に、前記手続きリストと紐づけされた前記確認項目キーワードリストから前記手続きの確認項目を特定することを特徴とする請求項1から3までのいずれか1項に記載のオペレータ本人確認支援システム。
【発明の概要】
【発明が解決しようとする課題】
【0006】
上記の特許文献1,2に記載のシステムは、音声認識により、オペレータの業務の効率化や一部自動化をすることを目的としたものである。しかし、顧客の本人確認のために音声認識を利用するシステムはまだ知られていない。音声を用いた本人確認(本人認証)は、特許文献3に記載のような声紋認証を用いるものが一般的である。本人確認は、オペレータと顧客との決まりきったやりとりであるため、音声認識を使って自動化するまでもないと思われるが、本人確認は、顧客の言ったことをオペレータが逐次復唱する必要があり、意外と手間の掛かる作業である。音声認識技術は、最近の音声認識率の向上と、リアルタイム性の向上により、本人確認やその他の顧客との各種の確認項目のチェックの自動化にも大いに役立つものと考えられる。
【0007】
したがって、本発明では、上記のような課題に鑑み、音声認識を用いて本人確認やその他確認項目の自動チェックを行うことで、オペレータの確認作業を支援するオペレータ本人確認支援システムを提供することを目的とする。
【課題を解決するための手段】
【0008】
上記課題を解決するため、本発明のオペレータ本人確認支援システムは、以下のような解決手段を提供する。
【0009】
コールセンタにおいて、オペレータ端末と、音声認識サーバと、解析サーバとで構成されるオペレータ本人確認支援システムであって、前記音声認識サーバは、顧客及びオペレータの発話を音声認識しテキストを出力する音声認識部と、前記音声認識の結果のテキストを日時情報と共に記憶する音声認識結果テキスト記憶部と、を備え、前記解析サーバは、前記音声認識の結果のテキストを読み出し、前記顧客及び前記オペレータの発話の組に含まれる確認項目のキーワードを、予め定められた確認項目キーワードリストから抽出するキーワード抽出部と、前記抽出された確認項目のキーワードと、会員マスタDBに格納された前記顧客の会員基本情報とを突合し、両者が合致した場合に、当該確認項目の確認完了と判断するキーワード突合部と、予め定められた本人確認項目すべての確認が完了した際に、本人確認完了通知を前記オペレータ端末に表示させるオペレータ端末送信部と、
前記顧客の電話機がコールセンタからの情報受信手段を有している場合に、前記本人確認項目の突合結果を当該顧客が確認するため前記顧客の端末にも送信する顧客端末送信部と、を備えることを特徴とする。
【0010】
上記の構成によれば、音声認識によって得られた顧客とオペレータの会話のテキストデータから、本人確認項目に関するキーワードを抽出し、会員マスタデータベースにある顧客の会員基本情報と突合し、両者が合致した場合に、本人確認完了とシステムが自動的に判定するので、顧客の発話を復唱する等のオペレータの確認作業が軽減される。
また、顧客の電話機がコールセンタからの情報受信手段(例えば、電話番号だけでメッセージを受信する機能)を有していれば、顧客は、自分の電話機でも確認項目を逐次確認できるので、自分の言い間違いやオペレータの聞き間違いを即座に訂正することができる。
【0011】
コールセンタにおいて、オペレータ端末と、音声認識サーバと、解析サーバとで構成されるオペレータ本人確認支援システムであって、前記音声認識サーバは、顧客及びオペレータの発話を音声認識しテキストを出力する音声認識部と、前記音声認識の結果のテキストを日時情報と共に記憶する音声認識結果テキスト記憶部と、を備え、前記解析サーバは、前記音声認識の結果のテキストを読み出し、前記顧客及び前記オペレータの発話の組に含まれる確認項目のキーワードを、予め定められた確認項目キーワードリストから抽出するキーワード抽出部と、前記抽出された確認項目のキーワードと、会員マスタDBに格納された前記顧客の会員基本情報とを突合し、両者が合致した場合に、当該確認項目の確認完了と判断するキーワード突合部と、予め定められた本人確認項目すべての確認が完了した際に、本人確認完了通知を前記オペレータ端末に表示させるオペレータ端末送信部と、を備え
、前記キーワード突合部は、前記抽出された確認項目のキーワードと、会員マスタDBに格納された前記顧客の会員基本情報とを突合し、両者が合致しなかった場合に、確認項目キーワードを含んだ発話に続く前記顧客の発話に当該確認項目に対する返答があるかどうかを検証し、当該確認項目に対する返答がなければ、前記顧客に再度確認を求め、前記確認の結果を前記オペレータに入力させることを特徴とする。
【0012】
このようにすることで、従来の自動音声応答では不可能であった氏名や住所の漢字を正確に確認することができる。また、このような漢字の確認は、オペレータにとっても時間のかかるものなので、特に漢字知識の乏しいオペレータの負担をも軽減することができる。
【0013】
請求項3に記載の発明は、請求項1又は2に記載の発明において更に、前記顧客の基本情報が前記会員マスタDBになく、前記顧客が新規顧客と判断された場合に、前記キーワード抽出部は、前記新規顧客の氏名及び/又は住所に含まれる漢字を特定させるための漢字候補リストを前記オペレータ端末に表示させることを特徴とする。
【0014】
上記の構成によれば、顧客が新規顧客であった場合、顧客の発話から抽出されたキーワードを基に、漢字候補リストを自動的にオペレータ端末に表示するので、顧客の氏名や住所に含まれる漢字の確認作業を軽減することができる。
【0015】
請求項4に記載の発明は、請求項1〜3に記載の発明において更に、前記キーワード抽出部は、手続き毎の確認項目を定めた手続きリストを有し、前記本人確認項目の確認後に、前記手続きリストと紐づけされた前記確認項目キーワードリストから前記手続きの確認項目を特定することを特徴とする。
【0016】
上記の構成によれば、本人確認後に、顧客の本来の用件である手続き毎の確認項目に対しても、本人確認と同じ処理で確認が可能となる。
【0017】
請求項5に記載の発明は、請求項1〜4に記載の発明において更に、前記オペレータ端末送信部は、前記本人確認項目の突合結果を前記コールセンタの管理者の端末にも送信することを特徴とする。
【0018】
上記の構成によれば、オペレータの確認作業の画面を、オペレータの管理者の端末にも送信するので、管理者は、オペレータが確認作業を確実にやっているかをチェックすることができる。
【0019】
コールセンタのシステムにおいて、オペレータが顧客の本人確認をする際の作業を支援するオペレータ本人確認支援方法であって、前記コールセンタのコンピュータのいずれかが、前記顧客及び前記オペレータの発話を音声認識し、テキストを出力するステップと、前記音声認識の結果のテキストを日時情報と共に記憶するステップと、前記音声認識の結果のテキストを読み出し、前記顧客及び前記オペレータの発話の組に含まれる確認項目のキーワードを、予め定められた確認項目キーワードリストから抽出するステップと、前記抽出された確認項目のキーワードと、会員マスタDBに格納された前記顧客の会員基本情報とを突合し、両者が合致した場合に、当該確認項目の確認完了と判断するステップと、予め定められた本人確認項目すべての確認が完了した際に、本人確認完了通知を前記オペレータの端末に表示させるステップと、
前記顧客の電話機がコールセンタからの情報受信手段を有している場合に、前記本人確認項目の突合結果を当該顧客が確認するため前記顧客の端末にも送信するステップと、を実行することを特徴とする。
【0020】
上記請求項6の発明は、請求項1のオペレータ本人確認支援システムをオペレータが顧客の本人確認をする際の作業を支援するオペレータ本人確認支援方法の発明と捉えたものであり、請求項1の発明と同様な作用効果を奏する。
【発明の効果】
【0021】
本発明によれば、音声認識を用いて、本人確認項目やその他確認項目の自動チェックを行うことで、オペレータの確認作業を支援するオペレータ本人確認支援システムを提供することができる。
【発明を実施するための形態】
【0023】
以下、添付図面を参照して、本発明を実施するための形態(以下、実施形態)について詳細に説明する。なお、実施形態の説明の全体を通して同じ要素には同じ番号または符号を付している。また、機能ブロック間の矢印は、データの流れ方向、又は処理の流れ方向を表している。
【0024】
図1は、本発明のオペレータ本人確認支援システム(以下、本システムと呼ぶ)の基本概念を示す図である。本システムを備えたコールセンタには、顧客とオペレータとの会話を音声認識して、リアルタイムにテキスト変換する音声認識サーバと、テキスト変換された会話内容をキーワードに分割して解析する解析サーバが備えられている。顧客がコールセンタに電話を掛け、オペレータが電話に出ると、この音声認識及びキーワードの解析処理が自動的にスタートするようになっている。
【0025】
顧客が、コールセンタがサービスを行っている企業又は企業グループの会員であった場合には、オペレータは、まず、顧客が会員本人であるかどうかを確認する必要があるが、この確認作業を本人確認と呼んでいる。例えば、図示するように、顧客の用件が携帯電話の料金プランの変更であったとすると、オペレータは、本人確認のために、顧客の名前をフルネームで言ってもらうように要求する。そして、顧客が氏名を告げると、次に生年月日を求め、続いて郵便番号や住所の確認を求め、顧客が告げた全ての項目が会員マスタに登録された会員基本情報と合致した場合に、電話を掛けてきた顧客が会員本人であると確認する。
【0026】
この本人確認の作業は、予め決められた確認項目を順次確認していくだけの作業にもかかわらず、結構時間のかかるやりとりでもある。本システムは、この本人確認の作業をできる限り自動化することを目的としている。ただし、完全に無人化することを目指すものではなく、あくまでオペレータとの対話の中で本人確認を効率的に行うことを目的としている。機械による無味乾燥な応対より、オペレータによる応対のほうが顧客に安心感を与えられると考えるからである。例えば、機械でなくオペレータの優れているところは、悪意を持った者が本人を偽って電話している場合は、言いよどんだり、自信のない声であったり、ということがあるが、現在では、まだ機械でそこまでを判定することが一般的になっていない。しかし、生身のオペレータが対応しているとなれば、悪意を持った者も、一定の抵抗感があるはずで、犯罪防止にも有効な対応であると考えられる。
【0027】
本人確認の際には、顧客とオペレータの会話の中には決まりきったキーワードが含まれる。図の例では、顧客の用件が、料金プランの手続きであることを認識したオペレータは、顧客の本人確認を行うために、顧客の氏名等の情報を求める。このときオペレータが発した、「お名前」、「フルネーム」というキーワードを含む発話に続く顧客の応答の中には、顧客の氏名が含まれる可能性が高いことが容易に判断できる。また、オペレータの「生年月日」というキーワードを含む発話に続く顧客の応答の中には、顧客の生年月日が含まれる可能性が高いと考えられる。郵便番号や住所についても同様である。
【0028】
解析サーバは、このオペレータの発話の中のキーワードに基づいて、それに続く顧客の発話の中からこのキーワードに対応する用語(返答)を見つけ、それを会員マスタの会員基本情報の登録データと突合し、両者が合致すれば次の用件に移るようにオペレータに指示する。具体的には、オペレータの端末に本人確認項目の画面を表示し、確認が終った項目には順次チェックマークを付けるなどして、オペレータに逐次知らせる。
図1のオペレータ端末の画面では、本人確認項目として、「電話番号」、「氏名」、「生年月日」、「住所」が指定されているものとする(ただし、顧客が掛けてきた電話番号は、オペレータの端末に自動的に表示されているものとする)。これら本人確認項目すべてのチェックが完了すると、「本人確認OK!」と表示されるので、オペレータは、本人確認後の次の会話をスムーズに進めることができる。この例では、顧客の用件が料金プラン変更であることが既に分かっているので、本人確認完了後或いは完了直前に、料金プラン変更のための確認項目が自動的に表示されるようにしてもよい。
【0029】
このようにすることで、本システムによってオペレータの本人確認作業(顧客の言ったことを復唱する等の作業)の支援をすることができる。また、オペレータ端末の画面は、コールセンタ内の他の端末からも見ることができるので、本人確認を確実に行っているかを、第三者(オペレータの管理者等)が容易にチェックすることができる。
【0030】
図2は、本発明の一実施形態に係る本システムの機能ブロックを示す図である。
図2では、前図で説明した音声認識サーバと解析サーバの内部について詳細に説明する。以下では、音声認識サーバと解析サーバをまとめて、確認項目処理サーバ20と呼ぶことにする。
【0031】
確認項目処理サーバ20は、顧客端末10、オペレータ端末30、管理者端末40と、ネットワーク(LAN,インターネット)で接続され、相互に通信可能となっている。顧客端末10は、顧客の所持する固定電話機、携帯電話機、スマートフォン、又は電話機能を備えたPC(Personal Computer)である。オペレータ端末30及び管理者端末40は、コールセンタ内のネットワークで、確認項目処理サーバ20(音声認識サーバ20A及び解析サーバ20B)と接続される。オペレータ端末30は、電話機能を備えており、各オペレータの座席に設置される。管理者端末40は、オペレータの管理を行う管理者の座席に設置されている。通常、コールセンタでは、一人の管理者が10人程度のオペレータを監督しているケースが多い。
【0032】
図示するように、確認項目処理サーバ20は、機能処理部として、音声認識部21、音声認識結果テキスト記憶部22、キーワード抽出部23、キーワード突合部24、オペレータ端末送信部25、顧客端末送信部26を備えている。またデータベース(DB)として、会員マスタDB27を備え、会員基本情報27Aを格納している。また、確認項目キーワードリスト100、手続きリスト200をサーバ内の任意の記憶領域又はデータベースに記憶している。
【0033】
音声認識部21は、顧客及びオペレータの発話をリアルタイムで音声認識し、その認識結果であるテキストを出力して、顧客及びオペレータの発話の組毎に、日時情報と共に音声認識結果テキスト記憶部22に格納する。音声認識できなかった用語や複数の認識候補がある用語は、マークアップされて記憶されるようにしてもよい。また、オペレータ端末30から、必要な時には音声認識結果を表示できることが望ましい。
【0034】
キーワード抽出部23は、音声認識結果テキスト記憶部22に記憶されたテキストデータの顧客とオペレータの発話の組からキーワードを抽出する。テキストデータからキーワードを抽出する技術は、様々な公知技術があるのでここでは説明を省略する。さらに、キーワード抽出部23は、抽出されたキーワードの中に、確認項目キーワードリスト100に登録されたキーワードがあるかどうかを探索し検出する。登録されたキーワードがあれば、キーワード突合部24に処理を渡す。ここで、確認項目キーワードリスト100とは、本人確認を含む様々な確認項目のキーワード、及びその同義語、類擬語を含んだリストである。また、顧客が求める手続き毎に必要な確認項目が異なるので、手続き毎の確認項目を定義した手続きリスト200が用意される。確認項目キーワードリスト100及び手続きリスト200については具体例を後述する。
【0035】
会員マスタDB27は、会員基本情報27Aを含み、会員の氏名、生年月日、住所、電話番号等の本人確認に必要な会員の基本情報を格納している。
【0036】
キーワード突合部24は、検出されたキーワードを会員マスタDB27に格納された会員基本情報27Aの各項目名と突合し、このキーワード突合の結果、両者が合致すれば、その項目について確認完了とする。合致しなければ、オペレータに確認を依頼し、オペレータは、顧客の返答に正しい回答がない場合には、顧客に再度回答してもらうように促す。正しい回答があるのに突合結果が不一致となる場合は、音声認識のエラーとし、オペレータ自らが顧客の回答をインプットする。
【0037】
オペレータ端末送信部25は、オペレータ端末30の操作画面、及び場合によっては、管理者端末40の管理画面に対して、確認項目ごとにキーワード突合部24が処理した突合結果を表示させる。本人確認の場合は、予め定められた確認項目の確認がすべて完了した場合に、本人確認完了通知として、「本人確認OK!」とオペレータ画面に表示させる。その他の手続きの場合は、すべての確認項目が完了した時点で「手続き確認項目OK!」と表示させる。
【0038】
顧客端末送信部26は、顧客端末10が、コールセンタからの情報受信手段(例えば、スマートフォンや携帯電話機等の電話番号だけでメッセージが送れるような電話機である場合)を有している場合には、本人確認項目の突合結果を顧客の端末にも送信する。また、スマートフォンの場合、専用アプリをインストールすることで、突合結果をより簡単に見やすく表示することも可能である。
【0039】
このようにすると、顧客はオペレータの音声による確認に加え、文字情報での確認結果を自分の端末で見ることができる。例えば、漢字の同音異義語などを確認する場合には大変有効である。また、管理者にとっては、オペレータの確認作業を適宜見ることができるので、経験の少ないオペレータ等をチェックするのに有効である。
【0040】
上記の実施形態の本システムの機能構成は、あくまで一例であり、一つの機能ブロック(データベース及び機能処理部)を更に分割したり、複数の機能ブロックをまとめて一つの機能ブロックとして構成したりしてもよい。各機能処理部は、装置に内蔵されたCPU(Central Processing Unit)が、ROM(Read Only Memory)またはハードディスク等の記憶装置に格納されたコンピュータ・プログラムを読み出し、CPUにより実行されたコンピュータ・プログラムによって実現される。すなわち、各機能処理部は、このコンピュータ・プログラムが、記憶装置に格納されたデータベース(DB;Data Base)やメモリ上の記憶領域からテーブル等の必要なデータを読み書きし、場合によっては、関連するハードウェア(例えば、入出力装置、表示装置、通信インターフェース装置)を制御することによって実現される。また、本発明の実施形態におけるデータベース(DB)は、商用データベースであってよいが、単なるテーブルやファイルの集合体をも意味し、データベースの内部構造自体は問わないものとする。
【0041】
図3は、確認項目キーワードリスト100及び手続きリスト200の具体例を示す図である。コールセンタでは様々な顧客からの問合せを受けるが、定型のやりとりで済む手続きも多い。手続きリスト200には、このような定型の手続きがIDと共にリスト化されている。例えば、契約関係であれば、新規契約、契約変更、退会(解約)等である。また、住所変更等の会員の登録情報の変更や、請求金額やポイント等の各種照会である。
【0042】
手続き毎の確認項目は、登録情報変更の中の住所変更を例にとると、まず、本人確認として、カード番号やお客様番号のような顧客識別データの確認、そして、氏名、生年月日、郵便番号、住所、電話番号等の確認が必要となる。更に、本人確認終了後には、新住所や、電話番号の変更がある場合には、新電話番号を確認する必要がある。確認項目キーワードリスト100は、このような確認項目毎に、確認項目ID、確認項目名、確認項目名の同義語、類義語のキーワードを保存したテーブルである。これらのキーワードには、オペレータが発話する標準用語だけでなく、顧客が発話しそうな用語を可能な限り含んでいる。例えば、オペレータが生年月日を西暦で求めても、元号で答えるような顧客もいるため、生年月日のキーワードには元号も含んでいる。
【0043】
手続きリスト200の各手続きは、確認項目キーワードリスト100の各確認項目IDと紐づけられ対応づけられている。例えば、図の例では、住所変更の手続きの場合、確認項目IDがX01,Y05,Y06,Y07,Y08,Y09までは、本人確認の際に確認すべき項目(両テーブル間の実線で示す)であり、確認項目IDがZ10,Z11,Z12は、本人確認後に必要な確認項目(両テーブル間の点線で示す)であることを示している。手続き自体の追加や変更もよく生じるため、このような対応関係は手続き毎に存在する。なお、顧客が会員でない場合は、単なる問合せ等、本人確認を行なわずともよいものもある。
【0044】
図4は、キーワード抽出及び突合処理のフローを示す図である。この処理は、
図2のキーワード抽出部23及びキーワード突合部24によって行なわれる処理である。
【0045】
キーワード抽出部23は、まずステップS10において、確認項目キーワードリスト100を読み込む。次に、ステップS11において、オペレータの発話とそれに対応する顧客の発話を組にして、音声認識結果のテキストを読み込む。発話の組とは、質問とその質問に対する回答の組であり、必ずしも1対1の関係とは限らず、3つ、4つの発話が一つの組となることもある。そして、ステップS12において、オペレータの発話の中に確認項目キーワードリストのキーワードが含まれているかどうかをチェックする。例えば、顧客の氏名の確認であれば、「お名前」、「フルネーム」等がそのキーワードである。また、オペレータの発話の末尾に「をお願いします」、「いただけますか」等の用語がある場合には、顧客に質問をしていると判断し、その後の顧客の発話にその質問に対する返答が含まれている可能性が高いのでその前後の文字列を探索する。
【0046】
ステップS12において、オペレータの発話の中に確認項目キーワードがなければ、ステップS13に移り、今度は、顧客の発話中に確認項目キーワードがないかどうかを確認する。顧客によっては、オペレータが質問する前に、自分の氏名等を名のり始めることがあるからである。オペレータ、顧客共に確認キーワードを含む発話をしていなければ、ステップS11に戻り、次の発話の組を調べる。オペレータ又は顧客が確認項目キーワードを発話していれば、ステップS14において、その確認項目IDを特定する。
【0047】
キーワード突合部24は、ステップS15において、確認項目キーワードを含んだ発話に続く顧客の発話に、確認項目に対する返答があるかどうかを検証する。確認項目に対する返答がなければ、オペレータに再度確認するように求め、顧客の回答を待つ。氏名の確認であれば、キーワード直後の3〜6文字の名詞が氏名である可能性が高いのでその前後の文字列を探索する。電話番号の確認であれば、キーワード直後の10桁程度の数字が電話番号である可能性が高いと判断してその前後の数字の文字列を探索する。
【0048】
そしてステップS16において、探索の結果、抽出された文字列が会員基本情報に登録された情報と一致しているかどうかをチェックする。この際、会員ID等が先に特定されていれば、その会員IDの会員基本情報を参照するが、会員ID等が特定されていなければ、氏名又は電話番号をキーに、会員マスタDB27を検索して顧客の会員基本情報を求める。
【0049】
ステップS16で抽出された文字列が会員基本情報の該当項目と合致すれば、その確認項目については確認OKと判断する(ステップS17)。合致しなければ、ステップS11に戻るが、その前にオペレータに対して、再度顧客の回答に間違いがないかを確認するように促す。具体的には、オペレータ端末30の画面にその旨のメッセージを表示させる。
【0050】
ステップS17で確認OKと判断された後は、ステップS18において、本人確認の全項目について確認が終ったかどうかをチェックする。確認が終っていなければ、ステップS11に戻り、次の確認項目について同様の処理を行う。本人確認の全項目が確認終了していれば、ステップS19に移り、本人確認済フラグをONにする。
【0051】
そして、最後にステップS20において、全ての発話の組について処理したかどうかをチェックし、まだ処理すべき発話があればステップS11に戻り、本人確認後の確認項目(手続きによって異なる)について同様の処理を行う。ただし、このときは、本人確認済フラグが既にONになっているので、ステップS18,S19の処理は無視される。そして、すべての確認項目の処理が終れば、キーワード抽出・突合処理は終了する。
【0052】
図5は、本システムを用いた顧客とオペレータとの対話例1を示す図である。この例では、カード会員である顧客が、スマートフォンを使用して、カード会社のコールセンタに電話を掛けたとする。
【0053】
顧客は、コールセンタに電話が繋がったあと、まず、住所変更の手続きを申し出たとする(発話410)。オペレータは、顧客の用件が住所変更であることを確認すると、顧客のカード番号を確認する(発話310)。このとき、確認項目処理サーバでは、顧客とオペレータの会話中の「住所変更」というキーワードを検出し、オペレータ端末30の画面に、図示するような会員に対する本人確認の項目を表示させる。顧客の用件が住所変更であることがすでに分かっているので本人確認以外にも住所変更の確認が必要であることを示すために、住所変更の欄にも既にチェックマークが入っている。
【0054】
顧客のスマートフォンにコールセンタ用の専用アプリがインストールされている場合には、図示する顧客画面400のように、これから求められる確認項目が表示される。このことにより顧客は、次に聞かれる内容が事前に分かるので、よりスムーズにオペレータとの対話を行うことができる。顧客画面400は、スマートフォンの画面に表示されるが、スマートフォンと接続された外部ディスプレイがある場合には、顧客は、スマートフォンを耳から話さずに、この画面を確認することができる。ただし、周りに他人がいて、個人情報を覗き見されたくない場合には、個々の内容は表示されず、確認項目だけを表示するようにもできる。
【0055】
顧客がオペレータの求めに応じてカード番号を伝えると(発話411)、オペレータ画面にも音声認識されたカード番号が表示される。ここでは、発話311でオペレータがカード番号を確認しているが、顧客画面400に表示して確認してもらってもよい。もちろん、カード番号は口頭で告げなくともスマートフォンからキー入力してもよい。続いて、顧客は、氏名、生年月日、電話番号を順に口頭で又はキー入力し、会員基本情報との突合がすべてOKであると、オペレータ画面301には、これらの確認項目すべてにチェックマークが付き、本人確認がOKであったことが表示される。そして、この時点で、次の住所変更の確認項目がオペレータ画面301に自動的に表示される。
【0056】
本人確認が終って、住所変更の情報を確認する際にも、同様に、オペレータ画面302に、住所変更の確認項目の処理状況が表示される。また、顧客が伝えた内容をスマートフォンの顧客画面401にも表示することができる。この場合、確認事項の送信は、項目毎であってもよいし、最後に、一括して送信してもよい。このようにすることで、オペレータが、顧客の言った内容を確認のためにもう一度繰り返して言う必要がなくなり、顧客との対話時間の短縮に繋がる。このようにすることで、音声自動応答の場合と比べても処理時間は大差なく、オペレータと常に対話しながら確認を行えるので、顧客は安心感をもつことができる。
【0057】
図6は、本システムを用いた顧客とオペレータとの対話例2を示す図である。この例では、顧客は、会員ではなく、初めてのコールセンタに電話を掛けた場合を想定している。この場合であっても、本システムは、同じ仕組みで、確認項目の自動チェックを行うことができる。
【0058】
コールセンタに電話した顧客は、商品を注文したい旨を告げると、オペレータは、顧客が会員でないこと、はじめての商品の注文であることを認識し、求める商品名を確認する。この時、本システムは、オペレータの発話317に含まれる「XXサプリメント」、「初めてのご注文」というキーワードから、顧客が新規顧客であると判断し、新規顧客の商品注文における確認項目をオペレータ画面303に表示させる。そして、オペレータが発話318において、商品名、単価、数量を確認すると、オペレータ画面303の商品欄、単価欄、数量欄にも自動的にチェックが入る。
【0059】
次に、オペレータは、商品を送付するために、顧客の電話番号、氏名、住所の確認に移る(発話319〜323)。このときの処理は、会員の本人確認の場合と同様であるが、新規顧客の場合は、会員基本情報がデータベースに存在しないため、会員マスタDB27との突合処理はスキップされる。
【0060】
顧客の氏名確認の際、この例では、顧客の名前の漢字に候補がたくさんあるので確認を求める必要が生じた。この場合には、オペレータ画面305に漢字候補リスト306がポップアップで表示され、オペレータの確認作業を助ける。顧客が自分の名前の漢字を説明する言い方が、発話417のように、システムが自動認識するには困難な場合であっても、オペレータは、漢字候補リスト306からその漢字を容易に特定することができる。
【0061】
そして、特定した顧客の氏名の漢字表記も顧客の端末がスマートフォンであれば、念のためメッセージを送り、顧客に確認してもらうこともできる。この場合には、特にスマートフォンに専用アプリがインストールされていなくもよい。顧客は、送られてきた氏名の漢字を画面で確認後に住所等を告げてもよいが、住所の漢字でも同様のことが起こる可能性があるので、氏名、住所、電話番号をすべて告げてから、確認のメッセージを受け取るようにしたほうがよい。
【0062】
このようにすることで、従来の自動音声応答では不可能であった氏名や住所の漢字を正確に確認することができる。また、このような漢字の確認は、オペレータにとっても時間のかかるものなので、特に漢字知識の乏しいオペレータの負担をも軽減することができる。
【0063】
以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されないことは言うまでもない。上記実施形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。またその様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。