(58)【調査した分野】(Int.Cl.,DB名)
前記会話内容監視サーバは、前記NGワードと前記コールセンタのサービス内容に紐づけられた兆候ワードと、前記通話中の会話の会話時間、前記通話中の顧客が特定顧客として指定されているか否かの情報、及び前記通話中の顧客が特定地域の顧客であるか否かの情報のうち少なくとも1つの情報とに基づいて、オペレータがNGワードを発する危険性であるNGワード危険度を算出し、
前記アラーム発生部は、前記NGワード危険度に応じて前記アラームのレベルを決定することを特徴とする請求項2に記載のコールセンタ用語管理システム。
前記会話内容監視サーバは、前記NGワード危険度に応じて、前記音声認識サーバの音声/テキスト変換を処理するリソースの割当を変更させることを特徴とする請求項3に記載のコールセンタ用語管理システム。
【発明の概要】
【発明が解決しようとする課題】
【0008】
NGワードに関しては、多数の顧客(見込み顧客を含む)からの電話を受け付ける企業のコールセンタにおいても同様なことが存在し、電話を掛けてきた顧客に対して、オペレータが発してはいけないNGワードが定められている。しかし、コールセンタのシステムに、仮に上記の特許文献1の方法を適用しようとすると、NGワードの発信自体は防止できても、NGワードが変換されたダミー音声(ピー音等)が発信されるので、それを聞いた顧客は非常に違和感を感じることになる。また、特許文献2の方法では、NGワードを発信してしまった後の注意喚起や訂正は行えても、NGワードの発信そのものを事前に防止することはできない。
【0009】
そこで本発明では、上記のような課題に鑑み、コールセンタにおいて、オペレータが顧客に対してNGワードを不用意に発することを事前に防止するためのシステム及びその方法を提供することを目的とする。
【課題を解決するための手段】
【0010】
上記課題を解決するため、本発明のシステムは、以下のような解決手段を提供する。
【0011】
請求項1に記載の発明は、コールセンタにおいてオペレータが顧客に対して発する用語を管理するシステムであって、前記顧客と前記オペレータとの会話を録音する音声キャプチャサーバと、前記音声キャプチャサーバが録音した音声データを読み出してテキストデータである会話テキストに変換し、会話テキスト蓄積DBに蓄積する音声認識サーバと、前記会話テキスト蓄積DBの前記会話テキストを統計処理して分析する会話テキスト分析サーバと、を備えており、前記会話テキスト分析サーバは、前記会話テキスト蓄積DBから前記会話テキストを読み出し、形態素解析により用語単位に分解する形態素解析部と、前記形態素解析部により用語単位に分解された会話テキストに、予め定められたNGワードが含まれているか否かを検出し、前記NGワードが含まれている場合に、
前記NGワードの前の発話に含まれる用語が、前記オペレータが前記NGワードを発する兆候となる兆候ワードか否かを
前記NGワードごとに紐付された兆候ワードが登録されたNGワード兆候DBに基づいて判定する兆候ワード
発話判定部と、を備えることを特徴とする。
【0012】
上記の構成によれば、コールセンタに
おいてオペレータがNGワードを発生する兆候を事前に検出す
ることができる。
【0013】
請求項2に記載の発明は、請求項1に記載の発明において、顧客とオペレータの通話中の音声データを取得し、会話内容をリアルタイムにチェックする会話内容監視サーバをさらに備え、前記会話内容監視サーバは、前記NGワード兆候DBに格納されたデータに基づいて、前記通話中の会話に前記兆候ワードが含まれているか否かを検出するNGワード兆候検出部と、前記兆候ワードが前記通話中の会話に含まれている場合に、当該オペレータの端末と当該オペレータを管理するスーパバイザの端末にアラームを発生させるアラーム発生部と、を備えることを特徴とする。
【0014】
上記の構成によれば、会話内容監視サーバが、通話中の会話をリアルタイムに監視し、その会話に上記の兆候ワードが含まれていることを検出した場合には、アラームが直ちに発生するので、オペレータが顧客に対してNGワードを不用意に発することを事前に防止することができる。すなわち、オペレータは自分の会話に注意を払うことができ、オペレータを管理するスーパバイザもそのオペレータに対して優先的に注意を払うことができる。
【0015】
請求項3に記載の発明は、請求項2に記載の発明において、前記会話内容監視サーバは、前記NGワードと前記コールセンタのサービス内容に紐づけられた兆候ワードと、前記通話中の会話の会話時間、前記通話中の顧客が特定顧客として指定されているか否かの情報、及び前記通話中の顧客が特定地域の顧客であるか否かの情報のうち少なくとも1つの情報とに基づいて、オペレータがNGワードを発する危険性の度合いであるNGワード危険度を算出し、前記アラーム発生部は、前記NGワード危険度に応じて前記アラームのレベルを決定することを特徴とする。
【0016】
上記の構成によれば、兆候ワードだけでなく、会話時間、顧客が特定の顧客(クレーマ、重要顧客等)であるか否か、特定地域(地域によってセンシティブな用語がある場合)の顧客であるか否かの情報に基づいて、NGワード危険度(NGワードを発する危険性の度合)を算出するので、NGワード危険度に応じた適切なアラームを発生させることができる。
【0017】
請求項4に記載の発明は、請求項3に記載の発明において、前記会話内容監視サーバは、前記NGワード危険度に応じて、前記音声認識サーバの音声/テキスト変換を処理するリソースの割当を変更させることを特徴とする。
【0018】
上記の構成によれば、通話中の会話のテキスト化をリアルタイムに処理する際に、音声認識サーバのリソース(サーバの数、CPUの数等)の構成を、そのときの負荷状況に応じて柔軟に変更することができる。
【0019】
請求項5に記載の発明は、
前記会話テキストから抽出された兆候ワードの候補を、前記兆候ワードとして登録するか否かの判定を求める判定画面を管理者端末に生成する
兆候ワード登録判定部を備えることを特徴とする。
【0020】
上記の構成によれば、会話テキスト分析サーバが行う兆候ワードの判定に、人間によるチェックや判断を加えることができる。
【0021】
コールセンタにおいてオペレータが顧客に対して発する用語を管理する方法であって、前記顧客と前記オペレータとの会話を録音する音声キャプチャステップと、前記音声キャプチャステップで録音した音声データを読み出してテキストデータである会話テキストに変換するステップと、前記会話テキストを会話テキスト蓄積DBに蓄積するステップと、
前記会話テキスト蓄積DBの前記会話テキストを統計処理して分析する会話テキスト分析ステップと、を有し、前記会話テキスト分析ステップは、前記会話テキスト蓄積DBから前記会話テキストを読み出し、形態素解析により用語単位に分解する形態素解析ステップと、前記形態素解析ステップで用語単位に分解された会話テキストに、予め定められたNGワードが含まれているか否かを検出するステップと、
前記NGワードの前の発話に含まれる用語が、前記オペレータが前記NGワードを発する兆候となる兆候ワードか否かを
前記NGワードごとに紐付された兆候ワードが登録されたNGワード兆候DBに基づいて判定するステップと、を含むことを特徴とする。
【0022】
上記請求項6の発明は、請求項1のシステムを方法の発明と捉えたものであり、請求項1の発明と同様な作用効果を奏する。
また、請求項7に記載の発明は、コールセンタにおいてオペレータが顧客に対して発する用語を管理するシステムであって、前記顧客と前記オペレータとの会話を録音する音声キャプチャサーバと、前記音声キャプチャサーバが録音した音声データを読み出してテキストデータである会話テキストに変換し、会話テキスト蓄積DBに蓄積する音声認識サーバと、前記会話テキスト蓄積DBの前記会話テキストを統計処理して分析する会話テキスト分析サーバと、を備えており、前記会話テキスト分析サーバは、前記会話テキスト蓄積DBから前記会話テキストを読み出し、形態素解析により用語単位に分解する形態素解析部と、前記形態素解析部により用語単位に分解された会話テキストに、予め定められたNGワードが含まれているか否かを検出し、前記NGワードが含まれている場合に、前記NGワードの前に発せられた用語の出現回数が所定値よりも大きい用語を、前記オペレータが前記NGワードを発する兆候となる兆候ワード候補として、NGワード兆候DBに格納する兆候ワード登録判定部と、を備えることを特徴とする。
上記請求項7の構成によれば、コールセンタにおける過去の会話内容のテキストを統計的に分析して、兆候ワードとして抽出しデータベースに蓄積するので、オペレータがNGワードを発生する兆候を事前に検出するためのデータを得ることができる。
【発明の効果】
【0023】
本発明によれば、NGワードを発する兆候のデータを捉えることができ、そのデータを用いて通話中の兆候ワードを検出することで、オペレータが顧客に対してNGワードを不用意に発することを事前に防止することができる。
【発明を実施するための形態】
【0025】
以下、添付図面を参照して、本発明を実施するための形態(以下、実施形態)について詳細に説明する。なお、実施形態の説明の全体を通して同じ要素には同じ番号または符号を付している。また、後述の機能ブロック図における矢印は、データの流れ方向、又は処理の流れ方向を表している。
【0026】
図1、
図2は、本発明の基本概念を示した図である。本発明は、基本概念として、コールセンタの音声認識システムを用いて、NGワードそのものでなく、NGワードに繋がる兆候(ワーニング要因)となるような用語(以下、「兆候ワード」と呼ぶ)、及びNGワード発生状況のデータを蓄積し、兆候ワードを顧客又はオペレータが発したときに又はNGワード発生の兆候を捉えたときに、そのオペレータ又はオペレータの管理者(スーパバイザ)等に対して注意喚起を行うようにしたものである。
図1では、NGワード兆候データの蓄積段階でのシステムの概念図を示し、
図2では、NGワードの兆候の検出段階でのシステムの概念図を示している。
【0027】
まず、
図1について説明する。顧客がコールセンタに電話を掛けると、一般的には、まず自動音声応答システム(IVR:Interactive Voice Response)に繋がり、自動応答音声では対応できない要件についてのみオペレータに繋がるようになっているが、本発明ではオペレータとの通話が確立した後を対象としている。
【0028】
図示するように、顧客とオペレータの通話が確立すると、まず、音声キャプチャサーバがその会話内容の音声をデータベースに録音する。次に、音声認識サーバが、録音された音声データを読み出し、会話内容をテキストに変換する。ここまでは、一般のコールセンタで広く行われていることである。本発明では、その後、会話テキスト分析サーバが、テキストに変換された会話内容(「会話テキスト」と呼ぶ)を分析し、予め定められたNGワードに繋がるような兆候ワードを含む兆候データを蓄積し、統計的に処理する。
【0029】
ここでいう「NGワード」とは、コールセンタにおいてオペレータが顧客に対して発するべきでないと予め定められた用語を意味し、放送禁止用語のようなものとは異なる。顧客が発した用語はNGワードとしては扱わないが、NGワードに繋がるような「兆候ワード」としては取り扱われる。例えば、顧客が発した用語がきっかけでオペレータがNGワードをうっかり発したような場合には、顧客の発したその用語は兆候ワードとなる。また、顧客がNGワードに登録されている用語を発した後に、オペレータがオウム返しで繰り返したような場合も同様である。
【0030】
ここで、NGワードの兆候は、顧客又はオペレータが発した特定のキーワード、特定のサービスでのキーワード、顧客とオペレータとの会話時間、顧客が特定の人か否か、及び顧客が特定の地域の人か否か等のデータ(これを各要素の評価項目と呼ぶ)から分析する。
【0031】
上記の特定のキーワード及び特定サービスでのキーワードのうち、オペレータがNGワードを発した兆候またはきっかけとなったと判定されるキーワードを、特に「兆候ワード」と呼ぶことにする。兆候ワードについては、例えば、商品案内等をする際のNGワードである“絶対大丈夫”をオペレータが発する前に、“大丈夫ですか”、“絶対ですか”等の顧客の発言がきっかけとなる場合が統計的に多ければ、その“大丈夫ですか”、“絶対ですか”を兆候ワードとして登録する。また、「特定のサービスでのキーワード」とは、一般的には、NGワードや兆候ワードとは考えにくい用語であっても、特定のサービスにおいては、NGワードや兆候ワードとなる場合があることを考慮して設けられている。例えば、カード会社のコールセンタにおいて、顧客のカードのポイントの確認するサービスのような場合、“少ない”、“足りない”、“減ってる”などの用語がそのサービス特有の兆候ワードとなり得る。
【0032】
また、顧客とオペレータとの会話時間については、問い合わせ内容に比して、会話時間が通常より大幅に長いときにNGワードを発する傾向が高ければ、会話時間を問い合わせ内容と関連付けして兆候データとして登録する。また、「特定の顧客か否か」については、クレーマなど特定の気質を持った顧客、または重要顧客であると判別できる場合には、NGワードの兆候をより注意して捉える必要があるために設けられている。また、「特定の地域か否か」については、地域によって時期的にセンシティブに扱わなければならないような用語(例えば、地震、災害、原発等)がある場合に、その用語をその地域におけるNGワードとして定義し、そのNGワードを発する兆候を注意して捉える必要があるために設けられている。
【0033】
会話テキスト分析サーバによって分析された統計データは、そのためのデータベース(「NGワード兆候DB」と呼ぶ)に格納され、後述の
図2のNGワード兆候検出段階で利用される。なお、音声認識サーバの音声からテキストへの変換、及び会話テキスト分析サーバの統計的分析、データの蓄積は、必ずしもコールセンタ稼働時にオンラインで実行しなくともよく、当日得られた録音データをまとめて、夜間などにバッチ処理してもよい。もちろん、音声認識サーバの処理能力によっては、コールセンタ稼働中にもオンラインで処理してもよい。
【0034】
図2は、NGワード兆候検出段階の基本概念を示した図である。図示するように、会話内容監視サーバは、顧客とオペレータの会話内容をリアルタイムでチェックし、NGワードの兆候が現れていないかを監視する。もちろん、オペレータが実際にNGワードを発していないかどうかを同時にチェックしてもよい。
【0035】
会話内容監視サーバがオペレータAの会話にNGワードの兆候を検出すると、オペレータAの会話のテキスト変換の処理速度を上げるために、音声認識サーバにオペレータAの会話を優先的に処理するために最適なリソース(音声/テキスト変換を行うサーバの数、CPU数、CPUの内蔵コア数、メモリ容量等)の割当を指示する。この指示を受けた音声認識サーバは、オペレータAの今までの会話内容を直ちにテキスト化し、これからの会話内容はリアルタイムにテキスト化して、会話内容監視サーバに送信する。会話内容監視サーバは、このデータを受信時或いは受信前に、スーパバイザ及びオペレータAに対して、「NGワード危険度」に応じたアラームを送信する。NGワード危険度とは、NGワードに繋がる兆候の危険度(兆候の強さの度合い)を意味し、NGワード兆候DBに格納されたデータ(
図1で説明した評価項目の各データ)に基づいて、会話内容監視サーバが算出するものである。この算出方法について詳しくは後述する。
【0036】
このように本発明のシステムによれば、オペレータがNGワードを発する兆候をできるだけ早く捉え、スーパバイザやそのオペレータ(オペレータA)にNGワード危険度に応じた適切なアラームを発生させて送信するので、NGワードの発信を事前に防止することができる。また、アラームを受けたスーパバイザには、オペレータAと顧客の会話内容が、アラ−ム発生後はもちろん、今までの会話内容も全てテキスト化され送信されるので、いままでの会話の録音を聞き直したりすることなく、オペレータAの監視を優先的に行うことができる。また、オペレータAに対しても以後の会話に注意するように注意喚起することができる。
【0037】
図3は、本発明の典型的な実施形態であるコールセンタ用語管理システム100(以下、単に本システムと呼ぶ)の機能ブロック図を示した図である。本システムは、企業のコールセンタのコンピュータ・システムであり、
図1で説明した各サーバが、複数(十台程度から数百台程度の規模まで)のオペレータ端末200と、1以上のスーパバイザ端末210と、1以上の管理者端末220とにネットワークを介して接続されている。通常、1人のスーパバーザが、10人程度のオペレータの状況を管理しているケースが一般的である。大規模なコールセンタでは、スーパバイザと複数のオペレータの組(オペレータグループ)が多数存在する。
【0038】
図3の中で実線110で囲った部分が
図1、
図2で説明した音声キャプチャサーバに相当し、同様に、実線120で囲った部分が音声認識サーバ、実線130で囲った部分が会話テキスト分析サーバ、実線140で囲った部分が会話内容監視サーバに相当する。各サーバは単一又は複数のコンピュータで構成されるが、特に音声認識サーバについては、負荷に応じて処理能力を柔軟に変更できるように、複数のサーバ構成とし、各サーバは、複数のCPUと複数のCPUコアを備えたハードウェア装置とすることが望ましい。以下、本システムの各機能ブロックについて順に説明する。
【0039】
コールセンタに顧客からの電話が着電すると、構内交換機101(PBX:Private Branch eXchange)が自動音声応答装置102(IVR)に制御を渡し、まずは自動音声応答で応対させる。自動音声応答装置102は、顧客に問い合わせ内容に対応する要件番号を入力させ(問い合わせ内容ごとに電話番号を分けているコールセンタでは省略可)、自動応答ができない場合には、オペレータ端末200の中から現在通話中でない端末を見つけ、端末制御部103を介して、そのオペレータ端末200に着電を接続する。このとき、要件番号(サービスコード)、及びカード番号や携帯電話番号等の顧客を特定できる情報が得られる場合は、その情報も同時にオペレータ端末200に送信する。なお、オペレータ端末200は必ずしもコールセンタの施設内とは限らず、在宅オペレータの自宅のPCであることもある。
【0040】
端末制御部103では、着電した顧客が特定できる場合は、顧客情報DB104からその顧客の情報を読み出してオペレータ端末200に表示する。このようにして顧客とオペレータの通話が確立する。なお、IVRを採用していないコールセンタの場合、或いはIVRからの伝達される情報が不十分な場合は、オペレータが顧客との会話開始時に、顧客特定情報や問い合わせ要件を聞きだし、システムにインプットすることが望ましい。
【0041】
(音声キャプチャサーバ)
顧客とオペレータとの会話が開始すると、音声キャプチャサーバ110の音声録音部111が、会話の内容の音声データを録音し、会話日時、オペレータID、顧客ID、サービスコード(問い合わせ内容)とともに音声データを会話録音DB112に格納する。これはオペレータの品質向上のための基礎データとして、或いは顧客とトラブルがあった際の対策として、コールセンタでは広く行われている。
【0042】
(音声認識サーバ)
会話録音DB112に格納された録音データは、音声認識サーバ120の音声/テキスト変換部122によって、テキストデータに変換され、変換出力されたテキストは、音声認識サーバ120内部又は外部に備えた会話テキスト蓄積DB123に順次格納される。音声認識については、公知技術であるのでここでは説明を省略する。ただし、本システムの音声認識サーバ120は、通話中の音声/テキスト変換をリアルタイムで処理する必要があるときは、会話内容監視サーバ140からの指示によって、リソースの割当を柔軟に変更できるようにリソースの割当を変更するリソース管理部121を備えている。これについて詳しくは後述する。
【0043】
(会話テキスト分析サーバ)
会話テキスト分析サーバ130は、形態素解析部131を備え、会話テキスト蓄積DB123から会話テキストを読み出し、形態素(言語で意味をもつ最小単位)に分解する。そして、解析された形態素を元に、単語又は文節である用語(ワード)単位に結合し、会話中に現れる全ての用語を兆候ワード判定部132に受け渡す。なお、形態素解析及び文節の解析は、様々な公知の技術を用いてよいが、それらの公知技術についてはここでは説明を省略する。
【0044】
兆候ワード判定部132は、会話中の全ての用語について、その用語がNGワードに当たるかをチェックする。ただし、NGワード自体は、NGワードリストとしてNGワードDB134に予め登録されているものとする。NGワードの登録は、NGワード登録部135を介して、管理者端末220から行う。
【0045】
兆候ワード判定部132は、2つの機能を有し、特に図示していないが、さらに兆候ワード発話判定部と兆候ワード登録判定部とに分かれる。兆候ワード発話判定部は、発話中の用語が兆候ワードリストに当たるかどうかをリアルタイムに判定する。すなわち、兆候ワード発話判定部は、発話中にNGワードが含まれている場合は、そのNGワードが現れる前の発話の用語を再度チェクし、NGワード兆候DB133に格納された兆候ワードリストに格納された用語に当たるかを判定する。
【0046】
兆候ワード登録判定部は、通常はバッチ処理で、会話の内容から兆候ワード候補を抽出し、兆候ワードとして登録するかどうか判定する。すなわち、兆候ワード登録判定部は、抽出された1又は複数の用語を兆候ワード候補としてひとまず記憶し、記憶された兆候ワード候補は、好ましくは管理者の確認を経た後、兆候ワードとして登録される。通常は、1つのNGワードに対して複数の兆候ワードが紐付されて登録される。同様に1つの兆候ワードに対して、複数のNGワードを紐づけしてもよい。このような、NGワードと兆候ワードの相互の紐づけ登録は、リレーショナル・データベース等の公知の技術を用いて実現する。
【0047】
兆候ワードが紐づけされていない場合は、管理者端末220にNGワードが出現する直前又は所定の範囲の会話テキストを送信して、システム管理者に判断を仰ぐようにする。また、兆候ワード判定部132は、NGワードが出現する前の用語の出現頻度を統計処理し、NGワードの前に出現頻度が高い用語について、「兆候ワード候補」として、管理者端末220に表示する機能を備えている。管理者端末220からは、兆候ワード候補を兆候ワードとして登録するか否かの判定を行うこともできる。例えば、出現したNGワードが前述した“絶対大丈夫”であるとすると、その前に顧客が発した“絶対”とか“大丈夫”といった用語も兆候ワードの候補として表示する。管理者は、この兆候ワードの候補から、当該NGワードの兆候ワードとすべきか否かを判断してシステムにインプットする。このようにすることで、兆候ワードの統計的な蓄積及び人間によるチェックが同時に可能となる。
【0048】
さらに、兆候ワード判定部132は、兆候ワードのデータの蓄積に応じて、管理者の判定結果を学習する機能を持っていることが望ましい。例えば、新しいNGワードが登録された場合に、類似のNGワードと兆候ワードとして判定された結果から、新たなNGワードの兆候ワードを類推する機能を備える等である。また、一度登録された兆候ワードであっても、オペレータやスーパバイザからのフィードバックを受け付けるようにして、適宜更新する機能も備えていることが望ましい。
【0049】
(会話内容監視サーバ)
NGワード兆候検出部141は、NGワード兆候DB133を参照しながら、現在、オペレータと顧客の通話中の会話内容に兆候ワードが現れてないかをチェックする機能を有する。また、NGワード検出部144は、NGワード自体が現れてないかもチェックする。NGワード兆候検出部141とNGワード検出部144は統合した構成としてもよい。兆候ワード若しくはNGワードのチェックは、先行特許文献1に示されたような禁止語音素モデルを用いてもよいし、後述の音声認識リソース変更機能によって、リアルタイム(例えば1秒以内)に音声/テキスト変換が可能な場合は、その変換後のテキストでチェックしてもよい。問い合わせ内容(サービス内容)が取得できる場合は、そのサービス内容ごとにカテゴリー分けされた兆候ワードリストやNGワードリストを用いると処理が効率化できる。
【0050】
NGワード兆候検出部141は、兆候ワードの検出以外にも、会話時間、サービス内容、特定顧客、特定地域、の各要素の評価値もチェックし、NGワード危険度を算出する。NGワード危険度は、重回帰分析(多変量解析の一つ)の手法を用いて、例えば、下記の数式で算出できる。
【0051】
NGワード危険度=(b
1×N
1+b
2×N
2+b
3×N
3+・・・)+a
1×T+a
2×S+a
3×C+a
4×R
ただし、
N
1,N
2,N
3,・・・は会話中に出現した兆候ワードの出現回数でb
1,b
2,b
3は兆候ワードごとの重み係数、
Tは後述する経過時間値(会話開始から現時点までの会話時間に関する値)、
Sはサービス内容ごとに決められる所定の値、
Cは後述する特定顧客値、
Rは後述する特定地域値、
a
1〜a
4は各評価値の重み係数である。
【0052】
なお、NGワードの兆候を検出するために、兆候ワードの出現回数を用いるとき、カウントされた回数をそのまま使うのではなく、兆候ワードを発話する前の会話の状況を考慮した回数を使ってもよい。例えば、顧客の「絶対大丈夫ですか?」の質問に対して、オペレータが「はい。大丈夫です。」と答えた場合は、兆候ワードである「大丈夫です」の回数は「1」とするが、顧客の「問合せには、長い時間がかかりそうですが、いいですか。」の質問に対して、オペレータが「はい。大丈夫です。」と答えた場合は、兆候ワードである「大丈夫です」の回数は「0」としてもよい。
【0053】
また、所定の数式で算出されたNGワード危険度を算出する際、そのオペレータの熟練度を考慮してもよい。熟練度の高いオペレータであれば、兆候ワードを発しつつもNGワードは発しないが、熟練度の低いオペレータであれば、兆候ワードを発しつつあるときは、その後にNGワードを発する危険性が高いからである。
【0054】
音声認識リソース変更指示部142は、NGワード兆候検出部141がNGワード発生の兆候を検出すると起動され、音声認識サーバ120のリソース管理部121に当該オペレータの音声認識処理の優先度を上げてリアルタイムで音声/テキスト変換を行うように指示する。この指示を受けたリソース管理部121は、音声認識リソース変更機能を備えており、音声/テキスト変換部122に可能な限りのリソース(サーバ、CPU、CPUコア、メモリ容量等)の割当を提供して処理速度を向上させる。このとき提供されるリソースは、NGワード危険度によって決定する。最高レベルのNGワード危険度が検出された場合は、音声/テキスト変換部122に割り当てられるリソースも最大となることは言うまでもない。また、後述するアラーム発生部143により注意喚起を受けた当該オペレータがその後の会話内容から兆候ワードの検出がされなくなった場合は、一度優先度が上げられた当該オペレータの音声認識の優先度を下げるようにしてもよい。このようにすることでシステムリソースを有効に活用できるからである。
【0055】
アラーム発生部143は、NGワード兆候検出部141又はNGワード検出部144の検出結果に応じて、オペレータ端末200及びスーパバイザ端末210に対して、注意喚起又はアラームのメッセージを送信する。メッセージの内容は、前述したNGワード危険度に応じたアラームのレベルを定義し、アラームのレベルごとに変化させるようにしてもよい。このメッセージの具体例については、後述の図で説明する。
【0056】
上記の本システムの機能構成は、あくまで一例であり、一つの機能ブロック(データベース及び機能処理部)を更に分割したり、複数の機能ブロックをまとめて一つの機能ブロックとして構成したりしてもよい。各機能処理部は、コンピュータ装置に内蔵されたCPU(Central Processing Unit)が、ROM(Read Only Memory)又はハードディスク等の記憶装置に格納されたコンピュータ・プログラムを読み出し、CPUにより実行されたコンピュータ・プログラムによって実現される。すなわち、各機能処理部は、このコンピュータ・プログラムが、記憶装置に格納されたデータベース(DB;Data Base)やメモリ上の記憶領域からテーブル等の必要なデータを読み書きし、場合によっては、関連するハードウェア(例えば、入出力装置、表示装置、通信インターフェース装置)を制御することによって実現される。また、本発明の実施形態におけるデータベース(DB)は、商用データベースであってよいが、単なるテーブルやファイルの集合体をも意味し、データベースの内部構造自体は問わないものとする。なお、データベースも1つのサーバ(データベースサーバ)と考えてもよい。
【0057】
(兆候ワードデータ蓄積処理フロー)
図4は、兆候ワードのデータを蓄積する処理フローを示す図である。この処理は、会話テキスト分析サーバ130(以下、分析サーバと略す)が行う処理である。なお、以下の処理は、必ずしもこのフローチャートで示した順で処理される必要はなく、各処理ブロックの入力データと出力データの関係が損なわれない限り、処理順序を変更してもよい。
【0058】
分析サーバは、まずステップS10において、NGワードリストをNGワードDB134から読み出し、続いてステップS11で、未処理の会話テキストを会話テキスト蓄積DB123から読み出す。そして、ステップS12において、読み出した会話テキストにNGワードが含まれているかをチェックする。NGワードが含まれていなければ、その会話テキストに処理済のフラグを付した後、ステップS26に飛び、未処理の会話テキストがなくなるまで順次チェックしていく。
【0059】
会話テキストにNGワードが含まれていれば、ステップS13において、その会話のサービス内容または問い合わせ内容、会話時間を取得する。サービス内容又は問い合わせ内容には、サービスコードが予め定義されているものとし、サービスコードは、IVR又はオペレータが顧客との会話開始時に取得して、会話テキストのヘッダ部に付加されたものを取得する。ただし、1つの会話中に複数のサービス内容が含まれる場合があるので、会話全文からサービス内容を特定できるようなキーワードを検出して、複数のサービス内容が含まれる場合は、そのサービスコードを追加する。
【0060】
分析サーバは、次にステップS14において、登録顧客かどうかをチェックする。登録済みの顧客であれば、着信時に入手した携帯電話番号、顧客番号、オペレータが会話開始時から聞き出した情報から顧客を特定できる。顧客が登録されていなければ、次のステップS15〜S16の処理はスキップする。
【0061】
ステップS15においては、「特定顧客」かどうかをチェックする。特定顧客とは、クレーマ等の特別の気質も持った顧客、或いは重要顧客(VIP)として登録されている顧客で、通常の顧客よりも注意を払うべき顧客をいう。特定顧客であれば、特定顧客向NGワードリストをチェック用に追加する(ステップS16)。
【0062】
分析サーバは、さらにステップS17において、顧客の地域が特定可能かどうかをチェックする。顧客からの着信が固定電話からであれば、その市外番号から容易に特定できるが、会話テキスト中に地域に関するキーワード(県、市町村名など)が含まれていれば、その前後のテキストから顧客の地域を自然言語解析技術等を用いて推定するようにしてもよい。そして地域が特定できれば、NGワードがその地域特有であるかを判定する(ステップS18)。地域特有であればそのNGワードを特定地域に紐づける。具体的には、地域名をNGワードのテーブルの特定地域欄に書き込む(ステップS19)。
【0063】
特定顧客、特定地域の処理が終わると、分析サーバは、ステップS20の処理に移る。ステップS20においては、会話テキスト中で、検出されたNGワードよりも前に発せられた用語(これを前発用語と呼ぶことにする)の出現回数をカウントし、統計データに加える。そしてステップS21において、前発用語であって、かつ当該NGワードの統計データ中の出現回数が所定値よりも大きい用語を兆候ワード候補としてリスト化する。前発用語がすでに兆候ワードとして登録されていれば、その旨の情報も付加する。
【0064】
このようにしてリスト化された兆候ワード候補を直ちに当該NGワードの兆候ワードとして登録するか否かについて、人間(システム管理者又は判定者としてアサインされた者)の判断を求めるか否かを設定できるようにすることが望ましい。人間の判断が必要と設定されている場合は(ステップS22:Y)、ステップS23に移り、そのための判定画面を管理者の端末等に表示し、判断を求める。
【0065】
図5は、この判定画面の例を示したものである。この図は、画面に表示される情報を示したものであり、画面内のレイアウトは自由である。図示する符号301で示す部分は、処理中の会話テキストの基本情報を表示する部分である。符号302で示す部分は、会話の全文テキストと検出された用語を時系列に表示する領域である。ここでは、検出された用語の中で、兆候ワード候補を太字で、判定者によって兆候ワードであると判定された用語を太線+下線で、NGワードを囲み罫線で示している。実際には、文字をカラーで表示したり、サイズを変えたりして操作性を高めることは言うまでもない。用語の後ろのかっこ内の数字は、その用語が会話内に複数回出現したことを示す。判定者が、このような画面で兆候ワードとして登録するか否かの最終判定を行い、登録ボタン303を押すことで指定された兆候ワードがシステムに登録される。
【0066】
図4に戻り、ステップS24で兆候ワードの新たな登録が必要であると判定された場合は、ステップS25において、判定された用語を当該NGワードに紐づく兆候ワードとして、NGワード兆候DB133に格納する。
【0067】
図6は、このNGワード兆候DB133に格納されるデータを表形式で模式的に示したものである。この例では、クレジットカード会社のコールセンタを想定している。この表では、NGワードをカテゴリーに分けて、そのカテゴリーに属するNGワード全体に対して、NGワード出現前の用語を発生回数順に並べてリスト化し、兆候ワードとしての評価値を付加する構成としている。評価値が高いほど兆候ワードの可能性が高いことを示している。ただし、用語の発生回数が高いからといって必ずしも評価値が高くなるわけではないことに注意されたい。兆候ワードは、ゼロか一かで登録してもよいが、このように評価値を設けることで、サービス内容に応じて、所定の評価値以上を兆候ワードとするなど、場面によって評価値の判定基準を変えることができる。なお、この表は、複数の表を結合するリレーショナル・データベースで実現できる。
【0068】
(会話内容チェック処理フロー)
図7は、会話内容をリアルタイムにチェックする処理のフローを示した図である。オペレータが顧客との会話(通話)を開始すると、会話内容監視サーバ140(以下、単に監視サーバと呼ぶ)は、まず、サービス内容を取得し(ステップS30)、そのサービス内容に対応するNGワードの兆候ワードリスト(ステップS31)を取得する。サービス内容が取得できない場合は、全てのサービス内容に対応するNGワードの兆候ワードリストを取得する。さらに、監視サーバは、オペレータの習熟度の情報を取得してもよい(ステップS32)。
【0069】
次に、ステップS33において、会話基本情報から特定顧客か否かをチェックする。特定顧客であれば、特定顧客値を設定する(ステップS34)。特定顧客値とは、その顧客の要注意度であり、特定顧客値が高いほど要注意度を上げてアラームを行うための値である(最も単純にした場合は、0か1である)。特定顧客値は、前述したように、NGワード危険度を算出する際に用いられる。
【0070】
次に、ステップS35においては、会話基本情報から特定地域か否かをチェックする。特定地域であれば、特定地域値を設定する(ステップS36)。特定地域値とは、その地域の要注意度であり、特定地域値が高いほど要注意度を上げてアラームを行うための値である(単純に0か1でもよい)。特定地域値も、NGワード危険度を算出する際に用いられる。
【0071】
次に、ステップS37においては、会話開始から現在までの会話時間を求め、会話時間がサービス内容ごとに定められた所定時間を経過していないかをチェックする。所定時間を経過していれば、経過時間値を設定する(ステップS38)。経過時間値とは、会話がそのサービス内容の通常の会話時間を大幅に超過していないかどうかを示す値であり、経過時間値が高いほど注意度を上げてアラームを行うための値である(例えば、所定時間を20%以上超過した場合は1、50%以上超過した場合は2、などのように定める)。経過時間値も、NGワード危険度を算出する際に用いられる。
【0072】
ステップS39においては、会話途中でサービス内容が変わったり(追加を含む)、オペレータの交代があったりしたかどうかをチェックする。会話途中でそれらの変更があった場合は、ステップS30からの処理をやり直す。また、ステップS40においては、会話途中で顧客又は顧客の地域が判明したかどうかをチェックする。これらの情報が判明していれば、ステップS33からの処理をやり直す。ただし、上記いずれの場合も既に処理済みの部分はそのまま記憶される。
【0073】
次にステップS41において、会話内容にステップS31で取得した兆候ワードが含まれているかをチェックする。そして、ステップS42において、NGワード危険度を算出する。NGワード危険度算出の具体的な方法については、すでに説明済みであるのでここでは省略する。ただし、ステップS32で取得したオペレータの習熟度を加味してもよい。
【0074】
さらに、ステップS43において、算出されたNGワード危険度が所定値(閾値)を超えていないかどうかをチェックする。閾値を超えていれば、NGワード危険度に応じたアラームを該当するオペレータの端末及びそのオペレータを管理・指導するスーパバイザの端末に送信する。このときのアラーム発生時の画面を
図8に示す。
【0075】
図8は、兆候ワード検出のアラーム発生時のオペレータの画面及びスーパバイザの画面の一例を示す図である。図示するように、オペレータAの端末画面400には、顧客及び自分が発した兆候ワードとその回数が表示される。また、兆候ワードと紐づいたNGワード(この例では“絶対大丈夫”)も表示される。
【0076】
図7に戻り、監視サーバは、アラームを発生した後、或いは同時に、ステップS45において、算出されたNGワード危険度に応じて、音声認識サーバ120に対して、兆候ワードが検出された会話の音声/テキスト変換のためのリソースを増やし、さらに優先度を上げて、当該会話の変換処理をリアルタイムで行うように指示を送信する。この指示を受けた音声認識サーバ120は、
図9で示すように、NGワード危険度と優先度に応じて音声認識のリソース(オンラインで実行するサーバ数、CPU数、CPUコア数、メモリ容量)を変化させ処理速度を上げる。
【0077】
図9は、このときの音声認識サーバのリソース変更のイメージを示す図である。例えば、優先度:低(通常状態)のときは、音声認識サーバ1のみがオンラインで稼働しており、音声認識サーバ2は、バッチ処理用又はバックアップ用に待機している状態とする。このときオペレータAの会話の音声/テキスト変換は、CPU1のCORE1のみで処理していたとする。
【0078】
NGワード危険度が上がり、優先度:中になると、CPU1の全コアが上記の処理に割り当てられ、さらにそれでも処理速度が不足する場合は、CPU2,CPU3,CPU4もこの処理に割り当てられるようになる。
【0079】
さらにNGワード危険度が上がり、優先度:高になると、音声認識サーバ1だけでなくバックアップ用の音声認識サーバ2も割り当てられるようになる。実際に割り当てられるサーバの数、CPU又はCOREの数は、他の負荷状況によって決定される。兆候ワードを検出している端末が複数ある場合は、そのNGワード危険度によって優先されるリソース配分が決定される。
【0080】
図7に戻り、最後に、ステップS46において、会話が終了したかどうかをチェックする。会話が終了していれば、監視サーバは、この通話に対しての監視を終了する。会話が継続していれば、ステップS37に戻り、以降の処理を繰り返す。このようにして、会話内容のリアルタイムなチェック処理が行われる。
【0081】
上述した
図5、
図6、
図8の例では、クレジットカード等のカード会社のコールセンタのシステムを具体例としてあげて説明したが、他の企業のコールセンタにも適用可能であるのは当然である。
【0082】
なお、本システムは、NGワードの兆候だけでなく、例えば、顧客の、満足や不満やイライラの言葉、喜びや怒りといった感情的な言葉を発する兆候を捉えるなど、顧客が発する言葉で、企業側が特に注意を払うべき用語に対しても応用することが可能である。
【0083】
また、コールセンタによっては、顧客からのメールでの問い合わせに対して、その顧客と一定の期間内に会話したオペレータがフォローアップとしてメールで返答する場合がある。その場合、その返答文にNGワードが含まれてはならないのは当然であるが、顧客からの問い合わせ文に、NGワードや兆候ワードが含まれていても、それをうっかり返答文に含ませることがないように注意する必要がある。このため、返答文のNGワード危険度をメール送信前に算出し、チェックして、普段からオペレータのNGワードに対する注意喚起をさらに高めることも可能である。
【0084】
以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されないことは言うまでもない。上記実施形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。またその様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。