JP6456754B2 - コールセンターシステム - Google Patents

Description

本発明は、顧客等からの問合せを受付ける窓口となるコールセンターシステムに関する。

企業や官公庁において、所定の商品またはサービスについて外部から多数の問合せに対して専門のオペレータ（係員）が応答するコールセンターを設けることがある。コールセンターを設けることにより、外部の問合せすべてに対してオペレータが個別に回答や取継ぎ（転送）を行うことができるので、顧客や住民の便宜を図ることができる。このようなコールセンターにおいては、顧客や住民の満足度を向上させるため、問合せ先の内容に応じたカテゴリ毎に複数の転送先のそれぞれに対する転送回数が多い転送先（そのカテゴリで一番対応する経験が多い）回答者への転送するように制御するコールセンターシステムが特許文献１に開示されている。

特開２０１０−１０９８９５号公報

顧客先に納入した商品（分析装置等の機器含む）に関する定期点検、動作不良の問合せ、緊急の故障修理依頼などに対応するコールセンターにおいては、顧客からの問合せを１日に数十件、数百件のオーダーで受ける。そのような情報はコールセンターで記録されるが、重要なのは、顧客毎に迅速に最適な対応ができることである。例えば、最近の、ある短期間内に多くの問合せをした顧客は、顧客にとっては緊急事態であったり、重要な得意顧客であることなどが推察されるため、通常以上に迅速で正確な顧客対応ができるサービス態勢で、よりその顧客の意向や特性に沿った対応をすることが望ましい。
本発明の目的は、顧客に対してより顧客満足度の高い対応ができるコールセンターシステムを提供することにある。

本発明の目的を達成するための構成は以下の通りである。
顧客からの通信を受ける交換機と、少なくとも前記顧客からの通信内容を記憶する電話受付用装置と、前記電話受付用装置に接続され前記顧客に対応する顧客対応画面を表示し、前記交換機が受けた顧客からの通信を、受付若しくは、予め定められた複数の転送先のうちいずれか一つの転送先に転送指示するオペレータ端末と、前記転送先であって前記顧客対応画面を表示するエンジニア端末と、を有するコールセンターシステムであって、前記電話受付用装置に記憶された顧客からの通信内容をテキストデータ化するテキストデータ化機構と、該テキストデータ化機構によりテキストデータ化されたテキスト情報を記憶するテキストデータ記憶機構と、
該テキストデータ記憶機構に記憶されたテキストデータから、予め設定したキーワードが含まれる通信を抽出する抽出機構を備えたことを特徴とするコールセンターシステム。

交換機とは、電話を受付け、他に転送できる機構を備えたものであれば、どのような物であっても良いが、通常は、制御用のコンピュータと記憶装置、及び電話の受信/発信ができるインターフェースを備えた電子機器で構成される。電話受け付け用装置は、電話の通話内容を記憶できるよう大きな記憶容量の記憶装置を備えていることが一般的であるが、専用の装置でなく、ＰＣ（パーソナルコンピュータ）でも対応可能である。通信はアナログデータで記憶した情報をデジタル化しても良いし、始めからデジタル情報で記録しても良い。デジタル化された情報から、ソフトウェアを用いてテキストデータに変換する。オペレータ（電話交換手）は、オペレータ端末を操作し、顧客からの電話をサービスエンジニアに伝える。オペレータ端末には、顧客対応画面が表示され、その画面上で通信を転送する転送先を指定することができる。また、オペレータだけで対応可能な問い合わせがあった場合は、オペレータに転送することなく、対応することも可能である。顧客とオペレータ、オペレータとサービスエンジニア、顧客とサービスエンジニアの会話など、電話受付用装置を介して交わした会話はすべて記憶される。エンジニア端末はサービスエンジニアが操作し、顧客からの電話を受けることができるものであればどのようなものであっても良い。エンジニアの居室などに設けられたＰＣや、持ち歩き可能なタブレット端末、スマートフォン、通常の携帯電話など、表示画面のあるものが好ましく、出来るだけ表示できる情報量が多い端末の方が好ましいが、電話のみを送受できるものであってもかまわない。

上記構成において前記抽出機構は、前記予め設定したキーワードの少なくとも１つについて、その出現頻度に基づいてランキングするランキング機構を備えても良い。

また、抽出機構は、ＰＣにインストールされたソフトウェアで構成されることが一般的であり、オペレータ端末、電話受付用装置、交換機などコンピュータで構成される機器のいずれかにソフトウェアがインストールされていれば、良い。すなわち、抽出機構という独立した装置である必要は無く、その機能があれば良い。またランキング機構も同様で、その機能を発揮させるソフトウェアがインストールされていれば良い。ランキング機構という独立した装置が無くても良い。

上記構成において、前記予め設定したキーワードが、顧客名、装置型式名、アラームコード、エラーコード、サービス部品名、部品在庫確認、部品価格、見積依頼、の少なくとも１つを含むものであっても良い。

顧客名は、例えば、日立ハイテクフィールディング、日立ハイテク、日立など、同じ顧客の呼称として複数の呼称が使用され得るのであれば、１つに纏めて、電話の中でどのような呼ばれ方をしても、同一顧客と認識されるようにソフトウェアで対応することが好ましい。また、同じ日立病院でも複数の地域に分散しているような場合は、顧客名（例えば“日立”）と地域名（例えば“東京”）など、組み合わせで認識するようにソフトウェアを構成しても良い。装置型式名も、ペットネーム（例えば“ラボスペクト”）と型式名（例えば“００８”）とを組み合わせて認識するようにしても良い。アラームコードとは、装置オペレータに注意を促す警報の種類を示すもので、「反応槽水を交換して下さい」とか、「光源ランプの交換をして下さい」などのようなすぐに問題とならないものから、すぐに対策をしないと装置に重大な影響を及ぼすようなものまで種々存在する。対応の緊急性に鑑みて赤色警告、黄色警告などカテゴリー分けをしている場合もある。アラームコード、エラーコードの“コード”とは、ユーザが使用している装置において設定しているアラームやエラーの番号であり、例えば“Ａ０１Ｅ”など英字と数字などで表記するものが一般的である。このような英数字によるコードの他に、日本語で○○アラーム、××エラーなどと表記されるものもアラームコード、エラーコードに含まれる。すなわち、ユーザが「△△アラームと装置の操作画面に表示されている」、「××エラーと装置の操作画面に表示されている」、という電話をかけてきたときに、その電話でユーザが指摘しているアラーム、エラーが同一なものである場合は、そのアラーム、エラーで抽出するために、抽出機構は、英数字のアラームコード、そのアラームコードを意味するアラーム内容などの抽出する為のキーワードを予めグループ化して登録しておくことが好ましい。

上記構成において、前記予め設定したキーワードが、部品在庫確認、部品価格、見積依頼、の少なくとも１つである場合、その内容についてサービス部品名、装置型式名の少なくとも１つについて分類する分類機構を備えても良い。

顧客が、部品在庫を電話で確認する場合、その部品の名称と、その部品が使われる製品を同時に特定することが普通である。すなわち、部品として、消耗品や交換部品（洗剤などの薬品類や、分注ノズルなどの顧客自身で交換できる部品など）と、装置型式を同時に特定する。このような場合、部品在庫確認というキーワードで一旦抽出し、それを更に、何の部品か、あるいは何の装置に使う部品か、で更に分類することが好ましい。

上記構成において、前記予め設定したキーワードがアラームコード、エラーコード、サービス部品名、部品在庫確認、部品価格、見積依頼、の少なくとも１つを含み、顧客名あるいは装置型式の少なくともいずれか毎に、該キーワードの出願頻度に基づいてランキングする機能を備えても良い。

上記構成において、前記ランキング機構によりランキングされた予め設定したテキストの出現回数が、予め定めた期間に、予め定めた回数以上出現した場合は、その旨を通知する通知機構を備えても良い。

テキストの抽出頻度を例えば、１週間単位で区切ってカウントし、その１週間に２０回以上、予め定めたキーワードが会話中に含まれていた場合は、電話受付用装置がその旨を通知しても良い。通知とは、オペレータが操作するオペレータ端末に表示したり、専用の画面に表示したりすることでも良い。専用の画面とは、顧客からの電話内容を集計した結果を纏めて表示するようなイントラネットのホームページであったり、インターネットのホームページでも良い。後者の場合は、装置ユーザにアクセス権限を付与して、ユーザが自分でその結果を見たりすることができるようにしても良い。表示する場合は、グラフ等を使ってわかりやすく表示することも可能である。

上記構成において、予め定めた期間、予め定めた回数の少なくともいずれかを設定する設定機構を備えても良い。

予め定めた期間、予め定めた回数は、オペレータや電話受付装置の管理者が自由に変更することができるようになっていることが好ましい。

上記構成において、前記通知機構は、予め登録されたメンバーへの電子メールによる通知であっても良い。

予め登録されたメンバーとは、通常は、サービス会社の所属メンバーである。装置の種類毎に登録メンバーを変えても良い。例えば、医用分析装置に関する顧客の問い合わせについては、医用分析装置を担当しているサービスエンジニアを登録しておき、半導体分析装置に関する顧客の問い合わせについては、別のサービスエンジニアを登録することもできる。また、コールセンターの管理者には、すべての電子メールが配信されるようにすることもできる。

上記電子メールによる通知は、予め設定したキーワード、検索した期間、顧客毎の検索結果、装置型式毎の検索結果、の少なくとも１つの通知することが好ましい。

上記構成において、予め設定したキーワードを、設定するキーワード設定機構を備えても良い。キーワードは予め登録するが、適宜追加する必要が生じることが想定される。その場合に備え、電話受付システムのオペレータ、サービスエンジニア、コールセンターの管理者などが適宜キーワードを設定できるようにすることが好ましい。

上記構成において、ランキング機構によりランキングされた予め設定したテキストの出現回数が、予め定めた期間に、予め定めた回数以上出現した場合は、そのテキストに関連する顧客に対し案内を通知する、案内通知機構を備えても良い。

また、本発明のコールセンターシステムの別の態様は以下の構成を備えたことを特徴とする。

顧客からの通信を受ける変換機と、少なくとも前記顧客からの通信に関連する履歴情報と前記顧客の情報を記憶する電話受付用装置と、前記電話受付用装置に接続され前記顧客に対応する顧客対応画面を表示し、前記所定の通信を、予め定められた複数の転送先のうちいずれか一つの転送先に転送指示するオペレータ端末と、前記転送先であって前記顧客対応画面を表示するエンジニア端末と、を有するコールセンターシステムであって、顧客毎に対応方法を記憶する記憶機構を備え、前記顧客対応画面に該記憶機構に記憶された対応方法を表示する表示機構を備えたコールセンターシステム。

上記構成において、前記対応方法は、対応方法は、前記顧客を担当するエンジニアが不在時の対応方法であっても良い。

上記構成において、前記対応方法は、緊急時の対応方法であっても良い。

上記構成において、前記顧客と、前記オペレータ端末の操作者との間での会話をテキスト解析し、該テキスト解析に基づき顧客の問い合わせ内容を予め定めた複数のカテゴリのいずれかに分類し、分類されたカテゴリに対応する予め定めた対応方法を、前記顧客対応画面に表示する表示機構を備えても良い。

上記構成において、前記顧客からの問い合わせに対し対応が完了したか否かの情報を記憶する完了情報記憶機構を備え、該完了情報記憶機構に記憶された情報が対応完了となるまで、予め定めた間隔で、前記エンジニア端末に対応をフォローするフォロー機構を備えても良い。

上記構成において、前記累積集計・分析機構は、問い合わせの顧客名や装置型式名を、単純にランキングするランキング機構を備えても良い。

上記構成のコールセンターシステムにより、より顧客満足度の高い対応ができるコールセンターシステムを提供することができる。

本発明の実施形態に係るコールセンターシステムの概略構成ブロック図である。 本発明の実施形態に係るコールセンターシステムの別の概略構成ブロック図である。 本発明の実施形態に係るコールセンターシステムの別の概略構成ブロック図である。 本発明の実施形態に係るコールセンターシステムの動作を示すフローチャートの一例である。 本発明の実施形態に係るコールセンターシステムにおけるオペレータ端末及びエンジニア端末の顧客対応画面に表示される内容を示す図である。 本発明の実施形態に係るコールセンターシステムの概略構成図である。 本発明の実施形態に係るコールセンターシステムの抽出キーワードを示す図である。 本発明の実施形態に係るコールセンターシステムのメールでの抽出結果の記載例を示す図である。 本発明の実施形態に係るコールセンターシステムの動作を示すフローチャートの一例である。 本発明の実施形態に係るコールセンターシステムの動作を示すフローチャートの一例である。 本発明の実施形態に係るコールセンターシステムの動作を示すフローチャートの一例である。

顧客がコールセンターに電話などで問合せを行う際、コールセンターはコールセンターシステムを用いて対応する。

図１は、本発明に係るコールセンターシステムの概略構成ブロック図である。以下、図１を参照してコールセンターシステムの概要を説明する。

まず、顧客の発信手段である顧客電話器１１からの信号は、回線を介してコールセンターシステム１に接続され、顧客の問合せはコールセンターのオペレータが受付け、オペレータもしくはエスカレーションにより問合せ内容に対して技術的に詳しいエンジニアなどが顧客に回答する。

コールセンターシステム１は、少なくとも交換機２、電話受付用装置３、オペレータ端末４、エンジニア端末５、これらを繋ぐ回線から構成されている。オペレータ端末４とエンジニア端末５は１台ずつでも良いが、大半のシステムでは多くの問合せに効率的に対応するため、複数台の端末を設置して夫々オペレータ端末群４ａ及びエンジニア端末群５ａを構成している。

図１において、顧客電話機１１と交換機２を繋ぐ矢印Ａ１は、顧客電話機１１と交換機２とが電話回線で繋がっていることを示している。また、交換機２と電話受付用装置３を繋ぐ矢印Ａ２は、交換機２に入った顧客電話番号情報を電話受付用装置３が取り込む流れを示している。交換機２とオペレータ端末４を繋ぐ矢印Ａ３は電話受付用装置３が指示したオペレータに顧客からの回線を繋ぐ流れを、交換機２とエンジニア端末５を繋ぐ矢印Ａ４は、オペレータが指定したエンジニアに顧客からの通信回線を繋ぐ流れを示している。電話受付用装置３とオペレータ端末４を結ぶ矢印Ａ５、及び、電話受付用装置３とエンジニア端末５を結ぶ矢印Ａ６は、電話受付用装置３とオペレータ端末４、エンジニア端末５との間の着信履歴情報、納入機器情報、エンジニア情報等の情報の流れを示している。

エンジニア端末群５ａとオペレータ端末群４ａとは、必ずしも同じフロアーに居る必要はないが、オペレータとエンジニアが互いに目の届く範囲に居ることで、回線や情報転送時などに確認できる利点がある。また、電話受付用装置３はオペレータ端末群４ａ及びエンジニア端末群５ａと必ずしも同じフロアー、同じ建屋にある必要はなく遠隔地にあっても良い。なお同じフロアーにない場合は、カメラなどでお互いの状況が確認できるようになっていてもよい。

交換機２は、顧客からの回線をコールセンターのオペレータやエンジニアに繋ぎ、また転送する役割をする。

電話受付用装置３は少なくとも記憶装置６を備え、記憶装置６には少なくとも着信履歴データベース７、顧客情報データベース８、納入機器情報データベース９、エンジニア情報データベース１０を有する。電話受付用装置３は、交換機２で受けた外部からの回線の転送先の判断や、受信番号を基にして上記データベースの記憶情報を転送先に提供するなどの処理機能を有するコンピュータでもある。また、記憶装置６は必ずしも電話受付用装置３に備えられることに限定されず、記憶装置６が電話受付用装置３の外にあって他のシステムと連動してもよい。

電話受付用装置３は、少なくとも、顧客電話機１１からの着信情報（例えば電話番号）を受けてその着信情報を基に少なくとも着信履歴データベース７、顧客情報データベース８、納入機器情報データベース９のいずれかを検索する機能を有し、同一着信電話番号について着信履歴情報と、その着信番号に関係する顧客の顧客情報と、その顧客先にこれまでに納入した機器に関する納入機器情報を抽出して、転送先のオペレータ端末４やエンジニア端末５に提供する。オペレータ端末４が複数ある場合、転送先のオペレータ端末の選択は、電話受付用装置３が予め定めた順序に従って選択する。転送先オペレータ端末の選択順序は、例えば、オペレータが直前の顧客対応において回線を遮断した後の時間が長いオペレータ端末を優先する順序や、直前の対応時間が短いオペレータ端末４を優先する順序などであり、また、これらに限らない。電話受信用装置３は選択したオペレータ端末４を交換機２に指示し、交換機２は顧客からの回線を指示されたオペレータに繋ぐ。

また、電話受付用装置３は、顧客情報データベース８や納入機器情報データベース９から抽出した顧客情報もしくは納入機器情報に基づいて、顧客の問合せに技術的な回答や対応を行うエンジニア候補をエンジニア情報データベース１０から抽出し、オペレータ端末４に提供する機能を有する。

着信履歴データベース７は、顧客先に納入した機器の定期保守点検、不良動作、故障修理依頼などでコールセンターに問合せされた情報が保存されており、着信番号別に、着信時の年月日時刻、問合せ対象の機器名、応対したエンジニア名、応対内容などが記録されている。電話受付用装置３は、着信と同時に着信電話番号を検出し、着信電話番号の予め定めた上位数桁、例えば、市外局番、局番、番号の順の連続数における下位３桁を除いた連続数を基に、顧客情報データベース８から顧客候補を抽出してオペレータ端末４に表示する。顧客候補が予め定めた件数より多数抽出された場合は、市外局番以下の連続数の下位２桁を除いた連続数を基に、顧客候補を数件までに絞り込んでオペレータ端末４に表示してもよい。最終的な顧客の特定は、顧客とオペレータとの間の回線上の会話から決定される。また、予め着信電話番号と完全一致するものを表示するようにも設定できる。

電話受付用装置３は着信番号を基に、その顧客が重要顧客であることを判断する機能を有している。予め定めた期間内の着信回数（履歴）、つまり、着信を受けた時点から遡って予め定めた期間、例えば過去１０日、１カ月、２カ月、６カ月間に同一番号で着信した回数を検出し、着信回数が予め定めた回数より多い場合には、その顧客を重要顧客と定義し、その重要顧客であるとの識別表示がオペレータ端末４に提供される。予め定めた期間に着信回数が多いということは、顧客にとっては緊急事態や重要顧客と推察されるため、コールセンターシステム１を有するコールセンターはその顧客を重要顧客と位置付け、通常以上に迅速で正確な顧客対応をするサービス態勢を取るために識別表示をする。なお、着信番号が同一であっても、複数の部署に複数の納入機器を有する顧客からの異なった機器についての問合せであっても、それらを積算した総着信回数が予め定めた回数を超えた場合に、重要顧客と判断する。あるいは部署毎の積算によってもよい。

重要度の区分は、一段階でも良いし複数段階でもよい。つまり、「通常」と「重要」の区分で、「通常」以外を１区分とするだけでも良いし、「通常」、「重要」と「最重要」などと通常以外を複数に区別してもよい。「通常」の場合は「通常」であるとの表示はしなくても良い。着信回数に対応させる例として、最新の着信時刻を基準にして過去１０日間に０回から２回は通常レベルと判断し、特に「通常」とは表示せず、３回または４回なら「重要」とし、５回以上を「最重要」と定義しても良い。勿論、この識別レベルの設定はコールセンターシステム１を有するコールセンターの業態、顧客からの問合せ状況等に応じて予め独自に設定できる。

一旦、「重要」と「最重要」などと通常以外の区分に区別された顧客は、顧客情報データベース８に記憶され、顧客からの着信が無い時であっても、オペレータ端末４やエンジニア端末５、若しくは、コールセンターシステム１にアクセスできるコールセンターの端末から必要に応じて検索でき、重要と判断している顧客先での対応状況を把握することができる。
なお、顧客からの着信内容が機器サービスに関わらない些細な問合せの場合は、たとえ予め定めた期間中に予め定めた回数以上の着信があったとしても、オペレータ又はエンジニアの判断によって、重要顧客の識別表示を解除することができる。もしくは、該当着信の回数を積算しないようにできる。但し、着信履歴データベース７には、着信内容、識別表示を変更した日付、理由、解除者の記録は残る。

重要度を判断する基準は、上記では着信履歴（所定期間の着信回数）としたが、本発明はこれに限定されることはなく、他の基準でもよい。例えば、直近の所定期間に顧客先で作業した回数と内容、顧客先での緊急対応回数、顧客からの機器対応要請回数、顧客先の設置機器総台数などを判断基準にしても良い。また、予めこれら複数の判断基準を設けておき、それらのうち少なくともいずれかの判断基準に達すれば、重要顧客と識別しても良い。これにより、更に幅広い顧客に対して顧客満足度の高い対応が提供できる。

顧客情報データベース８は、少なくとも顧客の所属機関（企業名、学校名など）、所属部署、住所、電話番号、代表者氏名、機器担当者氏名などの顧客情報を蓄えている。顧客情報データベース８は、また、顧客特有の注意事項（顧客先への訪問許可時間帯、敷地通用口の通過方法、機器設置部屋までのルート、作業服装、携帯品、持込み不可物品等々、過去に訪問したエンジニアが収集した情報）も記載されているため、顧客とスムーズな電話対応、顧客先訪問が可能となり、同じ内容を繰り返して尋ねる必要が無くなる。また、初めて対応するエンジニアにとっても、これらの情報によって問題なく顧客先に訪問できる。

納入機器情報データベース９は、顧客先に納入した機器の機器名、型式、製造番号などの製品情報や、顧客が保有する機器の過去の定期点検、故障修理、部品交換などのサービス履歴情報を記憶している。また、該当する機器に関する仕様変更、部品の取扱期限などの設計情報をエンジニアが登録、更新できる。これにより、顧客からの別件の問合せであっても、例えば、関連する機器の最新情報を顧客に提供することも可能になる。

なお、納入した機器には機器固有の認識番号（機器ＩＤ）が保守サービス会社から付与しておき、各機器ＩＤも納入機器情報データベース９に蓄えている。ある顧客先に同じ型式の同じ機器を複数台納入されている場合、顧客とオペレータとの電話通話では顧客が注目している機器を特定し難いので、オペレータは顧客に対して機器ＩＤを確認することで、即座に注目機器が特定でき、過去の履歴なども把握できる。一般に、納入機器の認識手段として装置メーカが付与した製造番号があるが、製造番号は機器の機種や製造拠点によって付番形態が異なる場合が多い。例えば、数字だけの場合や文字と数字の混在や、文字数が異なる。このため、例えば、数字のみの１０桁、数字とアルファベット混在の１０文字など統一フォーマットによる機器ＩＤを、顧客先に導入される各機器に対してコールセンターが各機器に付与しておくことで、その後のデータ管理が容易で顧客との対応が迅速になる。

エンジニア情報データベース１０は、顧客への技術的サポートを行なう複数人のエンジニアについて、少なくとも氏名、専門技術、専門機器、日々の行動予定、連絡手段などの情報を蓄えている。エンジニアは、特定の顧客の機器を専門に対応する専任エンジニアと、それ以外の通常エンジニアに大別され、顧客からの着信信号を基にエンジニア情報データベース１０から、少なくとも着信履歴情報、顧客情報と共に、エンジニア情報をオペレータ端末４に提供できる。

エンジニア情報データベース１０に保存されている行動予定表には、エンジニアは日々の３０分毎、２４時間３６５日の行動予定をエンジニア当人が登録し、他の顧客対応中で応対ができない場合に備えて、信頼ある別のエンジニアを割当てて登録できる。これにより、顧客からの緊急要請に対しても別のエンジニアが即応できる。また、例え深夜であってもいずれかのエンジニアが対応できる。エンジニアは、各端末からエンジニア情報データベース１０の情報を逐次更新されるため、エンジニアが対応できないことはない。

オペレータ端末４はオペレータが用いる端末装置である。オペレータ端末４は画面に後述の顧客対応画面を表示できる。顧客対応画面には、電話受付用装置３が保有する少なくとも顧客情報、納入機器情報、エンジニア情報、着信履歴情報が表示される。オペレータは、顧客対応画面の表示内容を見つつ、顧客と会話して問合せ内容を理解する。オペレータは必要に応じて顧客との会話で得た情報をオペレータ端末４から顧客対応画面に記載、修正などできる。

また、オペレータからエンジニアに対して連絡事項がある場合には、上記顧客対応画面に設けた連絡欄（不記載）に連絡事項を各端末から記録する。その際、記入者名、日時は自動的に記録される。オペレータ端末４を扱うオペレータは、端末画面に表示された顧客対応画面に表示される対応可能なエンジニア候補から最適な担当エンジニアを選択し、少なくとも顧客との通話回線、顧客対応画面の情報、通話情報を転送する。

顧客対応画面には着信した顧客の重要度を示す識別表示が表示される。顧客の重要度は、予め定めた期間中の、機器の不良動作、定期メンテナンスなどでコールセンターに問合せ（着信）した回数を基準に決められる。予め定めた期間とは、例えば、着信を受けた時刻から遡った過去１０日間、１カ月間、２カ月間、６カ月間などである。識別表示は、例えば、顧客対応画面の顧客情報欄の背景色を通常とは異なる色で示すことで、オペレータには即座に認識できる。識別表示は、サーバー内の着信履歴データベース７を基に、着信時に電話受付用装置３が判定して、自動的に顧客対応画面に識別表示を表示する。

エンジニア端末５は技術的サポートを行なうエンジニアが用いる端末装置である。エンジニア端末５の画面には、オペレータ端末４に表示された同じ顧客対応画面１２を表示し、エンジニアは、エンジニア端末５上の顧客対応画面を見ながら、顧客と通話対応できるため、顧客はオペレータに話した内容を繰り返して説明する必要はなくなる。また、必要に応じてオペレータと顧客との会話内容を記憶装置６から再生させることで、顧客との重複した会話を避けられ、迅速な対応が図れる。エンジニアは、必要に応じて顧客との通話で得た情報をエンジニア端末５から顧客対応画面に上書きでき、顧客情報データベース８に保存する。エンジニアは必要に応じて、顧客先に出向いて、設備や機器の状況を把握し、必要に応じてその場で修理する。

オペレータ端末４およびエンジニア端末５は、顧客とオペレータ、顧客とエンジニアとの間の会話内容の聞き漏らしや誤認識を防止するために、会話を録音し音声情報を記録する録音手段を有している。録音データは着信履歴データベース７に顧客毎の着信情報と対応付けて保存できる。録音データはオペレータ又はエンジニアが簡潔なテキストで手入力するか、音声認識システムを用いて自動的にテキスト情報に変換して、テキスト情報として納入機器情報データベース９にも保存される。また、必要に応じてオペレータと顧客との会話内容をオペレータ端末４もしくはエンジニア端末５で再生させることで、顧客との重複した会話を避けられ、迅速な対応が図れる。また、オペレータ及びエンジニアは、必要に応じて顧客との通話で得た情報をそれぞれの端末で顧客対応画面に上書き更新でき、顧客情報データベース８に更新保存できる。

なお、本発明によるコールセンターシステムは図１に示した構成に限られることはない。本発明によるコールセンターシステムの別の実施形態例を図２に示す。図２では、図１のように交換機２と電話受付用装置３とが別々の存在ではなく、電話受付用装置３内に電話交換機機能を持たせた装置とし、電話受付用装置３が顧客からの電話信号を受信しても良い。この場合、顧客とオペレータやエンジニアとの会話は電話受付用装置３を介してなされる。また、本構成では、顧客が緊急の要件の時、保守サービス会社の電話番号に続き、特殊番号（＃や＊記号）を入力した後、引き続いて、機器ＩＤのボタンを押すことで、電話受付用装置３を介して、該当機器に対応する専任エンジニアに繋がり、同時にエンジニア端末５に顧客情報を提供することができる。

また、別の実施形態例を図３に示す。図３では、交換器２は既存のものを使い、コールセンターシステム１は電話受付用装置３とオペレータ端末群４ａとエンジニア端末群５ａから構成してもよい。この場合、交換機２が顧客からの回線をオペレータやエンジニアに転送することはなく、電話受付用装置３がオペレータ端末やエンジニア端末に繋ぎ、顧客とオペレータ、又はエンジニア間の会話がなされる。

次に、本実施の形態によるコールセンターシステム１における動作手順を説明する。図４は動作手順を示すフローチャートである。

まず、顧客からの電話が発信された時が、フローの開始である（Ｓ１００）。
顧客の電話信号がコールセンターシステム１の交換機２に着信する（Ｓ１１０）。
着信と同時に電話受付用装置３にも繋がり、着信電話番号を検出し、着信電話番号の予め定めた数桁を基に、顧客情報データベース８から同じ番号の顧客を検索する（Ｓ１２０）。

また、着信と同時に電話受付用装置３は、ステップＳ１２０で検索した顧客について、着信履歴データベース７から過去の着信履歴を検出する。ここで電話受付用装置３は、予め定めた期間に、予め定めた規定回数以上か否かを判定する（Ｓ１３０）。ステップＳ１３０は、発信元が重要な顧客からのものであることを判断するステップであり、ここでは、代表的に予め定めた期間内の着信回数としているが、これに限ることはなく、例えば、直近（所定期間で）の顧客先での作業回数と内容、顧客先での緊急対応回数、緊急の顧客先での機器対応要請回数、顧客先の設置機器台数などを判断基準にしても良い。また、予めこれら複数の判断基準を設けておき、それらのうち少なくともいずれかの判断基準に達すれば、オペレータ端末やエンジニア端末に表示するようにしても良い。

着信履歴が、予め定めた期間に予め定めた規定回数以上ならば、フローチャートで「Ｙ」側に向かい、サーバーは顧客からの着信回線をオペレータ端末４に繋いで、オペレータは顧客からの着信を受付ける（Ｓ１４０）。この時、電話受付用装置３は、ステップＳ１２０で得た顧客情報、その顧客担当の専任エンジニアを含むエンジニア情報、その顧客に関連する納入機器情報、ステップＳ１３０で得た着信履歴情報のうちの少なくともいずれかをオペレータ端末４に送り、表示する（Ｓ１５０）。識別表示１７された顧客対応画面１２を見たオペレータは、即座にその顧客の専任エンジニアに転送する。専任エンジニアのその時の行動が別件の対応で、たとえその時、そのエンジニアが出社していなくても、識別表示１７がある場合には、優先して専任エンジニアに緊急電話で繋ぐ。ステップＳ１４０とステップＳ１５０は殆ど時間差がなく、受付けとほぼ同時に顧客情報・製品情報・識別表示される。

ここで、顧客情報にはステップＳ１３０で得た着信履歴に応じて重要顧客であることを意味する識別表示１７を施している。次に、オペレータは顧客の問合せを音声で対応すると同時に、オペレータ端末４に表示された識別表示１７を認識し、オペレータ端末４に表示されたエンジニア情報の専任エンジニアの行動予定を確認する（Ｓ１６０）。

ステップＳ１３０において、着信履歴が予め定めた期間に、予め定めた回数未満ならば、フローチャートで「Ｎ」側に向かい、サーバーは顧客からの着信回線をオペレータ端末４に繋いで、オペレータは顧客からの着信を受付ける（Ｓ１７０）。この時、サーバーは、ステップＳ１２０で得た顧客情報、その顧客担当の通常エンジニアを含むエンジニア情報、その顧客に関連する納入機器情報、ステップＳ１３０で得た着信履歴情報のうちの少なくともいずれかをオペレータ端末４に送り、表示する（Ｓ１８０）。ここで、顧客情報にはステップＳ１３０で得た着信履歴に応じて、特に重要顧客であるとの識別表示１７は施されない（Ｓ１９０）。次に、オペレータは顧客の問合せを音声で対応すると同時に、オペレータ端末４に表示された識別表示１７を認識し、オペレータ端末４に表示された通常エンジニア一覧の上位から行動予定を確認し、対応可能な最適エンジニアを選択する（Ｓ２００）。

ステップＳ１５０とＳ１８０の相違点は、表示画面に識別表示されるか否かの違いである。識別表示されていることで、オペレータは即座に、顧客と製品の絞り込み、転送先の専任エンジニアの候補の絞り込みを行なう態勢で顧客との通話に入れる。

なお、受付（Ｓ１４０、Ｓ１７０）時に顧客・製品情報表示（Ｓ１５０、Ｓ１８０）において、顧客先に納入製品が多く、顧客が問合せている機器が絞り込めない場合は、まず、顧客に対して後述する機器ＩＤを問い掛けるステップ（Ｓ１５５、Ｓ１８３）（不記載）を設けてもよい。このステップで顧客が機器ＩＤ番号を回答すると同時にオペレータ端末は音声認識して、その機器ＩＤに関する機器情報を納入機器情報データベース９から抽出して、即座にオペレータ端末に表示できる。

なお、ステップＳ１１０からステップＳ１４０まではサーバー内で瞬時に実行されるため、顧客にとっては待ち時間が無くコールセンターのオペレータに繋がったと感じ、オペレータにとっては、着信と同時に、顧客と会話する前に発信先の顧客情報や重要度が解る。このため、重要度の高い顧客の場合、顧客と会話を交わす前に即座に次の態勢を整えることができ、顧客満足度の高い応答が可能となる。

次に、識別表示の有無に関係なく、オペレータが転送先のエンジニアが対応可能であることを把握したのち、顧客情報、顧客との通話情報、電話回線を転送する（Ｓ２１０）。これ以降は、顧客との対応は転送先であるエンジニアが行う（Ｓ２２０）。オペレータとの会話で顧客の要件を満たした場合は専任エンジニアに転送せず終話してもよい。転送と同時に、既にエンジニア端末５には顧客対応画面１２が表示され、顧客情報、顧客が有する製品情報が、また、事前のオペレータとの会話情報も音声ファイルもしくはテキスト情報で確認できるため、顧客の問合せや要求に対して、顧客にとっては待ち時間が無く、的確で迅速な顧客満足度の高い応答が可能となる。

このような顧客への応対によって、顧客に対して現地に出向いての機器の検分や修理を約束などして応対を終了し、回線を遮断する（Ｓ２３０）。

最後に、上記のオペレータ及びエンジニアは顧客との応対で得た情報を基に、既存の顧客情報や製品情報を更新し、顧客情報データベース８、に保存する（Ｓ２４０）。なお、着信履歴情報はサーバーが自動的に更新する。
以上の流れでコールセンターシステム１における一連の動作フローが終了する。

次に、本実施の形態によるコールセンターシステム１におけるオペレータ端末４及びエンジニア端末５で表示される顧客対応画面について説明する。

図５は、顧客対応画面１２の一例である。
顧客対応画面１２は、少なくとも顧客情報欄１３、納入機器情報欄１４、エンジニア情報欄１５、着信履歴情報欄１６を有している。但し、画面には必ずしも常に全ての欄を表示する必要はない。少なくとも顧客情報欄１３、納入機器情報欄１４、エンジニア情報欄１５、着信履歴情報欄１６を表示する場合は、オペレータ端末４またはエンジニア端末５の画面にこれら全ての情報を表示する際には、これら各情報欄の上位の情報のみを表示して、オペレータやエンジニアが画面をスクロールすること無く一目見るだけで最低限の情報を短時間で把握することができ、顧客に待ち時間を与えること無く即座に対応がとれる。各欄の詳細情報は詳細ボタン１８を押すことで表示でき、下位の情報は各欄横のスクロールバーによって表示できる。もちろん、画面の大きさに余裕がある場合は全ての情報を表示しても良い。

顧客情報欄１３は、顧客名（会社名、大学名等）、部署名、住所、電話番号等の顧客情報が表示される。同じ顧客名で複数の部署に顧客が居る場合には、全ての顧客を表示されるが、オペレータは通話者との会話から通話者を絞り込める。または、着信電話番号の認識桁数を増やすか完全一致と設定することで通話者を絞り込み、確定することもできる。

納入機器情報欄１４は、同じ顧客、同じ部署に納品した全ての機器について、機器名、型式、納品日等の納入機器情報が表示される。同じ顧客名で多数の機器が納入されていても、上記のオペレータと通話者で担当者名が特定できれば、対象機器が絞り込まれて表示され、特定できる。顧客情報欄１３と納入機器情報欄１４は連動しているため、通話者の部署など詳細が明らかになるにつれて、納入機器が絞り込まれて表示される。このため、オペレータと通話者とのわずかな通話時間で、通話者が問合せようとしている機器が明らかになり、顧客にとっては待ち時間がなく、スムーズに詳細な問合せに移れる。

また、同じ顧客に同じ型式の機器を多数台納入している場合には、顧客とオペレータとの通話では注目している機器を特定し難い。この場合には、オペレータは、納入した機器に付与した機器固有の認識番号（機器ＩＤ）を顧客に確認することで、注目機器が特定できる。機器ＩＤも納入機器情報データベース９に各機器に対応付けて記憶されている。

また、納入機器情報欄１４の各機器名の横にある詳細ボタン１８aを押すことにより、各機器の定期点検記録、故障対応状況、部品交換履歴など詳細情報が表示できる。これにより、顧客からの問合せに対して、即座に対象とする機器の過去のサービス履歴を把握することができ、顧客とスムーズな応対ができる。

エンジニア情報欄１５は、顧客の問合せに対応するエンジニアの情報が表示される。オペレータは、エンジニアの行動予定を閲覧することで、顧客からの問合せに対して専任エンジニアもしくは複数の通常エンジニアから最適なエンジニアを選択できる。顧客情報に識別表示１７が表示された顧客については、オペレータは専任エンジニアを選択する。通常エンジニアは複数人表示され、その着信時刻において出張等の予定が無く、空き時間が多い者ほど上位に表示される。このため、オペレータは複数の通常エンジニアから選択する場合、まず最上位に位置する通常エンジニアを躊躇なく選択する。

また、エンジニア情報欄１５は、専任エンジニアと通常エンジニアに区別されてエンジニアの氏名が表示される。詳細ボタン１８ｂ、１８ｃを押すことによって、各エンジニアが予め登録した日々の行動予定、顧客対応の可否、行き先、連絡先、不在時の代理者の連絡先等が表示される。転送先が決まればオペレータは該当エンジニア名横の転送ボタン１９a、１９ｂを押すことで、そのエンジニアに顧客対応画面１２と共に顧客との回線がサーバーを介して転送される。

着信履歴情報欄１６は、過去の受付け履歴が掲載され、少なくとも受付日時が表示される。着信日の詳細ボタン１８ｄを押すことで、その他の詳細情報、例えば、対応時間、対応者、対応内容などの情報が表示される。顧客情報欄１３での識別表示１７の根拠は着信履歴情報データベースであり、予め定めた期間内に着信した回数によって、識別表示１７を行う。また、その予め定めた期間内に着信した回数を期間内着信回数欄２０に表示する。図５の例では７回であることが表示されている。これにより、上限のない「最重要」との識別表示１７とは別に、顧客の緊急度、重要度を把握することができる。

識別表示１７は、例えば、顧客対応画面１２の顧客情報欄１３の背景色を通常とは異なる色で示す。具体的には、例えば過去１０日間で２度までの着信は通常状態と定義して白色で表示し、過去１０日間で３度目の受付けでは「重要」顧客と定義して黄色表示に、５度目以上の受付けなら「最重要」顧客と定義して朱色表示と、受付回数に応じて背景色を違えて、オペレータ及びエンジニアに注意喚起を行うように施されている。

識別表示１７は、上記の例では、「通常」、「重要」、「最重要」の区別によって、顧客情報欄１３の背景色を違えて明示した。識別表示１７はこの例に限定されることはない。例えば、顧客対応画面１２の最上段のスペースに、単純に、大きなフォントの赤文字で（重要）、（最重要）と目立つように記載し、通常の場合は記載しないようにしても良い。また、顧客情報欄１３の外枠線の色を違えても良いし、顧客対応画面１２全体の背景色を違えても良い。記号であっても良い。要するに、オペレータ及びエンジニアには、顧客対応画面１２が表示されると同時に、瞬時に一目で識別できる表示であれば良い。

顧客の識別表示は画面上の表示に限らない。例えば、着信音とは異なった予め定めた注意喚起音を、少なくともオペレータ端末４またはエンジニア端末５から発するように設定しても良い。この場合も、重要度のレベルによって音質や音のパターン（断続音とし、断続の時間を変える等）を変えてもよい。

このように、オペレータ端末４では顧客と直接会話する前に少なくとも顧客の重要度を把握することができ、加えて顧客情報、顧客の機器情報を把握することができ、オペレータと顧客との直接会話が開始されると同時にスムーズにその顧客に即した対応ができ、顧客満足度を高めることができる。

なお、上記電話受付用装置３内の各種データの内容は、コールセンターシステムを保有するコールセンターの社員が閲覧することができ、関連する設計部門や営業部門等と情報共有できるので、設計変更や営業訪問の際にもこれらの顧客からの情報が活かせることができ、更に顧客満足度を高めることができる。

また、上記実施例では、顧客の重要度を示す表示は、所定期間の予め定めた着信回数を基にして自動的に顧客対応画面１２に表示ようにしたが、これに限ることはない。別の実施形態例では、顧客とオペレータ、エンジニアとの対応において、優先度が高く即座の対応を要するなどとオペレータやエンジニアが判断した場合、上記の予め定めた判断基準による自動表示とは別に、手動によって重要度表示を変更させることもできる。例えば、期間内着信回数がたとえ１回であっても、顧客先での機器の事故の発生など重要な顧客と判断した場合や再入電待ちの場合、オペレータ又はエンジニアが顧客対応画面１２上段に『ＡＡＡ』などの予め定めた記号を大きく表示させても良い。

また、顧客の重要度を判断する基準は上記の実施例に限らない。別の実施形態例として、顧客とオペレータの会話の音声を電話受付用装置３またはオペレータ端末４が解析し、両者の話し口調の速度、音程、予め定めたキーワードの出現頻度などをデータとして抽出して解析し、顧客の感情を把握して、予め定めた基準を超えた時に重要顧客と判断してもよい。基準を超えた時、オペレータ端末４、エンジニア端末５、センター管理者端末（図示せず）、表示灯（図示せず）のうちの少なくともいずれかで識別できるよう表示または点灯させる。これにより、真に緊急の顧客については短時間に、エンジニアやセンター管理者は顧客の緊急を知り、即座の対応を取る態勢がとれ、顧客満足度を高めた対応をとることができる。

また、通常、コールセンターにおいては、オペレータ端末群４aやエンジニア端末群５aの対応状況を統括、把握するセンター管理者がいる。センター管理者は、センター管理者が有する専用端末（図示せず）ではオペレータの対応状況のほか、重要顧客からの受信状況や対応状況も把握できる。重要顧客の対応をしているオペレータやエンジニアを、本明細書では仮にホットスポットと名付けると、センター管理者はホットスポットの増減を把握することができる。ホットスポットが発見できれば、オペレータが顧客と通話対応している間にセンター管理者は専任エンジニアの対応可能の確認ができる。また、ホットスポットが複数発見されたり、若しくは増加傾向にあると判断されたりした場合は、エンジニアの増強やベテランオペレータとの交代などの対応策を、オペレータ対応の間に並行して速やかに進めることができる。また、オペレータや電話受付用装置が重要と判断しなくても、顧客とエンジニアとの通話で重要と判断した場合は、エンジニアが手動で重要度表示を行ない、これをセンター管理者が状況を把握して、顧客とエンジニアとの通話の間に並行して、センター管理者が別のエンジニアの増員の準備ができ、顧客満足度を高めることができる。

このように、緊急を要する重要顧客であっても顧客が回答を得るまでの待ち時間を短く、かつ的確に対応でき、顧客満足度を高めることができる。なお、ホットスポットの把握は、センター管理者専用端末への表示だけに限ることはなく、オペレータやエンジニアの各端末にオペレータやエンジニア、センター管理者の席が離れていても確認できる表示灯を設けておき、ホットスポット状態となれば表示灯が自動的にまたはオペレータやエンジニアが手動で点灯するようにしてもよい。このようなコールセンターシステムの構成によって、コールセンター全体が状況を把握することができる。

顧客対応画面１２を表示するエンジニア端末の対応画面に、前記顧客に関し伝達したい事項を表示する表示機構を備えても良い。例えば、「この顧客が使用している装置は、過去にこのような不具合が発生した履歴があるので、まずはその部分をチェックすること。」とか、「問題があれば、まず、顧客の誰に連絡して欲しい。」など、顧客毎に最適な対応ができるようなコメント（伝言）を記録しておき、エンジニア端末５に表示させることで、迅速な対応が可能となる。この伝言には、専任エンジニアが不在の場合、別のどのエンジニアに転送して欲しいというオペレータへの伝言を記載することもできる。

また、顧客対応画面１２を表示するエンジニア端末の対応画面に、前記顧客と、前記オペレータ端末４を操作するオペレータと、の間でなされた会話をテキスト表示するテキスト表示機構を備えても良い。テキスト表示は音声データをソフトウェアで解析してテキストに変換してエンジニア端末５に表示させることで、それまでの顧客とオペレータとの間の会話が一目でわかるため、エンジニアがオペレータから、どのような会話をしたかを聞く間、顧客に待ってもらう必要が無くなる。テキスト変換は多少変換ミスがあったとしても、概要がわかれば十分である。テキスト変換した情報のうち、顧客の要望がわかるようなキーワードを予め登録しておき、そのようなキーワード毎にグループ分けして表示することも効果的である。例えば、故障というキーワードとか、シリンジ、ピペッタなどの自動分析装置の部位（機構）の名称などでソートして表示することが効果的である。

また、前記顧客対応画面１２を表示するエンジニア端末５の対応画面に、問い合わせ履歴、作業履歴、問い合わせ回数のうちの少なくとも一つを表示するようにしても良い。この表示項目は、全てのエンジニアに共通の項目としても良いし、エンジニアＡ氏は問い合わせ履歴を表示する、エンジニアＢは作業履歴を表示するようにするなど、エンジニア毎に異なる項目を表示させるようにしても良い。また、顧客毎に表示項目が自動的に選択されるようにしても良い。

また、特定顧客の装置に不定期に同一箇所で不具合が発生するなどがある場合は、当該顧客に対しての対応方法、例えば、どの個所をチェックすること、とかどの部品を交換して様子を見るなどの対応方法がだいたいわかっている場合がある。そのような対応方法を顧客毎に予め記憶させておき、顧客がオペレータ端末４などで特定された場合、エンジニア端末５にその対応方法を表示させることで、エンジニアの対応をスムーズにすることができる。

また、顧客毎に担当エンジニアを決めておく運用の場合、顧客から問い合わせがあった時点で当該担当エンジニアが不在だった場合でも、代わりのエンジニアがある程度の対応ができるように対応方法を伝言メモのような形式で記憶させておき、代わりのエンジニアの端末に、その伝言メモを表示させることも有効である。これにより、エンジニア毎に顧客に伝える指示がばらつくことを回避することができ、顧客の信頼度を高めることができる。また、伝言メモには、自分が不在の場合には、特定のエンジニアに対応させるようにという指示があっても良い。また、システムは、このような担当エンジニアが不在である場合の、代わりのエンジニアの転送情報を記憶しておき、担当エンジニアが不在の場合、システムが自動的に顧客問い合わせを転送するようにしても良い。これにより、顧客の対応待ち時間をより少なくすることができる。

また、緊急時の対応方法を記憶しておき、顧客とオペレータの間の会話をテキスト解析等で解析して、緊急の対応が必要であることをシステムが認識した場合に、当該記憶された緊急の対応方法をエンジニア端末５に表示する機能があっても良い。

更に、顧客とオペレータの間の会話をテキスト解析等で解析して、顧客の要望を予め定めたカテゴリーに分類し、分類されたカテゴリー毎に予め定めた対応方法をエンジニア端末に表示させることもできる。予め定めたカテゴリーとは、装置の故障、装置の使い勝手等の使用上の不満、その他問い合わせ、など、装置毎に予め定めておき、どのカテゴリーの問い合わせかを判断するためのキーワードを決めておく。例えば、そのようなキーワードが会話中に３回以上表示された場合は、この問い合わせはどのカテゴリーに分類される問い合わせかをシステムが判断する。このような構成により、迅速な対応が可能となる。

また、顧客からの問い合わせに対しその場では解決できず、宿題として預かることがある。その場合、ずっと放置すると顧客満足度は下がる。そのため、例えば２日、１週間など、予め対応期限をシステムが決めるか、あるいはエンジニアが期限を設定し、その期限までに対応が完了したか否かをシステムが判断して、対応が完了していない場合は、定期的にエンジニア端末５にフォローの表示をするようにすることもできる。そのため、対応が完了したか否かの情報を記憶させる。この情報は担当エンジニアが自ら入力することができる。

図６〜図９を用いて本発明の別の実施例を説明する。
図６は顧客５０から電話、メール、またはインターネットを介して、コールセンタ５１が問い合わせ（５２）を受けた時の処理システムの概念を示す図である。コールセンタ５１のオペレータ６１が電話、メール、またはインターネットを介して顧客から問い合わせを受けた際、受付・対応内容をテキストデータ５４で保管する。テキストデータ化するためには、録音された音声記録を音声認識ソフトウェアでテキストデータに変換して保管する方法、オペレータ、あるいは専門の人が聞きとった音声をワープロ等でテキスト入力する方法などが利用できる（５３）。テキスト化された情報をテキストマイニング用のソフトウェア等を利用して分析する（５５）。分析手法としては、テキスト記録された情報に予め登録したキーワードが出てきたかどうかを検索する。キーワードとしては、顧客名、装置型式名、エラー（アラーム）コード、サービス部品名、部品在庫確認、部品価格確認、見積もり依頼・確認、その他の予め登録したキーワードなどがある。それら予め登録されたキーワードがテキストデータ中に出てきた場合は、キーワード毎に会話中に出てきた旨のフラグを付ける（５６）。例えば、１ヶ月の会話中にＡという顧客名が１０回あった場合は、Ａという顧客が使用している分析装置に何らかの問題があり、Ａという顧客から１ヶ月の間に１０回問い合わせを受けたことが推定される。そのような場合、サービスエンジニアをＡという顧客に派遣し、顧客から直接話を聞くことにより、顧客が困っていることを正確に知ることができ、顧客満足度を向上することができる。また、１ヶ月の会話の間に、ＺＺＸという製品型式名が２０回出てきた場合（この場合、顧客は限定しないで検索する、あるいは顧客毎に問い合わせ数を累積集計し設定顧客数に応じた上位の顧客を検索する）は、例えばＺＺＸという製品に何らかの問題が発生していることが推定される。ＺＺＸが新製品である場合は、顧客がＺＺＸという製品の取り扱いに不慣れであるため問い合わせが集中したのかも知れないし、あるいはＺＺＸという製品の設計に不具合があり、問い合わせが集中したのかも知れない。そのような情報をサービス拠点５８にいるサービスエンジニア５９に伝える（５７）ことで、サービスエンジニアは、ＺＺＸという製品について、顧客からどのような問い合わせを受けたのか、記録されている顧客との会話データを直接チェックすることで、発生している問題を正確に把握することができる。その上で、ＺＺＸという製品を使用している顧客を訪問し（６０）、不具合を修正することで、故障の発生を事前に防止することができたりできる。また、そのような不具合をまだ経験していない顧客に対しても、不具合を経験する前に使用方法の説明をすることで、顧客が不具合を経験することを事前に防止することができるので、顧客満足度を向上することができる。装置使用時にエラーコードが発生した場合、そのエラー内容が顧客に理解できない場合は、顧客からコールセンターに問い合わせが来る。１ヶ月の間に同一のエラーコードについて顧客から問い合わせがあった場合、当該エラーコードは顧客にとってわかりにくいものであったり、あるいは顧客が誤った使い方をしやすいため、エラーが発生するものである可能性がある。同一のエラーコードについての問い合わせが多いことをサービスエンジニアに伝えることで、サービスエンジニアがテキストデータをチェックし、何故そのエラーコードが発生しやすいのかを確認し、顧客に対し、説明を行うあるいは部品交換などの処置を推奨するとか、装置設計者に対し、装置設計の改善を求めるとかの能動的なアクションを取ることができるようになる。アラームコードについても、同様である。

また、同一のサービス部品について問い合わせが集中していることがわかれば、何故その部品に問い合わせが集中したのかを調査することができる。例えば、同一仕様の部品であっても、部品の購入先が変わったため不具合が発生した可能性もあるし、同一の部品購入先でもロットが変わったため、不具合が発生した可能性もある。また、マニュアルの記載が適切でないため、その部品の交換方法が良くわからず、問い合わせが集中した可能性もある。その原因を突き止めることにより、サービスエンジニアが顧客へ適切かつタイムリーに説明、あるいは不具合対策を行うことができ、顧客満足度を向上することができる。特定の部品について在庫確認が多かった場合は、その在庫を増やすことで、部品の欠品等を防ぐことができ、またインターネットに価格や納期などの部品情報を公開している場合は、問合せの多い部品の情報を追加することで顧客からの問合せコールの低減にも繋がり、顧客満足度を向上させることができる。また、何故、その部品について在庫確認が多かったのかの原因を検討することで、顧客の困っていることを迅速に把握することができる。

特定の製品について見積もり依頼・確認が多かった場合は、その製品について顧客の関心が高いことを意味するので、その製品について積極的にＰＲすることで、売上を伸ばすこともできる。また、製品そのものでなくオプションやメンテナンス依頼の見積もりについても、タイムリーに対応することができるようになる。また、サービスエンジニアが気になっている特定キーワードを登録することもできる。例えば、光源ランプなどの消耗品名や、精度管理のやり方、など測定方法についての具体的な問い合わせの名称を登録することができる。また、予めキーワードを登録しないこともできる。すなわち、テキストマイニングで単純に使われた用語の多い順で、リストを作成し、そのうち、実際には意味の無い言葉（例えば、お世話になっておりますなどの挨拶）を除き、意味のある言葉のみを抽出し、抽出された言葉のランキングを作成することもできる。そのランキングされた言葉が例えば１ヶ月の間に３０回出現した場合は、サービスエンジニア等にその事実を展開することで、予期せぬ問題が、大きな問題になる前に解決することができる可能性がある。なお上記は特定キーワードを検索する事例を記載したが、単純に問い合わせの多い顧客名，装置型式名などをランキングして、例えば上位の１０位をサービスエンジニアに通知することでも良い（図１１参照）。同通知により上位の顧客に巡回訪問を実施したり、上位の装置型式の技術資料を問い合わせに備えて常時携行したり、顧客満足の向上に繋がる行動を起こすことが可能になる。また上述は、検索結果をサービスエンジニアに通知する手順であるが、直接顧客へ通知をしてもよい（図１０参照）。例えば、同一エラーコードの問い合わせが多い顧客には、そのエラーに関する予防保全メニューの実施を推奨する通知を出すことで、予期せぬ装置稼動停止の未然防止に結び付けることも可能である。同様に部品の問い合わせが多い顧客には、部品リストの送付案内やインターネットに公開されている部品情報の閲覧手順を案内することで、顧客満足度向上に結び付けることも可能である。図７は予め登録したキーワード毎の問い合わせランキング例を示したものである。活用用途例には、このようなランキングを行うことによるメリットを記載している。図８は、テキスト情報を解析した結果のサービスエンジニアに対するメールでの展開例を示す。この例では、雪山三太郎のみに対してメール送信しているが、登録されたメンバー全員に同時に送信することもできる。登録されたメンバーは、サービスエンジニアだけでなく、工場の設計者や品質保証部のメンバーなど適宜選択できる。また、検索されるキーワードの内容に応じて宛先メンバーを変えることもできる。例えば、装置型式ＺＺＸについての情報は、海川二郎、谷水四郎を宛先に登録し、装置型式ＧＦＤについての情報は、雲霧五郎、雪山三太郎を宛先に登録するということもできる。

メールの本文には、設定されたキーワードの内容、検索された期間などを記載するとともに、ランキングの日付にはリンクが貼ってあり、メールシステム上でそのリンクをクリックすることで、検索された内容を見ることができる。
図９には、このようなコールセンターシステムのフローチャートを示す。情報更新までのステップは図４と同一である。その後、テキストデータ化した記録から予め設定したキーワードを含むかどうかのステップ、キーワードを含んでいた場合は、キーワード毎に、予め設定した期間（１週間、１ヶ月など）で、出現した回数が、設定した回数（閾値）を超えているかどうかをチェックし、超えていた場合は設定した部署へ通知するステップが記載されている。

１・・・コールセンターシステム
２・・・交換機
３・・・電話受付用装置
４・・・オペレータ端末
４ａ・・・オペレータ端末群
５・・・エンジニア端末
５ａ・・・エンジニア端末群
６・・・記憶装置
７・・・着信履歴データベース
８・・・顧客情報データベース
９・・・納入機器情報データベース
１０・・・エンジニア情報データベース
１１・・・顧客電話器
１２・・・顧客対応画面
１３・・・顧客情報欄
１４・・・納入機器情報欄
１５・・・エンジニア情報欄
１６・・・着信履歴情報欄
１７・・・識別表示
１８・・・詳細ボタン
１９・・・転送ボタン
２０・・・期間内着信回数欄
５０・・・顧客
５１・・・コールセンタ
５２・・・問い合わせ
６１・・・コールセンタのオペレータ

Claims (11)

1. 顧客に納品した機器の点検、修理などを行うエンジニアに顧客からの問合せ情報を転送するコールセンターシステムにおいて、
   前記顧客からの通信を受ける交換機と、
   少なくとも前記顧客からの通信内容を記憶する電話受付用装置と、
   前記顧客を特定する情報を保存する顧客情報データベースと、
   前記顧客に納品した機器を特定する情報と、前記機器の点検、修理などの履歴情報と、を保存する機器情報データベースと、
   前記電話受付用装置に接続され前記顧客に対応する顧客対応画面に前記顧客を特定する情報と、前記顧客に納品した機器を特定する情報と、前記機器の点検、修理などの履歴情報と、を表示し、前記交換機が受けた顧客からの通信を、受付若しくは、予め定められた複数の転送先のうちいずれか一つの転送先に転送指示するオペレータ端末と、
   前記転送先であるエンジニア端末と、
   を有するコールセンターシステムであって、
   前記電話受付用装置に記憶された顧客からの通信内容をテキストデータ化するテキストデータ化機構と、該テキストデータ化機構によりテキストデータ化されたテキスト情報を記憶するテキストデータ記憶機構と、
   該テキストデータ記憶機構に記憶されたテキストデータから、予め設定したキーワードが含まれる通信を抽出する抽出機構を備え、
   前記エンジニア端末は、前記顧客対応画面および前記キーワードを表示および上書き更新可能であることを特徴とするコールセンターシステム。
2. 請求項１記載のコールセンターシステムであって、
   前記抽出機構は、前記予め設定したキーワードの少なくとも１つについて、その出現頻度に基づいてランキングするランキング機構を備えたことを特徴とするコールセンターシステム。
3. 請求項１または２記載のコールセンターシステムにおいて、
   前記予め設定したキーワードが、顧客名、装置型式名、アラームコード、エラーコード、サービス部品名、部品在庫確認、部品価格、見積依頼、の少なくとも１つを含むことを特徴とするコールセンターシステム。
4. 請求項３記載のコールセンターシステムにおいて、
   前記予め設定したキーワードが、部品在庫確認、部品価格、見積依頼、の少なくとも１つである場合、その内容についてサービス部品名、装置型式名の少なくとも１つについて分類する分類機構を備えたことを特徴とするコールセンターシステム。
5. 請求項１または２記載のコールセンターシステムにおいて、
   前記予め設定したキーワードがアラームコード、エラーコード、サービス部品名、部品在庫確認、部品価格、見積依頼、の少なくとも１つを含み、顧客名あるいは装置型式の少なくともいずれか毎に、該キーワードの出願頻度に基づいてランキングする機能を備えたことを特徴とするコールセンターシステム。
6. 請求項２記載のコールセンターシステムにおいて、
   前記ランキング機構によりランキングされた予め設定したキーワードの出現回数が、予め定めた期間に、予め定めた回数以上出現した場合は、その旨を通知する通知機構を備えたことを特徴とするコールセンターシステム。
7. 請求項６記載のコールセンターシステムにおいて、
   前記予め定めた期間、予め定めた回数の少なくともいずれかを設定する設定機構を備えたことを特徴とするコールセンターシステム。
8. 請求項６記載のコールセンターシステムにおいて、
   前記通知機構は、予め登録されたメンバーへの電子メールによる通知であることを特徴とするコールセンターシステム。
9. 請求項８記載のコールセンターシステムにおいて、前記電子メールによる通知は、予め設定したキーワード、検索した期間、顧客毎の検索結果、装置型式毎の検索結果、の少なくとも１つの通知するものであることを特徴とするコールセンターシステム。
10. 請求項１〜９のいずれかに記載のコールセンターシステムにおいて、
    前記予め設定したキーワードを、設定するキーワード設定機構を備えたことを特徴とするコールセンターシステム。
11. 請求項２記載のコールセンターシステムにおいて、
    前記ランキング機構によりランキングされた予め設定したキーワードの出現回数が、予め定めた期間に、予め定めた回数以上出現した場合は、そのテキストに関連する顧客に対し案内を通知する、案内通知機構を備えたことを特徴とするコールセンターシステム。

Images