JP3963216B2 - 受付方法、情報提供方法、受付システム、受付サーバ、及びコンピュータプログラム - Google Patents
受付方法、情報提供方法、受付システム、受付サーバ、及びコンピュータプログラム Download PDFInfo
- Publication number
- JP3963216B2 JP3963216B2 JP2002098108A JP2002098108A JP3963216B2 JP 3963216 B2 JP3963216 B2 JP 3963216B2 JP 2002098108 A JP2002098108 A JP 2002098108A JP 2002098108 A JP2002098108 A JP 2002098108A JP 3963216 B2 JP3963216 B2 JP 3963216B2
- Authority
- JP
- Japan
- Prior art keywords
- business
- store
- charge
- database
- information
- 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.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 title claims description 55
- 238000004590 computer program Methods 0.000 title claims description 11
- 230000010365 information processing Effects 0.000 claims description 16
- 208000027418 Wounds and injury Diseases 0.000 claims description 3
- 230000006378 damage Effects 0.000 claims description 3
- 208000014674 injury Diseases 0.000 claims description 3
- 230000008569 process Effects 0.000 description 29
- 230000008439 repair process Effects 0.000 description 19
- 238000010586 diagram Methods 0.000 description 18
- 238000004364 calculation method Methods 0.000 description 8
- 230000004044 response Effects 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 3
- KNMAVSAGTYIFJF-UHFFFAOYSA-N 1-[2-[(2-hydroxy-3-phenoxypropyl)amino]ethylamino]-3-phenoxypropan-2-ol;dihydrochloride Chemical compound Cl.Cl.C=1C=CC=CC=1OCC(O)CNCCNCC(O)COC1=CC=CC=C1 KNMAVSAGTYIFJF-UHFFFAOYSA-N 0.000 description 2
- 230000000295 complement effect Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 125000002066 L-histidyl group Chemical group [H]N1C([H])=NC(C([H])([H])[C@](C(=O)[*])([H])N([H])[H])=C1[H] 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、業務依頼の受付を行う受付方法、受付システム、及び該受付システムを実現するためのコンピュータプログラム、並びに業務依頼の受付に係る情報を提供する情報提供方法及び受付サーバに関する。
【０００２】
【従来の技術】
従来、顧客からの業務依頼を受付けるコールセンタでは、依頼された業務の実施希望日時をオペレータが顧客に伺った後、業務の遂行を請負う担当店と電話連絡をとり、顧客の実施希望日時に業務を実施することが可能か否かを問い合わせていた。
【０００３】
【発明が解決しようとする課題】
しかしながら、前述の方法では、顧客から業務依頼を受けた際にオペレータが顧客の居所に最も近い担当店を探し出して、電話連絡により顧客の希望日時に業務を遂行することができる者がいるか否かを担当店に確認しなければならず、オペレータは煩わしさを感じることがあり、また、顧客に対し速やかに対応出来ない場合があった。
【０００４】
そこで、各担当店、各業務毎に業務担当者の余力を効率的に管理でき、オペレータが担当店に逐次連絡をして確認することなく、速やかに顧客の応対ができる受付システムの開発が望まれていた。
【０００５】
また、複数の業務がある場合、一の業務担当者が他の業務の担当を兼任することがあり、業務単位で担当者の余力を管理することができるだけでなく、各担当店の業務形態に応じ、相互補完できる業務についての情報が得られる受付システムの開発が望まれていた。
【０００６】
本発明は斯かる事情に鑑みてなされたものであり、複数の処理について各処理毎に実行要求を受付ける際、各処理毎の処理可能数を予め定めておき、既に受付けた実行要求の数と前記処理可能数とに基づき、実行要求を受付けた処理の実行が可能であるか否かを判定し、前記処理の実行が不可能であると判定した場合、他の処理により実行可能であるか否かを判定することにより、実行要求を受付けることが可能であるか否かを速やかに判定することができる受付方法、受付システム、及びコンピュータプログラムを提供することを目的とする。
【０００７】
本発明の他の目的は、複数の受付形態に分類し、業務請負単位毎に予め選択された受付形態と既に受付けた各業務毎の実行依頼の件数とに基づき、各業務毎に実行依頼が受付可能であるか否かを判定し、判定した結果に関する情報を提供することにより、実行要求を受付けることが可能であるか否かについての情報を速やかに提供することができる情報提供方法及び受付サーバに関する。
【０００８】
本発明の更に他の目的は、各業務毎の受付可能数を予め定められた時間帯毎に規定して、実行依頼を受付けた業務が可能であるか否かを各時間帯毎に判定し、判定した結果についての情報を提供することにより、時間帯毎に実行依頼を受付けることが可能であるか否かについての情報を提供することができる情報提供方法を提供することにある。
【０００９】
【課題を解決するための手段】
第１発明に係る受付方法は、複数の業務について各業務毎の実行依頼を受付ける際、情報処理装置内のデータベースに記憶された情報に基づいて前記実行依頼の受付けが可能であるか否かを前記情報処理装置にて判定する受付方法において、業務を請負う各担当店が受付けることができる各業務毎の受付可能件数と一の業務の担当者が他の業務を実行可能であるか否かを定めた業務余力に関する管理パターンとをそれぞれ各担当店を識別するためのＩＤに関連付けて前記情報処理装置内のデータベースに予め記憶させておき、前記情報処理装置は、各担当店が既に受付けた各業務毎の件数を各担当店のＩＤに関連付けてデータベースに記憶させ、業務の実行依頼を受付けた場合、前記業務を請負う担当店のＩＤを取得し、取得した担当店のＩＤと関連付けて記憶してある各業務毎の受付可能件数、業務余力の管理パターン及び既存受付数をデータベースから読出し、読出した担当店における業務余力の管理パターンに従い、読出した受付可能件数及び既存受付数を用いて前記担当店の各業務毎の余力を算出し、算出した余力に基づいて前記業務依頼の受付けが可能であるか否かを判定することを特徴とする。
【００１０】
第２発明に係る情報提供方法は、複数の業務について各業務毎の実行依頼を受付ける際、情報処理装置内のデータベースに記憶された情報に基づいて前記実行依頼が受付け可能であるか否かを前記情報処理装置が判定し、判定結果に係る情報を出力する情報提供方法において、業務を請負う各担当店が受付けることができる各業務毎の受付可能件数と一の業務の担当者が他の業務を実行可能であるか否かを定めた業務余力に関する管理パターンとをそれぞれ各担当店を識別するためのＩＤに関連付けて前記情報処理装置内のデータベースに予め記憶させておき、前記情報処理装置は、各担当店が既に受付けた各業務毎の件数を各担当店のＩＤに関連付けてデータベースに記憶させ、業務の実行依頼を受付けた場合、前記業務を請負う担当店のＩＤを取得し、取得した担当店のＩＤと関連付けて記憶してある各業務毎の受付可能件数、業務余力の管理パターン及び既存受付数をデータベースから読出し、読出した担当店における業務余力の管理パターンに従い、読出した受付可能件数及び既存受付数を用いて前記担当店の各業務毎の余力を算出し、算出した余力に基づいて前記業務依頼の受付けが可能であるか否かを判定し、判定結果を出力することを特徴とする。
【００１１】
第３発明に係る情報提供方法は、第２発明に係る情報提供方法において、各担当店における各業務毎の受付可能件数は予め定められた時間帯毎に規定されており、実行依頼を受付けた業務が受付可能であるか否かを各時間帯毎に判定し、判定結果を出力することを特徴とする。
【００１２】
第４発明に係る受付システムは、複数の業務について各業務毎に実行依頼を受付け、受付けた実行依頼に関する情報を送信する端末装置と、該端末装置から送信される情報を受信した場合、前記実行依頼を受付けるか否かを判定し、判定結果を前記端末装置へ送信する受付サーバとを備える受付システムにおいて、前記端末装置は、業務を請負う担当店を識別するためのＩＤの入力を受付ける手段を備え、受付けた担当店のＩＤを前記実行依頼に関する情報と共に送信するようにしてあり、前記受付サーバは、各担当店が受付けることができる各業務毎の受付可能件数を各担当店のＩＤに関連付けて予め記憶するデータベースと、一の業務の担当者が他の業務を実行可能であるか否かを定めた業務余力に関する管理パターンを各担当店のＩＤに関連付けて予め記憶するデータベースと、各担当店が既に受付けた各業務毎の件数を各担当店のＩＤに関連付けて記憶するデータベースと、前記端末装置から送信される情報を受信した場合、業務を請負う担当店のＩＤを取得する手段と、取得した担当店のＩＤと関連付けて記憶してある各業務毎の受付可能件数、業務余力の管理パターン及び既存受付数を各データベースから読出す手段と、読出した担当店における業務余力の管理パターンに従い、読出した受付可能件数及び既存受付数を用いて前記担当店の各業務毎の余力を算出する手段と、算出した余力に基づいて前記業務依頼を受付けるか否かを判定する手段と、該手段による判定結果を前記端末装置へ送信する手段とを備え、前記端末装置は、前記受付サーバから送信される判定結果を受信し、受信した判定結果を表示するようにしてあることを特徴とする。
【００１３】
第５発明に係る受付サーバは、複数の業務について各業務毎に実行依頼を受付ける際、該実行依頼の受付けが可能であるか否かを判定し、判定結果に係る情報を出力する受付サーバにおいて、業務を請負う各担当店が受付けることができる各業務毎の受付可能件数を各担当店を識別するためのＩＤに関連付けて予め記憶するデータベースと、一の業務の担当者が他の業務を実行可能であるか否かを定めた業務余力に関する管理パターンを各担当店のＩＤに関連付けて予め記憶するデータベースと、各担当店が既に受付けた各業務毎の件数を各担当店のＩＤに関連付けて記憶するデータベースと、業務の実行依頼を受付けた場合、前記業務を請負う担当店のＩＤを取得する手段と、取得した担当店のＩＤと関連付けて記憶してある各業務毎の受付可能件数、業務余力の管理パターン及び既存受付数を各データベースから読出す手段と、読出した担当店における業務余力の管理パターンに従い、読出した受付可能件数及び既存受付数を用いて前記担当店の各業務毎の余力を算出する手段と、算出した余力に基づいて前記業務依頼を受付けるか否かを判定する手段とを備え、該手段による判定結果に係る情報を出力するようにしてあることを特徴とする。
【００１４】
第６発明に係るコンピュータプログラムは、複数の業務について各業務毎の実行依頼を受付ける際、コンピュータ内のデータベースに記憶された情報に基づいて前記実行依頼の受付けが可能であるか否かを判定させるコンピュータプログラムにおいて、業務を請負う各担当店が受付けることができる各業務毎の受付可能件数と一の業務の担当者が他の業務を実行可能であるか否かを定めた業務余力に関する管理パターンとをそれぞれ各担当店を識別するためのＩＤに関連付けて前記データベースに予め記憶させておき、コンピュータに、各担当店が既に受付けた各業務毎の件数を各担当店のＩＤに関連付けてデータベースに記憶させるステップと、コンピュータに、業務の実行依頼を受付けた場合、前記業務を請負う担当店のＩＤを取得させるステップと、コンピュータに、取得させた担当店のＩＤと関連付けて記憶してある各業務毎の受付可能件数、業務余力の管理パターン及び既存受付数をデータベースから読出させるステップと、コンピュータに、読出させた担当店における業務余力の管理パターンに従い、読出させた受付可能件数及び既存受付数を用いて前記担当店の各業務毎の余力を算出させるステップと、コンピュータに、算出させた余力に基づいて前記業務依頼の受付けが可能であるか否かを判定させるステップとを有することを特徴とする。
【００１５】
本発明にあっては、各処理毎の処理可能数を予め定めておき、既に受付けた実行要求の数と処理可能数とに基づき、実行要求を受付けた処理の実行が可能であるか否かを判定し、前記処理の実行が不可能であると判定した場合、他の処理により実行可能であるか否かを判定するようにしている。したがって、例えば、複数の処理を行う各担当店が処理可能件数を予め定めておくことによって、各担当店、各処理毎に処理を実行する担当者の余力を効率的に管理することができ、処理の実行要求を受付けた者が担当店に逐次連絡をして確認することなく、処理の実行が可能であるか否かについての情報を得ることができるため、速やかな顧客の応対が可能となる。
【００１６】
また、本発明にあっては、各業務毎の受付可能件数と、一の業務が他の業務により実行可能であるか否かとを規定した受付形態が、業務請負単位毎に予め選択されており、選択された受付形態と既に受付けた各業務毎の実行依頼の件数とに基づき、各業務毎に実行依頼が受付可能であるか判定し、判定した結果を提供するようにしている。したがって、例えば、業務の実行を請負う各担当店は、その業務形態に応じて柔軟に受付形態を選択することができ、選択された受付形態に応じ、複数の業務間にて相互補完できる業務についての情報を提供することが可能となる。
【００１７】
更に、本発明にあっては、各業務毎の受付可能数を予め定められた時間帯毎に規定して、業務依頼を受付けた業務が可能であるか否かを各時間帯毎に判定するようにしている。したがって、時間帯毎に業務の受付余力を管理することが可能となる。
【００１８】
更に、本発明にあっては、各業務毎の受付可能件数を予め定めておき、既に受付けた業務依頼の件数と受付可能件数とに基づき、業務依頼を受付けた業務の実行が可能であるか否かを判定し、前記業務の実行が不可能であると判定した場合、他の業務により実行可能であるか否かを判定するようにしている。したがって、例えば、各担当店、各業務毎に業務依頼の受付可能件数を予め定めておくことによって、各担当店、各業務毎に業務担当者の余力を効率的に管理することができ、業務依頼を受付けた者が担当店に逐次連絡をして確認することなく、業務の実行が可能であるか否かについての情報を得ることができるため、速やかな顧客の応対が可能となる。
【００１９】
【発明の実施の形態】
以下、本発明をその実施の形態を示す図面に基づいて具体的に説明する。
図１は本実施の形態に係る受付システムの構成を示す模式図である。図中２００は、コールセンタ内にてオペレータが操作をする端末装置であり、該端末装置２００には、後述する受付サーバ１００及び自動分配機３００が接続されている。コールセンタ内に設置された自動分配機３００には、公衆電話回線網ＴＮを介して顧客が利用する電話機５００に接続される。
【００２０】
コールセンタは、例えば、ガス会社によって運営されており、顧客からガス栓の開栓、閉栓、修繕等の業務依頼を電話にて受付けている。顧客は、電話機５００を利用してガス栓の開栓、閉栓又は修繕の業務依頼をコールセンタ内のオペレータに音声により伝える。オペレータは業務依頼を受付ける際に、依頼内容、顧客の氏名、住所、業務の実施希望日時等を顧客に尋ねる。そして、オペレータは顧客の応答に基づき、端末装置２００に依頼内容、顧客の氏名、住所、業務の実施希望日時等の情報を入力する。
【００２１】
端末装置２００に入力された依頼内容、顧客の氏名、住所、業務の実施希望日時等の情報は受付サーバ１００へ送信される。受付サーバ１００では、ガス栓の開栓、閉栓、修繕等の業務を取扱っている担当店の情報をデータベースに記憶しており、各担当店にて業務の受付件数に余力があるか否かを判定することによって、受付けた業務を顧客の実施希望日時に業務依頼が実施可能であるか否かを判定する。なお、各業務の受付件数の余力を業務余力と呼ぶ。
【００２２】
また、受付サーバ１００には、専用回線ＰＬを介して指示サーバ４００に接続されている。指示サーバ４００は、指示サーバ４００が属する地区の担当店の情報をデータベース化しており、各担当店における業務余力の年次計画、会議又は休日による業務余力の変更等の情報を各担当店から随時受付けている。各担当店から受付けた業務余力に関する情報は、専用回線ＰＬを通じて受付サーバ１００へ送信され、受付サーバ１００が備えるデータベースが更新される。
【００２３】
図２は、受付サーバ１００の内部構成を示すブロック図である。図中１０１はＣＰＵであり、バス１０２を介して後述する各ハードウェア各部に接続されていて、ＲＯＭ１０３に格納された制御プログラムに従って、それらを制御する。ＲＡＭ１０４は、ＳＲＡＭ又はフラッシュメモリ等で構成され、ＲＯＭ１０３に格納された制御プログラムの実行時に発生するデータを記憶する。
【００２４】
表示部１０５は、ＣＲＴ、液晶ディスプレイ等の表示装置であり、入力部１０６は、キーボード、マウス等の入力装置である。表示部１０５及び入力部１０６は、例えば、担当店に関する情報を表示・入力する際に利用される。端末装置２００を通じて、各種の情報を表示・入力する形態である場合には、表示部１０５及び入力部１０６を受付サーバ１００に備えている必要はない。
【００２５】
通信部１０７は、モデム等の回線終端装置を備えている。通信部１０７は、端末装置２００からの要求に応じて担当店の業務余力に関する情報を端末装置２００へ送信し、端末装置２００から送信された業務依頼に関する情報を受信する。また、指示サーバ４００から送信された各担当店の業務余力に関する情報、休日・会議に関する情報等を受信する。通信部１０７はこれらの情報の送受信の制御を行う。
【００２６】
内部記憶装置１０９は、ハードディスクのような記憶装置からなり、記憶領域の一部は、各担当店に関する情報を記憶する担当店マスタ１０９ａ、各担当店の業務余力の形態を分類した余力チェックパターンデータベース（余力チェックパターンＤＢ）１０９ｂ、各担当店にて受付けることが可能な最大件数が時間帯毎、業務毎に記憶してある受付管理データベース（受付管理ＤＢ）１０９ｃ、各担当店にて受付けた件数を記憶した既存受付データベース（既存受付ＤＢ）１０９ｄとして用いられており、必要に応じて各種データベースにアクセスし、情報の記憶及び読取り処理が行われる。
【００２７】
なお、本実施の形態では、受付サーバ１００の内部記憶装置１０９に各種データベースを備えているが、これらのデータベースは必ずしも受付サーバ１００の内部にある必要はなく、受付サーバ１００に接続したデータベースサーバを用意して、このデータベースサーバの内部に備える構成であってもよい。
【００２８】
外部記憶装置１０８は、本発明のコンピュータプログラム及びデータを記録したＣＤ−ＲＯＭ等の記録媒体１１０からコンピュータプログラム及びデータを読取るＣＤ−ＲＯＭドライブ等からなり、読取られたコンピュータプログラム及びデータは、内部記憶装置１０９に記憶される。
【００２９】
内部記憶装置１０９に記憶されているコンピュータプログラム及びデータは、ＲＡＭ１０４に読込まれ、ＣＰＵ１０１が実行すること本実施の形態に係る受付サーバ１００として動作する。
【００３０】
図３は、端末装置２００の内部構成を示すブロック図である。端末装置２００は、電話機の機能を備えるコンピュータであり、ＣＰＵ２０１を備えており、バス２０２を介して、ＲＯＭ２０３、ＲＡＭ２０４、表示部２０５、入力部２０６、通信部２０７、外部記憶装置２０８、及び内部記憶装置２０９等の各種ハードウェアに接続されている。ＲＯＭ２０３に格納された制御プログラムを実行することで各ハードウェアを制御する。
【００３１】
通信部２０７は、受付サーバ１００及び自動分配機３００へ接続されている。通信部２０７は、受付サーバ１００へ接続し、各担当店の業務余力に関する情報等の送信要求をすると共に、受付サーバ１００から送信された各種の情報を受信する。また、通信部２０７は、自動分配機３００を介して顧客の電話機５００へ接続され、端末装置２００と電話機５００との間で音声情報の送受信を行う。通信部２０７ではこれらの各種情報の送受信を制御している。
【００３２】
外部記憶装置２０８は、ＣＤ−ＲＯＭドライブのような記憶装置からなり、内部記憶装置２０９は、ハードディスクのような記憶装置からなる。内部記憶装置２０９には、例えば、受付サーバ１００から送信される各種の情報を表示するためのアプリケーション・ソフトウェア、受付けた業務依頼の情報の入力するためのアプリケーション・ソフトウェア等が予めインストールされている。
【００３３】
音声応答部２１０には、顧客の電話機５００から送信された音声情報を外部に出力するためのスピーカのような拡声手段（不図示）、オペレータの音声を入力して音声情報に変換するマイクロホンのような受音手段（不図示）を備えている。
【００３４】
図４は、指示サーバ４００の内部構成を示すブロック図である。指示サーバ４００は、例えばパーソナルコンピュータであり、ＣＰＵ４０１を備え、バス４０２を介して、ＲＯＭ４０３、ＲＡＭ４０４、表示部４０５、入力部４０６、通信部４０７、外部記憶装置４０８、及び内部記憶装置４０９等の各種ハードウェアに接続されており、ＲＯＭ４０３に格納された制御プログラムを実行することで各ハードウェアを制御する。
【００３５】
通信部４０７は、専用回線ＰＬを介して受付サーバ１００へ接続されている。通信部４０７は、受付サーバ１００へ接続し、各担当店の業務余力に関する情報を必要に応じて送信する。
【００３６】
外部記憶装置４０８は、ＣＤ−ＲＯＭドライブのような記憶装置からなり、内部記憶装置４０９は、ハードディスクのような記憶装置からなる。内部記憶装置４０９の記憶領域の一部は、担当店に関する情報を記憶する担当店情報データベース４０９ａ（担当店情報ＤＢ）、各担当店の余力に関する情報が記憶されている余力テンプレートマスタ４０９ｂとして利用されており、必要に応じて情報の記憶及び読取り処理が行われる。
【００３７】
図５は、各業務の余力管理について説明する模式図である。受付サーバ１００では、開栓、閉栓、及び修繕の各業務に対する業務余力の管理（余力管理）を行っている。本実施の形態では、各業務を区別して管理せずに、トータルで余力管理をする形態（図５（ａ））、修繕のみを個別に余力管理する形態（図５（ｂ））、各業務を個別に余力管理する形態（図５（ｃ））の３つの形態に分類している。
【００３８】
トータル余力管理では、更に２種類のパターン（余力チェックパターン）に分類している。パターン１０では、各担当者が開栓、閉栓及び修繕の業務を行うことができる。したがって、実際には業務での区切りは必要ないが、便宜的に業務別に顧客からの依頼を割振る。パターン１１では、開栓及び閉栓の担当者は、どちらの業務も行うことが可能であるが、修繕の業務は行うことができない。また、修繕の担当者は、修繕の業務のみならず、開栓及び閉栓の業務も行うことが可能である。したがって、開栓及び閉栓の業務依頼が余力を超えた場合であっても、修繕の担当者を賄うことにより業務を遂行することができる。
【００３９】
修繕のみを個別に管理する形態、すなわちパターン２０では、開栓及び閉栓の担当者はどちらの業務も行うことが可能であるが、修繕の業務を行うことはできない。また、修繕の担当者は修繕の業務のみ行うことができ、開栓及び閉栓の業務は行うことができない。
【００４０】
各業務を個別に余力管理する形態、すなわちパターン３０では、各業務の担当者は自分の担当業務のみを行うことが可能であり、その他の業務を行うことができない。したがって、各業務にて余力が超過する場合には、他の業務から担当者を賄うことができないため、それ以上業務依頼を受付ることができない。
【００４１】
図６は、受付サーバ１００が有するマスタディスク及びデータベースの一例を示す概念図である。図６（ａ）は、担当店マスタ１０９ａの一例を示す概念図であり、担当店ＩＤ、担当店名、担当区分、責任者、及び電話番号が互いに関連付けられて記憶されている。図６（ｂ）は、余力チェックパターンデータベース１０９ｂの一例を示す概念図であり、担当店ＩＤ及び余力管理のチェックパターンが互いに関連付けられて記憶されている。
【００４２】
図６（ｃ）は、受付管理データベース１０９ｃの一例を示す概念図であり、各担当店の担当店ＩＤに対応させ、時間帯毎に各業務を受付けることができる最大件数が規定されている。時間帯は、９時から１２時（ＡＭ）、１３時から１５時（ＰＭ１）、１５時から１７時（ＰＭ２）、そして１７時以降（ＥＶＥ）に分類されている。
【００４３】
例えば、担当店ＩＤ＝「Ｓ００１」の担当店は、図６（ｂ）に示した如く、余力チェックパターンが「１１」であり、図６（ｃ）に示した如く、時間帯が「ＡＭ」における受付最大件数は、開栓が１０件、閉栓２０件、修繕が３０件である。図６（ｂ）に示した担当店（担当店ＩＤ＝「Ｓ００１」）はチェックパターンを「１１」に設定しているため、開栓の業務について受付けた件数が１０件を超える場合であっても、閉栓又は修繕の業務の受付件数に余力がある場合、開栓業務の受付けを行うことが可能である。
【００４４】
図６（ｄ）は、既存受付データベース１０９ｄの一例を示す概念図であり、各担当店の担当店ＩＤに対応させ、実際に顧客から受付けた業務依頼の件数を記憶している。例えば、図６（ｄ）に示した例では、２００１年３月２９日に前記担当店では、時間帯「ＡＭ」に７件、時間帯「ＰＭ１」に６件、時間帯「ＰＭ２」に１件、時間帯「ＥＶＥ」に０件の開栓業務依頼を受付けている。なお、時間帯「ＰＭ」の受付件数は、時間帯「ＰＭ１」又は時間帯「ＰＭ２」の何れかに実行すべき業務依頼の件数を示している。
【００４５】
図７は、端末装置２００の表示部２０５に表示される画面の一例を示す模式図である。受付けた業務依頼の内容、すなわち、開栓、閉栓又は修繕の区別、担当店ＩＤ、担当店名、実施希望日（訪問年月日）、実施希望時間帯（訪問時間帯）、顧客の氏名等の情報が業務依頼記入欄１１に記入される。
【００４６】
また、業務依頼記入欄１１の下部に配置される余力チェックボタン１２、又は受付ボタン１３が押下操作された場合、第１候補の担当店の担当店ＩＤ及び担当店名が夫々の表示欄１５ａ，１５ｂに表示されると共に、当該担当店の余力が余力テーブル１６に表示される。
【００４７】
余力テーブル１６には、業務依頼記入欄１１に入力された訪問年月日付近の業務余力が各時間帯毎にシンボリックに示されている。すなわち、業務依頼記入欄１１で入力された業務について、依然として受付可能である場合には「○」で示され、受付件数が余力を超過しており、すでに受付ることができない場合には「×」で示されている。なお、「○」、「×」が表示される升目の背景色を受付件数に応じて変更することも可能である。例えば、受付件数が残り１件になったときに、例えば、背景色を白色から黄色に変更することによって、受付を行う端末装置２００のオペレータに注意を喚起することが可能となる。
【００４８】
また、第２候補の担当店の担当店ＩＤ、担当店名が夫々の表示欄１７ａ，１７ｂに示され、当該担当店の余力が余力テーブル１８に表示される。
ここで、第１候補の担当店には、業務依頼記入欄１１で入力された担当店が選択され、第２候補の担当店には、第１候補の担当店に地理的に最も近い担当店が選択される。なお、図７に示した例では、第２候補までを表示させているが、第３候補以降の担当店を表示させてもよいことは勿論のことである。
【００４９】
図８は、本実施の形態に係る受付システムの処理手順を示したフローチャートである。端末装置２００では、図７に示した如き画面を表示させることによって受付を開始する（ステップＳ１）。そして、余力チェックボタン１２が押下操作されたか否かを判断し（ステップＳ２）、余力チェックボタン１２が押下操作されていない場合（Ｓ２：ＮＯ）、受付ボタン１３が押下操作されたか否かを判断する（ステップＳ３）。受付ボタン１３が押下操作されていない場合（Ｓ３：ＮＯ）、処理をステップＳ２へ戻す。
【００５０】
余力チェックボタン１２又は受付ボタン１３が押下操作された場合（Ｓ２，Ｓ３：ＹＥＳ）、業務依頼入力欄１１に受付けた情報の入力があるか否かを判断する（ステップＳ４）。受付けた情報の入力がない場合（Ｓ４：ＮＯ）、処理をステップＳ２へ戻す。
【００５１】
業務依頼入力欄１１に受付けた情報の入力がある場合（Ｓ４：ＹＥＳ）、受付けた情報を受付サーバ１００へ送信する（ステップＳ５）。
【００５２】
端末装置２００から送信された情報を受付サーバ１００にて受信した場合（ステップＳ６）、担当店マスタ１０９ａから担当店に関する情報を取得する（ステップＳ７）。そして、余力チェックパターンデータベース１０９ｂから担当店の余力チェックパターンを取得する（ステップＳ８）。次いで、受付管理データベース１０９ｃからその担当店の受付可能数を取得する（ステップＳ９）。次いで、既存受付データベース１０９ｄから既存受付数を取得する（ステップＳ１０）。
【００５３】
次いで、ステップＳ８からステップＳ１０で取得した余力チェックパターン、受付可能数、及び既存受付数に基づいて後述するパターン別余力算出処理を行う（ステップＳ１１）。そして、顧客の希望日の前後数日の各時間帯に業務を行うことが可能であるかを判定して、受付を行うか否かの判定をする（ステップＳ１２）。判定された結果は、端末装置２００へ送信される（ステップＳ１３）。
【００５４】
端末装置２００にて、判定された結果を受信した場合（ステップＳ１４）、その情報を余力テーブル１６，１８に表示する（ステップＳ１５）。
【００５５】
図９及び図１０は、パターン別余力算出処理の手順を示したフローチャートである。まず、余力チェックパターンデータベース１０９ｂから取得された余力チェックパターンがパターン１０であるか否かを判断する（ステップＳ２１）。余力チェックパターンがパターン１０である場合（Ｓ２１：ＹＥＳ）、パターン１０の余力管理形態に従い余力を算出する（ステップＳ２２）。
【００５６】
余力チェックパターンがパターン１０でない場合（Ｓ２１：ＮＯ）、余力チェックパターンデータベース１０９ｂから取得された余力チェックパターンがパターン１１であるか否かを判断する（ステップＳ２３）。余力チェックパターンがパターン１１である場合（Ｓ２３：ＹＥＳ）、パターン１１の余力管理形態に従い余力を算出する（ステップＳ２４）。
【００５７】
余力チェックパターンがパターン１１でない場合（Ｓ２３：ＮＯ）、余力チェックパターンデータベース１０９ｂから取得された余力チェックパターンがパターン２０であるか否かを判断する（ステップＳ２５）。余力チェックパターンがパターン２０である場合（Ｓ２５：ＹＥＳ）、パターン２０の余力管理形態に従い余力を算出する（ステップＳ２６）。
【００５８】
余力チェックパターンがパターン２０でない場合（Ｓ２５：ＮＯ）、余力チェックパターンデータベース１０９ｂから取得された余力チェックパターンがパターン３０であるか否かを判断する（ステップＳ２７）。余力チェックパターンがパターン３０である場合（Ｓ２７：ＹＥＳ）、パターン３０の余力管理形態に従い余力を算出する（ステップＳ２８）。
【００５９】
次いで、「ＡＭ」又は「ＥＶＥ」の時間帯についての余力算出か否かを判断する（ステップＳ２９）。「ＡＭ」又は「ＥＶＥ」の時間帯についての余力算出である場合（Ｓ２９：ＹＥＳ）、各パターンの余力管理形態に従って算出した値を返す。
【００６０】
次いで、「ＡＭ」及び「ＥＶＥ」の時間帯についての余力算出でない場合（Ｓ２９：ＮＯ）、「ＰＭ１」の時間帯についての余力算出であるか否かを判断する（ステップＳ３０）。
【００６１】
「ＰＭ１」の時間帯での余力算出である場合（Ｓ３０：ＹＥＳ）、ＰＭ２残余力数がＰＭ受付数以上であるか否かを判断する（ステップＳ３２）。ここで、ＰＭ２残余力数は、時間帯「ＰＭ２」において更に受付けることができる件数であり、また、ＰＭ受付数として、「ＰＭ１」、「ＰＭ２」、及び「ＰＭ」の各時間帯で既に受付けている件数を足し合わせた値である。
【００６２】
ＰＭ２残余力数がＰＭ受付数以上である場合（Ｓ３２：ＹＥＳ）、ＰＭ１残余力数として、各パターンの余力管理形態に従って算出した値を返し、ＰＭ２残余力数として、各パターンの余力管理形態に従って算出した値からＰＭ受付数を差引いた値を返す（ステップＳ３３）。
【００６３】
また、ＰＭ２残余力数がＰＭ受付数より小さい場合（Ｓ３２：ＮＯ）、ＰＭ１残余力数として、各パターンの余力管理形態に従って算出した値からＰＭ受付数とＰＭ２残余力数との差を差引いた値を返し、ＰＭ２残余力数として零値を返す（ステップＳ３４）。
【００６４】
「ＰＭ１」の時間帯での余力算出でない場合（Ｓ３０：ＮＯ）、「ＰＭ２」の時間帯での余力算出であるか否かを判断する（ステップＳ３１）。
【００６５】
「ＰＭ２」の時間帯での余力算出である場合（Ｓ３１：ＹＥＳ）、ＰＭ１残余力数がＰＭ受付数以上であるか否かを判断する（ステップＳ３５）。
【００６６】
ＰＭ１残余力数がＰＭ受付数以上である場合（Ｓ３５：ＹＥＳ）、ＰＭ１残余力数として、各パターンの余力管理形態に従って算出した値からＰＭ受付数を差引いた値を返し、ＰＭ２残余力数として、各パターンの余力管理形態に従って算出した値を返す。（ステップＳ３６）。
また、ＰＭ１残余力数がＰＭ受付数より小さい場合（Ｓ３５：ＮＯ）、ＰＭ１残余力数として零値を返し、ＰＭ２残余力数として、各パターンの余力管理形態に従って算出した値からＰＭ受付数とＰＭ１残余力数との差を差引いた値を返す（ステップＳ３７）。
【００６７】
以下、図９及び図１０のフローチャートについて具体的な適用例について説明する。各業務の受付最大可能数が表１に示した如く規定されており、時間帯「ＡＭ」又は「ＥＶＥ」に属するある時点での既存受付数が表２に示した通りであった場合を考える。
【００６８】
【表１】
【００６９】
【表２】
【００７０】
余力チェックパターンがパターン１０である場合、開栓、閉栓、修繕の各残余力数は、MaxAll-(UkeK+UkeH+UkeS)により算出され、表１及び表２に基づき算出した場合、４３（＝６０−（６＋４＋７））となる。
【００７１】
余力チェックパターンがパターン１１である場合、開栓、閉栓、修繕の各残余力数は、以下のように算出される。
まず、開栓、閉栓の残余力数は、修繕に残余力が無い場合、MaxAll-(UkeK+UkeH+BaseS)により算出され、修繕に残余力がある場合、MaxAll-(UkeK+UkeH+UkeS)により算出される。したがって、表１及び表２に示した例では、修繕に残余力があるため、開栓及び修繕の残余力数は、４３（＝６０−（６＋４＋７））となる。
【００７２】
修繕の残余力数は、開栓又は閉栓の受付け件数が最大受付件数を超過している場合、修繕の残余力から賄うため、MaxAll-(UkeK+UkeH+UkeS)となる。また、開栓及び閉栓に残余力がある場合、修繕の残余力数は、BaseS-UkeSにより算出される。すなわち、表１及び表２に示した例では、開栓及び閉栓に残余力があるため、２３（＝３０−７）により算出される。
【００７３】
また、余力チェックパターンが、パターン２０及びパターン３０である場合も、同様にして算出することができる。
【００７４】
次いで、業務に実施希望時間帯が「ＰＭ１」、「ＰＭ２」、又は「ＰＭ」である場合の各業務の残余力数の算出について説明する。各業務の受付最大可能数が表３に示した如く規定されており、時間帯「ＰＭ１」、「ＰＭ２」又は「ＰＭ」に属するある時点での既存受付数が表４に示した通りであった場合を考える。
【００７５】
【表３】
【００７６】
【表４】
【００７７】
「ＰＭ１」の残余力数は、「ＰＭ」全受付数が「ＰＭ２」の残余力を超過するまで前述と同様に算出する。すなわち、「ＰＭ２」の残余力を超過するまで、「ＰＭ２」の残余力により「ＰＭ」の受付を賄う。また、「ＰＭ２」の残余力数は、「ＰＭ」全受付数が「ＰＭ１」の残余力を超過するまで前述と同様に算出する。すなわち、「ＰＭ１」の残余力を超過するまで、「ＰＭ１」の残余力により「ＰＭ」の受付を賄う。ここで、「ＰＭ」全受付数とは、ＰＭ１」、「ＰＭ２」、「ＰＭ」の各受付数（=SumUkeAll#PM）の合計（=UkeK#PM+UkeH#PM+UkeS#PM）である。
【００７８】
余力チェックパターンがパターン１０である場合、時間帯が「ＰＭ」の開栓、閉栓、修繕の残余力数は、(Yoryoku#PM1+Yoryoku#PM2)-SumUkeAll#PMにより算出される。ここで、Yoryoku#PM1，Yoryoku#PM2は、「ＡＭ」及び「ＥＶＥ」の残余力数の算出方法と同じ手法により算出した「ＰＭ１」、「ＰＭ２」の残余力数である。
【００７９】
表３及び表４に示した例では、Yoryoku#PM1が４３（＝６０−（６＋４＋７））となり、Yoryoku#PM2が１３（＝３０−（３＋５＋８））となる。また、「ＰＭ」全受付数（SumUkeAll#PM）は、９（＝６＋２＋１）である。
したがって、「ＰＭ」の開栓、閉栓、修繕の残余力数は、４８（＝（４３＋１４）−９）となる。
【００８０】
「ＰＭ１」の開栓、閉栓、修繕の残余力数は、「ＰＭ２」の残余力により「ＰＭ」受付を賄える場合、Yoryoku#PM1であり、「ＰＭ２」の残余力を超過する場合、（Yoryoku#PM1+Yoryoku#PM2）-SumUkeAll#PMにより算出する。表３及び表４に示した例では、「ＰＭ２」の残余力で「ＰＭ」受付を賄えるため、開栓、閉栓、修繕の残余力数はそれぞれ４３となる。
【００８１】
「ＰＭ２」の開栓、閉栓、修繕の残余力数は、「ＰＭ１」の残余力により「ＰＭ」受付を賄える場合、Yoryoku#PM2であり、「ＰＭ１」の残余力を超過する場合、（Yoryoku#PM1+Yoryoku#PM2）-SumUkeAll#PMにより算出する。表３及び表４に示した例では、「ＰＭ１」の残余力で「ＰＭ」受付を賄えるため、開栓、閉栓、修繕の残余力数はそれぞれ１４となる。
【００８２】
また、余力チェックパターンが、パターン１１、パターン２０及びパターン３０である場合も、同様にして算出することができる。
【００８３】
なお、本実施の形態では、受付サーバ１００に端末装置２００を１台のみ接続する形態であったが、端末装置２００を複数台接続する形態であってもよい。このとき、顧客の電話機５００からの呼出信号を自動分配機４００が受信した場合、電話機５００と接続する端末装置２００を自動分配機４００にて選択する形態であってもよい。
【００８４】
なお、本実施の形態では、ガス会社によって運営されている受付システムの形態について説明したが、ガス会社に限定されるものではなく、業務の依頼を電話にて受付ける各種の業界に適用できることは勿論のことである。
【００８５】
【発明の効果】
以上、詳述したように、本発明にあっては、各処理毎の処理可能数を予め定めておき、既に受付けた実行要求の数と処理可能数とに基づき、実行要求を受付けた処理の実行が可能であるか否かを判定し、前記処理の実行が不可能であると判定した場合、他の処理により実行可能であるか否かを判定するようにしている。したがって、例えば、複数の処理を行う各担当店が処理可能件数を予め定めておくことによって、各担当店、各処理毎に処理を実行する担当者の余力を効率的に管理することができ、処理の実行要求を受付けた者が担当店に逐次連絡をして確認することなく、処理の実行が可能であるか否かについての情報を得ることができるため、速やかな顧客の応対が可能となる。
【００８６】
また、本発明にあっては、各業務毎の受付可能件数と、一の業務が他の業務により実行可能であるか否かとを規定した受付形態が、業務請負単位毎に予め選択されており、選択された受付形態と既に受付けた各業務毎の実行依頼の件数とに基づき、各業務毎に実行依頼が受付可能であるか判定し、判定した結果を提供するようにしている。したがって、例えば、業務の実行を請負う各担当店は、その業務形態に応じて柔軟に受付形態を選択することができ、選択された受付形態に応じ、複数の業務間にて相互補完できる業務についての情報を提供することが可能となる。
【００８７】
更に、本発明にあっては、各業務毎の受付可能数を予め定められた時間帯毎に規定して、業務依頼を受付けた業務が可能であるか否かを各時間帯毎に判定するようにしている。したがって、時間帯毎に業務の受付余力を管理することが可能となる。
【００８８】
更に、本発明にあっては、各業務毎の受付可能件数を予め定めておき、既に受付けた業務依頼の件数と受付可能件数とに基づき、業務依頼を受付けた業務の実行が可能であるか否かを判定し、前記業務の実行が不可能であると判定した場合、他の業務により実行可能であるか否かを判定するようにしている。したがって、例えば、各担当店、各業務毎に業務依頼の受付可能件数を予め定めておくことによって、各担当店、各業務毎に業務担当者の余力を効率的に管理することができ、業務依頼を受付けた者が担当店に逐次連絡をして確認することなく、業務の実行が可能であるか否かについての情報を得ることができるため、速やかな顧客の応対が可能となる等、本発明は優れた効果を奏する。
【図面の簡単な説明】
【図１】本実施の形態に係る受付システムの構成を示す模式図である。
【図２】受付サーバの内部構成を示すブロック図である。
【図３】端末装置の内部構成を示すブロック図である。
【図４】指示サーバの内部構成を示すブロック図である。
【図５】各業務の余力管理について説明する模式図である。
【図６】受付サーバが有するマスタディスク及びデータベースの一例を示す概念図である。
【図７】端末装置の表示部に表示される画面の一例を示す模式図である。
【図８】本実施の形態に係る受付システムの処理手順を示したフローチャートである。
【図９】パターン別余力算出処理の手順を示したフローチャートである。
【図１０】パターン別余力算出処理の手順を示したフローチャートである。
【符号の説明】
１００ 受付サーバ
１０９ａ 担当店マスタ
１０９ｂ 余力チェックパターンデータベース
１０９ｃ 受付管理データベース
１０９ｄ 既存受付データベース
２００ 端末装置
３００ 自動分配機
４００ 指示サーバ
５００ 電話機
ＴＮ 公衆電話回線網
ＰＬ 専用回線
【発明の属する技術分野】
本発明は、業務依頼の受付を行う受付方法、受付システム、及び該受付システムを実現するためのコンピュータプログラム、並びに業務依頼の受付に係る情報を提供する情報提供方法及び受付サーバに関する。
【０００２】
【従来の技術】
従来、顧客からの業務依頼を受付けるコールセンタでは、依頼された業務の実施希望日時をオペレータが顧客に伺った後、業務の遂行を請負う担当店と電話連絡をとり、顧客の実施希望日時に業務を実施することが可能か否かを問い合わせていた。
【０００３】
【発明が解決しようとする課題】
しかしながら、前述の方法では、顧客から業務依頼を受けた際にオペレータが顧客の居所に最も近い担当店を探し出して、電話連絡により顧客の希望日時に業務を遂行することができる者がいるか否かを担当店に確認しなければならず、オペレータは煩わしさを感じることがあり、また、顧客に対し速やかに対応出来ない場合があった。
【０００４】
そこで、各担当店、各業務毎に業務担当者の余力を効率的に管理でき、オペレータが担当店に逐次連絡をして確認することなく、速やかに顧客の応対ができる受付システムの開発が望まれていた。
【０００５】
また、複数の業務がある場合、一の業務担当者が他の業務の担当を兼任することがあり、業務単位で担当者の余力を管理することができるだけでなく、各担当店の業務形態に応じ、相互補完できる業務についての情報が得られる受付システムの開発が望まれていた。
【０００６】
本発明は斯かる事情に鑑みてなされたものであり、複数の処理について各処理毎に実行要求を受付ける際、各処理毎の処理可能数を予め定めておき、既に受付けた実行要求の数と前記処理可能数とに基づき、実行要求を受付けた処理の実行が可能であるか否かを判定し、前記処理の実行が不可能であると判定した場合、他の処理により実行可能であるか否かを判定することにより、実行要求を受付けることが可能であるか否かを速やかに判定することができる受付方法、受付システム、及びコンピュータプログラムを提供することを目的とする。
【０００７】
本発明の他の目的は、複数の受付形態に分類し、業務請負単位毎に予め選択された受付形態と既に受付けた各業務毎の実行依頼の件数とに基づき、各業務毎に実行依頼が受付可能であるか否かを判定し、判定した結果に関する情報を提供することにより、実行要求を受付けることが可能であるか否かについての情報を速やかに提供することができる情報提供方法及び受付サーバに関する。
【０００８】
本発明の更に他の目的は、各業務毎の受付可能数を予め定められた時間帯毎に規定して、実行依頼を受付けた業務が可能であるか否かを各時間帯毎に判定し、判定した結果についての情報を提供することにより、時間帯毎に実行依頼を受付けることが可能であるか否かについての情報を提供することができる情報提供方法を提供することにある。
【０００９】
【課題を解決するための手段】
第１発明に係る受付方法は、複数の業務について各業務毎の実行依頼を受付ける際、情報処理装置内のデータベースに記憶された情報に基づいて前記実行依頼の受付けが可能であるか否かを前記情報処理装置にて判定する受付方法において、業務を請負う各担当店が受付けることができる各業務毎の受付可能件数と一の業務の担当者が他の業務を実行可能であるか否かを定めた業務余力に関する管理パターンとをそれぞれ各担当店を識別するためのＩＤに関連付けて前記情報処理装置内のデータベースに予め記憶させておき、前記情報処理装置は、各担当店が既に受付けた各業務毎の件数を各担当店のＩＤに関連付けてデータベースに記憶させ、業務の実行依頼を受付けた場合、前記業務を請負う担当店のＩＤを取得し、取得した担当店のＩＤと関連付けて記憶してある各業務毎の受付可能件数、業務余力の管理パターン及び既存受付数をデータベースから読出し、読出した担当店における業務余力の管理パターンに従い、読出した受付可能件数及び既存受付数を用いて前記担当店の各業務毎の余力を算出し、算出した余力に基づいて前記業務依頼の受付けが可能であるか否かを判定することを特徴とする。
【００１０】
第２発明に係る情報提供方法は、複数の業務について各業務毎の実行依頼を受付ける際、情報処理装置内のデータベースに記憶された情報に基づいて前記実行依頼が受付け可能であるか否かを前記情報処理装置が判定し、判定結果に係る情報を出力する情報提供方法において、業務を請負う各担当店が受付けることができる各業務毎の受付可能件数と一の業務の担当者が他の業務を実行可能であるか否かを定めた業務余力に関する管理パターンとをそれぞれ各担当店を識別するためのＩＤに関連付けて前記情報処理装置内のデータベースに予め記憶させておき、前記情報処理装置は、各担当店が既に受付けた各業務毎の件数を各担当店のＩＤに関連付けてデータベースに記憶させ、業務の実行依頼を受付けた場合、前記業務を請負う担当店のＩＤを取得し、取得した担当店のＩＤと関連付けて記憶してある各業務毎の受付可能件数、業務余力の管理パターン及び既存受付数をデータベースから読出し、読出した担当店における業務余力の管理パターンに従い、読出した受付可能件数及び既存受付数を用いて前記担当店の各業務毎の余力を算出し、算出した余力に基づいて前記業務依頼の受付けが可能であるか否かを判定し、判定結果を出力することを特徴とする。
【００１１】
第３発明に係る情報提供方法は、第２発明に係る情報提供方法において、各担当店における各業務毎の受付可能件数は予め定められた時間帯毎に規定されており、実行依頼を受付けた業務が受付可能であるか否かを各時間帯毎に判定し、判定結果を出力することを特徴とする。
【００１２】
第４発明に係る受付システムは、複数の業務について各業務毎に実行依頼を受付け、受付けた実行依頼に関する情報を送信する端末装置と、該端末装置から送信される情報を受信した場合、前記実行依頼を受付けるか否かを判定し、判定結果を前記端末装置へ送信する受付サーバとを備える受付システムにおいて、前記端末装置は、業務を請負う担当店を識別するためのＩＤの入力を受付ける手段を備え、受付けた担当店のＩＤを前記実行依頼に関する情報と共に送信するようにしてあり、前記受付サーバは、各担当店が受付けることができる各業務毎の受付可能件数を各担当店のＩＤに関連付けて予め記憶するデータベースと、一の業務の担当者が他の業務を実行可能であるか否かを定めた業務余力に関する管理パターンを各担当店のＩＤに関連付けて予め記憶するデータベースと、各担当店が既に受付けた各業務毎の件数を各担当店のＩＤに関連付けて記憶するデータベースと、前記端末装置から送信される情報を受信した場合、業務を請負う担当店のＩＤを取得する手段と、取得した担当店のＩＤと関連付けて記憶してある各業務毎の受付可能件数、業務余力の管理パターン及び既存受付数を各データベースから読出す手段と、読出した担当店における業務余力の管理パターンに従い、読出した受付可能件数及び既存受付数を用いて前記担当店の各業務毎の余力を算出する手段と、算出した余力に基づいて前記業務依頼を受付けるか否かを判定する手段と、該手段による判定結果を前記端末装置へ送信する手段とを備え、前記端末装置は、前記受付サーバから送信される判定結果を受信し、受信した判定結果を表示するようにしてあることを特徴とする。
【００１３】
第５発明に係る受付サーバは、複数の業務について各業務毎に実行依頼を受付ける際、該実行依頼の受付けが可能であるか否かを判定し、判定結果に係る情報を出力する受付サーバにおいて、業務を請負う各担当店が受付けることができる各業務毎の受付可能件数を各担当店を識別するためのＩＤに関連付けて予め記憶するデータベースと、一の業務の担当者が他の業務を実行可能であるか否かを定めた業務余力に関する管理パターンを各担当店のＩＤに関連付けて予め記憶するデータベースと、各担当店が既に受付けた各業務毎の件数を各担当店のＩＤに関連付けて記憶するデータベースと、業務の実行依頼を受付けた場合、前記業務を請負う担当店のＩＤを取得する手段と、取得した担当店のＩＤと関連付けて記憶してある各業務毎の受付可能件数、業務余力の管理パターン及び既存受付数を各データベースから読出す手段と、読出した担当店における業務余力の管理パターンに従い、読出した受付可能件数及び既存受付数を用いて前記担当店の各業務毎の余力を算出する手段と、算出した余力に基づいて前記業務依頼を受付けるか否かを判定する手段とを備え、該手段による判定結果に係る情報を出力するようにしてあることを特徴とする。
【００１４】
第６発明に係るコンピュータプログラムは、複数の業務について各業務毎の実行依頼を受付ける際、コンピュータ内のデータベースに記憶された情報に基づいて前記実行依頼の受付けが可能であるか否かを判定させるコンピュータプログラムにおいて、業務を請負う各担当店が受付けることができる各業務毎の受付可能件数と一の業務の担当者が他の業務を実行可能であるか否かを定めた業務余力に関する管理パターンとをそれぞれ各担当店を識別するためのＩＤに関連付けて前記データベースに予め記憶させておき、コンピュータに、各担当店が既に受付けた各業務毎の件数を各担当店のＩＤに関連付けてデータベースに記憶させるステップと、コンピュータに、業務の実行依頼を受付けた場合、前記業務を請負う担当店のＩＤを取得させるステップと、コンピュータに、取得させた担当店のＩＤと関連付けて記憶してある各業務毎の受付可能件数、業務余力の管理パターン及び既存受付数をデータベースから読出させるステップと、コンピュータに、読出させた担当店における業務余力の管理パターンに従い、読出させた受付可能件数及び既存受付数を用いて前記担当店の各業務毎の余力を算出させるステップと、コンピュータに、算出させた余力に基づいて前記業務依頼の受付けが可能であるか否かを判定させるステップとを有することを特徴とする。
【００１５】
本発明にあっては、各処理毎の処理可能数を予め定めておき、既に受付けた実行要求の数と処理可能数とに基づき、実行要求を受付けた処理の実行が可能であるか否かを判定し、前記処理の実行が不可能であると判定した場合、他の処理により実行可能であるか否かを判定するようにしている。したがって、例えば、複数の処理を行う各担当店が処理可能件数を予め定めておくことによって、各担当店、各処理毎に処理を実行する担当者の余力を効率的に管理することができ、処理の実行要求を受付けた者が担当店に逐次連絡をして確認することなく、処理の実行が可能であるか否かについての情報を得ることができるため、速やかな顧客の応対が可能となる。
【００１６】
また、本発明にあっては、各業務毎の受付可能件数と、一の業務が他の業務により実行可能であるか否かとを規定した受付形態が、業務請負単位毎に予め選択されており、選択された受付形態と既に受付けた各業務毎の実行依頼の件数とに基づき、各業務毎に実行依頼が受付可能であるか判定し、判定した結果を提供するようにしている。したがって、例えば、業務の実行を請負う各担当店は、その業務形態に応じて柔軟に受付形態を選択することができ、選択された受付形態に応じ、複数の業務間にて相互補完できる業務についての情報を提供することが可能となる。
【００１７】
更に、本発明にあっては、各業務毎の受付可能数を予め定められた時間帯毎に規定して、業務依頼を受付けた業務が可能であるか否かを各時間帯毎に判定するようにしている。したがって、時間帯毎に業務の受付余力を管理することが可能となる。
【００１８】
更に、本発明にあっては、各業務毎の受付可能件数を予め定めておき、既に受付けた業務依頼の件数と受付可能件数とに基づき、業務依頼を受付けた業務の実行が可能であるか否かを判定し、前記業務の実行が不可能であると判定した場合、他の業務により実行可能であるか否かを判定するようにしている。したがって、例えば、各担当店、各業務毎に業務依頼の受付可能件数を予め定めておくことによって、各担当店、各業務毎に業務担当者の余力を効率的に管理することができ、業務依頼を受付けた者が担当店に逐次連絡をして確認することなく、業務の実行が可能であるか否かについての情報を得ることができるため、速やかな顧客の応対が可能となる。
【００１９】
【発明の実施の形態】
以下、本発明をその実施の形態を示す図面に基づいて具体的に説明する。
図１は本実施の形態に係る受付システムの構成を示す模式図である。図中２００は、コールセンタ内にてオペレータが操作をする端末装置であり、該端末装置２００には、後述する受付サーバ１００及び自動分配機３００が接続されている。コールセンタ内に設置された自動分配機３００には、公衆電話回線網ＴＮを介して顧客が利用する電話機５００に接続される。
【００２０】
コールセンタは、例えば、ガス会社によって運営されており、顧客からガス栓の開栓、閉栓、修繕等の業務依頼を電話にて受付けている。顧客は、電話機５００を利用してガス栓の開栓、閉栓又は修繕の業務依頼をコールセンタ内のオペレータに音声により伝える。オペレータは業務依頼を受付ける際に、依頼内容、顧客の氏名、住所、業務の実施希望日時等を顧客に尋ねる。そして、オペレータは顧客の応答に基づき、端末装置２００に依頼内容、顧客の氏名、住所、業務の実施希望日時等の情報を入力する。
【００２１】
端末装置２００に入力された依頼内容、顧客の氏名、住所、業務の実施希望日時等の情報は受付サーバ１００へ送信される。受付サーバ１００では、ガス栓の開栓、閉栓、修繕等の業務を取扱っている担当店の情報をデータベースに記憶しており、各担当店にて業務の受付件数に余力があるか否かを判定することによって、受付けた業務を顧客の実施希望日時に業務依頼が実施可能であるか否かを判定する。なお、各業務の受付件数の余力を業務余力と呼ぶ。
【００２２】
また、受付サーバ１００には、専用回線ＰＬを介して指示サーバ４００に接続されている。指示サーバ４００は、指示サーバ４００が属する地区の担当店の情報をデータベース化しており、各担当店における業務余力の年次計画、会議又は休日による業務余力の変更等の情報を各担当店から随時受付けている。各担当店から受付けた業務余力に関する情報は、専用回線ＰＬを通じて受付サーバ１００へ送信され、受付サーバ１００が備えるデータベースが更新される。
【００２３】
図２は、受付サーバ１００の内部構成を示すブロック図である。図中１０１はＣＰＵであり、バス１０２を介して後述する各ハードウェア各部に接続されていて、ＲＯＭ１０３に格納された制御プログラムに従って、それらを制御する。ＲＡＭ１０４は、ＳＲＡＭ又はフラッシュメモリ等で構成され、ＲＯＭ１０３に格納された制御プログラムの実行時に発生するデータを記憶する。
【００２４】
表示部１０５は、ＣＲＴ、液晶ディスプレイ等の表示装置であり、入力部１０６は、キーボード、マウス等の入力装置である。表示部１０５及び入力部１０６は、例えば、担当店に関する情報を表示・入力する際に利用される。端末装置２００を通じて、各種の情報を表示・入力する形態である場合には、表示部１０５及び入力部１０６を受付サーバ１００に備えている必要はない。
【００２５】
通信部１０７は、モデム等の回線終端装置を備えている。通信部１０７は、端末装置２００からの要求に応じて担当店の業務余力に関する情報を端末装置２００へ送信し、端末装置２００から送信された業務依頼に関する情報を受信する。また、指示サーバ４００から送信された各担当店の業務余力に関する情報、休日・会議に関する情報等を受信する。通信部１０７はこれらの情報の送受信の制御を行う。
【００２６】
内部記憶装置１０９は、ハードディスクのような記憶装置からなり、記憶領域の一部は、各担当店に関する情報を記憶する担当店マスタ１０９ａ、各担当店の業務余力の形態を分類した余力チェックパターンデータベース（余力チェックパターンＤＢ）１０９ｂ、各担当店にて受付けることが可能な最大件数が時間帯毎、業務毎に記憶してある受付管理データベース（受付管理ＤＢ）１０９ｃ、各担当店にて受付けた件数を記憶した既存受付データベース（既存受付ＤＢ）１０９ｄとして用いられており、必要に応じて各種データベースにアクセスし、情報の記憶及び読取り処理が行われる。
【００２７】
なお、本実施の形態では、受付サーバ１００の内部記憶装置１０９に各種データベースを備えているが、これらのデータベースは必ずしも受付サーバ１００の内部にある必要はなく、受付サーバ１００に接続したデータベースサーバを用意して、このデータベースサーバの内部に備える構成であってもよい。
【００２８】
外部記憶装置１０８は、本発明のコンピュータプログラム及びデータを記録したＣＤ−ＲＯＭ等の記録媒体１１０からコンピュータプログラム及びデータを読取るＣＤ−ＲＯＭドライブ等からなり、読取られたコンピュータプログラム及びデータは、内部記憶装置１０９に記憶される。
【００２９】
内部記憶装置１０９に記憶されているコンピュータプログラム及びデータは、ＲＡＭ１０４に読込まれ、ＣＰＵ１０１が実行すること本実施の形態に係る受付サーバ１００として動作する。
【００３０】
図３は、端末装置２００の内部構成を示すブロック図である。端末装置２００は、電話機の機能を備えるコンピュータであり、ＣＰＵ２０１を備えており、バス２０２を介して、ＲＯＭ２０３、ＲＡＭ２０４、表示部２０５、入力部２０６、通信部２０７、外部記憶装置２０８、及び内部記憶装置２０９等の各種ハードウェアに接続されている。ＲＯＭ２０３に格納された制御プログラムを実行することで各ハードウェアを制御する。
【００３１】
通信部２０７は、受付サーバ１００及び自動分配機３００へ接続されている。通信部２０７は、受付サーバ１００へ接続し、各担当店の業務余力に関する情報等の送信要求をすると共に、受付サーバ１００から送信された各種の情報を受信する。また、通信部２０７は、自動分配機３００を介して顧客の電話機５００へ接続され、端末装置２００と電話機５００との間で音声情報の送受信を行う。通信部２０７ではこれらの各種情報の送受信を制御している。
【００３２】
外部記憶装置２０８は、ＣＤ−ＲＯＭドライブのような記憶装置からなり、内部記憶装置２０９は、ハードディスクのような記憶装置からなる。内部記憶装置２０９には、例えば、受付サーバ１００から送信される各種の情報を表示するためのアプリケーション・ソフトウェア、受付けた業務依頼の情報の入力するためのアプリケーション・ソフトウェア等が予めインストールされている。
【００３３】
音声応答部２１０には、顧客の電話機５００から送信された音声情報を外部に出力するためのスピーカのような拡声手段（不図示）、オペレータの音声を入力して音声情報に変換するマイクロホンのような受音手段（不図示）を備えている。
【００３４】
図４は、指示サーバ４００の内部構成を示すブロック図である。指示サーバ４００は、例えばパーソナルコンピュータであり、ＣＰＵ４０１を備え、バス４０２を介して、ＲＯＭ４０３、ＲＡＭ４０４、表示部４０５、入力部４０６、通信部４０７、外部記憶装置４０８、及び内部記憶装置４０９等の各種ハードウェアに接続されており、ＲＯＭ４０３に格納された制御プログラムを実行することで各ハードウェアを制御する。
【００３５】
通信部４０７は、専用回線ＰＬを介して受付サーバ１００へ接続されている。通信部４０７は、受付サーバ１００へ接続し、各担当店の業務余力に関する情報を必要に応じて送信する。
【００３６】
外部記憶装置４０８は、ＣＤ−ＲＯＭドライブのような記憶装置からなり、内部記憶装置４０９は、ハードディスクのような記憶装置からなる。内部記憶装置４０９の記憶領域の一部は、担当店に関する情報を記憶する担当店情報データベース４０９ａ（担当店情報ＤＢ）、各担当店の余力に関する情報が記憶されている余力テンプレートマスタ４０９ｂとして利用されており、必要に応じて情報の記憶及び読取り処理が行われる。
【００３７】
図５は、各業務の余力管理について説明する模式図である。受付サーバ１００では、開栓、閉栓、及び修繕の各業務に対する業務余力の管理（余力管理）を行っている。本実施の形態では、各業務を区別して管理せずに、トータルで余力管理をする形態（図５（ａ））、修繕のみを個別に余力管理する形態（図５（ｂ））、各業務を個別に余力管理する形態（図５（ｃ））の３つの形態に分類している。
【００３８】
トータル余力管理では、更に２種類のパターン（余力チェックパターン）に分類している。パターン１０では、各担当者が開栓、閉栓及び修繕の業務を行うことができる。したがって、実際には業務での区切りは必要ないが、便宜的に業務別に顧客からの依頼を割振る。パターン１１では、開栓及び閉栓の担当者は、どちらの業務も行うことが可能であるが、修繕の業務は行うことができない。また、修繕の担当者は、修繕の業務のみならず、開栓及び閉栓の業務も行うことが可能である。したがって、開栓及び閉栓の業務依頼が余力を超えた場合であっても、修繕の担当者を賄うことにより業務を遂行することができる。
【００３９】
修繕のみを個別に管理する形態、すなわちパターン２０では、開栓及び閉栓の担当者はどちらの業務も行うことが可能であるが、修繕の業務を行うことはできない。また、修繕の担当者は修繕の業務のみ行うことができ、開栓及び閉栓の業務は行うことができない。
【００４０】
各業務を個別に余力管理する形態、すなわちパターン３０では、各業務の担当者は自分の担当業務のみを行うことが可能であり、その他の業務を行うことができない。したがって、各業務にて余力が超過する場合には、他の業務から担当者を賄うことができないため、それ以上業務依頼を受付ることができない。
【００４１】
図６は、受付サーバ１００が有するマスタディスク及びデータベースの一例を示す概念図である。図６（ａ）は、担当店マスタ１０９ａの一例を示す概念図であり、担当店ＩＤ、担当店名、担当区分、責任者、及び電話番号が互いに関連付けられて記憶されている。図６（ｂ）は、余力チェックパターンデータベース１０９ｂの一例を示す概念図であり、担当店ＩＤ及び余力管理のチェックパターンが互いに関連付けられて記憶されている。
【００４２】
図６（ｃ）は、受付管理データベース１０９ｃの一例を示す概念図であり、各担当店の担当店ＩＤに対応させ、時間帯毎に各業務を受付けることができる最大件数が規定されている。時間帯は、９時から１２時（ＡＭ）、１３時から１５時（ＰＭ１）、１５時から１７時（ＰＭ２）、そして１７時以降（ＥＶＥ）に分類されている。
【００４３】
例えば、担当店ＩＤ＝「Ｓ００１」の担当店は、図６（ｂ）に示した如く、余力チェックパターンが「１１」であり、図６（ｃ）に示した如く、時間帯が「ＡＭ」における受付最大件数は、開栓が１０件、閉栓２０件、修繕が３０件である。図６（ｂ）に示した担当店（担当店ＩＤ＝「Ｓ００１」）はチェックパターンを「１１」に設定しているため、開栓の業務について受付けた件数が１０件を超える場合であっても、閉栓又は修繕の業務の受付件数に余力がある場合、開栓業務の受付けを行うことが可能である。
【００４４】
図６（ｄ）は、既存受付データベース１０９ｄの一例を示す概念図であり、各担当店の担当店ＩＤに対応させ、実際に顧客から受付けた業務依頼の件数を記憶している。例えば、図６（ｄ）に示した例では、２００１年３月２９日に前記担当店では、時間帯「ＡＭ」に７件、時間帯「ＰＭ１」に６件、時間帯「ＰＭ２」に１件、時間帯「ＥＶＥ」に０件の開栓業務依頼を受付けている。なお、時間帯「ＰＭ」の受付件数は、時間帯「ＰＭ１」又は時間帯「ＰＭ２」の何れかに実行すべき業務依頼の件数を示している。
【００４５】
図７は、端末装置２００の表示部２０５に表示される画面の一例を示す模式図である。受付けた業務依頼の内容、すなわち、開栓、閉栓又は修繕の区別、担当店ＩＤ、担当店名、実施希望日（訪問年月日）、実施希望時間帯（訪問時間帯）、顧客の氏名等の情報が業務依頼記入欄１１に記入される。
【００４６】
また、業務依頼記入欄１１の下部に配置される余力チェックボタン１２、又は受付ボタン１３が押下操作された場合、第１候補の担当店の担当店ＩＤ及び担当店名が夫々の表示欄１５ａ，１５ｂに表示されると共に、当該担当店の余力が余力テーブル１６に表示される。
【００４７】
余力テーブル１６には、業務依頼記入欄１１に入力された訪問年月日付近の業務余力が各時間帯毎にシンボリックに示されている。すなわち、業務依頼記入欄１１で入力された業務について、依然として受付可能である場合には「○」で示され、受付件数が余力を超過しており、すでに受付ることができない場合には「×」で示されている。なお、「○」、「×」が表示される升目の背景色を受付件数に応じて変更することも可能である。例えば、受付件数が残り１件になったときに、例えば、背景色を白色から黄色に変更することによって、受付を行う端末装置２００のオペレータに注意を喚起することが可能となる。
【００４８】
また、第２候補の担当店の担当店ＩＤ、担当店名が夫々の表示欄１７ａ，１７ｂに示され、当該担当店の余力が余力テーブル１８に表示される。
ここで、第１候補の担当店には、業務依頼記入欄１１で入力された担当店が選択され、第２候補の担当店には、第１候補の担当店に地理的に最も近い担当店が選択される。なお、図７に示した例では、第２候補までを表示させているが、第３候補以降の担当店を表示させてもよいことは勿論のことである。
【００４９】
図８は、本実施の形態に係る受付システムの処理手順を示したフローチャートである。端末装置２００では、図７に示した如き画面を表示させることによって受付を開始する（ステップＳ１）。そして、余力チェックボタン１２が押下操作されたか否かを判断し（ステップＳ２）、余力チェックボタン１２が押下操作されていない場合（Ｓ２：ＮＯ）、受付ボタン１３が押下操作されたか否かを判断する（ステップＳ３）。受付ボタン１３が押下操作されていない場合（Ｓ３：ＮＯ）、処理をステップＳ２へ戻す。
【００５０】
余力チェックボタン１２又は受付ボタン１３が押下操作された場合（Ｓ２，Ｓ３：ＹＥＳ）、業務依頼入力欄１１に受付けた情報の入力があるか否かを判断する（ステップＳ４）。受付けた情報の入力がない場合（Ｓ４：ＮＯ）、処理をステップＳ２へ戻す。
【００５１】
業務依頼入力欄１１に受付けた情報の入力がある場合（Ｓ４：ＹＥＳ）、受付けた情報を受付サーバ１００へ送信する（ステップＳ５）。
【００５２】
端末装置２００から送信された情報を受付サーバ１００にて受信した場合（ステップＳ６）、担当店マスタ１０９ａから担当店に関する情報を取得する（ステップＳ７）。そして、余力チェックパターンデータベース１０９ｂから担当店の余力チェックパターンを取得する（ステップＳ８）。次いで、受付管理データベース１０９ｃからその担当店の受付可能数を取得する（ステップＳ９）。次いで、既存受付データベース１０９ｄから既存受付数を取得する（ステップＳ１０）。
【００５３】
次いで、ステップＳ８からステップＳ１０で取得した余力チェックパターン、受付可能数、及び既存受付数に基づいて後述するパターン別余力算出処理を行う（ステップＳ１１）。そして、顧客の希望日の前後数日の各時間帯に業務を行うことが可能であるかを判定して、受付を行うか否かの判定をする（ステップＳ１２）。判定された結果は、端末装置２００へ送信される（ステップＳ１３）。
【００５４】
端末装置２００にて、判定された結果を受信した場合（ステップＳ１４）、その情報を余力テーブル１６，１８に表示する（ステップＳ１５）。
【００５５】
図９及び図１０は、パターン別余力算出処理の手順を示したフローチャートである。まず、余力チェックパターンデータベース１０９ｂから取得された余力チェックパターンがパターン１０であるか否かを判断する（ステップＳ２１）。余力チェックパターンがパターン１０である場合（Ｓ２１：ＹＥＳ）、パターン１０の余力管理形態に従い余力を算出する（ステップＳ２２）。
【００５６】
余力チェックパターンがパターン１０でない場合（Ｓ２１：ＮＯ）、余力チェックパターンデータベース１０９ｂから取得された余力チェックパターンがパターン１１であるか否かを判断する（ステップＳ２３）。余力チェックパターンがパターン１１である場合（Ｓ２３：ＹＥＳ）、パターン１１の余力管理形態に従い余力を算出する（ステップＳ２４）。
【００５７】
余力チェックパターンがパターン１１でない場合（Ｓ２３：ＮＯ）、余力チェックパターンデータベース１０９ｂから取得された余力チェックパターンがパターン２０であるか否かを判断する（ステップＳ２５）。余力チェックパターンがパターン２０である場合（Ｓ２５：ＹＥＳ）、パターン２０の余力管理形態に従い余力を算出する（ステップＳ２６）。
【００５８】
余力チェックパターンがパターン２０でない場合（Ｓ２５：ＮＯ）、余力チェックパターンデータベース１０９ｂから取得された余力チェックパターンがパターン３０であるか否かを判断する（ステップＳ２７）。余力チェックパターンがパターン３０である場合（Ｓ２７：ＹＥＳ）、パターン３０の余力管理形態に従い余力を算出する（ステップＳ２８）。
【００５９】
次いで、「ＡＭ」又は「ＥＶＥ」の時間帯についての余力算出か否かを判断する（ステップＳ２９）。「ＡＭ」又は「ＥＶＥ」の時間帯についての余力算出である場合（Ｓ２９：ＹＥＳ）、各パターンの余力管理形態に従って算出した値を返す。
【００６０】
次いで、「ＡＭ」及び「ＥＶＥ」の時間帯についての余力算出でない場合（Ｓ２９：ＮＯ）、「ＰＭ１」の時間帯についての余力算出であるか否かを判断する（ステップＳ３０）。
【００６１】
「ＰＭ１」の時間帯での余力算出である場合（Ｓ３０：ＹＥＳ）、ＰＭ２残余力数がＰＭ受付数以上であるか否かを判断する（ステップＳ３２）。ここで、ＰＭ２残余力数は、時間帯「ＰＭ２」において更に受付けることができる件数であり、また、ＰＭ受付数として、「ＰＭ１」、「ＰＭ２」、及び「ＰＭ」の各時間帯で既に受付けている件数を足し合わせた値である。
【００６２】
ＰＭ２残余力数がＰＭ受付数以上である場合（Ｓ３２：ＹＥＳ）、ＰＭ１残余力数として、各パターンの余力管理形態に従って算出した値を返し、ＰＭ２残余力数として、各パターンの余力管理形態に従って算出した値からＰＭ受付数を差引いた値を返す（ステップＳ３３）。
【００６３】
また、ＰＭ２残余力数がＰＭ受付数より小さい場合（Ｓ３２：ＮＯ）、ＰＭ１残余力数として、各パターンの余力管理形態に従って算出した値からＰＭ受付数とＰＭ２残余力数との差を差引いた値を返し、ＰＭ２残余力数として零値を返す（ステップＳ３４）。
【００６４】
「ＰＭ１」の時間帯での余力算出でない場合（Ｓ３０：ＮＯ）、「ＰＭ２」の時間帯での余力算出であるか否かを判断する（ステップＳ３１）。
【００６５】
「ＰＭ２」の時間帯での余力算出である場合（Ｓ３１：ＹＥＳ）、ＰＭ１残余力数がＰＭ受付数以上であるか否かを判断する（ステップＳ３５）。
【００６６】
ＰＭ１残余力数がＰＭ受付数以上である場合（Ｓ３５：ＹＥＳ）、ＰＭ１残余力数として、各パターンの余力管理形態に従って算出した値からＰＭ受付数を差引いた値を返し、ＰＭ２残余力数として、各パターンの余力管理形態に従って算出した値を返す。（ステップＳ３６）。
また、ＰＭ１残余力数がＰＭ受付数より小さい場合（Ｓ３５：ＮＯ）、ＰＭ１残余力数として零値を返し、ＰＭ２残余力数として、各パターンの余力管理形態に従って算出した値からＰＭ受付数とＰＭ１残余力数との差を差引いた値を返す（ステップＳ３７）。
【００６７】
以下、図９及び図１０のフローチャートについて具体的な適用例について説明する。各業務の受付最大可能数が表１に示した如く規定されており、時間帯「ＡＭ」又は「ＥＶＥ」に属するある時点での既存受付数が表２に示した通りであった場合を考える。
【００６８】
【表１】
【表２】
余力チェックパターンがパターン１０である場合、開栓、閉栓、修繕の各残余力数は、MaxAll-(UkeK+UkeH+UkeS)により算出され、表１及び表２に基づき算出した場合、４３（＝６０−（６＋４＋７））となる。
【００７１】
余力チェックパターンがパターン１１である場合、開栓、閉栓、修繕の各残余力数は、以下のように算出される。
まず、開栓、閉栓の残余力数は、修繕に残余力が無い場合、MaxAll-(UkeK+UkeH+BaseS)により算出され、修繕に残余力がある場合、MaxAll-(UkeK+UkeH+UkeS)により算出される。したがって、表１及び表２に示した例では、修繕に残余力があるため、開栓及び修繕の残余力数は、４３（＝６０−（６＋４＋７））となる。
【００７２】
修繕の残余力数は、開栓又は閉栓の受付け件数が最大受付件数を超過している場合、修繕の残余力から賄うため、MaxAll-(UkeK+UkeH+UkeS)となる。また、開栓及び閉栓に残余力がある場合、修繕の残余力数は、BaseS-UkeSにより算出される。すなわち、表１及び表２に示した例では、開栓及び閉栓に残余力があるため、２３（＝３０−７）により算出される。
【００７３】
また、余力チェックパターンが、パターン２０及びパターン３０である場合も、同様にして算出することができる。
【００７４】
次いで、業務に実施希望時間帯が「ＰＭ１」、「ＰＭ２」、又は「ＰＭ」である場合の各業務の残余力数の算出について説明する。各業務の受付最大可能数が表３に示した如く規定されており、時間帯「ＰＭ１」、「ＰＭ２」又は「ＰＭ」に属するある時点での既存受付数が表４に示した通りであった場合を考える。
【００７５】
【表３】
【表４】
「ＰＭ１」の残余力数は、「ＰＭ」全受付数が「ＰＭ２」の残余力を超過するまで前述と同様に算出する。すなわち、「ＰＭ２」の残余力を超過するまで、「ＰＭ２」の残余力により「ＰＭ」の受付を賄う。また、「ＰＭ２」の残余力数は、「ＰＭ」全受付数が「ＰＭ１」の残余力を超過するまで前述と同様に算出する。すなわち、「ＰＭ１」の残余力を超過するまで、「ＰＭ１」の残余力により「ＰＭ」の受付を賄う。ここで、「ＰＭ」全受付数とは、ＰＭ１」、「ＰＭ２」、「ＰＭ」の各受付数（=SumUkeAll#PM）の合計（=UkeK#PM+UkeH#PM+UkeS#PM）である。
【００７８】
余力チェックパターンがパターン１０である場合、時間帯が「ＰＭ」の開栓、閉栓、修繕の残余力数は、(Yoryoku#PM1+Yoryoku#PM2)-SumUkeAll#PMにより算出される。ここで、Yoryoku#PM1，Yoryoku#PM2は、「ＡＭ」及び「ＥＶＥ」の残余力数の算出方法と同じ手法により算出した「ＰＭ１」、「ＰＭ２」の残余力数である。
【００７９】
表３及び表４に示した例では、Yoryoku#PM1が４３（＝６０−（６＋４＋７））となり、Yoryoku#PM2が１３（＝３０−（３＋５＋８））となる。また、「ＰＭ」全受付数（SumUkeAll#PM）は、９（＝６＋２＋１）である。
したがって、「ＰＭ」の開栓、閉栓、修繕の残余力数は、４８（＝（４３＋１４）−９）となる。
【００８０】
「ＰＭ１」の開栓、閉栓、修繕の残余力数は、「ＰＭ２」の残余力により「ＰＭ」受付を賄える場合、Yoryoku#PM1であり、「ＰＭ２」の残余力を超過する場合、（Yoryoku#PM1+Yoryoku#PM2）-SumUkeAll#PMにより算出する。表３及び表４に示した例では、「ＰＭ２」の残余力で「ＰＭ」受付を賄えるため、開栓、閉栓、修繕の残余力数はそれぞれ４３となる。
【００８１】
「ＰＭ２」の開栓、閉栓、修繕の残余力数は、「ＰＭ１」の残余力により「ＰＭ」受付を賄える場合、Yoryoku#PM2であり、「ＰＭ１」の残余力を超過する場合、（Yoryoku#PM1+Yoryoku#PM2）-SumUkeAll#PMにより算出する。表３及び表４に示した例では、「ＰＭ１」の残余力で「ＰＭ」受付を賄えるため、開栓、閉栓、修繕の残余力数はそれぞれ１４となる。
【００８２】
また、余力チェックパターンが、パターン１１、パターン２０及びパターン３０である場合も、同様にして算出することができる。
【００８３】
なお、本実施の形態では、受付サーバ１００に端末装置２００を１台のみ接続する形態であったが、端末装置２００を複数台接続する形態であってもよい。このとき、顧客の電話機５００からの呼出信号を自動分配機４００が受信した場合、電話機５００と接続する端末装置２００を自動分配機４００にて選択する形態であってもよい。
【００８４】
なお、本実施の形態では、ガス会社によって運営されている受付システムの形態について説明したが、ガス会社に限定されるものではなく、業務の依頼を電話にて受付ける各種の業界に適用できることは勿論のことである。
【００８５】
【発明の効果】
以上、詳述したように、本発明にあっては、各処理毎の処理可能数を予め定めておき、既に受付けた実行要求の数と処理可能数とに基づき、実行要求を受付けた処理の実行が可能であるか否かを判定し、前記処理の実行が不可能であると判定した場合、他の処理により実行可能であるか否かを判定するようにしている。したがって、例えば、複数の処理を行う各担当店が処理可能件数を予め定めておくことによって、各担当店、各処理毎に処理を実行する担当者の余力を効率的に管理することができ、処理の実行要求を受付けた者が担当店に逐次連絡をして確認することなく、処理の実行が可能であるか否かについての情報を得ることができるため、速やかな顧客の応対が可能となる。
【００８６】
また、本発明にあっては、各業務毎の受付可能件数と、一の業務が他の業務により実行可能であるか否かとを規定した受付形態が、業務請負単位毎に予め選択されており、選択された受付形態と既に受付けた各業務毎の実行依頼の件数とに基づき、各業務毎に実行依頼が受付可能であるか判定し、判定した結果を提供するようにしている。したがって、例えば、業務の実行を請負う各担当店は、その業務形態に応じて柔軟に受付形態を選択することができ、選択された受付形態に応じ、複数の業務間にて相互補完できる業務についての情報を提供することが可能となる。
【００８７】
更に、本発明にあっては、各業務毎の受付可能数を予め定められた時間帯毎に規定して、業務依頼を受付けた業務が可能であるか否かを各時間帯毎に判定するようにしている。したがって、時間帯毎に業務の受付余力を管理することが可能となる。
【００８８】
更に、本発明にあっては、各業務毎の受付可能件数を予め定めておき、既に受付けた業務依頼の件数と受付可能件数とに基づき、業務依頼を受付けた業務の実行が可能であるか否かを判定し、前記業務の実行が不可能であると判定した場合、他の業務により実行可能であるか否かを判定するようにしている。したがって、例えば、各担当店、各業務毎に業務依頼の受付可能件数を予め定めておくことによって、各担当店、各業務毎に業務担当者の余力を効率的に管理することができ、業務依頼を受付けた者が担当店に逐次連絡をして確認することなく、業務の実行が可能であるか否かについての情報を得ることができるため、速やかな顧客の応対が可能となる等、本発明は優れた効果を奏する。
【図面の簡単な説明】
【図１】本実施の形態に係る受付システムの構成を示す模式図である。
【図２】受付サーバの内部構成を示すブロック図である。
【図３】端末装置の内部構成を示すブロック図である。
【図４】指示サーバの内部構成を示すブロック図である。
【図５】各業務の余力管理について説明する模式図である。
【図６】受付サーバが有するマスタディスク及びデータベースの一例を示す概念図である。
【図７】端末装置の表示部に表示される画面の一例を示す模式図である。
【図８】本実施の形態に係る受付システムの処理手順を示したフローチャートである。
【図９】パターン別余力算出処理の手順を示したフローチャートである。
【図１０】パターン別余力算出処理の手順を示したフローチャートである。
【符号の説明】
１００ 受付サーバ
１０９ａ 担当店マスタ
１０９ｂ 余力チェックパターンデータベース
１０９ｃ 受付管理データベース
１０９ｄ 既存受付データベース
２００ 端末装置
３００ 自動分配機
４００ 指示サーバ
５００ 電話機
ＴＮ 公衆電話回線網
ＰＬ 専用回線
Claims (6)
- 複数の業務について各業務毎の実行依頼を受付ける際、情報処理装置内のデータベースに記憶された情報に基づいて前記実行依頼の受付けが可能であるか否かを前記情報処理装置にて判定する受付方法において、
業務を請負う各担当店が受付けることができる各業務毎の受付可能件数と一の業務の担当者が他の業務を実行可能であるか否かを定めた業務余力に関する管理パターンとをそれぞれ各担当店を識別するためのＩＤに関連付けて前記情報処理装置内のデータベースに予め記憶させておき、前記情報処理装置は、各担当店が既に受付けた各業務毎の件数を各担当店のＩＤに関連付けてデータベースに記憶させ、業務の実行依頼を受付けた場合、前記業務を請負う担当店のＩＤを取得し、取得した担当店のＩＤと関連付けて記憶してある各業務毎の受付可能件数、業務余力の管理パターン及び既存受付数をデータベースから読出し、読出した担当店における業務余力の管理パターンに従い、読出した受付可能件数及び既存受付数を用いて前記担当店の各業務毎の余力を算出し、算出した余力に基づいて前記業務依頼の受付けが可能であるか否かを判定することを特徴とする受付方法。 - 複数の業務について各業務毎の実行依頼を受付ける際、情報処理装置内のデータベースに記憶された情報に基づいて前記実行依頼が受付け可能であるか否かを前記情報処理装置が判定し、判定結果に係る情報を出力する情報提供方法において、
業務を請負う各担当店が受付けることができる各業務毎の受付可能件数と一の業務の担当者が他の業務を実行可能であるか否かを定めた業務余力に関する管理パターンとをそれぞれ各担当店を識別するためのＩＤに関連付けて前記情報処理装置内のデータベースに予め記憶させておき、前記情報処理装置は、各担当店が既に受付けた各業務毎の件数を各担当店のＩＤに関連付けてデータベースに記憶させ、業務の実行依頼を受付けた場合、前記業務を請負う担当店のＩＤを取得し、取得した担当店のＩＤと関連付けて記憶してある各業務毎の受付可能件数、業務余力の管理パターン及び既存受付数をデータベースから読出し、読出した担当店における業務余力の管理パターンに従い、読出した受付可能件数及び既存受付数を用いて前記担当店の各業務毎の余力を算出し、算出した余力に基づいて前記業務依頼の受付けが可能であるか否かを判定し、判定結果を出力することを特徴とする情報提供方法。 - 各担当店における各業務毎の受付可能件数は予め定められた時間帯毎に規定されており、実行依頼を受付けた業務が受付可能であるか否かを各時間帯毎に判定し、判定結果を出力することを特徴とする請求項２に記載の情報提供方法。
- 複数の業務について各業務毎に実行依頼を受付け、受付けた実行依頼に関する情報を送信する端末装置と、該端末装置から送信される情報を受信した場合、前記実行依頼を受付けるか否かを判定し、判定結果を前記端末装置へ送信する受付サーバとを備える受付システムにおいて、
前記端末装置は、業務を請負う担当店を識別するためのＩＤの入力を受付ける手段を備え、受付けた担当店のＩＤを前記実行依頼に関する情報と共に送信するようにしてあり、
前記受付サーバは、各担当店が受付けることができる各業務毎の受付可能件数を各担当店のＩＤに関連付けて予め記憶するデータベースと、一の業務の担当者が他の業務を実行可能であるか否かを定めた業務余力に関する管理パターンを各担当店のＩＤに関連付けて予め記憶するデータベースと、各担当店が既に受付けた各業務毎の件数を各担当店のＩＤに関連付けて記憶するデータベースと、前記端末装置から送信される情報を受信した場合、業務を請負う担当店のＩＤを取得する手段と、取得した担当店のＩＤと関連付けて記憶してある各業務毎の受付可能件数、業務余力の管理パターン及び既存受付数を各データベースから読出す手段と、読出した担当店における業務余力の管理パターンに従い、読出した受付可能件数及び既存受付数を用いて前記担当店の各業務毎の余力を算出する手段と、算出した余力に基づいて前記業務依頼を受付けるか否かを判定する手段と、該手段による判定結果を前記端末装置へ送信する手段とを備え、
前記端末装置は、前記受付サーバから送信される判定結果を受信し、受信した判定結果を表示するようにしてあることを特徴とする受付システム。 - 複数の業務について各業務毎に実行依頼を受付ける際、該実行依頼の受付けが可能であるか否かを判定し、判定結果に係る情報を出力する受付サーバにおいて、
業務を請負う各担当店が受付けることができる各業務毎の受付可能件数を各担当店を識別するためのＩＤに関連付けて予め記憶するデータベースと、一の業務の担当者が他の業務を実行可能であるか否かを定めた業務余力に関する管理パターンを各担当店のＩＤに関連付けて予め記憶するデータベースと、各担当店が既に受付けた各業務毎の件数を各担当店のＩＤに関連付けて記憶するデータベースと、業務の実行依頼を受付けた場合、前記業務を請負う担当店のＩＤを取得する手段と、取得した担当店のＩＤと関連付けて記憶してある各業務毎の受付可能件数、業務余力の管理パターン及び既存受付数を各データベースから読出す手段と、読出した担当店における業務余力の管理パターンに従い、読出した受付可能件数及び既存受付数を用いて前記担当店の各業務毎の余力を算出する手段と、算出した余力に基づいて前記業務依頼を受付けるか否かを判定する手段とを備え、該手段による判定結果に係る情報を出力するようにしてあることを特徴とする受付サーバ。 - 複数の業務について各業務毎の実行依頼を受付ける際、コンピュータ内のデータベースに記憶された情報に基づいて前記実行依頼の受付けが可能であるか否かを判定させるコンピュータプログラムにおいて、
業務を請負う各担当店が受付けることができる各業務毎の受付可能件数と一の業務の担当者が他の業務を実行可能であるか否かを定めた業務余力に関する管理パターンとをそれぞれ各担当店を識別するためのＩＤに関連付けて前記データベースに予め記憶させておき、コンピュータに、各担当店が既に受付けた各業務毎の件数を各担当店のＩＤに関連付けてデータベースに記憶させるステップと、コンピュータに、業務の実行依頼を受付けた場合、前記業務を請負う担当店のＩＤを取得させるステップと、コンピュータに、取得させた担当店のＩＤと関連付けて記憶してある各業務毎の受付可能件数、業務余力の管理パターン及び既存受付数をデータベースから読出させるステップと、コンピュータに、読出させた担当店における業務余力の管理パターンに従い、読出させた受付可能件数及び既存受付数を用いて前記担当店の各業務毎の余力を算出させるステップと、コンピュータに、算出させた余力に基づいて前記業務依頼の受付けが可能であるか否かを判定させるステップとを有することを特徴とするコンピュータプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002098108A JP3963216B2 (ja) | 2002-03-29 | 2002-03-29 | 受付方法、情報提供方法、受付システム、受付サーバ、及びコンピュータプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002098108A JP3963216B2 (ja) | 2002-03-29 | 2002-03-29 | 受付方法、情報提供方法、受付システム、受付サーバ、及びコンピュータプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003296549A JP2003296549A (ja) | 2003-10-17 |
| JP3963216B2 true JP3963216B2 (ja) | 2007-08-22 |
Family
ID=29387858
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002098108A Expired - Lifetime JP3963216B2 (ja) | 2002-03-29 | 2002-03-29 | 受付方法、情報提供方法、受付システム、受付サーバ、及びコンピュータプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3963216B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012079060A (ja) * | 2010-09-30 | 2012-04-19 | Toshiba Corp | イメージエントリシステム、イメージエントリ方法およびプログラム |
| JP6735398B1 (ja) | 2019-08-06 | 2020-08-05 | 株式会社 ディー・エヌ・エー | ライブ動画を配信するためのシステム、方法、及びプログラム |
| JP7341956B2 (ja) * | 2019-08-06 | 2023-09-11 | 株式会社 ディー・エヌ・エー | ライブ動画を配信するためのシステム、方法、及びプログラム |
-
2002
- 2002-03-29 JP JP2002098108A patent/JP3963216B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003296549A (ja) | 2003-10-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN104823157B (zh) | 用于提供联络中心资源的动态弹性的系统和方法 | |
| US7792726B2 (en) | Reception management system for assigning transaction requests to operator terminals | |
| US20060190944A1 (en) | System and Method for Resource Management | |
| KR100778966B1 (ko) | 관리 서버 컴퓨터를 포함하는 글로벌 문서 생성 시스템 | |
| US20040267592A1 (en) | Method and program for assisting a worker in charge of operations | |
| GB2314232A (en) | Telephone transaction system | |
| CN113807955A (zh) | 信息审核方法及相关设备 | |
| KR102108541B1 (ko) | 상담사 스케쥴 관리 장치 및 방법 | |
| JP3963216B2 (ja) | 受付方法、情報提供方法、受付システム、受付サーバ、及びコンピュータプログラム | |
| US6345270B1 (en) | Data management system | |
| US20060026057A1 (en) | Collaborative organization analysis | |
| US6393333B1 (en) | Production management system | |
| JP3612640B2 (ja) | 電話取引支援システム | |
| US20220374809A1 (en) | Computer-based tracking and determining impact of events on contact center operations | |
| JP2003036323A (ja) | 輸出管理システム | |
| JP4518730B2 (ja) | 情報公開処理システム | |
| US6415301B1 (en) | Integrated retrieval system, integrated retrieval method and media recorded with integrated retrieval program in distributed file system | |
| JP3939904B2 (ja) | ワークフローシステム、文書承認方法および記憶媒体 | |
| JP2003288375A (ja) | 施設データベースシステム | |
| JP2003141313A (ja) | ワークフローシステム、及びナレッジマネジメントシステム | |
| JP4475999B2 (ja) | 住宅ローン審査システム、住宅ローン審査用プログラム及び住宅ローン判定支援用プログラム | |
| JP3667230B2 (ja) | ワークフロー管理制御装置 | |
| US20230053494A1 (en) | Service proposal support system and service proposal support method | |
| JPH09245087A (ja) | 業務改善支援装置 | |
| CN114240237A (zh) | 一种计划信息管控方法、系统及存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041129 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070220 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070417 |
|
| 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: 20070515 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070515 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 3963216 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130601 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130601 Year of fee payment: 6 |
|
| EXPY | Cancellation because of completion of term |