2

私はこれの壁に頭をぶつけてきました。

私は、クライアントがコールセンターを所有していて、ピーク時間を入力して、キャンペーンの30分スロットで働くのに必要な人数、その時間に必要な人の見積もり、そしておそらく標準偏差。これにより、値が他のスロットに「ファンアウト」されます(ピークの両側で減少します)。

これがグラフの場合、x軸に30分スロット(1〜48)があり、y軸に沿って必要な人数があります。これは、指定されたピーク時間にピークがあるベルカーブのように見えます。

30分ごとに必要な座席の概算値を取得するにはどうすればよいですか?正しい方向へのポイントは大歓迎です!

PSこれを実行できるライブラリを誰かが知っている場合は、.NETで作業します。

4

3 に答える 3

3

確率密度関数のフォーラム(.NETライブラリと共に)はここで入手できます。

しかし、私は自分の仕事でコールセンターソフトウェアに取り組んでおり、FTEが正規分布することは決してありません。通常、時間帯(早朝、午後遅く)とキャンペーンのタイプ(B2BからB2C)に応じて、2〜3の重複する正規分布があり、1つは左に偏り、もう1つは右に偏ります。

より正確な見積もりを行うには、コールセンターでの以前のアクティビティ/負荷の履歴(30分間隔ごとの平均負荷)を保持し、それを分散ベースラインとして使用して、予想されるピーク負荷に合わせてスケーリングすることをお勧めします。推定通話時間。これはProtCallで行うことであり、通常、実際の負荷の90%〜95%以内です。時々。時々私達は10倍を逃します。

編集:

わかりました。少し時間をかけて負荷を見積もる方法を確認しましたが、標準分布ではどこにも行き着きません。チャートのスクリーンショットをいくつか見てみると、分布が実際にどのように異なっているかがわかります。

あなたがする必要があること(基本的に):

  1. 1分あたりに行われた通話数のサンプル(60秒前からの通話数)
  2. それらのサンプルをテーブルに保存します:TimeOfDay、CallsMade
  3. それらのサンプルをロードし、スケーリングします。(つまり、合計テーブルに10.000の呼び出しがあり、新しいアクティビティが1日あたり4.000の呼び出しであると推定する場合、すべてに0.4を掛けます。推定呼び出し数または(より正確には)推定通話時間分数でスケーリングできます。 1日あたり)

または、呼び出しごとに行エントリを含むテーブルがある場合は、次のようにすることができます。

SELECT count(*),datepart(hour,[CalledOn]) as CalledOn from tableCalls group by datepart(hour,[CalledOn]) 

1時間ごとに行われた呼び出しをカウントします。1分ごとではなく、1時間ごとにサンプリングしますが、ベースラインを提供するには十分な場合があります

于 2009-11-06T09:12:36.050 に答える
2

うーん

日中(深夜から深夜までの24時間)の通話の分布が正常であった(つまり、ベルカーブに従った)場合は驚きます。ただし、それがクライアントが注文したものである場合は、そうです。ただし、先に進む前に、さらに調査を行ってください。

クライアントが標準偏差を指定できるというあなたの推測は正しいですか?

ピーク時間が12:00である場合を除いて、コールは通常、1日のピーク時間に分散されません。クライアントが、呼び出しの分散が00:00から23:59の間で単峰性であると本当に信じている場合は、私はモードが12:00ではないに違いない。

回答者の1人がすでに述べているように、正規分布の公式と実装を簡単に見つけることができます。

しかし、クライアントに印象を与え、より良いモデルを構築したい場合は、簡単なキューイングから始めます。

于 2009-11-06T09:16:09.953 に答える
0

これは本当の答えではないと思いますが、電話業界では、この種の問題の測定単位としてErlangを使用しています。これは、ある期間の平均通話時間と平均同時通話数から導き出されます。

于 2009-11-06T09:06:26.103 に答える