JP6461560B2 - 情報伝達システム、情報伝達方法及び情報伝達プログラム - Google Patents

情報伝達システム、情報伝達方法及び情報伝達プログラム Download PDF

Info

Publication number
JP6461560B2
JP6461560B2 JP2014222277A JP2014222277A JP6461560B2 JP 6461560 B2 JP6461560 B2 JP 6461560B2 JP 2014222277 A JP2014222277 A JP 2014222277A JP 2014222277 A JP2014222277 A JP 2014222277A JP 6461560 B2 JP6461560 B2 JP 6461560B2
Authority
JP
Japan
Prior art keywords
information
response
information transmission
maintenance
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2014222277A
Other languages
English (en)
Other versions
JP2016091143A (ja
Inventor
勇 高畑
勇 高畑
裕 細木
裕 細木
高島 俊哉
俊哉 高島
篠原 大輔
大輔 篠原
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Systems Ltd
Original Assignee
Hitachi Systems Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Systems Ltd filed Critical Hitachi Systems Ltd
Priority to JP2014222277A priority Critical patent/JP6461560B2/ja
Publication of JP2016091143A publication Critical patent/JP2016091143A/ja
Application granted granted Critical
Publication of JP6461560B2 publication Critical patent/JP6461560B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Debugging And Monitoring (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Description

本発明は、情報伝達システム、情報伝達方法及び情報伝達プログラムに関する。
汎用コンピュータやサーバなどから構成される情報処理システムを用いたオンラインシステムでは、昼夜を問わず24時間365日常時稼働し、停止することのなく使用されることが多い。そのために、このような情報処理システムには、高い信頼性と可用性が求められている。情報処理システムの可用性を向上させるには、システムを構成する機器、例えば、コンピュータやサーバなどを冗長化する方法がある。この冗長化は、ある機器に故障などの障害が発生した場合においても、他の機器が業務を引き継ぐことで、業務サービスの停止を防止することができる。また、この冗長化で迅速に障害機器を切り離すことができ、故障した機器の業務サービスへの影響を最小限に留めて、正常な機器で業務サービスを継続させることができる。
しかしながら、どのような高い信頼性と可用性なシステムを構築しても障害は必ず発生し、最悪の場合システムがダウンする可能性もある。情報処理システムに障害が発生しシステムがダウンしたときには、できるだけ早急に復旧させることが必要である。また、システムダウンが発生しなくとも、障害が発生した機器を早急に交換し、障害が他の機器に伝播しないようにする必要がある。
このような障害発生時に対するため、従来では、情報処理システムにシステム障害が発生した場合、情報処理システムのユーザが障害の発生した箇所に応じて、保守サービス提供会社に電話や電子メール等で連絡して、障害箇所の修理や交換をしてもらっていた。また、保守サービス提供会社では、連絡を受けたオペレータが適切な保守員を選別し、その保守員にメールや電話等で保守依頼を行っていた。これに関する技術としては、特許文献1記載のものがある。特許文献1記載の従来技術は、適切な保守員を迅速に障害発生装置あるいはシステムに向かわせることができる障害通報システムを提供するため、あらかじめ記憶テーブルに順次保守員を記憶しておき、応答がなかったときに次の保守員を呼び出すものである。
特開平08−314761号公報
特許文献1の障害通報システムでは、ユーザからの保守依頼について、対応する手段に関する開示がない。そのため、定型的な保守対応はできても、ユーザが直接依頼する障害への保守には対応できない。そこで、保守会社にオペレータを常駐させ、保守依頼を受け付けることが考えられる。しかしながら、夜間/休日の受付体制は、どの受付部署に置いても最低限の人数のオペレータで保守依頼の受付を処理している。そのため、待機している保守員で、1番目の保守員に連絡が付かないと2番目の保守員に連絡する。もし、2番目の保守員にも連絡が付かないと3番目、4番目と保守員への連絡をオペレータが行い、1つのユーザからの保守依頼に長時間オペレータが拘束され、他のオペレータの負荷が高くなり、別のユーザからの保守依頼を受け付けられなくなる可能性が高くなるという問題がある。そこで、本発明では、ユーザから直接、依頼のあった保守に対し、迅速な保守員の選別と依頼保守内容の伝達を可能とする情報伝達システムを提供することを目的とする。
上記課題を解決するために、代表的な本発明の情報伝達システムでは、待機保守員へ受け付けた保守依頼内容を含む第1の保守対応要求情報を第1の情報通信部で伝達し、第1の保守対対応要求から第1の所定時間が経過した後、第2の保守対応要求を第2の情報通信部で伝達し、第2の保守対応要求から第2の所定時間が経過しても第2の保守対応要求情報に対する応答が無い場合、次の待機保守員へ第3の保守対応要求情報を伝達する。
本発明では、ユーザ直接の保守依頼への対応時間を短縮することができ、ユーザ満足度を向上できる。なお、前述以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
図1は、本発明の情報伝達システム1の全体構成を示すブロック図である。 図2は、情報伝達システム1でのサーバ/端末の内部構成を示すブロック図である。 図3は、第1の待機者管理テーブル30の構成例を示す図である。 図4は、第2の待機者管理テーブル40の構成例を示す図である。 図5は、連絡環境管理テーブル50の構成例を示す図である。 図6aは、第1の連絡結果管理テーブル61の構成例を示す図である。 図6bは、第2の連絡結果管理テーブル62の構成例を示す図である。 図7は、連絡者検索結果の表示画面70の構成例を示す図である。 図8は、送信メールに関する情報を示す図である。 図9は、第1の自動連絡結果例の表示画面の構成例90を示す図である。 図10は、第2の自動連絡結果例の表示画面100の構成例を示す図である。 図11は、待機者への連絡処理を示すフローチャート図である。 図12は、待機者への連絡処理での電話応答判断処理を示すフローチャート図である。 図13は、待機者への連絡処理でのオペレータ転送処理を示すフローチャート図である。 図14は、メール送信処理を示すフローチャート図である。 図15は、連絡中止処理を示すフローチャート図である。
以下、図面を参照しながら実施の形態を説明する。なお、実施例の説明では、保守会社などの待機保守員に対する情報伝達を例とするが、巡回保守員などへの情報伝達でもよく、また、運送会社の運送員、ビル管理会社の警備員などへの情報伝達にも用いることができる。また、以下の説明では、「管理テーブル」等の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造で表現されていてもよい。また、データ構造に依存しないことを示すために「管理テーブル」を「管理情報」と呼ぶことができる。
また、「プログラム」を主語として処理を説明する場合がある。そのプログラムは、プロセッサ、例えば、MP(Micro Processor)やCPU(Central Processing Unit)によって実行されるもので、定められた処理をするものである。なお、適宜に記憶資源(例えばメモリ)及び通信インターフェース装置(例えば、通信ポート)を用いながら行うため、処理の主語がプロセッサとされてもよい。プロセッサは、CPUの他に専用ハードウェアを有していても良い。コンピュータプログラムは、プログラムソースから各コンピュータにインストールされても良い。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディアなどで提供されるものであっても良い。
また、各要素、例えば、コントローラは番号などで識別可能であるが、識別可能な情報であれば、名前など他種の識別情報が用いられても良い。本実施例の図及び説明において同一部分には同一符号を付与しているが、本発明が本実施例に制限されることは無く、本発明の思想に合致するあらゆる応用例が本発明の技術的範囲に含まれる。また、特に限定しない限り、各構成要素は複数でも単数でも構わない。
<情報伝達システム全体構成>図1
図1は、本発明の情報伝達システム1の全体構成を示すブロック図である。情報伝達システム1は、サーバ11、オペレータ端末12、電話交換機(PBX:Private Branch eXchange)113/118から構成する。また、サーバ11は、保守拠点13とイントラネット14で接続し、待機保守員1030が所持する携帯用機器(携帯電話や多機能タブレットなど)とインターネット網1002や公衆回線網1012で接続する。更に、サーバ11は、保守契約者1020(保守契約者の端末やサーバなど)とインターネット網1001や公衆回線網1011で接続する。
サーバ11は、伝達情報生成部111、保守依頼受付部112、メール作成部114、連絡者登録部115、連絡者作成部116、連絡部117より構成する。なお、各部をハードウェアで構成してもよいし、後述するCPU上で動作するプログラムでもよい。
オペレータ端末12は、保守契約者1020(ユーザ1020、1021など)から公衆回線網1011経由PBX113から保守依頼を受け付けるための端末で、サーバ11にも接続され待機保守員の情報や待機保守員への伝達情報の内容を閲覧するなどの機能を有する端末で、保守依頼受付部署のオペレータにより操作される。
サーバ11の保守依頼受付部112は、保守契約者1020(ユーザ1020、1021など)からインターネット網1001ないし公衆回線網1011経由PBX113から受信した保守依頼を受け付ける機能部である。保守依頼受付部112には受け付けた保守依頼内容を管理する保守依頼DB1121があり、保守依頼DB1121が、後述する記憶装置(メモリないしHDDなどの記憶部)に格納される。保守依頼DB1121には、“障害受付日時”、“お客様名”、“お客様部署名”、“保守契約形態”、“保守対応機種”、“型名/製造番号”、“障害現象”、“お客様住所”などの情報が格納される。これらの情報が、伝達情報生成部111や連絡部117に送られ、送信メールの生成や情報伝達先及び方法が決定される。
伝達情報生成部111は、保守依頼受付部112から受け付けた保守内容から待機保守員1030(保守員1031、1032、1033など)やオペレータ端末12を操作するオペレータに伝達する情報を生成する機能部である。伝達情報生成部111には、生成した伝達情報を管理する伝達情報DB1111があり、記憶装置に格納される。メール作成部114は、待機保守員1030に送信するための電子メールを作成する機能部である。作成する電子メールの内容は、伝達情報生成部111で生成された伝達情報を中心に構成される。詳細な内容については後述(図8)する。なお、メール作成部114で作成された電子メールは、連絡部117に送られ、連絡情報DB1171に格納される。
連絡者登録部115は、保守拠点13(拠点1301、1302など)から登録された待機保守員の情報、すなわち情報を伝達し連絡する連絡者を登録するための機能部である。登録された待機保守員の情報が連絡者DB1151として、記憶装置等に格納される。連絡者作成部116は、後述(図4ないし図7)する待機者管理テーブルや待機者一覧情報などを作成する機能部である。作成された待機者管理テーブルや待機者一覧情報などは、連絡部117の連絡情報DB1171に格納される。
連絡部117は、待機保守員1030(保守員1031、1032、1033など)へ電子メール送信や電話連絡を行い、また、連絡した待機保守員1030からの応答を受け付ける機能部である。待機保守員1030への連絡情報は連絡情報DB1171として、待機保守員1030からの応答結果は連絡結果DB1172として記憶装置等に格納される。
本発明の実施形態の情報伝達システム1では、以上のように保守拠点13からの待機保守員情報の登録、保守契約者1020からの保守依頼受付、待機保守員1030への依頼保守内容の連絡と応答の確認により、ユーザから直接、依頼のあった保守に対し、迅速な保守員の選別と依頼保守内容の伝達を可能とするものである。
<装置内部構成>図2
図2は、情報伝達システム1でのサーバ11/端末12の内部構成を示すブロック図である。サーバ11及び端末12は、CPU21、メモリ22、記憶部23、入力部24、出力部25、表示部26、通信部27を備える。
CPU21は、装置全体を制御するプロセッサである。メモリ22は、各種プログラム及び後述する各種データ(テーブル)などを一時的に記憶するデバイスである。記憶部23は、各種プログラム及び後述する各種データなどを恒久的に記憶するデバイスで、例えばHDDやSSDである。入力部24は、入力を受け付けるデバイスで、例えば、キーボードである。
出力部25は、情報やデータを出力するデバイスで、例えば、スピーカやプリンタである。表示部26は、情報やデータを表示するデバイスで、例えば、液晶ディスプレイである。通信部27は、ネットワーク(図示せず)を介し他のサーバや他の装置との間を接続するデバイスである。以上の構成要素は内部バスで相互に接続される。なお、入力部34、出力部35、表示部36のいずれかを各装置に備えない構成とすることもできる。
<待機者管理テーブル>図3、図4
図3は、第1の待機者管理テーブル30の構成例を示す図である。図4は、第2の待機者管理テーブル40の構成例を示す図である。待機者管理テーブル30は、夜間や休日などに保守対応を行うための待機保守員を管理するテーブルで、保守拠点毎に本テーブルが作成される。また、受け付けた保守依頼内容で本待機者管理テーブル30が更新される。待機者管理テーブル40は、夜間や休日などに保守対応を行うための待機保守員を管理するテーブルで、待機保守員毎に本テーブルが作成される。
待機者管理テーブル30は、#(管理番号)301、項目名302、設定値/格納値303から構成される。 項目名302に対応に対する設定値/格納値303には、各種情報がテーブル作成時に設定ないし保守依頼受付時に格納され管理される。なお、待機者管理テーブル30は、連絡部117の連絡情報DB1171に格納される。
待機者管理テーブル30の項目名302の例として、図3のように保守待機者を管理している情報を一意に識別するための“待機者認識番号”、本テーブルの作成日時を一意に特定する“作成日時”、保守待機者への連絡方法を特定する“連絡区分(0:通常(1名毎 メール送信→電話連絡)、1:特殊1(メール送信/全員同時、電話/順番)、2:特殊2(メール送信/全員同時、電話/実施せず)など)”、“通報者数”、“保守拠点(拠点コード)”、“保守先名称(障害連絡時に格納)、保守先部署名(障害連絡時に格納)”、“送信メールタイトル”、“送信メール内容(障害連絡時に格納)”、“発信電話番号”、“音声再生内容(障害連絡時に格納)”、“緊急度(A:高(最優先・至急)、B:中(優先)、C:低(障害連絡時に格納))”などである。
また、項目名302に対応する設定値/格納値303の例として、“T1406A3982−20140707105521”、“2014/07/07 10:55:21(YYYY/MM/DD hh:mm:ss)”、“0”、“4名”、“拠点1302(ZDL7)”、“A電機”、“Bデータセンタ”、“待機者連絡システムよりの障害対応依頼”、“A電機様のBデータセンタのサーバ(製造番号:HS1234ABC)に障害が発生しました。主な障害現象は、リブートの繰り返しです。その他の障害現象は・・・”、“123−4567−8901”、“A電機様のBデータセンタで障害が発生しました。対応お願いします。受信確認のため、電話の“Aボタン”を押してください。オペレータ転送希望の場合は、“Bボタン”を押してください。”、“B”などである。なお、#1の“待機者認識番号”での“T1406A3982−20140707105521”には、“20140707105521(2014/07/07 10:55:21)”というテーブル作成時刻情報も付加されている。
待機者管理テーブル30の#1から#5に対応する情報は、連絡者DB1151の情報を連絡者作成部116で加工し生成された情報が格納される。また、#6、#7、#9、#11、#12は、保守依頼受付部112からの保守依頼内容の情報が格納される。
待機者管理テーブル40は、#(管理番号)401、項目名402、設定値403から構成される。項目名402に対応する設定値403に各種情報がテーブル作成時に設定される。なお、 待機者管理テーブル40は、連絡者登録部1151の連絡者DB1151に格納される。
待機者管理テーブル40の項目名402の例として、図4のように、待機保守員を一意に識別するための“待機者認識番号”、本テーブルの生成日時である“作成日時”、連絡の順番を特定する“優先順位”、待機保守員を社員として一意に識別するための“社員認識番号”、“氏名”、“フリガナ”、“連絡先電話番号”、“メールアドレス”、“保守拠点名(コード)”、保守拠点での“部課コード”、保守拠点での“グループ名”、“その他”などである。
項目名402に対応する設定値/格納値403の例として、“T1406A3982−20140707085921”、“2014/07/04 10:55:21(YYYY/MM/DD hh:mm:ss)”、“2”、“H677850015A”、“C山G男”、“シーヤマジーオ”、“111−2222−3333”、“cyamago222@def333.netw”、“拠点1302(ZDL7)”、“CRC99”、“7G”、“ローテーショングループ2”などである。
<連絡環境管理テーブル>図5
図5は、連絡環境管理テーブル50の構成例を示す図である。連絡環境管理テーブル50は、障害情報の伝達手段毎に設定される伝達環境情報(連絡回数上限、許容エラー回数、待機時間上限など)を管理するテーブルである。連絡環境管理テーブル50は、#(管理番号)501、項目名502、設定値503から構成される。なお、連絡環境管理テーブル50は、連絡部117の連絡情報DB1171などに格納される。
連絡環境管理テーブル50の項目名502として、“連絡監視ループ秒数”、“発信利用回線番号”、“連絡ループ(繰り返し)回数”、“ダイヤルエラー回数”、“話し中時の待機秒数”、“電話発信秒数”、“ダイヤル入力待機秒数”、“メール送信リトライ回数”、“メール送信後の待機秒数”などである。
“連絡監視ループ秒数”には、連絡処理を正常に行われているかを判断する間隔(時間)が設定される。もし、異常が発生している場合、情報伝達システム1のサーバ11は、後述する待機保守員への連絡処理(図11)を初期化し、再度最初から連絡処理を実行する。
“発信利用回線番号”には、待機保守員への電子メール送信に使用する通信部のポート番号ないし電話連絡で使用するPBX118のポート番号が設定される。“連絡ループ(繰り返し)回数” には、電子メールの送信から電話連絡までの情報伝達回数(連絡回数)数が設定される。“ダイヤルエラー回数” には、電話連絡のダイヤルでのエラー(話し中、電源OFF等)発生時に、再度電話連絡のダイヤルを行う回数の上限が設定される。つまり、許容するダイヤルエラーの上限回数を、“ダイヤルエラー回数”に設定する。
“話し中時の待機秒数”には、電話連絡時に待機保守員の携帯電話が“話し中”状態であれば、次にダイヤルするまでの待機時間が設定される。“電話発信秒数” には、電話連絡時に電話への発信状態(呼び出し状態)を継続する時間が設定される。“ダイヤル入力待機秒数” には、電話が通じた状態になり音声ガイダンスによるダイヤル入力要求に対しダイヤル入力が完了するまでの待機時間の上限値が設定される。この設定値の待機時間を超えた場合は、ダイヤル入力がされないエラーが発生したと情報伝達システム1(ないしサーバ11)は判断する。
“メール送信リトライ回数”には、電子メールの送信回数が設定される。これは、送信エラーの発生や、携帯電話への1回のメール受信では、待機保守員がメールを受信したことが気づかない場合があるので、複数回のメール送信回数、つまりメール送信リトライ回数を設定しメール受信状況を待機保守員が確実に把握できるようにする。“メール送信後の待機秒数” には、メール送信後に電話連絡をするまでの待機時間が設定される。これは、前述のようにメール送信エラー発生時の再送信時間や、受信メールの内容の確認時間が必要なため、メール送信後に電話連絡をするまでの待機時間を設けて、待機保守員への連絡を確実に取れるようにする。
項目名502に対応する設定値/格納値503として、“30秒”、“ポート55番”、“3回”、“5回”、“180秒(3分)”、“30秒”、“25秒”、“2回”、“60秒”などである。
<連絡結果管理テーブル>図6a、図6b
図6aは、第1の連絡結果管理テーブル61の構成例を示す図である。図6bは、第2の連絡結果管理テーブル62の構成例を示す図である。連絡結果管理テーブル61は、保守依頼に対する保守対応の詳細情報を管理するテーブルで、連絡結果管理テーブル62は連絡結果管理テーブル61での主要部分の情報を抽出し管理するテーブルである。連絡結果管理テーブル61及び連絡結果管理テーブル62は、連絡部117の連絡情報DB1171などに格納される。
連絡結果管理テーブル61は、#(管理番号)611、項目名612及び設定値/格納値613から構成される。項目名612の例として、依頼された保守を一意に識別するための“保守案件番号”、“作成日時”、“優先順位”、“保守拠点名(コード)”、“部課コード”、“グループ名”、“社員認識番号”、“氏名”、“連絡媒体(1:メール、2:電話)”、“連絡媒体(1:メール、2:電話)”、“メール連絡結果(0:正常、0以外:異常)”、“電話連絡回数”、“電話連絡結果(0:ダイヤル入力値確認で成功、1:オペレータ転送で成功、2:オペレータ転送失敗、3:不在、4:話し中、5:途中切断、6:回線異常、7:電源OFF・電波状態異常)”、“ダイヤル入力正解値(受信確認)”、“ダイヤル入力正解値(オペレータ転送)”、“最終ダイヤル入力値”などである。
項目名612に対応する設定値/格納値613として、“T1406A3982−20140707XYZ”、“2014/07/07 22:54:21(YYYY/MM/DD hh:mm:ss)”、“2番”、“拠点1302(ZDL7)”、“CRC99”、“7G”、“H677850015A”、“C山G男”、“2(電話)”、“1”、“0(正常)”、“2”、“0(ダイヤル入力正解値(受信確認))”、“1”、“3”、“1”である。なお、#1の“保守案件番号”の設定値/格納値613である“T1406A3982−20140707XYZ”は、前述の“待機者認識番号”で時刻情報の代わりに“XYZ”という保守依頼の管理番号を付加したものである。これにより、各テーブルの関係を情報伝達システム1が認識することができる。
なお、#14の“ダイヤル入力正解値(受信確認)”でのダイヤル入力正解値と、#15の“ダイヤル入力正解値(オペレータ転送)” でのダイヤル入力正解値とは、誤入力を防止するため隣接した番号ではなく離れた異なった番号とする。例えば、#14の“ダイヤル入力正解値(受信確認)”でのダイヤル入力正解値が“1”であれば、#15の“ダイヤル入力正解値(オペレータ転送)” でのダイヤル入力正解値は“2”を挟んだ“3”ないし“5”を挟んだ“9”とする。また、#14の“ダイヤル入力正解値(受信確認)”でのダイヤル入力正解値が“2”であれば、#15の“ダイヤル入力正解値(オペレータ転送)” でのダイヤル入力正解値は“5”及び“8”を挟んだ“0”とする。また、#14の“ダイヤル入力正解値(受信確認)”でのダイヤル入力正解値と、#15の“ダイヤル入力正解値(オペレータ転送)”は、電話連絡毎にランダムに変更することで、誤入力を防止する。但し、このランダムでの変更時も隣接したダイヤル番号(同一ダイヤル番号も含め)が選択されないようにする。
連絡結果管理テーブル62は、#(管理番号)621、項目名622、設定値/格納値623を備える。項目名622の例として、“保守案件番号”、“作成日時”、“全体最終結果(0:成功、90:異常終了、91:中断ボタンが押下され、処理中止、92:規定回数、連絡処理を実行したが連絡者なし)”、“全体最終結果更新日時”などである。
項目名622に対応する設定値/格納値623は、“T1406A3982−20140707XYZ”、 “2014/07/07 22:54:21(YYYY/MM/DD hh:mm:ss)”、“0”、“2014/07/07 22:57:35(YYYY/MM/DD hh:mm:ss)”である。
<連絡者検索結果の表示画面>図7
図7は、連絡者検索結果の表示画面70の構成例を示す図である。連絡者検索結果の表示画面70は、
待機部署を検索するための条件(検索条件)71、検索条件71に対応する検索の結果である検索結果72(休日の待機保守員情報72)及び検索結果73(夜間の待機保守員情報73)、連絡条件74が表示される。
情報伝達システム1は、検索条件71として“拠点コード:ZDL7”、“部課コード:CRC99”、“グループ:9G”が入力部24で入力されると、オペレータ端末12の表示部26などに、休日での待機保守員情報72及び夜間での待機保守員情報73が表示する。その待機保守員情報72及び待機保守員情報73には、“日付情報”、“連絡条件”、“優先順位番号(1〜4)”及び“連絡者氏名”、“連絡者の電話番号”、“メール及び電話での連絡選択条件(1:メール&電話、2:メールのみ)”及び“送信メールアドレス”が表示される。
連絡条件74として、“1”は“1名毎、順番にメール送信と電話連絡を実施”を表し、“2”は“メールを全員へ同時に送信後、順番に電話連絡を実施”を表し、“3”は“メールを全員へ同時に送信後、電話連絡を実施しない”を表す。また、情報伝達システム1は、“2014/7/6(日)”の休日での保守対応では、連絡条件74が“1”であるの“1名毎、順番にメール送信と電話連絡を実施”を行い、優先順位が“1”である“B田F道”(電話番号:111−2222−99991、メール:bdenfmichi111@abc222.netw)に対し、メール及び電話での連絡選択条件(1:メール&電話)に従い連絡(情報伝達)をまず実行する。連絡が取れない場合、情報伝達システム1は、優先順位番号2の“C山G男”に連絡を実施する。以下、優先順位番号が“4”までの待機保守員に対し連絡を取れるまで連絡を実行する。また、情報伝達システム1は、“2014/7/7(月)”の平日夜間での保守対応も、“2014/7/6(日)”の休日での保守対応と同様な連絡を実行する。
<送信メール情報>図8
図8は、送信メールに関する情報を示す図である。送信メール80の例として、メール送信先81、送信メールヘッダ情報82、メール本文83から構成される。メール送信先81は、図7で示した優先順位番号に従った第1連絡者から第4連絡者の氏名と送信メールアドレスで構成される。例えば、第1連絡者は“B田F道”で、送信先メールアドレスは“bdenfmichi111@abc222.netw”である。
送信メールヘッダ情報82は、送信日時、題名、送信元メールアドレスを備え、図8のように、例えば、送信日時が“2014/7/7 22:52:30”、題名が“保守受付拠点への依頼(障害連絡)”、送信元メールアドレスとして、“Supervisor@Maintenance−master.wwwnetw”という情報が、送信メール80に付加されている。
メール本文83の項目の例として、“障害受付日時”、“お客様名”、“お客様部署名”、“保守契約形態”、“保守拠点(コード)”、“部課コード(グループ)”、“保守対応機種”、“型名/製造番号”、“障害現象”、“お客様住所”がある。
また、メール本文83の項目に対応する内容(待機保守員への伝達情報の内容)として、“2014/7/7 22:51:59”、“A電機”、“Bデータセンタ”、“X:標準出張保守契約”、“拠点1302(ZDL7)”、“CRC99(7G)”、“EXサーバ”、“Type−FloraPrius/HS1234ABC”、“リブート繰り返し/メモリエラー”、“東京都S区XX町AA−BB−CC DビルE階”、“0055−2458−9876−内線2245”がある。
<自動連絡結果の表示画面>図9、図10
図9は、第1の自動連絡結果例の表示画面の構成例90を示す図である。図10は、第2の自動連絡結果例の表示画面の構成例100を示す図である。自動連絡結果の表示画面構成90として、連絡先の検索条件91と、その検索条件91に対応する連絡結果を表示する。図9の例では、連絡結果1(符号92)及び連絡結果2(符号93)を表示しているが、実際にはどちらか一方がオペレータ端末12の表示部26に表示される。情報伝達処理(連絡処理)を中止するための中断ボタン94も備える。
検索条件91(拠点コード:ZDL7、部課コード:CRC99、グループ:9G)の入力が完了し、情報伝達システム1(サーバ11)の入力部で入力情報が受け付けられると、オペレータ端末12やサーバ11の表示部26に、検索条件91とそれに対応する連絡結果が表示される。
連絡結果1(符号92)を説明する。情報伝達システム1は、第1連絡者の“B田F道”へのメール送信が“2014/7/7 22:53:30”に完了し、送信完了の1分後(通話時刻1が“22:54:31”)に電話連絡したが、“不在”であった。そこで、情報伝達システム1は、第2連絡者である“C山G男”へ“22:55:02”にメールを送信し、“22:56:03”に電話連絡を行ったが、“不在”であった。そのため、情報伝達システム1は、第3連絡者である“D海H仁”へ“22:56:34”にメールを送信し、“22:57:35”に電話連絡を行い通話ができ、保守依頼内容という情報の伝達を完了した。その結果が、符号92に示す連絡結果1である。
次に、連絡結果2(符号93)を説明する。連絡結果2では、第1連絡者から第4連絡者までの1回目の電話連絡が“不在”で通話できなかったため、再度第1連絡者他に対し電話連絡を行ったものである。その結果、第1連絡者は“不在”、第2連絡者は“話し中で規定時間経過”したため、第3連絡者に電話連絡し保守依頼内容を伝達できたものである。
次に、第2の自動連絡結果例の表示画面構成100を説明する。表示画面構成例100は、検索条件101と、入力された検索条件101に対する検索結果102で構成する。検索条件101への入力項目は、保守依頼を受け付けた期間、保守拠点を一意に識別する保守拠点コード、保守契約者1020からの問合せNo(保守依頼番号)である。図10での検索条件101は、期間が“2014/7/6−2014/7/7”で、拠点コード及び問合せNoは“指定なし”である。
検索結果102の項目は、#(管理番号)、連絡部署、拠点コード、連絡者、最終連絡結果、問合せ番号、お客様名、連絡開始日時である。例えば、#(管理番号)が“1”である情報伝達結果(自動連絡結果)は、
連絡部署が“CRC99”、拠点コードが“ZDL7”である連絡者“3rd_D海H仁”(優先順位番号が3)に連絡が成功し、連絡開始日時が“2014/7/7 22:52:00”から約2分後の連絡終了時間が“22:54:21”に連絡が完了していることが分かる。これにより、お客様名が“A電機”で問合せ番号が“T1406A3982”に対する保守が開始されることも分かる。#(管理番号)が“1”以外の番号における情報伝達の状況も一覧表示できるので、情報伝達及び保守対応状況の全体を迅速に把握することができる。
<待機者への連絡処理>図11−図13
図11は、待機者への連絡処理を示すフローチャート図である。図12は、待機者への連絡処理での電話応答判断処理を示すフローチャート図である。図13は、待機者への連絡処理でのオペレータ転送処理を示すフローチャート図である。図11から図13の処理で待機者への連絡処理を構成する。なお、処理の主体をサーバ11のCPU21とするが、サーバ11ないし情報伝達システム1全体でもよい。
S1101で、CPU21は、連絡者発信データの有無をチェックする。そのため、CPU21は、連絡部117の連絡情報DB1171に待機保守員へ伝達すべき情報(未送信メール等)があるかをチェックする。
S1102で、CPU21は、S1101でのチェック結果から未伝達データが有るかを判断する。無い場合(S1102:No)、CPU21は再びS1101を実行し、有る場合(S1102:Yes)はS1103を実行する。
S1103で、CPU21は、メール送信済かを連絡結果DB1172内の連絡結果管理テーブル61により判断する。具体的には、CPU21は、連絡結果管理テーブル61の#10の“メール送信回数”と#11の“メール連絡結果”で、“メール送信回数”が1回以上で、“メール連絡結果”が“0(正常)”である場合にメール送信済と判断する。メール送信済の場合(S1103:Yes)、CPU21はS1108を実行し、メール送信が済んでない場合(S1103:Yes)、S1104を実行する。
S1104で、CPU21は、まず、優先順位が一番高い第1連絡者にメールを送信する。
S1105で、CPU21は、メール送信が成功したかを判断する。メール送信が成功している場合(S1105:Yes)、CPU21は、S1106を実行する。メール送信が失敗している場合(S1105:No)、CPU21は、連絡結果管理テーブル61の#10の“メール送信回数”に“1”を格納し、#11の“メール連絡結果”に0以外の値(異常)を格納して、再度S1104を実行する。なお、S1105の判断では、CPU21がメール送信回数の上限に到達したかも連絡環境管理テーブル50(#8の“メール送信リトライ回数”)により判断する。図示はしていないが、メール送信回数の上限に到達した場合、CPU21は、次の連絡者(第2連絡者)に対する連絡処理を実行するため、処理をS1101に戻す。
S1106で、CPU21は、連絡結果管理テーブル61の更新、すなわち、#10の“メール送信回数”に“1”を格納し、#11の“メール連絡結果”に“0(正常)”を格納する。
S1107で、CPU21は、所定時間(a)の間、待機する。所定時間(a)は、連絡環境管理テーブル50の#9の“メール送信後の待機秒数”に設定された値で、例えば図5のように60秒(1分)である。
S1108で、CPU21は、メールを送信した待機者へ電話発信を連絡部117に指示する。指示を受けた連絡部117はPBX118経由公衆回線網1012で、連絡者(待機保守員)の携帯電話に電話発信を行う。連絡部117は、連絡者(待機保守員)からの応答を所定時間待つ。その所定時間は、連絡環境管理テーブル50の#6の“電話発信秒数”に設定された時間である。図5の例では、“30秒”である。また、話し中の応答があった場合、連絡部117は、連絡環境管理テーブル50の#5の“話し中時の待機秒数”に設定された時間(図5の例では“180秒(3分)”)、待機する。そして、その結果を連絡部117は、CPU21に送信する。
S1109で、CPU21は、連絡部117からの送信された結果で応答が有ったか否かを判断する。応答があった場合(S1109:Yes)、CPU21はS1110を実行し、無い場合(S1109:No)、S1201(図12)を実行する。以降の説明では連絡部117等が実行する処理があるが、CPU21が処理するものとして説明する。
S1110で、CPU21は、音声連絡1と音声連絡1の受信確認を行う。音声連絡1としては、例えば、図3の待機者管理テーブル30の#11で示すように、“A電機様のBデータセンタで障害が発生しました。対応お願いします。受信確認のため、電話のAボタン(1のダイヤル)を押してください。オペレータ転送希望の場合は、Bボタン(3のダイヤル)を押してください。”という音声をCPU21が、連絡者(待機保守員)の携帯電話に連絡する。連絡を受けた連絡者(待機保守員)は、所定のダイヤルを押下する。CPU21は、押下されたダイヤルの情報を入力部24経由で受け付ける。
S1111で、CPU21は、受け付けた入力値が何であるかを判断する。連絡結果管理テーブル61の#14の“ダイヤル入力正解値(受信確認)”に設定された“1”であればS1112を、#15の“ダイヤル入力正解値(オペレータ転送)” に設定された“3”であればS1301(図13)を、それ以外であればS1117を実行する。
S1112で、CPU21は、音声連絡2、例えば“保守対応をお願いします”等の音声連絡を連絡者(待機保守員)の携帯電話に送信する。
S1113で、CPU21は、連絡者(待機保守員)の携帯電話との電話回線を切断する。
S1114で、CPU21は、連絡結果管理テーブル61を更新する。つまり、CPU21は、連絡結果管理テーブル61の#12の“電話連絡回数”に電話連絡を実行した回数を、#13の“電話連絡結果”に“0:ダイヤル入力値確認で成功”を、“最終ダイヤル入力値”に“1(受信確認)”をそれぞれ設定する。
S1115で、CPU21は、連絡結果管理テーブル62を更新する。つまり、CPU21は、連絡結果管理テーブル62の#3の“全体最終結果”に“0(成功)”を、#4の“全体最終結果更新日時”に最終結果更新時刻情報を格納する。
S1116で、CPU21は、電話連絡回数が規定回数を超えたかを連絡環境管理テーブル50の#4の“ダイヤルエラー回数”の設定値で判断する。図5の例では、設定値(規定回数)が5回なので、電話連絡回数が5回以下の場合(S1116:No)、CPU21はS1117を実行し、5回を超える場合(S1116:Yes)、図12のS1204を実行する。
S1117で、CPU21は、音声連絡3、例えば“指定されたダイヤル番号が入力されませんでした。ダイヤル番号1かダイヤル番号3のどちからを押してください”との音声ガイダンスで音声連絡を行い、再度受信確認を行う。そして、CPU21は、S1111を再び実行する。
S1201で、CPU21は、話し中であるかを判断する。話し中である場合(S1201:Yes)、CPU21はS1202を実行し、話し中でない場合(S1201:No)、S12023実行する。
S1202で、CPU21は、話し中の状態が1回目であるかを判断する。これは、同じ連絡者(待機保守員)に対し1回だけ電話連絡を繰り返す。なお、連絡環境管理テーブル50に話し中での繰り返し連絡回数の上限値という項目を設け、その設定値に応じて2回以上の電話連絡を繰り返すこともできる。話し中の状態が1回目である場合(S1202:Yes)、CPU21はS1210を実行し1回目でない場合(S1202:No)、S1203を実行する。
S1203で、CPU21は、連絡者(待機保守員)の携帯電話の留守電等に“連絡事項を確認願います。連絡内容は・・・”という音声連絡4を録音させる処理を実行する。
S1204で、CPU21は、連絡者(待機保守員)の携帯電話との電話回線を切断する。
S1205で、CPU21は、連絡結果管理テーブル61を更新する。つまり、連絡結果管理テーブル61の#13の“電話連絡結果”に対応する設定値/格納値613の欄に“4(話し中)”を格納する。
S1206で、CPU21は、現在連絡した連絡者が最終連絡者であるかを判断する。最終連絡者でない場合(S1206:No)、CPU21は、次の連絡者(待機保守員)に同じ情報伝達を行うためS1101からの処理を再び実行する。最終連絡者である場合(S1206:Yes)、CPU21は、S1207を実行する。
S1207で、CPU21は、所定ループ回数を超過したかを判断する。つまり、全ての連絡者(待機保守員)への連絡処理を所定回数、つまり連絡環境管理テーブル50の#3の“連絡ループ(繰り返し)回数”での設定値(図5の例では“3回”)の回数分、連絡処理を実行したかを判断する。超過した場合(S1207:Yes)、CPU21はS1208を実行し、超過していない場合(S1207:No)はS1101を再び実行する。
S1208で、CPU21は、連絡結果管理テーブル61を更新する。つまり、CPU21は、連絡結果管理テーブル61の#13の“電話連絡結果”に“3:不在”を設定する。
S1209で、CPU21は、連絡結果管理テーブル62を更新する。つまり、CPU21は、連絡結果管理テーブル62の#3の“全体最終結果”に“92(規定回数、連絡処理を実行したが連絡者なし)”を設定する。そして、本保守案件で、保守員を確保できなかったことをオペレータ端末12に通知する。次に、別の保守対応案件が存在するかを確認するため、再びS1101の処理を実行する。
S1210で、CPU21は、所定時間(b)待機する。つまり、CPU21は、連絡環境管理テーブル50の#5の“話し中時の待機秒数”での設定値の時間(図5では“180秒(3分)”)、待機状態とする。
S1212で、CPU21は、連絡結果管理テーブル61を更新する。つまり、連絡結果管理テーブル61の#12の“電話連絡回数”に“1回”を、#13の“電話連絡結果”に“4:話し中”を設定する。そして、CPU21は、S1108以降の処理を再び実行する。
S1301で、CPU21は、音声連絡5として“オペレータに転送します。暫くお待ちください。”との音声を、連絡者(待機保守員)の携帯電話に送信する。
S1302で、CPU21は、オペレータへの転送に成功したかを判断する。成功した場合(S1302:Yes)、CPU21はS1303を実行し、失敗した場合(S1302:No)はS1304を実行する。
S1303で、CPU21は、オペレータへの転送結果が成功したと判断し、次のS1113を実行する。
S1304で、CPU21は、オペレータへの転送結果が失敗したと判断し、S1305を実行する。
S1305で、CPU21は、音声連絡6として“転送に失敗しました” との音声を、連絡者(待機保守員)の携帯電話に送信する。
<メール送信処理>図14
図14は、メール送信処理を示すフローチャート図である。なお、処理の主体をサーバ11のCPU21とするが、サーバ11ないし情報伝達システム1全体でもよい。本処理は、CPU21がS1104でのメール送信処理を実行することを契機に開始される。
S1401で、CPU21は、SMTP(Simple Mail Transfer Protocol)動作、すなわち、メールサーバ特定と特定されたメールサーバへの接続を試行する。
S1402で、CPU21は、メールサーバへの接続が成功したかを判断する。接続が成功した場合(S1402:Yes)、CPU21はS1403を実行し、失敗した場合(S1402:No)はS1407を実行する。
S1403で、CPU21は、連絡者(待機保守員)の携帯電話へ電子メールを送信する。
S1404で、CPU21は、メール送信が成功したかを判断する。電子メール送信が成功した場合(S1404:Yes)、CPU21はS1405を実行し、失敗した場合(S1404:No)はS1405を実行する。
S1405で、CPU21は、メール送信回数が規定回数を超えたかを判断する。規定回数は、連絡環境管理テーブル50の#8の“メール送信リトライ回数”に設定された値である(図5の例では2回)。超えた場合(S1405:Yes)、CPU21はS1406を実行し、超えていない場合(S1404:No)はS1403を実行し、再度電子メールを送信する。
S1406で、CPU21は、オペレータ端末12にエラーを報告する。そして、CPU21は処理をS1104へ戻す。
S1407で、CPU21は、特定されたメールサーバへの接続の試行回数が、規定回数を超えたかを判断する。超えた場合(S1407:Yes)、CPU21はS1408を実行し、超えていない場合(S1407:No)は再びS1401を実行し、再度メールサーバへの接続を試みる。
S1408で、CPU21は、オペレータ端末12にエラーを報告する。
なお、本電子メール送信では、待機者管理テーブル30の#3の“連絡区分”に従い、連絡者(待機保守員)1名毎に電子メールを送信するか、連絡者全員に同時に電子メールを送信して同報するかを選択できる。同じく、電話連絡も“連絡区分”に従い、1名毎・実施せずという条件より選択することができる。また、図11から図14の処理は、異なる保守対応案件を同時に対応するため並列的に実行することもできる。
<連絡中止処理>図15
図15は、連絡中止処理を示すフローチャート図である。なお、処理の主体をサーバ11のCPU21とするが、サーバ11ないし情報伝達システム1全体でもよい。
S1501で、CPU21は、中断ボタン94が押されたかを判断する。中断ボタン94が押された場合(S1501:Yes)、CPU21はS1502を実行し、押されない場合(S1501:No)は再びS1501の判断を実行する。
S1502で、CPU21は、連絡処理は完了しているかを判断する。連絡処理が完了している場合(S1502:Yes)、CPU21はS1501を再び実行し、連絡処理は完了していない場合(S1502:No)はS1503を実行する。
S1503で、CPU21は、連絡処理を中止する。
以上のように、本発明の実施形態では、待機保守員へ受け付けた保守依頼内容の一部を含む第1の保守対応要求を第1の情報通信部で伝達し、第1の対応要求から第1の所定時間が経過した後、第2の保守対応要求を第2の情報通信部で伝達し、第2の対応要求から第2の所定時間が経過しても第2の保守対応要求に対する応答が無い場合、次の待機保守員へ保守対応要求を伝達する。このように、異なる伝達手段(第1の情報通信部及び第2の情報通信部)で、時間差を設けて保守対応要求と保守情報を伝達する。そして、要求への応答が無い場合は次の保守待機員に情報を伝達するようにした。1人以上の待機保守員に複数回の情報伝達を同時に実行することで、即時応答可能な待機保守員を確保できる。そのため、ユーザ直接の保守依頼への対応時間を短縮することができ、ユーザ満足度を向上できる。なお、上記実施例では、保守会社などの待機保守員に対する情報伝達を例としたが、巡回保守員などへの情報伝達でもよく、また、運送会社の運送員、ビル管理会社の警備員などへの情報伝達にも用いることができる。
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。また、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。
各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、SSD(Solid State Drive)等の記録装置、または、ICカード、SDカード、DVD等の記録媒体に置いてもよい。また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
1:情報伝達システム、11:サーバ、12:オペレータ端末、21:CPU、22:メモリ、23:記憶部、24:入力部、25:出力部、26:表示部、27:通信部、伝達情報生成部111、保守依頼受付部112、メール作成部114、連絡者登録部115、連絡者作成部116、連絡部117、113/118:PBX、1001/1002:インターネット、1011/1012:公衆電話回線網

Claims (19)

  1. ユーザからの受け付けた保守依頼内容を含む対応要求情報を保守対応要員へ連絡する情報伝達システムであって、
    前記情報伝達システムは、
    システム全体を制御するCPUと、
    前記保守依頼内容を含む対応要求情報を受け付ける受付部と、
    前記保守依頼内容を含む対応要求情報および保守対応要員からの応答結果を格納するメモリと、
    前記保守依頼内容を含む対応要求情報を伝達する第1の情報通信部と、
    前記保守依頼内容を含む対応要求情報を伝達する第2の情報通信部とを備え、
    前記CPUが、
    前記保守依頼内容を含む第1の対応要求情報を前記第1の情報通信部で前記対応要員へ伝達し、
    前記第1の対応要求情報に対する対応要求から第1の所定時間が経過した後、前記保守依頼内容を含む第2の対応要求情報を前記第2の情報通信部で前記対応要員へ伝達し、
    前記第2の対応要求情報に対する対応要求から第2の所定時間が経過しても、前記第2の対応要求情報に対する応答が前記対応要員から受け付けられないとき、前記第2の情報通信部で次の対応要員へ保守依頼内容を含む第3の対応要求情報の対応要求を伝達する
    ことを特徴とする情報伝達システム。
  2. 請求項1記載の情報伝達システムであって、前記第1の情報通信部は、インターネット網に接続され電子メールの送受信を行う機能を有し、前記第1の対応要求情報を前記電子メールで前記対応要員へ行う
    ことを特徴とする情報伝達システム。
  3. 請求項2記載の情報伝達システムであって、前記第2の情報通信部は、公衆電話回線網に接続され電話回線での通信を行う機能を有し、前記第2の対応要求情報を前記電話回線で前記対応要員へ行う
    ことを特徴とする情報伝達システム。
  4. 請求項3記載の情報伝達システムであって、前記対応要員に依頼情報または対応要求を実行する優先順位が付けられ、当該優先順位の情報が、前記情報伝達システムに格納される
    ことを特徴とする情報伝達システム。
  5. 請求項4記載の情報伝達システムであって、前記対応要員が2人以上存在する場合、全員に前記電子メールを同報した後、前記優先順位に従い前記対応要員へ前記電話回線で情報を伝達する
    ことを特徴とする情報伝達システム。
  6. 請求項4記載の情報伝達システムであって、前記対応要員が2人以上存在する場合、保守対応要員の全員に同時に前記電子メールを送信して同報するか否かを選択し、また、保守対応要員である待機者への連絡処理、電子メール送信処理は、異なる保守対応案件を並列的に実行する
    ことを特徴とする情報伝達システム。
  7. 請求項4記載の情報伝達システムであって、
    前記第2の対応要求情報に対する応答は、前記電話回線に接続された電話のダイヤル入力で行い、
    前記応答には2種類以上の応答方法があり、当該応答毎に異なる電話のダイヤル入力が割り当てられ、
    前記割り当てられた電話のダイヤル入力同士が隣接せず、前記第2の対応要求情報毎に前記電話のダイヤル入力をランダムに変更する
    ことを特徴とする情報伝達システム。
  8. 請求項7記載の情報伝達システムであって、前記対応要員が保守会社における保守員である
    ことを特徴とする情報伝達システム。
  9. ユーザからの受け付けた保守依頼内容を含む対応要求情報を対応要員へ連絡する情報伝達システムの情報伝達方法であって、
    前記情報伝達システムは、
    システム全体を制御するCPUと、
    前記保守依頼内容を含む対応要求情報を受け付ける受付部と、
    前記保守依頼内容を含む対応要求情報および保守対応要員からの応答結果を格納するメモリと、
    前記保守依頼内容を含む対応要求情報を伝達する第1の情報通信部と、
    前記保守依頼内容を含む対応要求情報を伝達する第2の情報通信部とを備え、
    前記CPUが、
    前記保守依頼内容を含む第1の対応要求情報を前記第1の情報通信部で前記対応要員へ伝達し、
    前記第1の対応要求情報に対する対応要求から第1の所定時間が経過した後、前記保守依頼内容を含む第2の対応要求情報を前記第2の情報通信部で前記対応要員へ伝達し、
    前記第2の対応要求情報に対する対応要求から第2の所定時間が経過しても、前記第2の対応要求情報に対する応答が前記対応要員から受け付けられないとき、前記第2の情報通信部で次の対応要員へ保守依頼内容を含む第3の対応要求情報の対応要求を伝達する
    ことを特徴とする情報伝達システムの情報伝達方法。
  10. 請求項9記載の情報伝達システムの情報伝達方法であって、前記第1の情報通信部は、インターネット網に接続され電子メールの送受信を行う機能を有し、前記第1の対応要求情報を前記電子メールで前記対応要員へ行う
    ことを特徴とする情報伝達システムの情報伝達方法。
  11. 請求項10記載の情報伝達システムの情報伝達方法であって、前記第2の情報通信部は、公衆電話回線網に接続され電話回線での通信を行う機能を有し、前記第2の対応要求情報を前記電話回線で前記対応要員へ行う
    ことを特徴とする情報伝達システムの情報伝達方法。
  12. 請求項11記載の情報伝達システムの情報伝達方法であって、前記対応要員に依頼情報または対応要求を実行する優先順位が付けられ、当該優先順位の情報が、前記情報伝達システムに格納される
    ことを特徴とする情報伝達システムの情報伝達方法。
  13. 請求項12記載の情報伝達システムの情報伝達方法であって、前記対応要員が2人以上存在する場合、対応要員である連絡者全員に前記電子メールを同報した後、前記優先順位に従い前記対応要員へ前記電話回線で情報を伝達する
    ことを特徴とする情報伝達システムの情報伝達方法。
  14. 請求項12記載の情報伝達システムの情報伝達方法であって、前記対応要員が2人以上存在する場合、保守対応要員の全員に同時に前記電子メールを送信して同報するか否かを選択し、また、保守対応要員である待機者への連絡処理、電子メール送信処理は、異なる保守対応案件を並列的に実行する
    ことを特徴とする情報伝達システムの情報伝達方法。
  15. 請求項12記載の情報伝達システムの情報伝達方法であって、
    前記第2の対応要求情報に対する応答は、前記電話回線に接続された電話のダイヤル入力で行い、
    前記応答には2種類以上の応答方法があり、当該応答毎に異なる電話のダイヤル入力が割り当てられ、
    前記割り当てられた電話のダイヤル入力同士が隣接せず、
    前記第2の対応要求情報毎に前記電話のダイヤル入力をランダムに変更する
    ことを特徴とする情報伝達システムの情報伝達方法。
  16. 請求項15記載の情報伝達システムの情報伝達方法であって、前記対応要員が保守会社における保守員である
    ことを特徴とする情報伝達システムの情報伝達方法。
  17. ユーザからの受け付けた保守依頼内容を含む対応要求情報を対応要員へ連絡する情報伝達システムで動作する情報伝達プログラムであって、
    前記情報伝達システムは、
    システム全体を制御するCPUと、
    前記保守依頼内容を含む対応要求情報を受け付ける受付部と、
    前記保守依頼内容を含む対応要求情報および保守対応要員からの応答結果を格納するメモリと、
    前記保守依頼内容を含む対応要求情報を伝達する第1の情報通信部と、
    前記保守依頼内容を含む対応要求情報を伝達する第2の情報通信部とを備え、
    前記CPUに、
    前記保守依頼内容を含む第1の対応要求情報を前記第1の情報通信部で前記対応要員へ伝達する機能と、
    前記第1の対応要求情報に対する対応要求から第1の所定時間が経過した後、前記保守依頼内容を含む第2の対応要求情報を前記第2の情報通信部で前記対応要員へ伝達する機能と、
    前記第2の対応要求情報に対する対応要求から第2の所定時間が経過しても、前記第2の対応要求情報に対する応答が前記対応要員から受け付けられないとき、前記第2の情報通信部で次の対応要員へ保守依頼内容を含む第3の対応要求情報の対応要求を伝達する機能とを
    実行させることを特徴とする情報伝達システムの情報伝達プログラム。
  18. 請求項17記載の情報伝達システムで動作する情報伝達プログラムであって、
    前記CPUに、
    前記第1の情報通信部で、
    インターネット網に接続され電子メールの送受信を行う機能と、
    前記電子メールで前記第1の対応要求情報の前記対応要員への伝達を行う機能とを
    実行させることを特徴とする情報伝達システムの情報伝達プログラム。
  19. 請求項18記載の情報伝達システムで動作する情報伝達プログラムであって、
    前記CPUに、
    前記第2の情報通信部で、
    公衆電話回線網に接続され電話回線での通信を行う機能と、
    前記電話回線で前記第2の対応要求情報の前記対応要員への伝達を行う機能とを
    実行させることを特徴とする情報伝達システムの情報伝達プログラム。
JP2014222277A 2014-10-31 2014-10-31 情報伝達システム、情報伝達方法及び情報伝達プログラム Active JP6461560B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2014222277A JP6461560B2 (ja) 2014-10-31 2014-10-31 情報伝達システム、情報伝達方法及び情報伝達プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014222277A JP6461560B2 (ja) 2014-10-31 2014-10-31 情報伝達システム、情報伝達方法及び情報伝達プログラム

Publications (2)

Publication Number Publication Date
JP2016091143A JP2016091143A (ja) 2016-05-23
JP6461560B2 true JP6461560B2 (ja) 2019-01-30

Family

ID=56016944

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014222277A Active JP6461560B2 (ja) 2014-10-31 2014-10-31 情報伝達システム、情報伝達方法及び情報伝達プログラム

Country Status (1)

Country Link
JP (1) JP6461560B2 (ja)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002271524A (ja) * 2002-01-16 2002-09-20 Yamatake Corp 燃焼制御機器警報監視システムおよび遠隔監視装置
JP2004032042A (ja) * 2002-06-21 2004-01-29 Casio Comput Co Ltd 電子メールシステムおよびプログラム
JP2004062249A (ja) * 2002-07-24 2004-02-26 Fujitsu Fip Corp 障害対応システム,障害対応方法,障害対応プログラムおよび記録媒体
JP2009099135A (ja) * 2007-09-28 2009-05-07 Fujitsu Ltd 支援管理方法、支援管理システム及び情報処理装置

Also Published As

Publication number Publication date
JP2016091143A (ja) 2016-05-23

Similar Documents

Publication Publication Date Title
US8879717B2 (en) Systems and methods for customer contact
US10445744B2 (en) Systems and methods for customer contact
US7266734B2 (en) Generation of problem tickets for a computer system
US9756186B2 (en) Portable continuity object
US9804821B2 (en) Interaction history management device, interaction device and interaction history management method
US11689904B2 (en) System and method for notification transmission and confirmation management
JP6415505B2 (ja) ユーザとサービスエージェントとの間のコンタクトを調整するためのシステムおよび方法
JP2006277685A (ja) 障害発生通知プログラム、および通知装置。
JP6461560B2 (ja) 情報伝達システム、情報伝達方法及び情報伝達プログラム
WO2012011122A2 (en) A system and method for integrated queries routing and processing
KR101758337B1 (ko) 메시지의 중복알림을 방지하는 방법, 저장 매체 및 이를 운용하는 사용자 장치
JP2019176442A (ja) 情報処理装置、情報処理方法およびプログラム
JP2010198516A (ja) 情報収集システム
JP6043666B2 (ja) 電話接続システム及びその方法、プログラム
JP2010200182A (ja) 情報収集システム
JP2010200183A (ja) 情報収集システム
JP6795752B1 (ja) メッセージ自動送信システム及びメッセージ自動送信プログラム
JP2013038472A (ja) 電話転送装置、及び電話転送プログラム
JP5409576B2 (ja) 複数人へ行動指示を通知した後の対応状況を管理可能な一斉通知システム
JP2014038534A (ja) 業務記録システム及び業務記録方法
JP2012060398A (ja) 通報システム、転送制御装置及び通報方法
JP2019208112A (ja) 中継サーバ、および、中継方法
JP2019091126A (ja) 入居者対応システム
CA3109728A1 (en) Connected machine initiated service
JP2006086827A (ja) コールセンターの着信制御方法および着信制御システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170907

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180814

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180817

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20181004

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20181023

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20181116

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20181204

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20181226

R150 Certificate of patent or registration of utility model

Ref document number: 6461560

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250