JP2003167981A - スケジュール管理システム - Google Patents

Abstract

(57)【要約】 【課題】 各要員の希望スケジュールを収集して入力す
る作業を不要とする。 【解決手段】 到来する呼に応答する複数要員の希望ス
ケジュールと、上記呼に関するトラフィック履歴情報と
に基づいて、所定期間における上記複数要員のスケジュ
ールを作成するスケジューラ２３を具備する。前記各要
員に対応して備えられ、夫々の要員による入力を受けて
所定形式の希望スケジュール情報を生成してネットワー
ク１を介して送信するオペレータ端末２−１〜２−ｎ、
４２−１〜４２−ｍ、４４−１〜４４−ｉを備える。こ
れらの端末から送られる希望スケジュール情報を前記ネ
ットワーク１を介して受け取り、前記スケジューラ２３
による処理に対応させて出力する希望スケジュール収集
・作成スケジュール確認処理手段２２を具備する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、コールセンタ等
と称される外部からの呼に応答して案内や苦情処理等を
行うシステムにおける要員のスケジュール管理システム
に関する。

【０００２】

【従来の技術】従来、この種のスケジュール管理システ
ムにあっては、各要員の希望スケジュールを入力すると
トラフィック履歴情報に基づき自動的に各日に要員を割
り振って全体のスケジュールを作成する装置が用いられ
ている。

【０００３】しかしながら、この装置は各要員の希望ス
ケジュールを入力する必要があり、基本的には担当者が
希望スケジュールを収集して入力する作業を要すること
から繁雑であるという問題があった。

【０００４】

【発明が解決しようとする課題】また、上記装置では、
スケジュールの作成を行うに際して調整機能を持たない
ことから、要員が必要な日にちや時間帯に十分な要員が
確保できない場合や要員が不必要に集中した日にちや時
間帯が生じた場合には、担当者が調整確認を行う必要が
あり、この点においてもやはり煩わしいものであった。

【０００５】本発明は上記のような従来のスケジュール
管理システムが備えている問題点を解決せんとしてなさ
れたもので、その目的は、各要員の希望スケジュールを
入力する必要がなく、希望スケジュールを収集して入力
する作業を不要とできるスケジュール管理システムを提
供することである。また、他の目的は要員が必要な日に
ちや時間帯に十分な要員が確保できない場合や要員が不
必要に集中した日にちや時間帯が生じた場合にも担当者
が調整確認を行う必要のないスケジュール管理システム
を提供することである。

【０００６】

【課題を解決するための手段】本発明の請求項１に係る
スケジュール管理システムは、到来する呼に応答する複
数要員の希望スケジュールと、上記呼に関するトラフィ
ック履歴情報とに基づいて、所定期間における上記複数
要員のスケジュールを作成するスケジュール作成手段を
具備するスケジュール管理システムにおいて、前記各要
員に対応して備えられ、夫々の要員による入力を受けて
所定形式の希望スケジュール情報を生成してネットワー
クを介して送信する要員用端末と、この要員用端末から
送られる希望スケジュール情報を前記ネットワークを介
して受け取り、前記スケジュール作成手段による処理に
対応させて出力するスケジュール収集手段とを具備する
ことを特徴とする。

【０００７】本発明の請求項２に係るスケジュール管理
システムは、到来する呼に応答する複数要員の希望スケ
ジュールと、上記呼に関するトラフィック履歴情報とに
基づいて、所定期間における上記複数要員のスケジュー
ルを作成するスケジュール作成手段を具備するスケジュ
ール管理システムにおいて、前記各要員に対応して備え
られ、夫々の要員による入力を受けて所定形式の希望ス
ケジュール情報を生成してネットワークを介して送信す
る要員用端末と、この要員用端末から送られる希望スケ
ジュール情報を前記ネットワークを介して受け取り、前
記スケジュール作成手段による処理に対応させて出力す
るスケジュール収集手段と、前記スケジュール作成手段
により作成されたスケジュールを前記各要員用端末へ配
信して、確認の処理を行う作成スケジュール確認処理手
段とを具備することを特徴としている。

【０００８】本発明の請求項３に係るスケジュール管理
システムでは、前記スケジュール作成手段は、複数要員
の希望スケジュールと前記トラフィック履歴情報とに基
づいて所定期間における上記複数要員のスケジュールを
作成した場合に、前記作成スケジュール確認処理手段に
よる処理を行わせて確認変更に係る情報を前記要員用端
末から受けて前記作成したスケジュールの変更処理を実
行することを特徴としている。

【０００９】本発明の請求項４に係るスケジュール管理
システムでは、前記スケジュール作成手段は、上記複数
要員のスケジュールを作成した場合に、スケジュールの
変更要請を要請対応履歴情報に基づき許諾確率の高い要
員から順に行い、許諾の結果を報酬に反映させる処理を
行うことを特徴とする。

【００１０】

【発明の実施の形態】以下添付図面を参照して本発明の
実施の形態に係るスケジュール管理システムを説明す
る。図１に、本発明の実施の形態に係るスケジュール管
理システムが組み込まれたコールセンタのシステム構成
を示す。このシステムは、ＴＣＰ／ＩＰ（Transmission
Control Protocol/Internet Protocol ）によるネット
ワーク１に、パーソナルコンピュータによるオペレータ
端末２−１〜２−ｎと、基本的に交換機の機能を有する
通信サーバ３が接続され、通信サーバ３へ外部の公衆網
３１や無線網３２に接続される端末３３−１〜３３−４
から呼が到来した場合に、これらの呼に対してオペレー
タ端末２−１〜２−ｎにて応答するようにしたものであ
る。

【００１１】上記システムでは、遠隔地にも要員を配置
するために、ファイアウオール４を介してインターネッ
ト４１にオペレータ端末４２−１〜４２−ｍが接続さ
れ、ルータ５を介してイントラネット４３にオペレータ
端末４４−１〜４４−ｉが接続されている。オペレータ
端末４２−１〜４２−ｍ、オペレータ端末４４−１〜４
４−ｉも、オペレータ端末２−１〜２−ｎと同様に外部
からの呼に応答するようにしたものである。

【００１２】また、ネットワーク１には、スケジュール
管理システムを構成するために、要員管理サーバ６、メ
ールサーバ７、管理者用端末８が接続されている。オペ
レータ端末４２−１〜４２−ｍ、オペレータ端末４４−
１〜４４−ｉ、オペレータ端末２−１〜２−ｎは、パー
ソナルコンピュータにより、また要員管理サーバ６、メ
ールサーバ７、管理者用端末８は、ワークステーション
等のコンピュータシステムにより構成される。

【００１３】つまり、これらはいずれも図２に示される
ような構成に係るワークステーション、パーソナルコン
ピュータ、その他の計算機として構築される。すなわ
ち、図２の計算機は、装置を統括制御するＣＰＵ５１を
有し、このＣＰＵ５１に上記ＣＰＵ５１が用いるプログ
ラム及びデータ等の情報が記憶される主記憶装置５２が
接続されている。更に、ＣＰＵ５１には、システムバス
５３を介してキーボード制御部５４、表示制御部５５、
プリンタ制御部５６、通信インタフェース５７、マウス
制御部５８、磁気ディスク制御部５９が接続されてい
る。キーボード制御部５４には各種情報をキー入力可能
なキーボード入力装置６０が接続され、表示制御部５５
には情報を表示するためのＣＲＴ表示装置６１が接続さ
れ、プリンタ制御部５６には情報を印字出力するための
プリンタ装置６２が接続され、通信インタフェース５７
には回線を介して通信を行うための通信制御部６３が接
続され、マウス制御部５８にはポインティングディバイ
スであるマウス６４が接続され、磁気ディスク制御部５
９には補助記憶装置である磁気ディスク装置６５が接続
されている。なお、メールサーバ７には、ＣＰＵ５１、
主記憶装置５２、磁気ディスク制御部５９、磁気ディス
ク装置６５、通信インタフェース５７、通信制御部６３
が少なくとも設けられる。また、各コンピュータシステ
ムにおいては、必要に応じてフレキシブルディスクドラ
イブ、磁気カード或いはＩＣカードリーダ、ＭＯ（光磁
気ディスク）ドライブ等が設けられる。

【００１４】上記のように構成されたオペレータ端末４
２−１〜４２−ｍ、オペレータ端末４４−１〜４４−
ｉ、オペレータ端末２−１〜２−ｎは、その主記憶装置
５２に要員による入力を受けて所定形式の希望スケジュ
ール情報を生成してネットワークを介して送信するため
のプログラムが備えられており、これに基づいて図３に
示されるフローチャートに示される要員用端末としての
動作が行われる。以下にこのフローチャートを用いて動
作を説明する。

【００１５】上記プログラムが起動されると、希望スケ
ジュールの入力要求が指示されるのかを待ち（Ｓ１）、
また、通信処理部６３と通信インタフェース５７を介し
て受信データがあるのか（メールサーバ７へメールが到
来しているか等）を検出する（Ｓ２）。

【００１６】上記ステップＳ１において希望スケジュー
ルの入力要求が指示されると、スケジュール入力画面を
ＣＲＴ表示装置６１へ表示してスケジュールの入力を受
け付ける（Ｓ３）。具体的には、図６の希望テーブルに
おいて、氏名の欄を除くような表を表示し、日時とその
日時における出勤時間帯情報を入力してもらう。この例
において出勤時間帯情報としては、９時から２１時まで
の任意の時間帯とする。

【００１７】そして、図３のフローチャートにおいて
は、上記の表に対しスケジュールの入力が完了して送信
要求が発せられるのを待ち（Ｓ４）、送信要求を受けて
希望スケジュールの登録である旨の情報と上記希望スケ
ジュールの情報を所定の形式（フォーマット）にして要
員管理サーバ６へ送信する（Ｓ５）。ステップＳ２にお
いて受信データの到来を検出した場合の動作について
は、後に説明を行う。

【００１８】要員管理サーバ６におけるスケジュール管
理に係る構成を図４に示す。要員管理サーバ６の例えば
磁気ディスク装置６５には、各種のテーブル等が記憶さ
れるデータベース２１が構築され、主記憶装置５２に
は、希望スケジュール収集・作成スケジュール確認処理
手段２２と、スケジュール作成手段であるスケジューラ
２３が備えられている。

【００１９】スケジューラ２３は、希望スケジュール
と、呼に関するトラフィック履歴情報とに基づいて、所
定期間における上記複数要員のスケジュールを作成する
ものである。また、希望スケジュール収集・作成スケジ
ュール確認処理手段２２は、要員用端末から送られる希
望スケジュール情報をネットワーク１を介して受け取
り、スケジューラ２３による処理に対応させて出力する
スケジュール収集手段として機能する。つまり、希望ス
ケジュール情報は、所定の形式であるので、日時や出勤
時間帯情報を取り出して、データベース２１内の図６に
示す希望テーブルの対応欄に登録してゆく。また、希望
スケジュール収集・作成スケジュール確認処理手段２２
は、スケジューラ２３により作成されたスケジュールを
各要員用端末へ配信して、確認の処理を行う作成スケジ
ュール確認処理手段として機能するものである。

【００２０】メールサーバ７には、送信されてきた電子
メールが記憶されており、図５に示されるように、１通
毎に送信元アドレスや送信先アドレス等を含むヘッダと
共にメールの内容（本体）が記憶され、未読／既読の別
を示す情報が付加されている。この例では、メールサー
バ７に対して要員管理サーバ６が要員端末側へのメール
送信して登録しておき、要員端末がメールサーバ７へア
クセスして受信メールの有無を確認し、メールがあると
これを受け取るように使用される。

【００２１】データベース２１には、希望スケジュール
が記憶される図６に示す希望テーブルが各要員（オペレ
ータ）に対応して設けられ、また、スケジューラ２３に
より作成されたスケジュールを記憶するための図７に示
す結果テーブルが各要員（オペレータ）に対応して設け
られる。図７に示す結果テーブルにおける調整数の欄
は、何回目の要請で調整を受け入れたかを記憶する欄で
あり、ボーナス点の欄は調整を受け入れた場合に、その
結果を報酬に反映させる処理を行うために設けられた点
数を記憶する欄であり、その内容は次の月の結果テーブ
ルに転記される。

【００２２】更にデータベース２１には、図８に示す呼
のトラフィック履歴情報のテーブルが備えている。この
テーブルは、例えば、１日から３１日までの各日にち
が、月曜から日曜までに当った場合、その曜日における
呼数の履歴情報を、テーブルに示す時間帯対応に記憶し
たものである。また、予測値は次の月において予測され
る呼数の予測値であり、この例の「１．０１」は、１パ
ーセントの伸びを示すデータである。この値は、例え
ば、イベントの有り無しや季節等により適宜決定され
る。ここでは、月に１つの予測値を用いたが、各日にち
の各時間帯毎に細かく予測しても良い。

【００２３】更にデータベース２１には、図９に示すス
ケジュール作成当月の勤務体制情報を記憶するテーブル
が設けられている。このテーブルは、当該月の各日にち
に対応して時間帯を区切り、勤務する要員のＩＤが記憶
されると共に、予測された要員数に対する過不足が分数
で記憶されるようになっている。

【００２４】そして、図４の希望スケジュール収集・作
成スケジュール確認処理手段２２は、図１０に示すフロ
ーチャートにより処理を行い、スケジューラ２３は図１
１に示すフローチャートにより処理を行うので、これに
基づき動作を説明する。

【００２５】既に図３のフローチャートにより説明した
ように、希望スケジュール情報が送られているときに、
オペレータよりデータが到来したかを検出しており（Ｓ
１１）、ここでＹＥＳへ分岐し、所定フォーマットデー
タに基づき、時間帯情報等の項目対応にデータを切り出
して該当するオペレータのＩＤを有する希望テーブル
（図６）へデータが登録される（Ｓ１４）。

【００２６】一方、スケジューラ２３は図１１に示すよ
うに、図８に示した履歴データと予測値より当月の各日
の各時間帯に必要な要員数を求め、図９の当月Ｓ（スケ
ジュール）のテーブルにおける過不足の欄の分母へ要員
数を展開する（Ｓ２１）。

【００２７】そして、上記図１０のフローチャートのス
テップ１４により登録された希望テーブルのデータを用
いて、図９の当月Ｓ（スケジュール）のテーブルにおけ
る勤務するオペレータのＩＤの欄へデータを展開する
（Ｓ２２）。

【００２８】以上の処理を全てのオペレータに関する希
望スケジュール情報について行い、過不足の欄のデータ
を求め、過不足なく決定できた日の時間帯のＩＤに基づ
き、図６の希望テーブルから図７の結果テーブルへの転
記を行う（Ｓ２３）。そして、次に図９の当月Ｓ（スケ
ジュール）のテーブルに関し全ての欄において過不足な
く決定できたかを検出する（Ｓ２４）。このステップＳ
２４において、過不足なく決定できていることを検出す
ると、図７の結果テーブルからスケジュール確認情報
（図７の結果テーブルの内容が分かる情報）を作成し
て、メールサーバ７へＩＤと共に転送する指示を希望ス
ケジュール収集・作成スケジュール確認処理手段２２へ
与える（Ｓ２５）。

【００２９】このデータは、図１０のステップＳ１３に
おいてＹＥＳへと分岐させ、メールサーバ７への転送が
行われる（Ｓ１５）。メールサーバ７では図５のファイ
ルへ送信されてきたメールを格納する。オペレータ端末
では、各オペレータが図３におけるステップＳ２におい
て受信メールの到来を待ち受けて（メールサーバ７へ確
認して）おり、メールが送られてきた端末ではＹＥＳへ
分岐して到来したメールをメールサーバ７から取り出し
表示する（図３のＳ６）。斯して管理者の手を煩わせる
ことなく、希望スケジュールの収集から確認までが行わ
れる。

【００３０】しかし、各オペレータの希望により通常は
図１１のステップＳ２４からＮＯへ分岐することが多
い。そこで図７に示す結果テーブルにおける調整数が最
大のオペレータを求めて、図９のテーブルにおいて過不
足の生じている日、時間帯を示して、希望の変更を要請
するメール（希望スケジュールを含む）を作成し、メー
ルサーバ７へ送信する（Ｓ２６）。この場合にも、図１
０のステップＳ１３においてＹＥＳとさせ、メールサー
バ７への転送が行われる（Ｓ１５）。

【００３１】図３におけるステップＳ２において受信デ
ータの到来を待ち受けて（メールサーバ７へ確認して）
おり、メールが送られてきた端末ではＹＥＳへ分岐して
到来したメールをメールサーバ７から取り出し表示する
（Ｓ６）。そして、当該オペレータ端末では、確認・変
更画面（送られてきた希望スケジュールと、過不足の生
じている日、時間帯）を表示し入力を受け付ける（Ｓ
７）。そして、入力が完了して送信要求が発せられるの
を待ち（Ｓ８）、送信要求を受けて確認・変更である旨
の情報と上記入力により変更された部分のスケジュール
または何らの変更がされない旨の情報を所定の形式（フ
ォーマット）にして要員管理サーバ６へ送信する（Ｓ
５）。

【００３２】これに対し、希望スケジュール収集・作成
スケジュール確認処理手段２２がスケジュール情報を受
け取り、ステップＳ１１からステップＳ１４へと進み希
望テーブルへデータを展開する。このとき、変更があれ
ば、その部分のみが書き替えられる。

【００３３】そこでスケジューラ２３は、希望スケジュ
ール収集・作成スケジュール確認処理手段２２の通知に
よりステップＳ２７において、図９のテーブルと結果テ
ーブルへの反映を行う（Ｓ２７）。勿論、変更されない
ときには、反映は何らなされない。調整に応じたとき調
整数の欄に何回目で調整に応じたかが記憶されている。
そこで、変更がなされたときには、何回目で変更に応じ
たことにより何ポイントという情報に基づき、変更に応
じた時間帯の数を上記ポイントに掛けて今月ポイントと
し登録し、以下においてはステップＳ３０からステップ
Ｓ２７へとループした何回目かの変更毎にポイントを加
算する処理を行う（Ｓ２８）。

【００３４】このステップＳ２８の処理を終えると、図
９のテーブルにおいて過不足が解消されたかを検出し
（Ｓ２９）、解消されなければ、次に前月のボーナスポ
イントの高いオペレータを選択し、図９のテーブルにお
いて過不足の生じている日、時間帯を示して、希望の変
更を要請するメール（希望スケジュールを含む）を作成
し、メールサーバ７へ送信する（Ｓ３０）。この場合に
も、図１０のステップＳ１３においてＹＥＳとさせ、メ
ールサーバ７への転送が行われる（Ｓ１５）。

【００３５】以下同様にして変更要請が行われ、何回か
の要請によりステップＳ２９においてはＹＥＳへ分岐
し、ステップＳ２５において全てのオペレータへの確認
情報が作成され、ズテップＳ１３においてＹＥＳとさ
せ、メールサーバ７への転送が行われる（Ｓ１５）。

【００３６】斯して、従来管理者が行っていたスケジュ
ール調整が自動的に行われる。また、ボーナス点は、例
えば管理者用端末８から読み出されて報酬に反映させる
ようにできる。

【００３７】なお、以上ではオペレータ端末をパーソナ
ルコンピュータとしたが、携帯電話機等の端末としても
良い。また、ネットワーク１はＴＣＰ／ＩＰによるもの
に限らず、スケジュール情報を送受信できるものであれ
ば良い。

【００３８】上記の説明では、メールサーバ７が通常の
メールサーバとして機能し、メールを蓄積し、受信側の
端末からのアクセスを受けて当該端末が取り出すように
したが、メールサーバ７が自立的に受信側の端末へ送信
を行うようにしても良い。

【００３９】例えば、メールサーバ７には、全てのオペ
レータ端末のアドレス（ＩＰアドレス）がオペレータ端
末のＩＤに対応させられて記憶されており、要員管理サ
ーバ６からのオペレータ端末へ送信すべき作成スケジュ
ール情報であるメールが転送されると、図１２に示され
るように、件名（もしくはジョブＩＤ）を付した送信チ
ェックテーブルを作成してメールを送信するように構成
する。送信チェックテーブルには、オペレータ端末のア
ドレス（ＩＰアドレス）がオペレータ端末のＩＤに対応
させられて記憶され、かつ送信済チェック（フラグ）及
び備考欄が設けられる。

【００４０】そして、図１０のステップＳ１３において
ＹＥＳへ分岐して、メールサーバ７への転送が行われる
と（Ｓ１５）、メールサーバ７では図５の送信チェック
テーブルを作成してメールを送信する処理を誘起させ
て、メールの送信がなされる。各オペレータのオペレー
タ端末では、図３におけるステップＳ２において受信デ
ータの到来を待ち受けており、メールが自動的に送られ
てきた端末ではＹＥＳへ分岐して到来したメール内容を
表示する（Ｓ６）。斯して管理者の手を煩わせることな
く、希望スケジュールの収集から確認までが行われる。
このように、メールサーバ７から送信がなされるので、
スケジュール管理・調整を素早く済ませることができ
る。

【００４１】

【発明の効果】以上説明したように本発明では、希望ス
ケジュール情報を要員端末から送信し、これを受けた側
でスケジュール作成による処理に対応させて出力するよ
うにしたので、管理者等の人手を要せず簡易にスケジュ
ール収集が可能である。また、作成されたスケジュール
を各要員用端末へ配信して、確認の処理を行う機能を備
えるので、人手によるスケジュール調整が不要であり効
率の良いスケジュール管理が可能となる。

【図面の簡単な説明】

【図１】本発明のスケジュール管理システムに係る一実
施例を含んだコールセンタシステムの構成図。

【図２】図１におけるオペレータ端末等の詳細構成を示
す構成図。

【図３】図１におけるオペレータ端末の動作を説明する
ためのフローチャート。

【図４】図１における要員管理サーバの要部構成を示す
図。

【図５】図１におけるメールサーバに備えられるメール
格納用のファイルの構成を示す図。

【図６】本発明のスケジュール管理システムを構成する
要員管理サーバに備えられるデータベースが有する希望
テーブルの内部構成図。

【図７】本発明のスケジュール管理システムを構成する
要員管理サーバに備えられるデータベースが有する結果
テーブルの内部構成図。

【図８】本発明のスケジュール管理システムを構成する
要員管理サーバに備えられるデータベースが有している
呼のトラフィック履歴情報のテーブルにおける内部構成
図。

【図９】本発明のスケジュール管理システムを構成する
要員管理サーバに備えられるデータベースが有している
スケジュール作成当月の勤務体制情報を記憶するテーブ
ルの内部構成図。

【図１０】本発明のスケジュール管理システムを構成す
る要員管理サーバに備えられる希望スケジュール収集・
作成スケジュール確認処理手段の動作を説明するための
フローチャート。

【図１１】本発明のスケジュール管理システムを構成す
る要員管理サーバに備えられるスケジューラの動作を説
明するためのフローチャート。

【図１２】図１におけるメールサーバに備えられるオペ
レータ端末のアドレスを用いた送信チェックテーブルの
構成を示す図。

【符号の説明】

１ ネットワーク ２−１〜２−ｎ、４２−１〜４２−ｍ、４４−１〜４４
−ｉ オペレータ端末 ３ 通信サーバ ４ ファイアウオール ５ ルータ ６ 要員管理サーバ ７ メールサーバ ８ 管理者端末 ２１ データベース ２２ 希望スケジュール収集・作成スケジュール確認処
理手段 ２３ スケジューラ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 荻野 洋光 東京都港区芝浦一丁目１番１号 株式会社 東芝本社事務所内

Claims (4)

【特許請求の範囲】
1. 【請求項１】 到来する呼に応答する複数要員の希望ス
   ケジュールと、上記呼に関するトラフィック履歴情報と
   に基づいて、所定期間における上記複数要員のスケジュ
   ールを作成するスケジュール作成手段を具備するスケジ
   ュール管理システムにおいて、 前記各要員に対応して備えられ、夫々の要員による入力
   を受けて所定形式の希望スケジュール情報を生成してネ
   ットワークを介して送信する要員用端末と、 この要員用端末から送られる希望スケジュール情報を前
   記ネットワークを介して受け取り、前記スケジュール作
   成手段による処理に対応させて出力するスケジュール収
   集手段とを具備することを特徴とするスケジュール管理
   システム。
2. 【請求項２】 到来する呼に応答する複数要員の希望ス
   ケジュールと、上記呼に関するトラフィック履歴情報と
   に基づいて、所定期間における上記複数要員のスケジュ
   ールを作成するスケジュール作成手段を具備するスケジ
   ュール管理システムにおいて、 前記各要員に対応して備えられ、夫々の要員による入力
   を受けて所定形式の希望スケジュール情報を生成してネ
   ットワークを介して送信する要員用端末と、 この要員用端末から送られる希望スケジュール情報を前
   記ネットワークを介して受け取り、前記スケジュール作
   成手段による処理に対応させて出力するスケジュール収
   集手段と、 前記スケジュール作成手段により作成されたスケジュー
   ルを前記各要員用端末へ配信して、確認の処理を行う作
   成スケジュール確認処理手段とを具備することを特徴と
   するスケジュール管理システム。
3. 【請求項３】 前記スケジュール作成手段は、複数要員
   の希望スケジュールと前記トラフィック履歴情報とに基
   づいて所定期間における上記複数要員のスケジュールを
   作成した場合に、前記作成スケジュール確認処理手段に
   よる処理を行わせて確認変更に係る情報を前記要員用端
   末から受けて前記作成したスケジュールの変更処理を実
   行することを特徴とする請求項２に記載のスケジュール
   管理システム。
4. 【請求項４】 前記スケジュール作成手段は、上記複数
   要員のスケジュールを作成した場合に、スケジュールの
   変更要請を要請対応履歴情報に基づき許諾確率の高い要
   員から順に行い、許諾の結果を報酬に反映させる処理を
   行うことを特徴とする請求項３に記載のスケジュール管
   理システム。