JP2020052521A - 事故対応装置、事故対応システム、事故対応方法および事故対応プログラム - Google Patents

Abstract

【課題】 チャットによって円滑な事故対応を可能とする事故対応装置、事故対応システム、事故対応方法および事故対応プログラムを提供する。【解決手段】 事故対応装置は、ユーザの事故情報に応じて、担当者テーブルから担当者を探索する担当者探索部と、前記ユーザと、前記担当者探索部が探索した第１担当者とが参加するチャットルームを提供するチャット提供部と、を備えることを特徴とする。【選択図】 図２

Description

本発明は、事故対応装置、事故対応システム、事故対応方法および事故対応プログラムに関する。

事故対応に必要な情報を保険会社からユーザに伝え、当該事故項目に従ってユーザから回答を得ることで事故対応を行うシステムが開示されている（例えば、特許文献１参照）。

特開２００４−８６８４４号公報

近年、携帯端末の普及により、チャットが広く利用されるようになっている。例えば、チャットを用いることで事故対応に関する問い合わせなどを容易に確認することができるようになる。すなわち、チャットによって円滑な事故対応が可能となる。しかしながら、チャットによって事故対応を可能とする技術についてはまだ開示されていない。

本発明は、上記課題に鑑みなされたものであり、チャットによって円滑な事故対応を可能とする事故対応装置、事故対応システム、事故対応方法および事故対応プログラムを提供することを目的とする。

本発明に係る事故対応装置は、ユーザの事故情報に応じて、担当者テーブルから担当者を探索する担当者探索部と、前記ユーザと、前記担当者探索部が探索した第１担当者とが参加するチャットルームを提供するチャット提供部と、を備えることを特徴とする。

上記事故対応装置において、前記チャット提供部が前記第１担当者からのチャットメッセージを受信するか否かを監視する監視部と、前記チャット提供部が前記ユーザからのチャットメッセージを受信してから所定時間経過するまでに、前記チャット提供部が前記第１担当者からのチャットメッセージを受信しない場合に、前記第１担当者の端末にアラートメッセージを送信する送信部と、を備えていてもよい。

上記事故対応装置において、前記チャットルームに対して前記第１担当者の参加が開始されたか否かを監視する監視部と、前記チャット提供部が前記チャットルームを生成してから所定時間経過するまでに前記第１担当者による前記チャットルームへの参加開始が検知されない場合に、前記第１担当者の端末に対してアラートメッセージを送信する送信部と、を備えていてもよい。

上記事故対応装置において、各担当者に関連付けて対応可能時間を格納する対応可能時間テーブルを参照することで前記第１担当者の対応可能時間を取得し、前記対応可能時間外に前記ユーザの端末から前記チャットルームにチャットメッセージが送信された場合に、前記チャットルームに応答メッセージを自動送信する自動応答部を備えていてもよい。

上記事故対応装置において、前記対応可能時間テーブルは、前記チャットルームの継続識別子を各担当者に関連付けて格納し、前記自動応答部は、前記第１担当者に関連付けられた前記継続識別子が継続を示している場合に、前記チャットルームに前記応答メッセージを自動送信しなくてもよい。

上記事故対応装置において、前記継続識別子は、前記第１担当者の端末からの入力情報に応じて変更可能としてもよい。

上記事故対応装置において、前記担当者探索部は、引継要求に応じて、前記担当者テーブルから前記第１担当者の引継担当者である第２担当者を探索し、前記チャット提供部は、前記第２担当者を前記チャットルームに参加させてもよい。

上記事故対応装置において、前記チャット提供部は、前記ユーザの端末に認証キーを送信し、前記ユーザの端末から前記認証キーを受信した場合に前記ユーザを前記チャットルームに参加させてもよい。

本発明に係る事故対応システムは、ユーザの事故情報に応じて、担当者テーブルから担当者を探索する担当者探索部と、前記ユーザと前記担当者探索部が探索した担当者とが参加するチャットルームを提供するチャット提供部と、を備える事故対応装置と、前記ユーザからのチャットメッセージを送信し、前記チャットルーム内のチャットメッセージの履歴を表示する第１端末と、
前記担当者からのチャットメッセージを送信し、前記チャットルーム内のチャットメッセージの履歴を表示する第２端末と、を備えることを特徴とする。

本発明に係る事故対応方法は、担当者探索部が、ユーザの事故情報に応じて、担当者テーブルから担当者を探索し、チャット提供部が、前記ユーザと、前記担当者探索部が探索した担当者とが参加するチャットルームを提供する、ことを特徴とする。

本発明に係る事故対応プログラムは、コンピュータに、ユーザの事故情報に応じて、担当者テーブルから担当者を探索する処理と、前記ユーザと、探索された担当者とが参加するチャットルームを提供する処理と、を実行させることを特徴とする。

本発明によれば、チャットによって円滑な事故対応が可能な事故対応システム、事故対応方法および事故対応プログラムを提供することができる。

実施形態に係る事故対応システムのブロック図である。 （ａ）は事故対応装置の機能ブロック図であり、（ｂ）は事故対応装置のハードウェア構成を説明するためのブロック図である。 （ａ）は第１端末〜第３端末の機能ブロック図であり、（ｂ）は制御部のハードウェア構成を説明するためのブロック図である。 事故対応の概要について説明するための図である。 事故対応システムの動作を表すフローチャートを例示する図である。 事故対応システムの動作を表すフローチャートを例示する図である。 ユーザ情報テーブルを例示する図である。 担当者テーブルを例示する図である。 引継担当者テーブルを例示する図である。 メイン担当者モードにおいて、チャット提供部が第１端末からチャットメッセージを受信した場合に実行されるフローチャートを例示する図である。 （ａ）はメイン担当者の監視テーブルを例示する図であり、（ｂ）は引継担当者の監視テーブルを例示する図である。 引継担当者モードにおいてチャット提供部が第１端末からチャットメッセージを受信した場合に実行されるフローチャートを例示する図である。 （ａ）はメイン担当者モードにおいてアラートメッセージが送信される場合のタイムチャートを例示する図であり、（ｂ）は引継担当者モードにおいてアラートメッセージが送信される場合のタイムチャートを例示する図であり、（ｃ）はメイン担当者が返信しなかった場合に引継担当者モードに移行する場合のタイムチャートを例示する図である。 チャットルームが生成された場合に実行されるフローチャートを例示する図である。 メイン担当者モードから引継担当者モードに移行した場合に実行されるフローチャートを例示する図である。

以下、図面を参照しつつ、実施形態について説明する。

（実施形態）
図１は、実施形態に係る事故対応システム１００のブロック図である。図１で例示するように、事故対応システム１００は、事故対応装置１０、ネットワーク３０、第１基地局４０ａ〜第３基地局４０ｃ、第１端末５０ａ〜第３端末５０ｃなどを備えている。なお、図１においては、基地局および端末は３台のみ図示してあるが、それ以上の基地局および端末が備わっていてもよい。また、各端末がそれぞれ異なる基地局と通信するように図示されているが、１つの基地局に対して複数の端末が通信可能であってもよい。

事故対応装置１０は、サーバなどのコンピュータである。ネットワーク３０は、インターネットなどの電気通信回線である。第１基地局４０ａ〜第３基地局４０ｃは、第１端末５０ａ〜第３端末５０ｃと無線通信するための基地局である。事故対応装置１０と第１端末５０ａ〜第３端末５０ｃとは、ネットワーク３０およびいずれかの基地局を介して通信を行う。なお、第１端末５０ａ〜第３端末５０ｃは、有線でネットワーク３０と接続される構成を有していてもよい。第１端末５０ａ〜第３端末５０ｃは、デスクトップＰＣ、ノートＰＣなどの端末であってもよく、スマートフォンなどの携帯端末であってもよい。これらの第１端末５０ａ〜第３端末５０ｃには、ＩＰアドレス認証によるアクセス制限などを行ってもよい。

図２（ａ）は、事故対応装置１０の機能ブロック図である。図２（ａ）で例示するように、事故対応装置１０は、ユーザ情報テーブル格納部１１、担当者探索部１２、担当者テーブル格納部１３、チャット提供部１４、メール送信部１５、返信漏れ監視部１６、監視テーブル格納部１７、自動応答部１８などとして機能する。

図２（ｂ）は、事故対応装置１０のハードウェア構成を説明するためのブロック図である。図２（ｂ）で例示するように、事故対応装置１０は、ＣＰＵ１０１、ＲＡＭ１０２、記憶装置１０３、通信装置１０４、入力機器１０５などを備える。これらの各機器は、バスなどによって接続されている。ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１は、中央演算処理装置である。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１０２は、ＣＰＵ１０１が実行するプログラム、ＣＰＵ１０１が処理するデータなどを一時的に記憶する揮発性メモリである。記憶装置１０３は、不揮発性記憶装置である。記憶装置１０３として、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、フラッシュメモリなどのソリッド・ステート・ドライブ（ＳＳＤ）、ハードディスクドライブに駆動されるハードディスクなどを用いることができる。記憶装置１０３に記憶されている事故対応プログラムをＣＰＵ１０１が実行することによって、事故対応装置１０の各部の機能が実現される。なお、事故対応装置１０の各部の機能は、それぞれ専用の回路等によって構成されていてもよい。通信装置１０４は、ネットワーク３０に対するインタフェースである。入力機器１０５は、情報を入力するための装置であり、キーボード、マウスなどである。

図３（ａ）は、第１端末５０ａ〜第３端末５０ｃの機能ブロック図である。図３（ａ）で例示するように、第１端末５０ａ〜第３端末５０ｃは、通信装置５１、制御部５２、ユーザインタフェース５３などを備えている。

通信装置５１は、第１端末５０ａ〜第３端末５０ｃが第１基地局４０ａ〜第３基地局４０ｃと無線通信するための通信装置である。制御部５２は、第１端末５０ａ〜第３端末５０ｃの各部を制御する。ユーザインタフェース５３は、タッチパネル装置などであり、表示機能および情報入力機能を備えている。

通信装置５１は、事故対応装置１０から電子メールを受信する。制御部５２は、通信装置５１が受信した電子メールをユーザインタフェース５３に表示させる。

また、通信装置５１は、事故対応装置１０からチャットメッセージを受信する。制御部５２は、通信装置５１が受信したチャットメッセージをユーザインタフェース５３に表示させる。一方、ユーザによってチャットメッセージがユーザインタフェース５３に入力された場合、制御部５２は、通信装置５１に当該チャットメッセージを事故対応装置１０に送信させる。

また、制御部５２は、通信装置５１を制御することで、ユーザがユーザインタフェース５３を操作することで入力した情報を、ネットワーク３０上のウェブサイトに送信することができる。

図３（ｂ）は、制御部５２のハードウェア構成を説明するためのブロック図である。図３（ｂ）で例示するように、制御部５２は、ＣＰＵ２０１、ＲＡＭ２０２、記憶装置２０３などを備える。これらの各機器は、バスなどによって接続されている。ＣＰＵ２０１は、中央演算処理装置である。ＲＡＭ２０２は、ＣＰＵ２０１が実行するプログラム、ＣＰＵ２０１が処理するデータなどを一時的に記憶する揮発性メモリである。記憶装置２０３は、不揮発性記憶装置である。記憶装置２０３として、例えば、ＲＯＭ、フラッシュメモリなどのソリッド・ステート・ドライブ（ＳＳＤ）、ハードディスクドライブに駆動されるハードディスクなどを用いることができる。記憶装置２０３に記憶されているプログラムをＣＰＵ２０１が実行することによって、制御部５２の各機能が実現される。制御部５２の各機能は、それぞれ専用の回路等によって構成されていてもよい。

次に、事故対応システム１００の各部の動作の詳細について説明する前に、事故対応の概要について説明する。図４は、事故対応の概要について例示する図である。まず、事故に遭遇したユーザは、保険会社に連絡することで事故に関する情報を伝える。その後、事故対応のメイン担当者が定まり、チャットルームが生成される。ユーザおよびメイン担当者は、当該チャットルームに参加する。ユーザは、当該チャットルームにチャットメッセージを送信することで、メイン担当者に事故対応について問い合わせを行う。メイン担当者は、当該チャットルームにチャットメッセージを送信することで、ユーザに回答する。

メイン担当者には、対応可能時間が設定されている。例えば、図４で例示するように、メイン担当者には９：００（開始時間）から１７：００（終了時間）という対応可能時間が設定されている。終了時間を過ぎてかつ継続モードがオフに設定されている場合にユーザがチャットメッセージを送信した場合、チャットルームに自動応答メッセージが送信される。当該自動応答メッセージには、ユーザが希望する選択肢が含まれている。選択肢には、例えば、（１）返信不要、（２）翌日の対応可能時間にメイン担当者からのチャットメッセージの返信を希望する、（３）引継担当者からのチャットメッセージの返信を希望する、の３つの選択肢がユーザの端末に表示される。

（１）が選択された場合、チャットルームに「承知致しました」などの自動応答メッセージが送信される。この場合、メイン担当者からも引継担当者からもチャットメッセージは返信されない。

（２）が選択された場合、ユーザは、必要に応じて、問い合わせに係るチャットメッセージをさらにチャットルームに送信する。ユーザは、翌日にメイン担当者からチャットメッセージが返信されることを待つ。メイン担当者には、電子メールなどで、ユーザからチャットメッセージが送信されていることが伝えられる。それにより、メイン担当者は、翌日の対応可能時間に、ユーザからの問い合わせに対するチャットメッセージをチャットルームに送信する。

（３）が選択された場合、引継担当者がチャットルームに参加する。引継担当者は、チャットルームのメッセージのやりとりの履歴を確認することで、事故対応の流れを把握することができる。引継担当者は、チャットルームにチャットメッセージを送信することで、ユーザに回答する。なお、引継担当者には、電子メールなどで、ユーザから引継要求があることが伝えられる。

なお、メイン担当者の対応可能時間を過ぎていても継続モードがオンに設定されていれば、自動応答メッセージは送信されず、継続モードがオフに設定されるまで、メイン担当者とユーザとの間のチャットのやりとりは継続される。また、引継担当者が事故対応を引き継いだ場合に引継担当者の継続モードがオンに設定されていれば、メイン担当者の対応可能時間になっても、引継担当者とユーザとのチャットのやりとりは継続される。

続いて、事故対応装置１０の動作の詳細について説明する。図５および図６は、事故対応装置１０の動作を表すフローチャートを例示する図である。まず、ユーザは、事故に遭遇した場合、事故対応を求めて保険会社に連絡する。例えば、ユーザは、ユーザ識別情報、事故情報等のユーザ情報を保険会社に伝える。保険会社への連絡手段は、電話などであるが、特に限定されるものではない。例えば、ユーザは、インターネット上のウェブサイトにアクセスし、ユーザ識別情報、事故情報等のユーザ情報を入力してもよい。ユーザ識別情報とは、ユーザを識別するための情報であって、ユーザ名、ユーザの電話番号、電子メールアドレスなどである。事故情報とは、事故種別、事故の場所等である。

これらのユーザ情報は、例えば入力機器１０５を介してユーザ情報テーブル格納部１１のユーザ情報テーブルに格納される（ステップＳ１）。図７は、ユーザ情報テーブルを例示する図である。図７の例では、ユーザ名、電話番号、メールアドレス、事故種別および場所が関連付けて格納されている。

担当者探索部１２は、担当者テーブル格納部１３に格納されている担当者テーブルを参照し、ユーザ情報テーブルの事故情報に応じて、該当する担当者をメイン担当者として探索する（ステップＳ２）。図８は、担当者テーブルを例示する図である。図８で例示するように、担当者テーブルでは、事故種別に担当者が関連付けられている。また、各担当者には、対応可能時間が設定されている。対応可能時間とは、メイン担当者がチャットルームを介してユーザとメッセージの送受信を行うことが可能な時間帯（開始時間から終了時間）のことである。ユーザ情報テーブルの事故情報に合致する担当者のうち、対応可能時間内の担当者が探索される。該当する担当者が複数である場合には、優先順位などに応じて担当者を探索してもよい。

次に、チャット提供部１４は、ユーザとメイン担当者とが参加可能なチャットルームを生成する（ステップＳ３）。それにより、ユーザおよびメイン担当者がチャットルームに参加可能となる。チャットルームが生成されてから、引継担当者が当該チャットルームに参加可能となるまでのモードを、以下、メイン担当者モードと称することがある。また、引継担当者が当該チャットルームに参加可能となってから、メイン担当者の対応可能時間内かつ引継担当者の継続モードがオフの条件が整うまでのモードを、以下、引継担当者モードと称することがある。

次に、メール送信部１５は、ユーザの端末に電子メールを送信する（ステップＳ４）。図１の例では、ユーザの端末は、第１端末５０ａであるものとする。例えば、メール送信部１５は、ユーザ情報テーブルに格納されている電話番号または電子メールアドレス宛てに電子メールを送信することで、第１端末５０ａに電子メールを送信する。電子メールには、チャット提供部１４が生成したチャットルームに入室するための認証キー、ＵＲＬなどが含まれている。認証キーおよびＵＲＬは、チャット提供部１４によって生成される。

また、メール送信部１５は、メイン担当者の端末に電子メールを送信する（ステップＳ５）。図１の例では、メイン担当者の端末は、第２端末５０ｂであるものとする。電子メールには、チャット提供部１４が生成したチャットルームに関する情報が含まれている。

ユーザは、第１端末５０ａのユーザインタフェース５３を操作することで、チャット提供部１４によって生成されたＵＲＬにアクセスし、認証キーを用いて認証を行うことで、チャットルームに参加することができる。ユーザは、チャットルームに参加後、第１端末５０ａのユーザインタフェース５３を操作することで、チャットルームにチャットメッセージを送信できるようになる。また、ユーザは、メイン担当者が第２端末５０ｂのユーザインタフェース５３を操作してチャットルームに送信したチャットメッセージを、第１端末５０ａのユーザインタフェース５３で確認できるようになる。また、ユーザは、第１端末５０ａのユーザインタフェース５３に表示されるチャットルームの画面をスクロールすることで、送受信したチャットメッセージの履歴を確認することができる。

メイン担当者には、事前に管理サイトのＵＲＬ、当該ＵＲＬにログインするためのＩＤ、パスワードなどが発行されている。メイン担当者は、自身のＩＤおよびパスワードでログインした後、チャットルーム一覧から該当のチャットルームを検索することでチャットルームに参加することができる。このように、メイン担当者がチャットルームに参加することは、ログイン等によってチャットルーム内に入室することを意味する。メイン担当者は、チャットルームに参加後、第２端末５０ｂのユーザインタフェース５３を操作することで、チャットルームにチャットメッセージを送信できるようになる。また、メイン担当者は、ユーザが第１端末５０ａのユーザインタフェース５３を操作してチャットルームに送信したチャットメッセージを、第２端末５０ｂのユーザインタフェース５３で確認できるようになる。また、メイン担当者は、第２端末５０ｂのユーザインタフェース５３に表示されるチャットルームの画面をスクロールすることで、送受信したチャットメッセージの履歴を確認することができる。

なお、チャットルームにチャットメッセージを送信することは、端末がチャットメッセージを送信し、チャット提供部１４が当該チャットメッセージを受信して他の参加者の端末に当該チャットメッセージを送信することを意味する。

メイン担当者がチャットルームに参加した場合、チャット提供部１４は、担当者テーブルから、チャットルームに参加したメイン担当者の対応可能時間を取得する（ステップＳ６）。図８で例示したように、各担当者に関連付けて対応可能時間が格納されている。例えば、メイン担当者の対応可能時間が、９時から１７時までに設定されているものとする。

次に、チャット提供部１４は、担当者テーブルに格納されている継続モードを取得する（ステップＳ７）。継続モードとは、終了時間を過ぎた場合にメイン担当者がチャットを継続する、終了時間を過ぎた場合にメイン担当者がチャットを継続しない、を識別するための継続識別子である。なお、メイン担当者は、必要に応じて、ユーザインタフェース５３に切替情報を入力することで継続モードを「オン」から「オフ」に切り替えることができる。

次に、チャット提供部１４は、現在時刻が対応可能時間外であるか否かを判定する（ステップＳ８）。ステップＳ８で「Ｎｏ」と判定された場合、ステップＳ６から再度実行される。ステップＳ８で「Ｙｅｓ」と判定された場合、チャット提供部１４は、担当者テーブルから、チャットルームに参加したメイン担当者の継続モードが「オフ」であるか否かを判定する（ステップＳ９）。ステップＳ９で「Ｎｏ」と判定された場合、ステップＳ６から再度実行される。

ステップＳ９で「Ｙｅｓ」と判定された場合、チャット提供部１４は、現在時刻が対応可能時間内であるか否かを判定する（ステップＳ１０）。ステップＳ１０で「Ｙｅｓ」と判定された場合、ステップＳ６から再度実行される。ステップＳ１０で「Ｎｏ」と判定された場合、チャット提供部１４は、第１端末５０ａからチャットメッセージを受信したか否かを判定する（ステップＳ１１）。ステップＳ１１で「Ｎｏ」と判定された場合、ステップＳ６から再度実行される。

ステップＳ１１で「Ｙｅｓ」と判定された場合、チャット提供部１４は、自動応答部１８が作成するメッセージを第１端末５０ａにチャットメッセージとして送信する（ステップＳ１２）。本実施形態においては、自動応答部１８は、（１）返信不要、（２）翌日の対応可能時間にメイン担当者からのチャットメッセージの返信を希望する、（３）引継担当者からのチャットメッセージの返信を希望する、の３つの選択肢を作成する。ユーザは、第１端末５０ａのユーザインタフェース５３を操作することで、いずれかの選択肢をチャット提供部１４に送信することができる。

チャット提供部１４は、いずれかの選択肢を受信するまで待機し、その後、（１）の返信不要が選択されたか否かを判定する（ステップＳ１３）。ステップＳ１３で「Ｙｅｓ」と判定された場合、チャット提供部１４は、自動応答部１８が作成するチャットメッセージを第１端末５０ａに送信する（ステップＳ１４）。具体的には、チャット提供部１４は、「承知致しました」といったチャットメッセージを送信する。その後、ステップＳ１０から再度実行される。

ステップＳ１３で「Ｎｏ」と判定された場合、チャット提供部１４は、（２）の返信希望が選択されたか否かを判定する（ステップＳ１５）。ステップＳ１５で「Ｙｅｓ」と判定された場合、メール送信部１５は、第２端末５０ｂに電子メールを送信する（ステップＳ１６）。例えば、メール送信部１５は、「対応可能時間になった場合にユーザに返信してください」といった電子メールを送信する。その後、ステップＳ６から再度実行される。

ステップＳ１５で「Ｎｏ」と判定された場合、ユーザが（３）を選択したことになる。すなわち、ユーザから引継要求がなされたことになる。この場合、担当者探索部１２は、担当者テーブル格納部１３の引継担当者テーブルを参照し、ユーザ情報テーブルの事故情報に応じて、該当する担当者を引継担当者として探索する（ステップＳ１７）。図９は、引継担当者テーブルを例示する図である。図９で例示するように、引継担当者テーブルでは、事故種別に担当者が関連付けられている。該当する担当者が複数である場合には、優先順位などに応じて担当者を探索してもよい。

次に、メール送信部１５は、引継担当者の端末に電子メールを送信する（ステップＳ１８）。図１の例では、引継担当者の端末は、第３端末５０ｃである。電子メールには、チャット提供部１４が生成したチャットルームに関する情報が含まれている。引継担当者には、事前に管理サイトのＵＲＬ、当該ＵＲＬにログインするためのＩＤ、パスワードなどが発行されている。引継担当者は、自身のＩＤおよびパスワードでログインした後、チャットルーム一覧から該当のチャットルームを検索することでチャットルームに参加することができる。引継担当者は、チャットルームに参加後、第３端末５０ｃのユーザインタフェース５３を操作することで、チャットルームにチャットメッセージを送信できるようになる。また、引継担当者は、ユーザがチャットルームに送信したチャットメッセージを第３端末５０ｃのユーザインタフェース５３で確認できるようになる。また、チャットルームを用いることから、引継担当者は、ユーザインタフェース５３に表示されるチャット画面をスクロールさせることで、メッセージの履歴を容易に確認することができる。

次に、チャット提供部１４は、引継担当者について、引継担当者テーブルに格納されている継続モードを取得する（ステップＳ１９）。次に、チャット提供部１４は、現在時刻がメイン担当者の対応可能時間内であるか否かを判定する（ステップＳ２０）。ステップＳ２０で「Ｙｅｓ」と判定された場合、引継担当者の継続モードが「オフ」であるか否かを判定する（ステップＳ２１）。ステップＳ２１で「Ｙｅｓ」と判定された場合、ステップＳ６から再度実行される。ステップＳ２０で「Ｎｏ」と判定された場合およびステップＳ２１で「Ｎｏ」と判定された場合、ステップＳ１９から再度実行される。なお、引継担当者は、必要に応じて、ユーザインタフェース５３に切替情報を入力することで継続モードを「オン」から「オフ」に切り替えることができる。

続いて、返信漏れ監視について説明する。返信漏れとは、ユーザからチャットルームにチャットメッセージが送信された場合にメイン担当者または引継担当者が返信を徒過することをいう。例えば、第２端末５０ｂにチャットメッセージが送信されても、メイン担当者が不在の場合、メイン担当者が返信を徒過する場合などがある。そこで、本実施形態においては、返信漏れが確認された場合に、アラートメッセージが送信される。

図１０は、メイン担当者モードにおいて、チャット提供部１４が第１端末５０ａからチャットメッセージを受信した場合に実行されるフローチャートを例示する図である。図１０で例示するように、返信漏れ監視部１６は、チャット提供部１４が第２端末５０ｂからチャットメッセージを受信したか否か（返信有りか否か）を判定する（ステップＳ３１）。ステップＳ３１で「Ｙｅｓ」と判定された場合、フローチャートが終了する。

ステップＳ３１で「Ｎｏ」と判定された場合、返信漏れ監視部１６は、監視テーブル格納部１７に格納されているメイン担当者の監視テーブルを参照し、チャット提供部１４が第１端末５０ａからチャットメッセージを受信してからの経過時間が経過時間Ｃ２を超えたか否かを判定する（ステップＳ３２）。

図１１（ａ）は、メイン担当者の監視テーブルを例示する図である。図１１（ａ）で例示するように、各担当者には、経過時間Ｃ１〜Ｃ４が設定されている。なお、管理者には、経過時間Ｃ１および経過時間Ｃ２が設定されておらず、フォロー担当者には、経過時間Ｃ１が設定されていない。管理者とは、メイン担当者の上司などである。フォロー担当者とは、メイン担当者をフォローする者であり、各メイン担当者について予め定められている。

ステップＳ３２で「Ｎｏ」と判定された場合、ステップＳ３１から再度実行される。ステップＳ３２で「Ｙｅｓ」と判定された場合、メール送信部１５は、該当者にアラートメッセージを送信する（ステップＳ３３）。この場合の該当者とは、経過時間Ｃ２が設定されている者である。図１１（ａ）の例では、メイン担当者およびフォロー担当者である。その後、返信漏れ監視部１６は、チャット提供部１４が第２端末５０ｂからチャットメッセージを受信したか否か（返信有りか否か）を判定する（ステップＳ３４）。ステップＳ３４で「Ｙｅｓ」と判定された場合、フローチャートが終了する。

ステップＳ３４で「Ｎｏ」と判定された場合、返信漏れ監視部１６は、監視テーブルを参照し、チャット提供部１４が第１端末５０ａからチャットメッセージを受信してからの経過時間が経過時間Ｃ３を超えたか否かを判定する（ステップＳ３５）。ステップＳ３５で「Ｎｏ」と判定された場合、ステップＳ３４から再度実行される。ステップＳ３５で「Ｙｅｓ」と判定された場合、メール送信部１５は、該当者にアラートメッセージを送信する（ステップＳ３６）。この場合の該当者とは、経過時間Ｃ３が設定されている者である。図１１（ａ）の例では、メイン担当者、管理者およびフォロー担当者である。

その後、返信漏れ監視部１６は、チャット提供部１４が第２端末５０ｂからチャットメッセージを受信したか否か（返信有りか否か）を判定する（ステップＳ３７）。ステップＳ３７で「Ｙｅｓ」と判定された場合、フローチャートが終了する。ステップＳ３７で「Ｎｏ」と判定された場合、返信漏れ監視部１６は、監視テーブルを参照し、チャット提供部１４が第１端末５０ａからチャットメッセージを受信してからの経過時間が経過時間Ｃ４を超えたか否かを判定する（ステップＳ３８）。ステップＳ３８で「Ｎｏ」と判定された場合、ステップＳ３７から再度実行される。ステップＳ３８で「Ｙｅｓ」と判定された場合、メール送信部１５は、該当者にアラートメッセージを送信する（ステップＳ３９）。この場合の該当者とは、経過時間Ｃ４が設定されている者である。図１１（ａ）の例では、メイン担当者、管理者およびフォロー担当者である。その後、フローチャートが終了してもよく、図６のステップＳ１２が実行されてもよい。

図１２は、引継担当者モードにおいて、チャット提供部１４が第１端末５０ａからチャットメッセージを受信した場合に実行されるフローチャートを例示する図である。図１２で例示するように、返信漏れ監視部１６は、チャット提供部１４が第３端末５０ｃからチャットメッセージを受信したか否か（返信有りか否か）を判定する（ステップＳ４１）。ステップＳ４１で「Ｙｅｓ」と判定された場合、フローチャートが終了する。

ステップＳ４１で「Ｎｏ」と判定された場合、返信漏れ監視部１６は、監視テーブル格納部１７に格納されている引継担当者の監視テーブルを参照し、チャット提供部１４が第１端末５０ａからチャットメッセージを受信してからの経過時間が経過時間Ｃ２を超えたか否かを判定する（ステップＳ４２）。

図１１（ｂ）は、引継担当者の監視テーブルを例示する図である。図１１（ｂ）で例示するように、引継担当者には、経過時間Ｃ１〜Ｃ４が設定されている。ステップＳ４２で「Ｎｏ」と判定された場合、ステップＳ４１から再度実行される。ステップＳ４２で「Ｙｅｓ」と判定された場合、メール送信部１５は、引継担当者にアラートメッセージを送信する（ステップＳ４３）。その後、返信漏れ監視部１６は、チャット提供部１４が第３端末５０ｃからチャットメッセージを受信したか否か（返信有りか否か）を判定する（ステップＳ４４）。ステップＳ４４で「Ｙｅｓ」と判定された場合、フローチャートが終了する。

ステップＳ４４で「Ｎｏ」と判定された場合、返信漏れ監視部１６は、引継担当者の監視テーブルを参照し、チャット提供部１４が第１端末５０ａからチャットメッセージを受信してからの経過時間が経過時間Ｃ３を超えたか否かを判定する（ステップＳ４５）。ステップＳ４５で「Ｎｏ」と判定された場合、ステップＳ４４から再度実行される。ステップＳ４５で「Ｙｅｓ」と判定された場合、メール送信部１５は、引継担当者にアラートメッセージを送信する（ステップＳ４６）。

その後、返信漏れ監視部１６は、チャット提供部１４が第３端末５０ｃからチャットメッセージを受信したか否か（返信有りか否か）を判定する（ステップＳ４７）。ステップＳ４７で「Ｙｅｓ」と判定された場合、フローチャートが終了する。ステップＳ４７で「Ｎｏ」と判定された場合、返信漏れ監視部１６は、引継担当者の監視テーブルを参照し、チャット提供部１４が第１端末５０ａからチャットメッセージを受信してからの経過時間が経過時間Ｃ４を超えたか否かを判定する（ステップＳ４８）。ステップＳ４８で「Ｎｏ」と判定された場合、ステップＳ４７から再度実行される。ステップＳ４８で「Ｙｅｓ」と判定された場合、メール送信部１５は、引継担当者にアラートメッセージを送信する（ステップＳ４９）。

図１３（ａ）は、メイン担当者モードにおいてアラートメッセージが送信される場合のタイムチャートを例示する図である。図１３（ａ）で例示するように、１３：００にチャット提供部１４が第１端末５０ａからチャットメッセージを受信した場合において、第２端末５０ｂからチャットメッセージが送信されなければ、１３：０５にメイン担当者およびフォロー担当者にアラートメッセージが送信され、１３：３０にメイン担当者、管理者およびフォロー担当者にアラートメッセージが送信され、１４：００にメイン担当者、管理者およびフォロー担当者にアラートメッセージが送信される。

図１３（ｂ）は、引継担当者モードにおいてアラートメッセージが送信される場合のタイムチャートを例示する図である。図１３（ｂ）で例示するように、１８：００にチャット提供部１４が第１端末５０ａからチャットメッセージを受信した場合において、第３端末５０ｃからチャットメッセージが送信されなければ、１８：０５に引継担当者にアラートメッセージが送信され、１８：３０にも引継担当者にアラートメッセージが送信され、１９：００にも引継担当者にアラートメッセージが送信される。なお、引継担当者へのアラートメッセージの送信は、必ずしも繰り返し実施する必要はない。例えば、チャットメッセージを受け取った１８：００に１度だけアラートメッセージを送信するように構成してもよい。

図１３（ｃ）は、メイン担当者が返信しなかった場合に引継担当者モードに移行する場合のタイムチャートを例示する図である。図１３（ｃ）で例示するように、１８：００にチャット提供部１４が第１端末５０ａからチャットメッセージを受信した場合において、第２端末５０ｂからチャットメッセージが送信されなければ、１８：０５にメイン担当者およびフォロー担当者にアラートメッセージが送信され、１８：３０にメイン担当者、管理者およびフォロー担当者にアラートメッセージが送信され、１９：００にメイン担当者、管理者およびフォロー担当者にアラートメッセージが送信される。その後、ユーザが引継担当者からの返信を希望すれば、担当者探索部１２が探索した引継担当者に電子メールが送信される。

さらに、返信漏れ監視部１６は、チャットルームが生成されてからメイン担当者がチャットルームに参加するまでの経過時間を監視してもよい。図１４は、チャットルームが生成された場合に実行されるフローチャートを例示する図である。図１４で例示するように、返信漏れ監視部１６は、メイン担当者がチャットルームに参加したか否かを判定する（ステップＳ５１）。ステップＳ５１で「Ｙｅｓ」と判定された場合、フローチャートが終了する。

ステップＳ５１で「Ｎｏ」と判定された場合、返信漏れ監視部１６は、監視テーブル格納部１７に格納されているメイン担当者の監視テーブルを参照し、チャットルームが生成されてからの経過時間が経過時間Ｃ２を超えたか否かを判定する（ステップＳ５２）。ステップＳ５２で「Ｎｏ」と判定された場合、ステップＳ５１から再度実行される。

ステップＳ５２で「Ｙｅｓ」と判定された場合、メール送信部１５は、該当者にアラートメッセージを送信する（ステップＳ５３）。この場合の該当者とは、経過時間Ｃ２が設定されている者である。図１１（ａ）の例では、メイン担当者およびフォロー担当者である。その後、返信漏れ監視部１６は、メイン担当者がチャットルームに参加したか否かを判定する（ステップＳ５４）。ステップＳ５４で「Ｙｅｓ」と判定された場合、フローチャートが終了する。

ステップＳ５４で「Ｎｏ」と判定された場合、返信漏れ監視部１６は、監視テーブルを参照し、チャットルームが生成されてからの経過時間が経過時間Ｃ３を超えたか否かを判定する（ステップＳ５５）。ステップＳ５５で「Ｎｏ」と判定された場合、ステップＳ４４から再度実行される。ステップＳ５５で「Ｙｅｓ」と判定された場合、メール送信部１５は、該当者にアラートメッセージを送信する（ステップＳ５６）。この場合の該当者とは、経過時間Ｃ３が設定されている者である。図１１（ａ）の例では、メイン担当者、管理者およびフォロー担当者である。

その後、返信漏れ監視部１６は、メイン担当者がチャットルームに参加したか否かを判定する（ステップＳ５７）。ステップＳ５７で「Ｙｅｓ」と判定された場合、フローチャートが終了する。ステップＳ５７で「Ｎｏ」と判定された場合、返信漏れ監視部１６は、監視テーブルを参照し、チャットルームが生成されてからの経過時間が経過時間Ｃ４を超えたか否かを判定する（ステップＳ５８）。ステップＳ５８で「Ｎｏ」と判定された場合、ステップＳ５７から再度実行される。ステップＳ５８で「Ｙｅｓ」と判定された場合、メール送信部１５は、該当者にアラートメッセージを送信する（ステップＳ５９）。この場合の該当者とは、経過時間Ｃ４が設定されている者である。図１１（ａ）の例では、メイン担当者、管理者およびフォロー担当者である。その後、フローチャートが終了してもよく、図６のステップＳ１２が実行されてもよい。

さらに、返信漏れ監視部１６は、引継担当者がチャットルームに参加可能になってからの経過時間を監視してもよい。図１５は、メイン担当者モードから引継担当者モードに移行した場合に実行されるフローチャートを例示する図である。図１５で例示するように、返信漏れ監視部１６は、引継担当者がチャットルームに参加したか否かを判定する（ステップＳ６１）。ステップＳ６１で「Ｙｅｓ」と判定された場合、フローチャートが終了する。

ステップＳ６１で「Ｎｏ」と判定された場合、返信漏れ監視部１６は、監視テーブル格納部１７に格納されている引継担当者の監視テーブルを参照し、引継担当者がチャットルームに参加可能になってからの経過時間が経過時間Ｃ２を超えたか否かを判定する（ステップＳ６２）。

ステップＳ６２で「Ｎｏ」と判定された場合、ステップＳ６１から再度実行される。ステップＳ６２で「Ｙｅｓ」と判定された場合、メール送信部１５は、引継担当者にアラートメッセージを送信する（ステップＳ６３）。その後、返信漏れ監視部１６は、引継担当者がチャットルームに参加したか否かを判定する（ステップＳ６４）。ステップＳ６４で「Ｙｅｓ」と判定された場合、フローチャートが終了する。

ステップＳ６４で「Ｎｏ」と判定された場合、返信漏れ監視部１６は、引継担当者の監視テーブルを参照し、引継担当者がチャットルームに参加可能になってからの経過時間が経過時間Ｃ３を超えたか否かを判定する（ステップＳ６５）。ステップＳ６５で「Ｎｏ」と判定された場合、ステップＳ６４から再度実行される。ステップＳ６５で「Ｙｅｓ」と判定された場合、メール送信部１５は、引継担当者にアラートメッセージを送信する（ステップＳ６６）。

その後、返信漏れ監視部１６は、引継担当者がチャットルームに参加したか否かを判定する（ステップＳ６７）。ステップＳ６７で「Ｙｅｓ」と判定された場合、フローチャートが終了する。ステップＳ６７で「Ｎｏ」と判定された場合、返信漏れ監視部１６は、引継担当者の監視テーブルを参照し、引継担当者がチャットルームに参加可能になってからの経過時間が経過時間Ｃ４を超えたか否かを判定する（ステップＳ６８）。ステップＳ６８で「Ｎｏ」と判定された場合、ステップＳ６７から再度実行される。ステップＳ６８で「Ｙｅｓ」と判定された場合、メール送信部１５は、引継担当者にアラートメッセージを送信する（ステップＳ６９）。

図１０、図１２、図１４および図１５の例では、経過時間Ｃ１〜Ｃ４の値が共通であったが、各例で異なっていてもよい。また、返信漏れ監視部１６は、メイン担当者の返信漏れのみを監視対象とし、引継担当者の返信漏れは監視対象としないように構成してもよい。

本実施形態においては、ユーザの事故情報に応じて担当者テーブルからメイン担当者が探索され、ユーザとメイン担当者とが参加するチャットルームが提供される。それにより、ユーザは、事故情報に応じて探索されたメイン担当者とチャットを行うことができる。この場合、同じチャットルーム内で、ユーザおよびメイン担当者がそれぞれメッセージを送受信することができる。それにより、ユーザは、メイン担当者から事故対応の情報を取得することができる。また、チャットルームを用いることから、端末のユーザインタフェースに表示されるチャット画面をスクロールさせることで、メッセージの履歴を容易に確認することができる。以上のことから、事故対応装置１０は、チャットによって円滑な事故対応を可能とする。

また、本実施形態においては、チャット提供部１４が担当者からのチャットメッセージを受信するか否かが監視され、チャット提供部１４がユーザからのチャットメッセージを受信してから所定時間経過するまでに、チャット提供部１４が担当者からのチャットメッセージを受信しない場合に、担当者の端末にアラートメッセージが送信される。この構成によれば、返信漏れを抑制することができる。この場合の担当者とは、メイン担当者および引継担当者のいずれであってもよい。

また、本実施形態においては、チャットルームに対して担当者の参加が開始されたか否かが監視され、チャットルームが生成されてから所定時間経過するまでに担当者によるチャットルームへの参加開始が検知されない場合に、担当者の端末に対してアラートメッセージが送信される。この構成によれば、返信漏れを抑制することができる。この場合の担当者とは、メイン担当者および引継担当者のいずれであってもよい。

また、本実施形態においては、メイン担当者の対応可能時間外にユーザの端末からチャットルームにチャットメッセージが送信された場合に、チャットルームに応答メッセージが自動送信される。この構成によれば、メイン担当者の対応可能時間外であっても、ユーザは事故対応を求めることができるようになる。

また、本実施形態においては、メイン担当者の対応可能時間外であっても、継続モードがオンになっていれば、応答メッセージが自動送信されず、メイン担当者がチャットを継続することができる。この構成によれば、柔軟な対応が可能となる。

また、本実施形態においては、担当者の端末からの入力情報に応じて継続モードのオン・オフの変更が可能である。この構成によれば、柔軟な対応が可能となる。この場合の担当者とは、メイン担当者および引継担当者のいずれであってもよい。

また、本実施形態においては、引継要求に応じて、担当者テーブルから引継担当者が探索され、引継担当者がチャットルームに参加可能となる。この構成によれば、柔軟な対応が可能となる。なお、この場合の引継要求とは、ユーザからの引継要求以外にも、他者からの引継要求が含まれていてもよい。

また、本実施形態においては、ユーザの端末に認証キーが送信され、ユーザの端末から認証キーが受信された場合にユーザをチャットルームに参加させる。この構成によれば、本人確認を行うことができる。

なお、本実施形態においては、チャットメッセージ以外の通知手段としてＳＭＳ（ショートメッセージサービス）などの電子メールを用いているが、他の通知手段を用いてもよい。例えば、Ｗｅｂｐｕｓｈ通知などの他の通知手段を、チャットメッセージ以外の通知手段として用いてもよい。

また、本実施形態においては、メイン担当者および引継担当者としてそれぞれ１人の担当者が探索されているが、それに限られない。例えば、複数の担当者がメイン担当者として探索され、複数の担当者が引継担当者として探索されてもよい。この場合、例えば、複数のメイン担当者がチャットルームに参加してもよく、複数の引継担当者がチャットルームに参加してもよい。また、複数の担当者のうち、最も早くチャットルームに参加した担当者だけがチャットルームを利用できるようにしてもよい。

また、本実施形態においては、事故種別に応じてメイン担当者が定められているが、それに限られない。例えば、さらに事故の場所などを反映させてもよい。例えば、事故の場所に応じて、当該場所に近い拠点の担当者を探索するようにしてもよい。

また、本実施形態においては、メイン担当者モードと引継担当者モードとが切り替わっても、チャットルームに参加している担当者を退出させていないが、それに限られない。例えば、メイン担当者モードから引継担当者モードに切り替わった場合にメイン担当者をチャットルームから退出させて、メイン担当者にチャットメッセージが送信されないようにしてもよい。また、引継担当者モードからメイン担当者モードに切り替わった場合に引継担当者をチャットルームから退出させて、引継担当者にチャットメッセージが送信されないようにしてもよい。

なお、上記各例において、担当者探索部１２が、ユーザの事故情報に応じて、担当者テーブルから担当者を探索する担当者探索部の一例として機能する。チャット提供部１４が、前記ユーザと、前記担当者探索部が探索した第１担当者とが参加するチャットルームを提供するチャット提供部の一例として機能する。返信漏れ監視部１６が、前記チャット提供部が前記第１担当者からのチャットメッセージを受信するか否かを監視する監視部または前記チャットルームに対して前記第１担当者の参加が開始されたか否かを監視する監視部の一例として機能する。メール送信部１５が、前記チャット提供部が前記ユーザからのチャットメッセージを受信してから所定時間経過するまでに、前記チャット提供部が前記第１担当者からのチャットメッセージを受信しない場合に、前記第１担当者の端末にアラートメッセージを送信する送信部、または、前記チャット提供部が前記チャットルームを生成してから所定時間経過するまでに前記第１担当者による前記チャットルームへの参加開始が検知されない場合に、前記第１担当者の端末に対してアラートメッセージを送信する送信部の一例として機能する。自動応答部１８が、各担当者に関連付けて対応可能時間を格納する対応可能時間テーブルを参照することで前記第１担当者の対応可能時間を取得し、前記対応可能時間外に前記ユーザの端末から前記チャットルームにチャットメッセージが送信された場合に、前記チャットルームに応答メッセージを自動送信する自動応答部の一例として機能する。

以上、本発明の実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０ 事故対応装置
１１ ユーザ情報テーブル格納部
１２ 担当者探索部
１３ 担当者テーブル格納部
１４ チャット提供部
１５ メール送信部
１６ 返信漏れ監視部
１７ 監視テーブル格納部
１８ 自動応答部
３０ ネットワーク
４０ａ〜４０ｃ 基地極
５０ａ〜５０ｃ 端末
１００ 事故対応システム

Claims (11)

1. ユーザの事故情報に応じて、担当者テーブルから担当者を探索する担当者探索部と、
   前記ユーザと、前記担当者探索部が探索した第１担当者とが参加するチャットルームを提供するチャット提供部と、を備えることを特徴とする事故対応装置。
2. 前記チャット提供部が前記第１担当者からのチャットメッセージを受信するか否かを監視する監視部と、
   前記チャット提供部が前記ユーザからのチャットメッセージを受信してから所定時間経過するまでに、前記チャット提供部が前記第１担当者からのチャットメッセージを受信しない場合に、前記第１担当者の端末にアラートメッセージを送信する送信部と、を備えることを特徴とする請求項１記載の事故対応装置。
3. 前記チャットルームに対して前記第１担当者の参加が開始されたか否かを監視する監視部と、
   前記チャット提供部が前記チャットルームを生成してから所定時間経過するまでに前記第１担当者による前記チャットルームへの参加開始が検知されない場合に、前記第１担当者の端末に対してアラートメッセージを送信する送信部と、を備えることを特徴とする請求項１記載の事故対応装置。
4. 各担当者に関連付けて対応可能時間を格納する対応可能時間テーブルを参照することで前記第１担当者の対応可能時間を取得し、前記対応可能時間外に前記ユーザの端末から前記チャットルームにチャットメッセージが送信された場合に、前記チャットルームに応答メッセージを自動送信する自動応答部を備えることを特徴とする請求項１〜３のいずれか一項に記載の事故対応装置。
5. 前記対応可能時間テーブルは、前記チャットルームの継続識別子を各担当者に関連付けて格納し、
   前記自動応答部は、前記第１担当者に関連付けられた前記継続識別子が継続を示している場合に、前記チャットルームに前記応答メッセージを自動送信しないことを特徴とする請求項４記載の事故対応装置。
6. 前記継続識別子は、前記第１担当者の端末からの入力情報に応じて変更可能であることを特徴とする請求項５記載の事故対応装置。
7. 前記担当者探索部は、引継要求に応じて、前記担当者テーブルから前記第１担当者の引継担当者である第２担当者を探索し、
   前記チャット提供部は、前記第２担当者を前記チャットルームに参加させることを特徴とする請求項１〜６のいずれか一項に記載の事故対応装置。
8. 前記チャット提供部は、前記ユーザの端末に認証キーを送信し、前記ユーザの端末から前記認証キーを受信した場合に前記ユーザを前記チャットルームに参加させることを特徴とする請求項１〜７のいずれか一項に記載の事故対応装置。
9. ユーザの事故情報に応じて、担当者テーブルから担当者を探索する担当者探索部と、前記ユーザと前記担当者探索部が探索した担当者とが参加するチャットルームを提供するチャット提供部と、を備える事故対応装置と、
   前記ユーザからのチャットメッセージを送信し、前記チャットルーム内のチャットメッセージの履歴を表示する第１端末と、
   前記担当者からのチャットメッセージを送信し、前記チャットルーム内のチャットメッセージの履歴を表示する第２端末と、を備えることを特徴とする事故対応システム。
10. 担当者探索部が、ユーザの事故情報に応じて、担当者テーブルから担当者を探索し、
    チャット提供部が、前記ユーザと、前記担当者探索部が探索した担当者とが参加するチャットルームを提供する、ことを特徴とする事故対応方法。
11. コンピュータに、
    ユーザの事故情報に応じて、担当者テーブルから担当者を探索する処理と、
    前記ユーザと、探索された担当者とが参加するチャットルームを提供する処理と、を実行させることを特徴とする事故対応プログラム。

Images