Pergunta

Eu estive batendo a cabeça contra uma parede neste.

Estou trabalhando em um projeto em que o cliente é dono de um call center e deseja estimar o número de pessoas precisava trabalhar em meia hora em uma campanha inserindo uma hora de pico, uma estimativa das pessoas necessárias naquela hora e presumivelmente um desvio padrão. Isso deve então "ventilar" os valores para os outros slots (diminuindo nos dois lados do pico).

Se esse fosse um gráfico, você teria meia hora no eixo x (1 a 48) e o número de pessoas necessárias ao longo do eixo y, o que pareceria uma curva de sino com o pico no horário de pico especificado.

Como posso obter valores aproximados dos assentos necessários para cada slot de meia hora? Qualquer ponto na direção certa seria muito apreciada!

PS trabalhando no .NET se alguém souber de quaisquer bibliotecas que possam fazer isso.

Foi útil?

Solução

Você pode obter a fórum para a função de densidade de probabilidade (junto com um .net libary) aqui

No entanto, eu mesmo trabalho em um software de call center no meu trabalho e posso dizer que as FTEs nunca são normalmente distribuídas. Geralmente, existem ~ 2-3 distribuições normais sobrepostas, uma esquerda inclinada à esquerda e uma inclinada à direita, dependendo da hora do dia (de manhã cedo, no final da tarde) e do tipo de campanha (B2B a B2C).

Para uma estimativa mais precisa, eu recomendaria manter um histórico de atividade/carga anterior em seu call center (qual é a carga média em cada intervalos de meia hora), então use-o como linha de base de distribuição, escalando-o para se encaixar na carga de pico esperada e comprimento estimado da chamada. É isso que fazemos na ProtCall, e geralmente estamos certos em 90 % - 95 % da carga real. As vezes. Às vezes perdemos por um fator de 10.

EDITAR:

Ok, demorei um pouco para ver como estimamos cargas, e a distribuição padrão não vai levar você a lugar algum. Dê uma olhada em um casal do capturas de tela De nossos gráficos e você verá o quão diferente a distribuição realmente parece.

O que você precisa fazer (basicamente):

  1. Experimente o número de chamadas feitas a cada minuto (quantas chamadas tivemos desde 60 segundos atrás)
  2. Salve essas amostras em uma tabela: TimeOfday, Callsmor
  3. Carregue essas amostras e escala -as. (ou seja. Se nossa tabela total tiver 10.000 chamadas e estimamos que nossa nova atividade tenha 4.000 ligações por dia, multiplique tudo por 0.4. Você pode escalar por NR estimado de chamadas ou (mais acuratelly) por número estimado de minas de conversão no tempo por dia)

Como alternativa, se você simplesmente tiver uma tabela com uma entrada de linha para cada chamada feita, você pode simplesmente:

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

Para contar as chamadas feitas a cada hora. Amostrá -lo por hora, não por minuto, mas pode ser suficiente para lhe dar a linha de base

Outras dicas

Hmmm

Eu ficaria surpreso se a distribuição de chamadas durante o dia (24 horas da meia -noite à meia -noite) fosse normal (ou seja, seguisse a curva da campainha). No entanto, se é isso que o cliente pediu, que assim seja. Mas antes de ir muito mais longe, faça uma investigação mais aprofundada.

Sua presunção de que o cliente pode especificar um dev std dev correto?

As chamadas não serão normalmente distribuídas sobre o horário de pico dentro de um dia, a menos que o horário de pico seja 12:00 - se o cliente realmente acreditar que a distribuição de chamadas é unimodal entre 00:00 e 23:59, então Aposto que o modo não está às 12:00.

Como um de seus entrevistados já disse, você pode encontrar as fórmulas e implementações da distribuição normal prontamente.

Mas se você quiser impressionar seu cliente e criar um modelo melhor, eu começaria com algumas filas simples.

Eu acho que isso não é realmente uma resposta, mas a indústria telefônica usa o Erlang Como uma unidade de medida para esses tipos de problemas, derivados do comprimento médio da chamada e do número médio de chamadas simultâneas em um período.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top