Este documento descreve em detalhes o módulo de Previsão Aprimorada de Requisitos de Agentes e como a Community usa clusters para proporcionar uma redução significativa no número necessário de funcionários com base no treinamento cruzado de agentes, e assim fornecer uma previsão mais precisa do número de agentes necessários para satisfazer a carga do centro de contato.
Por que a Previsão Aprimorada de Requisitos de Agentes?
A Community, como a maioria das aplicações atuais de gestão da força de trabalho, fornece
previsão de requisitos de agentes com base em fórmulas matemáticas de Erlang-C para converter
chamadas, tempos de atendimento e objetivos de serviço em agentes necessários. Embora as
fórmulas de Erlang-C tenham se mostrado confiáveis ao longo do tempo em seus cálculos, elas
não consideram agentes multihabilitados no centro de contato. A fórmula assume que os agentes
estarão dedicados a atender apenas a demanda de uma única habilidade.
O conceito por trás da estratégia de “clustering” é agrupar atividades para fins de gerar
requisitos de número de agentes analisando a matriz de treinamento cruzado para os agentes
envolvidos em uma escala. À medida que o treinamento cruzado aumenta, o número de agentes
necessários para satisfazer a demanda em uma única atividade é reduzido porque, novamente,
os agentes são compartilhados entre várias atividades. O clustering deve ser realizado de forma
que a alocação seja proporcional ao volume de chamadas para a atividade, mas relativa ao
número de agentes que também têm a atribuição da atividade em particular.
Uma vez que as atividades são agrupadas, elas podem ser previstas como uma única atividade e
as eficiências de treinamento cruzado de agentes são realizadas. O cluster representa um grupo
de atividades relacionadas, e para a atividade membro em um cluster, a Community calcula a
probabilidade de uma chamada ser atendida pela atividade dada no cluster dado. Quanto mais
desconexa a matriz de treinamento cruzado para os agentes na escala, mais clusters resultarão.
Considere um exemplo típico.
(Para todos os exemplos apresentados neste documento, assuma um nível de serviço de 80/20.)
Primeiro, assuma que não existe treinamento cruzado entre os agentes atribuídos às habilidades
acima. Isso apareceria como na tabela de atribuição de agentes a seguir:
Neste caso, a previsão de requisitos de agentes baseada em Erlang-C está perfeitamente correta,
porque nenhuma eficiência pode ser realizada a partir do treinamento cruzado de agentes.
Agora, considere o outro extremo, onde cada agente é atribuído a todas as habilidades
disponíveis. Neste caso, a tabela de atribuição de agentes aparece da seguinte forma:
O princípio fundamental por trás do algoritmo de clustering é que a demanda (volume de contato
e tempo de atendimento) para habilidades comumente atribuídas pode ser combinada em uma única habilidade e reprevista usando a fórmula padrão de Erlang-C.
No exemplo acima, todos os agentes estão disponíveis em todas as habilidades, então, essencialmente, a demanda pode ser representada como uma única habilidade composta. Neste caso, o seguinte será previsto:
Neste exemplo, podemos ver que o treinamento cruzado proporcionou um ganho de eficiência de 12% nos agentes (8 agentes) simplesmente combinando as habilidades treinadas cruzadamente. Note que a coluna Tempo de Atendimento Ponderado é a média ponderada pelo volume do tempo de atendimento calculada como:
SUM( Tempo Médio de Atendimento * ( SUM(Volume) ) )
Neste exemplo:
(250 * (100 / 175) ) + (300 * (50 / 175) ) + (320 * (25 / 175) ) = 274 wAHT
No entanto, na maioria das circunstâncias, a população de agentes não é nem 100% treinada cruzadamente nem 0% treinada cruzadamente. O resultado é que a capacidade de agrupar atividades comumente atribuídas é significativamente difícil. Para realizar isso, a Community usa um algoritmo baseado em uma equação quadrática para determinar a similaridade nas habilidades entre os agentes. O resultado é um conjunto de clusters de atividades e a probabilidade de que uma chamada seja atendida por uma determinada atividade em cada cluster.
Como a Community Gera os Clusters?
Os clusters fornecem a probabilidade de que uma chamada possa ser atendida em uma habilidade em um cluster. No exemplo totalmente treinado cruzadamente acima, a Community criaria um único cluster que representa todas as habilidades e agentes. O resultado é que cada habilidade (atividade) no cluster teria uma probabilidade de 100% de ser satisfeita nesse cluster, simplesmente porque não existem outros clusters.
No entanto, se o treinamento cruzado for fragmentado, mais clusters resultarão, e as probabilidades variarão dependendo dos clusters envolvidos. Considere uma matriz de treinamento cruzado mais realista:
Durante o processo de criação de uma Previsão de Requisitos de Agentes, a Community gera os clusters com base na matriz acima. O resultado são três clusters para cada atividade, devido à fragmentação das atividades em francês e espanhol. A matriz de clusters resultante aparece da seguinte forma:
Examinando os clusters, revelará que o Cluster 0 é a combinação das atividades em inglês e espanhol, o Cluster 1 é a combinação de todas as três atividades, e o Cluster 2 é a combinação das atividades em inglês e francês.
O Cluster 0 é resultado do treinamento cruzado fornecido pelo Agente2, que é atribuído apenas ao inglês e espanhol. O Cluster 1 é resultado do treinamento cruzado fornecido pelo Agente3, que é atribuído a todas as três atividades. O Cluster 2 é resultado do treinamento cruzado fornecido pelo Agente1, que é atribuído apenas ao inglês e francês.
Observe também que a atividade em inglês aparece em todos os clusters. A razão é que todos os agentes são atribuídos à atividade em inglês, então em todos os clusters existe alguma chance de que uma chamada oferecida à atividade em inglês seja atendida em cada cluster. Como todos os agentes são atribuídos ao inglês, a probabilidade é dividida igualmente entre os clusters.
O que os Clusters fazem?
Novamente, os clusters fornecem a probabilidade de que uma chamada oferecida a uma atividade seja atendida pela atividade no cluster. As probabilidades para uma atividade nos clusters sempre somarão 100 (100% de probabilidade de que a chamada será atendida pela atividade em um cluster). Essencialmente, para uma determinada matriz de treinamento cruzado, os clusters fornecem as combinações corretas de atividades para prever como um único grupo combinado. O agrupamento correto de atividades existe em algum lugar entre os dois extremos (nenhum treinamento cruzado e 100% de treinamento cruzado), e os clusters fornecem a estratégia de agrupamento.
O primeiro passo na criação da previsão aprimorada é determinar o número de servidores dado o volume e o tempo de atendimento para todas as atividades incluídas no cluster. Essencialmente, o algoritmo agrupa todo o volume de todas as atividades juntas, como no exemplo de 100% de treinamento cruzado acima. No entanto, o volume para atividades não é incluído na demanda agrupada se a probabilidade de uma chamada ser atendida naquele cluster for 0. A tabela a seguir ilustra a demanda agrupada resultante dos clusters definidos acima:
Lembre-se de que o Cluster 0 é uma combinação de inglês e espanhol, que contribuem com 100 e 50 chamadas para o "pool" combinado, respectivamente. O Tempo Médio Ponderado de Atendimento é calculado conforme descrito acima.
O Cluster 1 é uma combinação de todas as três atividades, resultando em uma demanda agrupada de 175 (100 + 50 + 25), e o Cluster 2 é uma combinação de inglês e francês com demanda agrupada de 125 (100 + 25).
O algoritmo então calcula o número de servidores para toda a demanda combinada usando os objetivos de serviço da atividade atual. O algoritmo somará os servidores rateados em todos os clusters onde a probabilidade é > 0. A fórmula abaixo fornece os servidores agrupados para uma determinada atividade:
Servidores Agrupados = SOMA( wC * sP * ( cA / cP) )
Onde:
• wC é o peso para um determinado cluster
• sP são os servidores para a demanda agrupada
• cA é o volume para a atividade dada
• cP é o volume para o pool dado
• Substituindo nossos valores para as atividades acima:
A acumulação de todos os requisitos de agentes é 34 + 17 + 8, ou 59 agentes. Comparado à previsão original de requisitos de agentes baseada em Erlang C de 67, percebemos um ganho de eficiência de 10 agentes, ou aproximadamente 15% para este intervalo específico. Nota: todos os valores para agentes necessários são arredondados para cima para o número inteiro mais próximo para garantir que os níveis de serviço desejados sejam alcançados.
A cálculo de eficiência para comparar a Previsão Padrão versus a Previsão Aprimorada é a seguinte:
Horas de Trabalho – Horas de Trabalho Aprimoradas / Horas de Trabalho
Previsão para Objetivos de Serviço Dissimilares
O algoritmo acima calcula o número de funcionários necessário para satisfazer a proporção de uma atividade dada da demanda agrupada com base nos objetivos de serviço da atividade. Enquanto os valores de volume e tempo de atendimento para o pool são usados em várias atividades, os servidores (agentes) necessários são baseados nos objetivos de serviço específicos da atividade. Portanto, o requisito de número de funcionários resultante para o pool é baseado no nível de serviço para a atividade e, consequentemente, a quantidade rateada reflete o objetivo de serviço individual.
Considere o exemplo acima com um nível de serviço para espanhol em 90/10.
O número de funcionários resultante aumenta para o Cluster 0, refletindo o aumento do nível de serviço necessário para o espanhol. No entanto, outras atividades não são afetadas pelo objetivo de serviço dissimilar.
Valores de Consolidação para Atividades Pai / Calculando Horas de Trabalho /
Calculando FTEs
O método para exibir os requisitos de agentes em um nível de atividade pai é o mesmo entre a Previsão Padrão e a Previsão Aprimorada. As horas de trabalho em qualquer nível da atividade são calculadas da seguinte forma:
SOMA( Requisitos de Contagem de Cabeças por Intervalo / Slots Padrão do Sistema por Hora)
Nos exemplos acima, se cada intervalo entre 7:00 AM e 5:00 PM (inclusive) exigisse 59 agentes, então as horas de trabalho no nível pai seriam:
Agentes Necessários * Slots/Hora * Horas (59 * 4 * 10) + 59 = 604 Horas de Trabalho
Observe que os últimos 59 são devido ao intervalo das 5:00 PM estar incluído na previsão.
O cálculo dos FTEs com base nas horas de trabalho é:
Horas de Trabalho / 8.0 (Assumir que FTE é um funcionário de 8 horas).
Esses valores para uma atividade individual são idênticos a uma atividade pai.
Programação Padrão Erlang vs. Previsão Aprimorada de Requisitos de Agentes
Community fornece escalas a capacidade de escolher o método de previsão usado para gerar escalas. Se a Previsão Aprimorada de Requisitos de Agentes for selecionada (usando Métodos de Previsão Baseados em Habilidades), Community exporta o valor de Requisitos de Agentes Aprimorados para o intervalo. Se a previsão padrão for selecionada, então Community exporta a previsão padrão de agentes baseada em Erlang. No entanto, em ambos os casos, o motor de otimização otimizará a força de trabalho em todas as atividades atribuídas.