BR112021004156A2 - método para prever demanda de carga de trabalho para planejamento de recursos em um ambiente de central de contatos. - Google Patents

Abstract

MÉTODO PARA PREVER DEMANDA DE CARGA DE TRABALHO PARA PLANEJAMENTO DE RECURSOS EM UM AMBIENTE DE CENTRAL DE CONTATOS A presente invenção se refere a um sistema e método para prever a demanda de carga de trabalho em um aplicativo de jornada do cliente. Com o uso de informações de histórico provenientes de análise de jornada, momentos de jornada podem ser agregados através de vários estágios. Os vetores de distribuição de probabilidade podem ser aproximados para várias trajetórias conectadas aos estágios. A estabilidade dessa distribuição de probabilidade pode ser determinada através de métodos estatísticos. As previsões para volumes futuros que progridem através dos estágios podem ser determinadas através de algoritmos recursivos após a aplicação de um algoritmo de previsão de série temporal no estágio (ou estágios) de origem. Uma vez que volumes futuros tenham sido previstos em cada estágio, pode-se estimar a carga de trabalho futura para melhor planejamento de capacidade e programação de recursos para lidar com tal demanda a fim de alcançar métricas de desempenho ao longo da função de custo.

Description

1 / 41

MÉTODO PARA PREVER DEMANDA DE CARGA DE TRABALHO PARA PLANEJAMENTO DE RECURSOS EM UM AMBIENTE DE CENTRAL DE CONTATOS ANTECEDENTES

[001] A presente invenção se refere de modo geral a sistemas e métodos de telecomunicações, bem como à provisão de recursos de central de contatos. Mais particularmente, a presente invenção se refere à previsão da carga de trabalho de recursos para provisão de recursos de central de contato.

REFERÊNCIA REMISSIVA A PEDIDO CORRELATO

[002] Este pedido reivindica o benefício do pedido de patente provisório US n° 62/729.856, intitulado "METHOD AND SYSTEM TO

PREDICT WORKLOAD DEMAND IN A CUSTOMER JOURNEY APPLICATION", depositado no United States Patent and Trademark Office (USPTO, ou Departamento de Patentes e Marcas dos EUA) em 11 de setembro de 2018, cujo conteúdo está aqui incorporado por referência.

SUMÁRIO

[003] A presente invenção se refere a um sistema e método para prever a demanda de carga de trabalho em um aplicativo de jornada do cliente. Com o uso de informações de histórico provenientes de análise de jornada, momentos de jornada podem ser agregados através de vários estágios. Os vetores de distribuição de probabilidade podem ser aproximados para várias trajetórias conectadas aos estágios. A estabilidade dessa distribuição de probabilidade pode ser determinada através de métodos estatísticos. As previsões para volumes futuros que progridem através dos estágios podem ser determinadas através de algoritmos recursivos após a aplicação de um algoritmo de previsão de série temporal no estágio (ou estágios) de origem. Uma vez que volumes futuros tenham sido previstos em cada estágio, pode-se estimar a carga de trabalho futura para melhor planejamento de capacidade e programação de recursos para lidar com tal

2 / 41 demanda a fim de alcançar métricas de desempenho ao longo da função de custo.

[004] Em uma modalidade, é apresentado um método para prever a demanda de carga de trabalho para planejamento de recursos em um ambiente de central de contatos, sendo que o método compreende: extrair dados de histórico a partir de uma base de dados, sendo que os dados de histórico compreendem uma pluralidade de níveis de estágio representativos do tempo que um recurso da central de contatos gasta atendendo um nível de estágio em uma jornada do cliente; pré-processar os dados de histórico, sendo que o pré- processamento compreende adicionalmente derivar gráficos de adjacência, derivar sequências zero e derivar históricos de estágios, para cada nível de estágio; determinar previsões de estágios com o uso dos dados de histórico pré-processados e construir um modelo de previsões; e derivar a demanda de carga de trabalho prevista com o uso do modelo construído.

[005] Os níveis de estágio compreendem pontos de foco da jornada do cliente e transições de cada estágio na jornada do cliente. A extração é disparada por um dentre os seguintes: ação do usuário, trabalho programado e solicitação em fila proveniente de outro serviço. Os gráficos de adjacência modelam conexões de gráfico entre estágios. Uma sequência zero compreende um primeiro estágio de uma cadeia de uma progressão de sequências. Um histórico de estágio compreende uma propriedade para cada estágio compreendendo contagem de vetor de histórico, taxa de abandono e matriz de vetor de probabilidade.

[006] A previsão de estágio compreende adicionalmente as etapas de: executar um algoritmo de liberação que executa iterações dos dados de histórico para liberar volumes através de múltiplos estágios e períodos; reter uma porção de dados de histórico para validação, resultando em uma porção restante; usar a porção restante para construir e treinar o modelo de previsões; e calibrar o modelo de previsões. A liberação de volumes compreende

3 / 41 trabalhar retrocedendo a partir da data de início da previsão menos um período e repetir com cada repetição aumentando cada período em 1.

[007] A demanda prevista da carga de trabalho compreende a carga de trabalho gerada a partir de um volume de interações conforme um cliente progride por estágios na jornada do cliente, incluindo abandonos previstos. A demanda de carga de trabalho prevista compreende adicionalmente recursos necessários para lidar com a carga de trabalho prevista para fornecer alvos métricos de KPI (indicadores-chave de desempenho) à central de contatos.

[008] Em outra modalidade, é apresentado um método para prever a demanda de carga de trabalho para planejamento de recursos em um ambiente de central de contatos, sendo que o método compreende: extrair dados de histórico a partir de uma base de dados, sendo que os dados de histórico compreendem uma pluralidade de níveis de estágio representativos de ações que um recurso da central de contatos gasta atendendo um nível de estágio em uma jornada do cliente; pré-processar os dados de histórico, sendo que o pré- processamento compreende adicionalmente derivar gráficos de adjacência, derivar sequências zero e derivar históricos de estágios, para cada nível de estágio; determinar previsões de estágios com o uso dos dados de histórico pré-processados e construir um modelo de previsões; e derivar demanda de carga de trabalho prevista com o uso do modelo construído.

[009] Em outra modalidade, é apresentado um sistema para prever a demanda de carga de trabalho para planejamento de recursos em um ambiente de central de contatos, sendo que o sistema compreende: um processador; e uma memória em comunicação com o processador, sendo que a memória armazena instruções que, quando executadas pelo processador, fazem com que o processador: extraia dados de histórico a partir de uma base de dados, sendo que os dados de histórico compreendem uma pluralidade de níveis de estágio representativos do tempo que um recurso da central de contatos gasta atendendo um nível de estágio em uma jornada do cliente; pré-processar os

4 / 41 dados de histórico, sendo que o pré-processamento compreende adicionalmente derivar gráficos de adjacência, derivar sequências zero e derivar históricos de estágios, para cada nível de estágio; determinar previsões de estágios com o uso dos dados de histórico pré-processados e construir um modelo de previsões; e derivar a demanda de carga de trabalho prevista com o uso do modelo construído.

[0010] Em outra modalidade, é apresentado um sistema para prever a demanda de carga de trabalho para planejamento de recursos em um ambiente de central de contatos, sendo que o sistema compreende: um processador; e uma memória em comunicação com o processador, sendo que a memória armazena instruções que, quando executadas pelo processador, fazem com que o processador: extraia dados de histórico de uma base de dados, sendo que os dados de histórico compreendem uma pluralidade de níveis de estágio representativos de ações que um recurso da central de contatos gasta atendendo um nível de estágio em uma jornada do cliente; pré-processar os dados de histórico, sendo que o pré-processamento compreende adicionalmente derivar gráficos de adjacência, derivar sequências zero, e derivar históricos de estágios, para cada nível de estágio; determinar previsões de estágios com o uso dos dados de histórico pré-processados e construir um modelo de previsões; e derivar a demanda de carga de trabalho prevista com o uso do modelo construído.

BREVE DESCRIÇÃO DOS DESENHOS

[0011] A Figura 1 é um diagrama ilustrando uma modalidade de uma infraestrutura de comunicação.

[0012] A Figura 2 é um diagrama que ilustra uma modalidade de uma arquitetura de gerenciamento de força de trabalho.

[0013] A Figura 3 é um fluxograma que ilustra uma modalidade de um processo para criar um modelo para previsão de demanda de carga de trabalho.

5 / 41

[0014] A Figura 4A é uma representação gráfica direcionada de uma modalidade de uma jornada.

[0015] A Figura 4B é uma modalidade de uma representação de gráfico adjacente.

[0016] A Figura 4C é uma modalidade de uma representação de gráfico adjacente.

[0017] A Figura 5 é um fluxograma que ilustra uma modalidade de um processo para derivar sequências zero.

[0018] A Figura 6 é um fluxograma que ilustra uma modalidade de um processo para derivar o histórico de estágio.

[0019] A Figura 7 é um fluxograma que ilustra uma modalidade de um processo para liberação de demanda.

[0020] A Figura 8A é um diagrama que ilustra uma modalidade de um dispositivo de computação.

[0021] A Figura 8B é um diagrama que ilustra uma modalidade de um dispositivo de computação.

DESCRIÇÃO DETALHADA

[0022] Com o propósito de promover um entendimento dos princípios da invenção, agora será feita referência à modalidade ilustrada nos desenhos, e linguagem específica será usada para descrever a mesma. Será entendido, todavia, que não se pretende com isso qualquer limitação do escopo da invenção. Quaisquer alterações e modificações adicionais nas modalidades descritas, e quaisquer aplicações adicionais dos princípios da invenção conforme aqui descritos, são contempladas como normalmente ocorreria ao versado na técnica à qual está relacionada a presente invenção.

[0023] O gerenciamento da interação com o cliente em um ambiente de central de contatos compreende o gerenciamento de interações entre partes, por exemplo, clientes e agentes, clientes e "bots", ou uma mistura de ambos. Isso pode ocorrer através de qualquer número de canais na central de

6 / 41 contatos, rastreando e direcionando os melhores recursos possíveis (agente ou autosserviço) com base em habilidades e/ou qualquer número de parâmetros. A emissão de relatórios pode ser feita em interações de canal em tempo real e de uma maneira histórica. Todas as interações que um cliente assume relacionadas ao mesmo serviço, necessidade ou propósito podem ser descritas como a jornada do cliente. Aqui e na técnica a análise em torno da jornada do cliente pode ser chamada de 'análise de jornada'. Por exemplo, se um cliente navegando pelo site da loja eletrônica da empresa A fizer login com suas credenciais, fizer uma compra e, então, ligar para a central de atendimento ao cliente da empresa A dentro de um certo período a partir daquela ação de compra on-line, haverá uma alta probabilidade de que o cliente esteja ligando sobre aquela compra on-line (por exemplo, consultar por que o item não foi enviado, atualizar para entrega em 24 horas, cancelar o pedido, etc.). Todas as interações feitas pelo cliente nesse exemplo compreendem uma jornada. Uma plataforma de 'análise de jornada' pode ser usada para analisar a jornada de ponto a ponto de um cliente através de interações com uma dada entidade (por exemplo, um site da web, um negócio, uma central de contatos, uma IVR) ao longo de um período de tempo.

[0024] A capacidade de determinar antecipadamente se a maioria das ligações feitas pela central de suporte do cliente é sobre consultas de envio pode fornecer à Empresa A a oportunidade de tomar medidas proativas como enviar uma notificação aos clientes através de um canal (por exemplo, e-mail, SMS, retorno de chamada, etc.). Nesse exemplo, a Empresa A pode enviar uma confirmação de pedido, números de rastreamento e/ou possibilidades para atualizar os métodos de envio.

[0025] Reconhecer o momento da jornada de um cliente e executar ações proativamente pode fornecer melhores serviço de atendimento ao cliente e resultados. A necessidade de relatar visual e estatisticamente a sucessão de eventos conforme um cliente progride através de estágios também

7 / 41 é importante para uma empresa que planeja seus recursos através da previsão de demanda e carga de trabalho dos recursos. Sistemas de central de contatos

[0026] A Figura 1 é um diagrama ilustrando uma modalidade de uma infraestrutura de comunicação, indicada genericamente por 100. Por exemplo, a Figura 1 ilustra um sistema para dar suporte a uma central de contatos no fornecimento de serviços de central de contatos. A central de contatos pode ser uma instalação interna a um negócio ou empresa para servir à empresa no desempenho das funções de vendas e serviço relacionados aos produtos e serviços disponíveis através da empresa. Em um outro aspecto, a central de contatos pode ser operada por um fornecedor de serviços terceirizado. Em uma modalidade, a central de contatos pode operar como um sistema híbrido, no qual alguns componentes do sistema de central de contatos são hospedados nas instalações da central de contatos e outros componentes são hospedados remotamente (por exemplo, em um ambiente baseado em nuvem). A central de contatos pode ser implantada em equipamento dedicado à empresa ou ao fornecedor de serviços terceirizado, e/ou implantada em um ambiente de computação remoto como, por exemplo, um ambiente de nuvem privado ou público com infraestrutura para dar suporte a múltiplas centrais de contatos para múltiplas empresas. Os vários componentes do sistema de central de contatos podem também ser distribuídos por várias localizações geográficas e ambientes de computação, e não necessariamente contidos em um único local, ambiente de computação ou mesmo dispositivo de computação.

[0027] Os componentes da infraestrutura de comunicação indicados genericamente por 100 incluem: uma pluralidade de dispositivos de usuário final 105A, 105B, 105C; uma rede de comunicações 110; um comutador/gateway de mídia 115; um controlador de chamada 120; um servidor IMR 125; um servidor de roteamento 130; um dispositivo de armazenamento 135; um servidor de estatísticas 140; uma pluralidade de

8 / 41 dispositivos de agente 145A, 145B, 145C que compreendem workbins 146A, 146B, 146C, um dos quais pode ser associado a um administrador da central de contatos ou supervisor 145D; um servidor de multimídia/mídia social 150; servidores web 155; um servidor iXn 160; um UCS 165; um servidor de emissão de relatórios 170; e serviços de mídia 175.

[0028] Em uma modalidade, o sistema de central de contatos gerencia recursos (por exemplo, equipes, computadores, equipamentos de telecomunicação etc.) para possibilitar a prestação de serviços via telefone ou outros mecanismos de comunicação. Esses serviços podem variar dependendo do tipo de central de contatos, e podem se estender do atendimento ao cliente a help desk, resposta a emergências, telemarketing, registro de pedidos etc.

[0029] Clientes, potenciais clientes ou outros usuários finais (coletivamente chamados de clientes ou usuários finais) que desejem receber serviços da central de contatos podem iniciar comunicações de entrada (por exemplo, chamadas de telefonia, mensagens de e-mail, bate-papos, etc.) com a central de contatos por meio de dispositivos de usuário final 105A, 105B e 105C (coletivamente citados como 105). Cada um dos dispositivos de usuário final 105 pode ser um dispositivo de comunicação convencional na técnica, como um telefone, telefone sem fio, smartphone, computador pessoal, tablete eletrônico, computador portátil etc., para citar alguns exemplos não limitadores. Os usuários operando os dispositivos de usuário final 105 podem iniciar, gerenciar e responder a chamadas telefônicas, mensagens de e-mail, bate-papos, mensagens de texto, sessões de navegação na web e outras transações multimídia. Embora três dispositivos de usuário final 105 sejam ilustrados em 100 por uma questão de simplicidade, qualquer número pode estar presente.

[0030] Comunicações de entrada e saída de e para os dispositivos de usuário final 105 podem percorrer uma rede 110, dependendo do tipo de dispositivo que estiver sendo usado. A rede 110 pode compreender uma rede

9 / 41 de comunicação de serviços de telefone, celular e/ou dados, e pode também compreender uma rede de telefonia comutada privada ou pública (PSTN - "Private or Public Switched Telephone Network"), uma rede de área local (LAN - "Local Area Network"), uma rede de longa distância (WAN - "Wide Area Network") privada e/ou uma WAN pública, como a Internet, para citar um exemplo não limitador. A rede 110 pode também incluir uma rede de operadora sem fio, inclusive uma rede de acesso múltiplo por divisão de código (CDMA - "Code Division Multiple Access"), uma rede de sistema global para comunicações móveis (GSM - "Global System for Mobile Communications"), ou qualquer rede/tecnologia sem fio convencional na técnica, incluindo, mas não se limitando a, 3G, 4G, LTE etc.

[0031] Em uma modalidade, o sistema de central de contatos inclui um comutador/gateway de mídia 115 acoplado à rede 110 para receber e transmitir chamadas de telefonia entre os usuários finais e a central de contatos. O comutador/gateway de mídia 115 pode incluir um comutador de telefonia ou um comutador de comunicação configurado para funcionar como um comutador central para roteamento em nível de agente dentro da central. O comutador pode ser um sistema de comutação por hardware ou um comutador implementado via software. Por exemplo, o comutador 115 pode incluir um distribuidor automático de chamadas, uma central de comunicação de ramal privado (PBX - "Private Branch Exchange"), um comutador de software baseado em IP e/ou qualquer outro comutador com hardware e software especializados, configurado para receber interações oriundas da Internet e/ou interações oriundas da rede telefônica provenientes de um cliente, e rotear essas interações para, por exemplo, um dispositivo de telefonia ou comunicação de um agente. Neste exemplo, o comutador/gateway de mídia estabelece uma trajetória/conexão de voz (não mostrada) entre o cliente fazendo a chamada e o dispositivo de telefonia do agente, mediante o estabelecimento, por exemplo, de uma conexão entre o

10 / 41 dispositivo de telefonia do cliente e o dispositivo de telefonia do agente.

[0032] Em uma modalidade, o comutador é acoplado a um controlador de chamadas 120 que pode, por exemplo, servir como um adaptador ou uma interface entre o comutador e o restante dos componentes de roteamento, monitoramento e outros componentes de manejo de comunicação da central de contatos. O controlador de chamada 120 pode ser configurado para processar chamadas PSTN, chamadas VoIP, etc. Por exemplo, o controlador de chamada 120 pode ser configurado com software de integração de telefonia por computador (CTI) para fazer interface com o comutador/gateway de mídia e o equipamento de central de contato. Em uma modalidade, o controlador de chamadas 120 pode incluir um servidor de protocolo de início de sessão (SIP - "Session Initiation Protocol") para processar chamadas de SIP. O controlador de chamadas 120 pode também extrair dados sobre a interação do cliente, como o número de telefone de quem fez a chamada (por exemplo, o número da identificação automática de número (ANI - "Automatic Number Identification")), o endereço de protocolo da internet (IP - "Internet Protocol"), ou o endereço de e-mail do cliente, e comunicar-se com outros componentes do sistema 100 no processamento da interação.

[0033] Em uma modalidade, o sistema 100 inclui adicionalmente um servidor de resposta interativa por mídia (IMR - "Interactive Media Response") 125. O servidor IMR 125 pode também ser chamado de um sistema de autoajuda, um assistente virtual, etc. O servidor IMR 125 pode ser similar a um servidor de resposta de voz interativa (IVR - "Interactive Voice Response"), exceto pelo fato de que o servidor IMR 125 não está restrito a voz e, adicionalmente, pode cobrir uma variedade de canais de mídia. Em um exemplo ilustrando a voz, o servidor de IMR 125 pode estar configurado com um roteiro de IMR para perguntar a clientes sobre suas necessidades. Por exemplo, uma central de contatos para um banco pode dizer aos clientes por

11 / 41 meio do roteiro de IMR para 'pressionar 1' se desejarem obter o saldo de sua conta. Por meio de interação continuada com o servidor de IMR 125, os clientes podem ser capazes de concluir o serviço sem precisar falar com um agente. O servidor de IMR 125 pode também fazer uma pergunta em aberto, como "Como posso ajudar?" e o cliente pode dizer ou, de outro modo, inserir uma razão para entrar em contato com a central de contatos. A resposta do cliente pode ser usada por um servidor de roteamento 130 para rotear a chamada ou a comunicação a um recurso adequado da central de contatos.

[0034] Se a comunicação se destina a ser roteada para um agente, o controlador de chamadas 120 interage com o servidor de roteamento (também chamado de servidor de orquestração) 130 para encontrar um agente adequado para o processamento da interação. A seleção de um agente adequado para roteamento de uma interação de entrada pode ser baseada, por exemplo, em uma estratégia de roteamento empregada pelo servidor de roteamento 130, e adicionalmente baseada em informações sobre disponibilidade do agente, habilidades e outros parâmetros de roteamento fornecidos, por exemplo, por um servidor de estatísticas 140.

[0035] Em uma modalidade, o servidor de roteamento 130 pode consultar uma base de dados de clientes que armazena informações sobre clientes existentes, como informações de contato, requisitos do acordo de nível de serviço (SLA - "Service Level Agreement"), natureza dos contatos anteriores do cliente e ações executadas pela central de contatos para resolver quaisquer questões do cliente, etc. A base de dados pode ser, por exemplo, Cassandra ou qualquer base de dados NoSQL, e pode ser armazenada em um dispositivo de armazenamento em massa A base de dados pode também ser uma base de dados SQL e pode ser gerenciada por qualquer sistema de gerenciamento de base de dados como, por exemplo, Oracle, IBM DB2, Microsoft SQL Server, Microsoft Access, PostgreSQL, etc., para citar alguns exemplos não limitadores. O servidor de roteamento 130 pode consultar as

12 / 41 informações do cliente provenientes da base de dados de clientes por meio de um ANI ou qualquer outra informação coletada pelo servidor de IMR 125.

[0036] Uma vez que um agente adequado seja identificado como estando disponível para lidar com uma comunicação, pode ser feita uma conexão entre o cliente e um dispositivo de agente 145A, 145B e/ou 145C (coletivamente citados como 145) do agente identificado. Embora três dispositivos de agente sejam ilustrados na Figura 1 por uma questão de simplicidade, qualquer número de dispositivos pode estar presente. As informações coletadas sobre o cliente e/ou as informações de histórico do cliente podem também ser fornecidas ao dispositivo de agente para auxiliar o agente a melhorar a comunicação e, adicionalmente, fornecidas ao dispositivo de administrador/supervisor da central de contatos 145D para gerenciar a central de contatos, incluindo a composição da equipe para lidar com a carga de trabalho. Nesse sentido, cada dispositivo 145 pode incluir um telefone adaptado para chamadas telefônicas regulares, chamadas VoIP, etc. O dispositivo 145 pode incluir também um computador para se comunicar com um ou mais servidores da central de contatos e realizar o processamento de dados associado a operações de central de contatos, e para fazer interface com clientes por meio de voz e outros mecanismos de comunicação multimídia.

[0037] O sistema de central de contatos 100 pode também incluir um servidor de multimídia/mídias sociais 150 para participar em interações de mídia diferentes de interações de voz com os dispositivos de usuário final 105 e/ou os servidores web 155. As interações de mídia podem estar relacionadas, por exemplo, a e-mail, vmail (correio de voz através de e-mail), bate-papo, vídeo, mensagens de texto, web, mídias sociais, conavegação, etc. O servidor de multimídia/mídia social 150 pode assumir a forma de qualquer roteador de IP convencional na técnica com hardware e software especializados para receber, processar e encaminhar eventos de multimídia.

[0038] Os servidores web 155 podem incluir, por exemplo, hosts de

13 / 41 sites de interação social para vários sites de interação social conhecidos, nos quais um usuário final pode se inscrever, como Facebook, Twitter, Instagram etc., para citar alguns exemplos não limitadores. Em uma modalidade, embora os servidores web 155 sejam representados como parte do sistema da central de contatos 100, os servidores web podem também ser fornecidos por terceiros e/ou mantidos fora das instalações da central de contatos. Os servidores web 155 podem também fornecer páginas web à empresa que está sendo apoiada pelo sistema de central de contatos 100. Os usuários finais podem navegar as páginas web e obter informações sobre os produtos e serviços da empresa. As páginas web podem também fornecer um mecanismo para entrar em contato com a central de contatos através, por exemplo, de bate-papo via web, chamada de voz, mensagem de e-mail, comunicação em tempo real via web (WebRTC - "Web Real-Time Communication"), etc. Widgets podem ser empregados nos sites da web hospedados nos servidores web.

[0039] Em uma modalidade, interações/atividades adiáveis podem também ser roteadas para os agentes da central de contatos, em adição às interações em tempo real. As interações/atividades adiáveis podem compreender trabalho de retaguarda ou trabalho que pode ser executado offline, como responder a e-mails, cartas, comparecer a treinamento ou outras atividades que não envolvam comunicação em tempo real com um cliente. Um servidor de interação (iXn) 160 interage com o servidor de roteamento 130 para selecionar um agente adequado para lidar com a atividade. Uma vez atribuída a um agente, uma atividade pode ser passada ao agente, ou pode aparecer no workbin 146A, 146B, 146C (coletivamente 146) do agente sob a forma de uma tarefa a ser concluída pelo agente. O workbin do agente pode ser implementado através de qualquer estrutura de dados convencional na técnica, como, por exemplo, uma lista vinculada, matriz, etc. Em uma modalidade, um workbin 146 pode ser mantido, por exemplo, na memória

14 / 41 buffer de cada dispositivo de agente 145.

[0040] Em uma modalidade, os um ou mais dispositivos de armazenamento em massa 135 podem armazenar uma ou mais bases de dados relacionadas aos dados do agente (por exemplo, perfis de agente, cronogramas etc.), dados do cliente (por exemplo, perfis de cliente), dados de interação (por exemplo, detalhes de cada interação com um cliente incluindo, mas não se limitando a: motivo para a interação, dados de disposição, tempo de espera, tempo de manejo, etc.) e similares. Em uma outra modalidade, alguns dos dados (por exemplo, dados de perfil do cliente) podem ser mantidos em uma base de dados de gerenciamento de relações com o cliente (CRM - "Customer Relations Management") hospedada no dispositivo de armazenamento em massa 135 ou em outro lugar. O dispositivo de armazenamento em massa 135 pode estar sob a forma de um disco rígido ou conjunto de discos, conforme é convencional na técnica.

[0041] Em uma modalidade, o sistema de central de contatos pode incluir um servidor de contato universal (UCS - "Universal Contact Server") 165, configurado para recuperar informações armazenadas na base de dados de CRM e direcionar informações a serem armazenadas na base de dados de CRM. O UCS 165 pode também estar configurado para facilitar a manutenção de um histórico das preferências interações dos clientes, e para capturar e armazenar dados referentes a comentários de agentes, histórico de comunicação do cliente etc.

[0042] O sistema de central de contatos pode também incluir um servidor de emissão de relatórios 170 configurado para gerar relatórios a partir de dados agregados pelo servidor de estatísticas 140. Tais relatórios podem incluir relatórios em tempo quase real ou relatórios históricos relacionados ao estado de recursos, como, por exemplo, tempo de espera médio, taxa de abandono, ocupação de agente, etc. Os relatórios podem ser gerados automaticamente ou em resposta a solicitações específicas de um

15 / 41 solicitante (por exemplo, agente/administrador, aplicativo de central de contatos, etc.).

[0043] O sistema de central de contato pode incluir também um servidor de gerenciamento de força de trabalho (WFM - "Workforce Management") 180. O servidor WFM sincroniza automaticamente os dados de configuração e age como a principal fonte de dados e serviços de aplicativo e localizador para clientes WFM. O servidor WFM 180 suporta um aplicativo de GUI que pode ser acessado a partir de qualquer um dos dispositivos de agente 145 e um dispositivo de administrador/supervisor da central de contato 145D para gerenciar a central de contato, incluindo acessar a plataforma de análise de jornada da central de contato. O servidor WFM 180 se comunica com o servidor de estatísticas 140 e pode também se comunicar com um servidor de configuração para fins de configuração (não mostrado). Em uma modalidade, o servidor WFM 180 pode também estar em comunicação com um agregador de dados 184, um construtor 185, um servidor web 155 e um daemon 182. Isso é descrito com mais detalhes com referência à Figura 2 abaixo.

[0044] Cada um dentre os vários servidores da Figura 1 pode incluir um ou mais processadores executando instruções de programa de computador e interagindo com outros componentes do sistema para executar as várias funcionalidades aqui descritas. As instruções de programa de computador são armazenadas em uma memória implementada com o uso de um dispositivo de memória padrão como, por exemplo, uma memória de acesso aleatório (RAM - "Random-Access Memory"). As instruções de programa podem também ser armazenadas em outra mídia legível por computador não transitória, tais como, por exemplo, um CD-ROM, uma unidade flash, etc. Embora a funcionalidade de cada um dos servidores seja descrita como sendo fornecida pelo servidor específico, o versado na técnica reconhecerá que a funcionalidade de vários servidores pode ser combinada ou integrada em um

16 / 41 único servidor, ou a funcionalidade de um servidor específico pode ser distribuída entre um ou mais outros servidores sem que se afaste do escopo das modalidades da presente invenção.

[0045] Em uma modalidade, os termos "interação" e "comunicação" são usados de forma intercambiável, e se referem, de modo geral, a qualquer interação, em tempo real ou não, que use qualquer canal de comunicação incluindo, sem limitação, chamadas de telefone (chamadas por PSTN ou VoIP), e-mails, v-mails, vídeo, bate-papo, compartilhamento de tela, mensagens de texto, mensagens de mídias sociais, chamadas por WebRTC, etc.

[0046] Os serviços de mídia 175 podem fornecer serviços de áudio e/ou vídeo para dar apoio às características da central de contatos, como solicitações por um sistema de IVR ou IMR (por exemplo, reprodução de arquivos de áudio), conter músicas, mensagens de voz/gravações com um único participante, gravações com múltiplos participantes (por exemplo, de chamadas de áudio e/ou de vídeo), reconhecimento de fala, reconhecimento de tons duplos de múltiplas frequências (DTMF - "Dual Tone Multi Frequency"), fax, transcodificação de áudio e vídeo, protocolo de transporte seguro em tempo real (SRTP - "Secure Real-Time Transport Protocol"), audioconferência, videoconferência, treinamento (por exemplo, suporte para que um treinador possa acompanhar ouvindo uma interação entre um cliente e um agente, e para que o treinador forneça comentários ao agente sem que o cliente ouça os comentários), análise de chamada e detecção de palavra- chave.

[0047] Em uma modalidade, o produto de plataforma baseado em instalações pode fornecer acesso a e controle de componentes do sistema 100 através de interfaces de usuário (IUs) presentes nos dispositivos de agente 145A a 145C. Dentro do produto de plataforma baseada em instalações, o programa gerador de aplicativo gráfico pode ser integrado, o que permite que

17 / 41 um usuário escreva os programas (manipuladores) que controlam vários comportamentos de processamento de interação dentro do produto de plataforma baseada em instalações.

[0048] Conforme observado acima, a central de contatos pode operar como um sistema híbrido no qual alguns ou todos os componentes são hospedados remotamente, como em um ambiente baseado em nuvem. Por uma questão de conveniência, serão descritos a seguir aspectos das modalidades da presente invenção relativos ao fornecimento de ferramentas modulares de um ambiente baseado em nuvem para componentes alojados nas instalações.

[0049] A Figura 2 é um diagrama que ilustra uma modalidade de uma arquitetura de gerenciamento de força de trabalho, indicada genericamente por 100. Os componentes podem incluir: dispositivo de supervisor 145D, dispositivo de agente 145, servidor web 155, servidor WFM 180, daemon 181, API 182, agregador de dados 183, construtor 184, dispositivo de armazenamento 135 e servidor de estatísticas 140.

[0050] O servidor web 155 compreende um aplicativo de servidor que pode ser hospedado em um contêiner de servlet e fornece conteúdo para uma pluralidade de interfaces de usuário baseadas em navegador web, (por exemplo, uma IU pode ser para um agente e outra IU pode ser para um supervisor). A interface apropriada é aberta após o login. A IU de supervisor permite que o supervisor acesse recursos como gerenciamento de calendário, previsão, programação, adesão do agente em tempo real, estatísticas de desempenho da central de contato, configuração de notificações de e-mail e emissão de relatórios. A IU de agente permite que um agente distribua informações de programação (por exemplo, um gerente para funcionários) e fornece agentes com capacidades de programação proativas, como inserir preferências de programação, planejar horas de folga, programar ofertas, negociação, etc.

18 / 41

[0051] O servidor WFM 180 sincroniza automaticamente os dados de configuração e age como a principal fonte de dados e serviços de aplicativo e localizador para clientes WFM. O servidor WFM 180 é um hub, conectando- se ou sendo conectado aos outros componentes na arquitetura.

[0052] O Daemon WFM 181 é um daemon configurável para enviar notificações por e-mail a agentes e supervisores. A API 182 pode facilitar integrações, alterações em objetos e recuperação de informações entre o servidor web 155 e o servidor WFM 180.

[0053] O agregador de dados 183 coleta dados de histórico do servidor de estatísticas 140 e fornece informações de adesão ao agente em tempo real ao dispositivo de supervisor 145D através do servidor WFM 180. Através da conexão do agregador de dados 183 ao servidor de estatísticas 140, ele serve como um único ponto de interação entre a arquitetura WFM e a central de contato 100. O construtor 184 constrói cronogramas usando informações do agregador de dados 183.

[0054] O servidor web 155 serve o conteúdo para os aplicativos de GUI baseados em navegador web e gera relatórios mediante solicitação dos usuários do dispositivo de supervisor 145D. O servidor WFM 180, daemon 181, agregador de dados 183, construtor 184 e servidor web 155 suportam os aplicativos de GUI. A base de dados 135 armazena todos os dados relevantes de configuração, previsão, programação, aderência de agente, desempenho e histórico. Os componentes da arquitetura WFM podem se conectar diretamente à base de dados ou indiretamente à mesma através do servidor WFM 180, conforme ilustrado na Figura 2. A arquitetura WFM pode operar em ambientes de um único local ou em empresas multilocais.

[0055] A Figura 3 é um fluxograma que ilustra uma modalidade de um processo para criar um modelo para previsão de demanda de carga de trabalho, indicado genericamente por 300. O modelo pode ser usado pelo servidor WFM 180 para gerar previsões de demanda de carga de trabalho para

19 / 41 o ambiente da central de contato 100, e saída usada pelo supervisor/administrador para alocar recursos na central de contato.

[0056] Na operação 305, os dados de histórico são extraídos. A extração pode ser realizada por código escrito para produzir os dados desejados. O código extrator funciona de dentro da aplicação de gerenciamento de força de trabalho (Figura 2) e pode ser utilizado por meio de um botão na interface de usuário. O extrator extrai da base de dados 135 o objeto de documento de informações de estágio (semelhante a uma tabela em uma base de dados). O filtro usado pelo extrator é o mesmo especificado pelo usuário acima. O extrator de dados pode ser acionado por uma ação do usuário no front-end, conforme descrito, ou pode também ser acionado a partir do back-end. Por exemplo, o extrator pode residir como um serviço em lotes no back-end disparado pelo trabalho CRON programado e os dados a serem fornecidos podem ser armazenados em um ponto final como um armazenamento de objeto em nuvem como Amazon S3. Em outro exemplo, o extrator pode residir como um serviço em lotes no back-end disparado por uma solicitação em fila proveniente de outro serviço.

[0057] Os dados de histórico têm vários requisitos. Por exemplo, os níveis de estágios precisam ser o proxy mais próximo da carga de trabalho dos agentes porque o objetivo final da previsão de demanda é o planejamento de capacidade, incluindo: a carga de trabalho que será gerada a partir do volume de interações conforme o cliente progride ao longo dos estágios, e os recursos (por exemplo, agentes Equivalentes de Tempo Completo (FTE - "Full Time Equivalent")) necessários para lidar com a carga de trabalho a fim de entregar certos alvos métricos de KPI (por exemplo, nível de serviço, NPS, abandono). Em uma modalidade, os dados analíticos de jornada a serem extraídos precisam estar no nível do filtro que emite estágios que usa proximamente um proxy no tempo que o agente (ou agentes) realmente gasta no atendimento dos estágios. Isso pode ser feito na plataforma ou no tipo de

20 / 41 evento e pode ser especificado por um usuário através de uma interface de usuário. Os níveis de estágio podem ser predefinidos por um administrador e são personalizáveis pelo usuário. Em uma modalidade, os níveis de estágio são um ponto focal da jornada do cliente e suas transições de cada estado na jornada. Eles podem depender dos objetivos de quais informações devem ser obtidas a partir da jornada do cliente. Também pode haver múltiplas trajetórias dentro da jornada. Os estágios predefinidos podem compreender também agrupamentos de ações e qualquer número de ações pode estar dentro de um estágio. Em uma modalidade, os níveis dos estágios extraídos podem não estar ligados ao tempo de um agente. Em vez disso, os níveis de estágio extraídos podem estar ligados a ações tomadas dentro do estágio. Por exemplo, conforme um cliente progride através de estágios, uma ação pode ser enviar uma amostra de produto àquele cliente quando o estágio estiver concluído na jornada.

[0058] Os dados de histórico devem conter elementos de dados necessários, incluindo: o nome do tipo de jornada, o ID do tipo de jornada, o ID do cliente, estágio, sequência, data de estado, data de término e lapso de tempo. O nome do tipo de jornada é um tipo de dado de cadeia de caracteres que descreve o tipo de jornada, por exemplo, uma "Solicitação de Carga". O ID do tipo de jornada é um tipo de dado de cadeia de caracteres que compreende um ID exclusivo que identifica o tipo de jornada. O ID do cliente é um tipo de dado de cadeia de caracteres que compreende um ID exclusivo que identifica o cliente. O estágio é um tipo de dado de cadeia de caracteres que compreende o nome do estágio. Esse campo pode ser dinâmico dependendo do filtro da estratégia de identificação escolhida por um usuário. A sequência é um tipo de dado de número inteiro que compreende o número do estágio no qual o cliente está. Por exemplo, o primeiro estágio pode começar com zero e o próximo estágio é 1.

[0059] Um estágio pode ser uma porção da jornada do cliente que é

21 / 41 personalizável para uma empresa com base em partes identificadas de uma jornada que são de interesse (por exemplo, preencher um formulário, executar uma verificação de crédito, processamento de aplicativos, pagamento, etc.) e ocorrer em sequências numeradas que podem variar em ordem dependendo da preferência. Um estágio pode ser um estágio intermediário em uma jornada, mas em outra jornada, esse mesmo estágio pode ser uma 'sequência zero'.

[0060] A data de início é um tipo de dado de data que compreende a data/hora de início quando um cliente inicia um estágio específico, por exemplo, 23/12/15 00:00 ou 19/01/16 14:20. A data de término é um tipo de dado de data que compreende a data/hora de término quando um cliente termina/sai de um estágio específico, por exemplo, 06/01/16 00:00 ou 24/01/16 18:56. O lapso de tempo pode ser um tipo de dado de número inteiro que compreende o número de segundos entre a data de término e a data de início. Este precisa ser um número positivo, já que a data de término é sempre maior ou igual à data de início.

[0061] Em uma modalidade, a saída de dados de histórico pode estar no formato CSV ou arquivo/fluxo JSON com codificação UTF-8 e precisa ser capaz de ser "desesterilizado" de volta à classe Python e Java.

[0062] Os dados de histórico devem, também, compreender marcações distintas para quando um cliente abandonar uma jornada em um estágio específico. O controle é passado para a operação 310 e o processo 300 continua.

[0063] Na operação 310, os dados de histórico são pré-processados. O pré-processamento compreende vários cálculos preliminares que são realizados com base nos dados de histórico. A saída das etapas de pré- processamento é usada no algoritmo do processo de previsão de estágios. O pré-processamento compreende derivar gráficos de adjacência, derivar sequências zero (incluindo o cálculo da taxa de abandono e gerar previsões de volume para cada estágio de sequência zero), e derivar históricos de estágios.

22 / 41

[0064] Na primeira etapa de pré-processamento, são derivados gráficos de adjacência. Para capturar a relação entre momentos de jornada, podem ser usadas representações gráficas que modelam conexões entre estágios na plataforma. Cada momento de jornada é uma sequência ou um estágio através do qual os clientes progridem do início ao fim. A Figura 4A é uma representação gráfica direcionada de uma modalidade de uma jornada, indicada genericamente por 400. Na Figura 4A, o estágio de origem de toda a jornada é representado como v0 enquanto o estágio de término é representado como v5. Estágios intermediários (ou de transição) são representados como v1, v2, v3 e v4 pelos quais o cliente pode passar durante a jornada. Estados de abandono também estão associados a cada estágio para agrupar clientes que, após certos períodos de tempo, supõe-se, abandonam a jornada e saem do estágio. As setas entre os estágios representam conexões na análise e podem ser modeladas com gráficos de adjacência. Os gráficos de adjacência modelam as bordas e os nós imediatos (pré-adjacentes e pós-adjacentes) em relação a um estágio específico. Cada nó pré-adjacente terá seus próprios nós pré-adjacentes e pós-adjacentes a ele conectados. Os nós pós-adjacentes também têm suas próprias conexões de nós pré- e pós-adjacentes. Todas as conexões no gráfico podem ser deduzidas por iteração através da lista de gráficos de adjacência, começando a partir do estágio pré-adjacente mais à esquerda e, então, até seus nós pós-adjacentes até os próximos nós pós- adjacentes, e assim por diante. As Figuras 4B e 4C são exemplos de gráficos adjacentes da jornada do cliente ilustrada na Figura 4A. Na Figura 4B, não há nós pré-adjacentes para o estágio v0 e esse está vazio. Os nós pós-adjacentes a v0 são v1 e v2. Na Figura 4C, representando o estágio v3, v1 é um nó pré- adjacente. Nós pós-adjacentes em v3 são v4 e v5. Embora apenas dois gráficos adjacentes sejam mostrados por uma questão de simplicidade, outros são possíveis na jornada 400. Em outros exemplos da jornada do cliente 400, o estágio v1 pode ter v0 como um nó pré-adjacente e v3 como um nó pós-

23 / 41 adjacente. O estágio v2 pode ter v0 como um nó pré-adjacente e v4 como um nó pós-adjacente. O estágio v4 pode ter os estágios v2 e v3 como nós pré- adjacentes e v5 como um nó pós-adjacente. O estágio v5 pode ter os estágios v3 e v4 como nós pré-adjacentes e nenhum nó pós-adjacente. Gráficos de adjacência podem ser preenchidos para cada estágio em uma jornada.

[0065] Em outra etapa de pré-processamento, são derivadas sequências zero. As sequências zero podem ser descritas como o estágio em que um cliente inicia sua jornada. Este é o primeiro estágio na progressão das sequências. Um estágio pode ser um estágio intermediário em uma jornada, mas em outra jornada, esse mesmo estágio pode ser uma sequência zero. Portanto, ser um estágio de sequência zero não impede a possibilidade de se tornar um estágio intermediário. A Figura 5 é um fluxograma que ilustra uma modalidade de um processo para derivar sequências zero, indicado genericamente por 500. As sequências zero e suas informações são derivadas dos dados de histórico extraídos da seguinte forma.

[0066] Uma previsão de duração de um período de tempo desejado T é definida em 502. Isso compreende quão antecipadamente as previsões são desejadas. Todas as 'sequências=0' distintas são identificadas a partir dos dados de histórico e salvas na lista de sequência zero. Para cada estágio na lista de sequência zero, o carimbo de data/hora das chamadas/interações de dados de histórico é obtido e salvo como uma série temporal 504. Simultaneamente, a partir dos dados de histórico, para cada estágio na lista de sequência zero, as durações médias dos clientes gastas nesse estágio são determinadas para todas as interações 506. Então, para cada estágio da lista de sequência zero, as durações de desvio padrão dos clientes gastas nesse estágio são determinadas 508. O 'limiar de duração de abandono' é então determinado para cada estágio na lista de sequência zero 510. Isso pode ser determinado com o uso da seguinte relação:

24 / 41

[0067] em que k pode ser qualquer valor entre 1,0 e positivo infinito, dependendo de quão agressivos os algoritmos precisam ser para categorizar/marcar uma interação como sendo abandonada (a partir do agrupamento de interação regular) que esperou 'tempo demais'.

[0068] Para cada estágio na lista de sequência zero, é marcada a interação (ou interações) que tiver uma duração maior que a 'duração de limiar de abandono' 512 definida. Essas interações que são marcadas são contadas como 'abandonadas'. Então, é contado o número total de interações marcadas como abandonadas para cada estágio na lista de sequência zero 514.

[0069] A taxa de abandono é, em seguida, determinada para cada estágio na lista de sequência zero 516. Isso pode ser representado pela seguinte relação:

[0070] O histórico de volume total líquido (518) é determinado para cada estágio na lista de sequência zero com o uso da seguinte relação: histórico de volume líquido para o estágio = histórico de volume total do estágio *(1-taxa de abandono do estágio )

[0071] Finalmente, o mecanismo de previsão de demanda pode ser executado com o uso do volume total líquido como histórico (dados de treinamento para o modelo de previsão) 520. Para cada estágio na lista de sequência zero, são obtidos os resultados da previsão da série temporal de volume de sequência e tempo. Os resultados do cálculo são armazenados como sequências zero 522. O mecanismo toma os dados de histórico da série temporal a serem previstos (por exemplo, volume de interação) e realiza a engenharia de recursos nos dados, incluindo resumo e agregação de dados, limpeza de dados (imputação de dados faltantes, zeros anteriores e posteriores, etc.), detecção de exceção, detecção de padrão, e seleção do melhor método para uso dado o padrão (ou padrões) encontrado que minimiza

25 / 41 o erro de previsão por meio de validações cruzadas.

[0072] Múltiplas hierarquias de dimensão de tempo podem ser previstas a fim de se obter melhor precisão, isto é, semanalmente, diariamente, de hora em hora e granularidade de 5/15/30 minutos. A previsão de granularidade mais baixa (por exemplo, semanalmente) é usada como a linha de base para previsão de granularidade mais alta por meio de distribuição como distribuição de valores previstos diariamente, horários e granularidade mais alta subsequente com o uso de distribuições previstas conectando os dados de nível de granularidade baixo a alto. Múltiplas metodologias estatísticas de previsão comumente usadas, como ARIMA ou Holt-Winter, podem ser consideradas juntamente com aquelas personalizadas e proprietárias. O melhor método é selecionado usando validação cruzada com múltiplas dobras. Os critérios a serem usados podem ser baseados no escore do cliente que é uma combinação de precisão e precisão geral do horizonte.

[0073] Em outra etapa de pré-processamento, os históricos de estágios são derivados dos dados de histórico extraídos. Cada estágio tem sua própria propriedade de histórico de estágio compreendendo: contagem de vetor de histórico, taxa de abandono e matriz de vetor de probabilidade. Todos os estágios têm volume histórico 'entrando' e/ou 'saindo' de todos os estágios, o que pode ser resumido em uma representação de matriz ou vetor de contagem de volume. Cada estágio pode também ter uma porcentagem de seu volume histórico que entra no estágio, mas não progride para estágios adjacentes subsequentes. Isto é contado para o abandono daquele estágio. A Figura 6 é um fluxograma que ilustra uma modalidade de um processo para derivar histórico de estágio, indicado genericamente por 600.

[0074] Os estágios distintos são identificados 602. As séries temporais de volume diário são preenchidas para cada estágio 604. A duração média para cada estágio é determinada 606. O desvio padrão para todas as durações

26 / 41 de interação é determinado para cada estágio 608. O limiar de duração de abandono é determinado para cada estágio 610. É marcada a interação (ou interações) que tiver uma duração maior que a 'duração de limiar de abandono' 612 definida. O total de abandonos é determinado para cada estágio 614. A taxa de abandono é, então, calculada para cada estágio 616. Isso pode ser feito com o uso da seguinte relação:

[0075] A série temporal de volume diário para cada combinação de estágio a estágio é preenchida 618. Como esses volumes que entram e saem de um estágio podem ocorrer ao longo do tempo (diariamente, por exemplo), estes são representáveis como dados da série temporal. Os vetores de probabilidade (620) são determinados com o uso da seguinte relação:

[0076] Os vetores e as taxas de abandono são armazenados como histórico de estágio para cada estágio na jornada. Os vetores são usados para popular a matriz de vetor de probabilidade para cada combinação de estágios de-para em toda a jornada com o uso dos resultados de gráficos de adjacência determinados anteriormente. O controle é passado para a operação 315 e o processo 300 continua.

[0077] Na operação 315, algoritmos de liberação são executados. A operação 310 precisa ser executada antes que a operação 315 possa ser executada. Com referência à Figura 4A, uma jornada exemplificadora pode compreender os estágios v0, v1, v3 e v5. Os vetores de probabilidade podem ser derivados a partir dessa jornada, por exemplo:

[0078] O vetor A pode ser uma representação do estágio v0 ao estágio v1. O vetor B pode ser uma representação do estágio v1 ao estágio v3. O vetor C pode ser uma representação do estágio v3 ao estágio v5. Do estágio v0 ao estágio v1, as interações podem ter aguardado 1 dia antes que 100% das

27 / 41 mesmas se movam para o estágio v1. A partir do estágio v1, nenhuma interação se move para o estágio v3 em um dia. Em vez disso, 100% das interações se movem para o estágio v3 no segundo dia. A partir do estágio v3, nenhuma interação se move para o estágio v5 em um dia. 50% de interações podem se mover do estágio v3 para o estágio v5 no segundo dia e 50% podem se mover no terceiro dia. A Figura 7 é um fluxograma que ilustra uma modalidade de um processo para liberação de demanda, indicada genericamente por 700. Um comprimento de previsão é primeiro determinado

702. Neste exemplo, é gerada uma previsão de 9 dias. A data de início da previsão é então definida 704, que, para este exemplo, começa do índice de dia 0 ao índice de dia 8. A iteração i=0 é definida 706. As iterações dos algoritmos de liberação podem ser ilustradas da seguinte forma:

[0079] Iteração n° 0: todos os estágios pré-processados são executados a partir do mecanismo de previsão durante o algoritmo de sequência zero para obter os volumes previstos para os estágios v0, 708. Em uma modalidade, para cada estágio da sequência zero, a previsão de volume e o abandono líquido de previsão de volume são obtidos a partir da sequência zero. Cinco dias de dados de histórico para cada uma das etapas v0, v1, v3 e v5 são usados para obter as previsões para o estágio 710. As previsões de estágio são definidas com valores da sequência zero.

[0080] É determinado se todas as iterações foram executadas para o comprimento da previsão. Especificamente, neste exemplo, as mesmas não foram, e, portanto, a iteração é incrementada em 1 714 e todos os estágios são processados 732 com o próximo estágio não processado definido para o estágio de processamento atual 718. As previsões de estágio a partir de iterações anteriores são obtidas e clonadas para a previsão de estágio 720a da iteração, e, então, o abandono líquido de previsão de volume é determinado para cada estágio na iteração 722a. Os vetores históricos para o histórico de estágio (a partir dos algoritmos de pré-processamento) são obtidos

28 / 41 simultaneamente 720b e todo o histórico de estágio é submetido a loop com os vetores históricos obtidos 722b. Os vetores de probabilidade são obtidos a partir do histórico de estágio 724. Então, cada ponto da série temporal do abandono líquido de previsão de volume é submetido a loop e o tempo de lapso é determinado como a diferença entre o carimbo de data e hora e a data de início da previsão 726a. Se o tempo de lapso corresponder ao índice de tempo de vetor de probabilidade e o destino corresponder ao estágio atual, o volume é liberado multiplicando-se o valor de volume pelo valor de probabilidade 728a. Simultaneamente, o tempo de lapso usando-se vetores históricos também é determinado 726b e o volume é liberado 728b para determinar o tempo de lapso, cada ponto da série temporal dos vetores históricos é submetido a loop e o tempo de lapso é determinado como a diferença entre o carimbo de data e hora da série temporal e a data de início da previsão. Se esse valor aguardou até um período de tempo específico e uma porção, se não todo, o volume for elegível para ser liberada (determinado pela distribuição de vetor de probabilidade), então ela é liberada. O valor liberado para a iteração atual é armazenado na matriz de previsão de estágio

730. Se todos os estágios tiverem sido processados (732), e todas as iterações no comprimento da previsão tiverem sido passadas (712), então a matriz de previsão de estágio final é obtida 734. A matriz de previsão de estágio final deve conter o estado final de volumes para todos os estágios, por todo o período de previsão, começando a partir da data de previsão. Continuando com o exemplo acima, o texto a seguir descreve o processamento das iterações como pertencentes à jornada 400.

[0081] Iteração n° 1: as interações chegam ao estágio v0 no dia 0.

[0082] Iteração n° 2: as interações do estágio v0 dia n° 0 fluem para o estágio v1 dia n° 1 na proporção de 100%, de acordo com o vetor de probabilidade A. Os valores previstos do estágio v0 como um estágio da sequência zero são preenchidos.

29 / 41

[0083] Iteração n° 3: as interações do v0 dia n° 1 fluem para o estágio v1 dia n° 2 na proporção de 100%, de acordo com o vetor de probabilidade A. Os valores previstos do estágio v0 para o dia n° 2 como um estágio da sequência zero são preenchidos.

[0084] Iteração n° 4: as interações do fluxo do v0 dia no 2 para o estágio v1 dia n° 3 na proporção de 100%, de acordo com o vetor de probabilidade A. Os valores previstos do estágio v0 para o dia n° 3 como um estágio da sequência zero são preenchidos. As interações que estavam no estágio v1, dia n° 1, tendo gasto dois dias nesse estágio, são agora elegíveis para fluir completamente para o estágio v3 devido ao vetor de probabilidade B.

[0085] Iteração n° 5: as interações do v0 dia n° 3 fluem para o estágio v1 dia n° 4 na proporção de 100%, de acordo com o vetor de probabilidade A. Os valores previstos do estágio v0 para o dia n° 4 como um estágio da sequência zero são preenchidos. As interações que estavam no estágio v1, dia n° 2, tendo gasto dois dias nesse estágio, são agora elegíveis para fluir completamente para o estágio v3 devido ao vetor de probabilidade B.

[0086] Iteração n° 6: as interações do v0 dia n° 4 fluem para o estágio v1 dia n° 5 na proporção de 100%, de acordo com o vetor de probabilidade A. Os valores previstos do estágio v0 para o dia no 5 como um estágio da sequência zero são preenchidos. As interações que estavam no estágio v1, dia n° 3, tendo gasto dois dias nesse estágio, são agora elegíveis para fluir completamente para o estágio v3 devido ao vetor de probabilidade B. As interações que estavam no estágio v3, dia n° 3, tendo gasto dois dias nesse estágio, são agora elegíveis para fluir 50% para o estágio v5 devido ao vetor de probabilidade C.

[0087] Iteração n° 7: as interações do v0 dia n° 5 fluem para o estágio v1 dia n° 6 na proporção de 100%, de acordo com o vetor de probabilidade A. Os valores previstos do estágio v0 para o dia n° 6 como um estágio da

30 / 41 sequência zero são preenchidos. As interações que estavam no estágio v1, dia n° 4, tendo gasto dois dias nesse estágio, são agora elegíveis para fluir completamente para o estágio v3 devido ao vetor de probabilidade B. As interações que estavam no estágio v3, dia n° 4, tendo gasto dois dias nesse estágio, são agora elegíveis para fluir 50% para o estágio v5 devido ao vetor de probabilidade C. Adicionalmente, dos 50% de interações que estavam no estágio v3 no dia n° 3, tendo gasto três dias nesse estágio, 50% daquelas são agora elegíveis para também fluir para v5 devido ao vetor de probabilidade C.

[0088] Iteração no 8: as interações do v0 dia n° 6 fluem para o estágio v1 dia n° 7 na proporção de 100%, de acordo com o vetor de probabilidade A. Os valores previstos do estágio v0 para o dia n° 7 como um estágio da sequência zero são preenchidos. As interações que estavam no estágio v1, dia 5, tendo gasto dois dias nesse estágio, são agora elegíveis para fluir completamente para o estágio v3 devido ao vetor de probabilidade B. As interações que estavam no estágio v3, dia n° 5, tendo gasto dois dias nesse estágio, são agora elegíveis para fluir 50% para o estágio v5 devido ao vetor de probabilidade C. Adicionalmente, dos 50% de interações que estavam no estágio v3 no dia n° 4, tendo gasto três dias nesse estágio, 50% daquelas são agora elegíveis para também fluir para v5 devido ao vetor de probabilidade C.

[0089] Iteração n° 9: as interações do v0 dia n° 7 para o estágio v1 dia n° 8 na proporção de 100%, de acordo com o vetor de probabilidade A. Os valores previstos do estágio v0 para o dia n° 7 como um estágio da sequência zero são preenchidos. As interações que estavam no estágio v1, dia n° 6, tendo gasto dois dias nesse estágio, são agora elegíveis para fluir completamente para o estágio v3 devido ao vetor de probabilidade B. As interações que estavam no estágio v3, dia n° 6, tendo gasto dois dias nesse estágio, são agora elegíveis para fluir 50% para o estágio v5 devido ao vetor de probabilidade C. Adicionalmente, dos 50% de interações que estavam no estágio v3 no dia n° 5, tendo gasto três dias nesse estágio, 50% daquelas são

31 / 41 agora elegíveis para também fluir para v5 devido ao vetor de probabilidade C.

[0090] Por uma questão de simplicidade, o exemplo acima apresentou para a iteração de 0 a 9 dados de histórico ignorados antes do dia 0 (antes da data de início da previsão) a fim de transmitir a ideia de volumes de liberação através de múltiplos estágios e períodos. Com dados de histórico antes do dia n° 0, cada iteração precisa também considerar os volumes da série de dados de histórico e executar o mesmo processo de 'liberação de volume' nesses volumes: começar retrocedendo a partir da previsão dos dados iniciais menos um período, então menos dois períodos, menos três períodos, etc. Os mesmos vetores de probabilidade regem.

[0091] O controle é passado para a operação 320 e o processo 300 continua.

[0092] Na operação 320, o modelo é validado. Para validação, uma porção de dados de histórico é retida. Por exemplo, 10% podem ser retidos. Os outros 90% dos dados de histórico serão usados para treinar/construir o modelo. O modelo é então usado para gerar previsões que serão comparadas aos dados retidos. Os erros de previsão médios podem ser determinados e usados como KPI. A previsão pode ser determinada como o valor real subtraído do valor previsto. Isso é feito para cada ponto de dados. A média é então tomada ao longo de todos os pontos de dados para obter o erro de previsão médio. Uma validação cruzada é realizada na qual os dados de histórico retidos são de um período ou faixa diferente, e os dados de treinamento são de um subconjunto de períodos diferentes. Os erros de previsão médios também são determinados para cada um dos cenários de validação cruzada. O desvio padrão de erros também pode ser apresentado. O controle é passado para a operação 325 e o processo 300 continua.

[0093] Na operação 325, o modelo é calibrado e o processo termina. Uma vez concluída a etapa de validação, recalibrações do modelo de previsões devem ser executadas para minimizar erros de previsão. Isso pode

32 / 41 ser feito com o uso de quaisquer procedimentos padrão conhecidos na técnica.

[0094] Em uma modalidade, o modelo compreende carga de trabalho gerada a partir do volume de interações conforme um cliente progride através de estágios, e inclui abandonos previstos dentro da jornada do cliente. As previsões feitas com o uso do modelo incluem os recursos (por exemplo, agentes equivalentes em tempo integral) necessários para lidar com a carga de trabalho a fim de fornecer alvos métricos de KPI (por exemplo, nível de serviço, NPS, abandono) para a central de contatos. O modelo pode ser aplicado à plataforma de análise de jornada da central de contatos. Sistemas de computação

[0095] Em uma modalidade, cada um dos vários servidores, controles, comutadores, gateways, motores e/ou módulos (coletivamente chamados de servidores) nas figuras descritas é implementado via hardware ou firmware (por exemplo, ASIC) conforme será entendido pelo versado na técnica. Cada um dos vários servidores pode ser um processo ou thread, sendo executado em um ou mais processadores, em um ou mais dispositivos de computação (por exemplo, Figuras 8A, 8B), executando instruções de programa de computador e interagindo com outros componentes de sistema para executar as várias funcionalidades descritas na presente invenção. As instruções de programa de computador são armazenadas em uma memória, a qual pode ser implementada em um dispositivo de computação com o uso de um dispositivo de memória padrão como, por exemplo, uma memória RAM. As instruções de programa de computador podem também ser armazenadas em outras mídias legíveis por computador não transitórias como, por exemplo, um CD-ROM, um pen drive, etc. Um versado na técnica deve reconhecer que um dispositivo de computação pode ser implementado através de firmware (por exemplo, um circuito integrado para aplicação específica), hardware ou uma combinação de software, firmware e hardware. O versado na técnica reconhecerá que a funcionalidade de vários dispositivos de computação pode ser combinada ou

33 / 41 integrada em um único dispositivo de computação, ou a funcionalidade de um dispositivo de computação específico pode ser distribuída por um ou mais outros dispositivos de computação sem que se afaste do escopo das modalidades exemplificadoras da presente invenção. Um servidor pode ser um módulo de software, o qual pode também ser simplesmente chamado de módulo. O conjunto de módulos na central de contatos pode incluir servidores e outro módulos.

[0096] Os vários servidores podem estar situados em um dispositivo de computação interno à mesma localização física que os agentes da central de contatos, ou podem estar situados externamente (ou na nuvem) em uma localização geograficamente diferente, por exemplo em um centro de dados remoto, conectados à central de contatos por meio de uma rede como a Internet. Além disso, alguns dos servidores podem estar situados em um dispositivo de computação interno à central de contatos, enquanto outros podem estar situados em um dispositivo de computação externo ao local, ou servidores fornecendo funcionalidade redundante podem ser fornecidos via dispositivos de computação tanto internos como externos ao local para fornecer maior tolerância a falhas. Em algumas modalidades, a funcionalidade fornecida pelos servidores situados em dispositivos de computação externos pode ser acessada e fornecida em uma rede privada virtual (VPN - "Virtual Private Network"), como se esses servidores fossem internos, ou a funcionalidade pode ser fornecida com o uso de software como serviço (SaaS - "Software as a Service") para fornecer funcionalidade via internet usando vários protocolos, como fazendo intercâmbio de dados com o uso de codificação em linguagem de marcação extensível (XML - "eXtensible Markup Language") ou notação de objeto em JavaScript (JSON - "JavaScript Object Notation").

[0097] As Figuras 8A e 8B são diagramas que ilustram uma modalidade de um dispositivo de computação como pode ser empregado em

34 / 41 uma modalidade da invenção, indicado genericamente por 800. Cada dispositivo de computação 800 inclui uma CPU 805 e uma unidade de memória principal 810. Conforme ilustrado na Figura 8A, o dispositivo de computação 800 pode também incluir um dispositivo de armazenamento 815, uma interface de mídia removível 820, uma interface de rede 825, um controlador de entrada/saída (E/S) 830, um ou mais dispositivos de exibição 835A, um teclado 835B e um dispositivo apontador 835C (por exemplo, um mouse). O dispositivo de armazenamento 815 pode incluir, sem limitação, armazenamento para um sistema operacional e software. Conforme mostrado na Figura 8B, cada dispositivo de computação 800 pode também incluir elementos opcionais adicionais, como uma porta de memória 840, uma ponte 845, um ou mais dispositivos adicionais de entrada/saída 835D, 835E, e uma memória cache 850 em comunicação com a CPU 805. Os dispositivos de entrada/saída 835A, 835B, 835C, 835D e 835E podem ser coletivamente referidos na presente invenção como 835.

[0098] A CPU 805 é qualquer conjunto de circuitos lógicos que responda a, e processe, instruções trazidas da unidade de memória principal

810. Ela pode ser implementada, por exemplo, em um circuito integrado, sob a forma de um microprocessador, microcontrolador ou unidade de processamento gráfico, ou em uma matriz de portas programável em campo (FPGA - "Field-Programmable Gate Array") ou um circuito integrado de aplicação específica (ASIC). A unidade de memória principal 810 pode ser um ou mais chips de memória capazes de armazenar dados e de permitir que qualquer local de armazenamento seja diretamente acessado pela unidade central de processamento 805. Conforme mostrado na Figura 8A, a unidade central de processamento 805 se comunica com a memória principal 810 por meio de um barramento de sistema 855. Conforme mostrado na Figura 8B, a unidade central de processamento 805 pode também se comunicar diretamente com a memória principal 810 por meio de uma porta de

35 / 41 memória 840.

[0099] Em uma modalidade, a CPU 805 pode incluir uma pluralidade de processadores e pode fornecer funcionalidade para execução simultânea de instruções, ou para execução simultânea de uma instrução em mais de um dado. Em uma modalidade, o dispositivo de computação 800 pode incluir um processador paralelo com um ou mais núcleos. Em uma modalidade, o dispositivo de computação 800 compreende um dispositivo paralelo de memória compartilhada, com múltiplos processadores e/ou múltiplos núcleos de processador, acessando toda a memória disponível como um único espaço global de endereçamento. Em outra modalidade, o dispositivo de computação 800 é um dispositivo paralelo de memória distribuída com múltiplos processadores, cada qual acessando apenas a memória local. O dispositivo de computação 800 pode ter tanto alguma memória que é compartilhada, como alguma que só pode ser acessada por processadores ou subconjuntos de processadores específicos. A CPU 805 pode incluir um microprocessador de múltiplos núcleos, o qual combina dois ou mais processadores independentes em um único volume, por exemplo em um único circuito integrado (IC - "Integrated Circuit"). Por exemplo, o dispositivo de computação 800 pode incluir ao menos uma CPU 805 e ao menos uma unidade de processamento gráfico.

[00100] Em uma modalidade, uma CPU 805 fornece funcionalidade de instrução única, múltiplos dados (SIMD - "Single Instruction, Multiple Data"), por exemplo a execução de uma única instrução simultaneamente em múltiplas peças de dados. Em outra modalidade, vários processadores na CPU 805 podem fornecer funcionalidade para execução de múltiplas instruções simultaneamente em múltiplas peças de dados (MIMD - "Multiple Instruction, Multiple Data"). A CPU 805 pode também usar qualquer combinação de núcleos SIMD e MIMD em um único dispositivo.

[00101] A Figura 8B mostra uma modalidade na qual a CPU 805 se

36 / 41 comunica diretamente com a memória cache 850 através de um barramento secundário, às vezes chamado de barramento traseiro. Em outras modalidades, a CPU 805 se comunica com a memória cache 850 com o uso do barramento de sistema 855. A memória cache 850 tipicamente tem um tempo de resposta mais rápido que o da memória principal 810. Conforme ilustrado na Figura 8A, a CPU 805 se comunica com vários dispositivos de E/S 835 por meio do barramento de sistema local 855. Vários barramentos podem ser usados como o barramento de sistema local 855, incluindo, porém sem limitação, um barramento local de acordo com a Associação de Padrões para Eletrônicos com Vídeo (VESA - "Video Electronics Standards Association") (VLB - "VESA Local Bus"), um barramento com arquitetura padrão da indústria (ISA - "Industry Standard Architecture"), um barramento com arquitetura padrão da indústria estendido (EISA - "Extended Industry Standard Architecture"), um barramento com arquitetura de microcanais (MCA - "Micro Channel Architecture"), um barramento para interconexão de componentes periféricos (PCI - "Peripheral Component Interconnect"), um barramento PCI estendido (PCI-X - "PCI Extended"), um barramento PCI-Express ou um NuBus. Para modalidades nas quais um dispositivo de E/S é um dispositivo de exibição 835A, a CPU 805 pode se comunicar com o dispositivo de exibição 835A através de uma porta gráfica avançada (AGP - "Advanced Graphics Port"). A Figura 8B representa uma modalidade de um computador 800 no qual a CPU 805 se comunica diretamente com o dispositivo de E/S 835E. A Figura 8B mostra também uma modalidade na qual os barramentos locais e a comunicação direta são misturados: a CPU 805 se comunica com o dispositivo de E/S 835D com o uso de um barramento de sistema local 855 enquanto se comunica com o dispositivo de E/S 835 diretamente.

[00102] Uma ampla variedade de dispositivos de E/S 835 pode estar presente no dispositivo de computação 800. Os dispositivos de entrada incluem um ou mais teclados 835B, mouses, trackpads, trackballs,

37 / 41 microfones e mesas de desenho, para citar alguns exemplos não limitadores. Os dispositivos de saída incluem dispositivos de exibição de vídeo 835A, alto-falantes e impressoras. Um controlador de E/S 830, conforme mostrado na Figura 8A, pode controlar o um ou mais dispositivos de E/S, como um teclado 835B e um dispositivo apontador 835C (por exemplo, um mouse ou caneta óptica), por exemplo.

[00103] Novamente com referência à Figura 8A, o dispositivo de computação 800 pode suportar uma ou mais interfaces de mídia removível 820, como uma unidade de disco flexível, uma unidade de CD-ROM, uma unidade de DVD-ROM, unidades de fitas de vários formatos, uma porta USB, uma porta para cartão de memória SD ("Secure Digital") ou COMPACT FLASHTM, ou qualquer outro dispositivo adequado para ler dados a partir de mídias de somente leitura, ou para ler dados de, ou gravar dados em, mídias para gravação e leitura. Um dispositivo de E/S 835 pode ser uma ponte entre o barramento de sistema 855 e uma interface de mídia removível 820.

[00104] A interface de mídia removível 820 pode, por exemplo, ser usada para instalar software e programas. O dispositivo de computação 800 pode incluir adicionalmente um dispositivo de armazenamento 815, como uma ou mais unidades de disco rígido ou arranjos de unidades de disco rígido, para armazenar um sistema operacional e outros softwares relacionados, e para armazenar programas de software aplicativos. Opcionalmente, uma interface de mídia removível 820 pode também ser usada como o dispositivo de armazenamento. Por exemplo, o sistema operacional e o software podem ser executados a partir de uma mídia inicializável, por exemplo um CD inicializável.

[00105] Em uma modalidade, o dispositivo de computação 800 pode incluir ou estar conectado a múltiplos dispositivos de exibição 835A, cada um dos quais pode ser de tipos e/ou formas iguais ou diferentes. Assim sendo, qualquer um dentre os dispositivos de E/S 835 e/ou o controlador de E/S 830

38 / 41 pode incluir qualquer tipo e/ou forma de hardware, software ou combinação de hardware e software adequados para suportar, habilitar ou proporcionar a conexão a, e o uso de, múltiplos dispositivos de exibição 835A pelo dispositivo de computação 800. Por exemplo, o dispositivo de computação 800 pode incluir qualquer tipo e/ou forma de adaptador de vídeo, placa de vídeo, driver e/ou biblioteca para fazer interface, comunicar, conectar ou, de outro modo, usar os dispositivos de exibição 835A. Em uma modalidade, um adaptador de vídeo pode incluir múltiplos conectores para fazer interface com múltiplos dispositivos de exibição 835A. Em outra modalidade, o dispositivo de computação 800 pode incluir múltiplos adaptadores de vídeo, com cada adaptador de vídeo conectado a um ou mais dentre os dispositivos de exibição 835A. Em outras modalidades, um ou mais dentre os dispositivos de exibição 835A podem ser fornecidos por um ou mais outros dispositivos de computação conectados, por exemplo, ao dispositivo de computação 800 por meio de uma rede. Essas modalidades podem incluir qualquer tipo de software projetado e construído para usar o dispositivo de exibição de outro dispositivo de computação como um segundo dispositivo de exibição 835A para o dispositivo de computação 800. O versado na técnica reconhecerá e entenderá as várias maneiras e modalidades em que um dispositivo de computação 800 pode ser configurado para ter múltiplos dispositivos de exibição 835A.

[00106] Uma modalidade de um dispositivo de computação indicado de modo geral nas Figuras 8A e 8B pode operar sob o controle de um sistema operacional, o qual controla a programação de tarefas e o acesso aos recursos do sistema. O dispositivo de computação 800 pode estar executando qualquer sistema operacional, qualquer sistema operacional integrado, qualquer sistema operacional em tempo real, qualquer sistema operacional open source, qualquer sistema operacional proprietário, quaisquer sistemas operacionais para dispositivos de computação móvel, ou qualquer outro sistema

39 / 41 operacional capaz de ser executado no dispositivo de computação e de executar as operações descritas na presente invenção.

[00107] O dispositivo de computação 800 pode ser qualquer estação de trabalho, computador de mesa, computador portátil ou computador do tipo notebook, computador servidor, computador de mão, telefone móvel ou outro dispositivo portátil de telecomunicação, dispositivo reprodutor de mídias, sistema para jogos, dispositivo móvel de computação, ou qualquer outro tipo e/ou forma de computação, telecomunicações ou dispositivo de mídia que tenha a capacidade de comunicação e que tenha suficiente poder de processamento e capacidade de memória para executar as operações descritas na presente invenção. Em algumas modalidades, o dispositivo de computação 800 pode ter diferentes processadores, sistemas operacionais e dispositivos de entrada consistentes com o dispositivo.

[00108] Em outras modalidades, o dispositivo de computação 800 é um dispositivo móvel. Os exemplos podem incluir um telefone celular habilitado para Java ou um assistente pessoal digital (PDA - "Personal Digital Assistant"), um smartphone, um reprodutor de áudio digital ou um reprodutor de mídia portátil. Em uma modalidade, o dispositivo de computação 800 inclui uma combinação de dispositivos, como um telefone móvel combinado com um reprodutor de áudio digital ou um reprodutor de mídia portátil.

[00109] Um dispositivo de computação 800 pode ser um dentre uma pluralidade de máquinas conectadas por uma rede, ou pode incluir uma pluralidade de máquinas assim conectadas. Um ambiente de rede pode incluir um ou mais dentre máquinas locais, clientes, nós de cliente, máquinas clientes, computadores clientes, dispositivos clientes, pontos de extremidade ou nós de ponto de extremidade em comunicação com uma ou mais máquinas remotas (as quais podem também ser genericamente chamadas de máquinas servidoras ou máquinas remotas) por meio de uma ou mais redes. Em uma modalidade, uma máquina local tem a capacidade de funcionar tanto como

40 / 41 um nó de cliente buscando acesso a recursos fornecidos por uma máquina servidora, quanto como uma máquina servidora fornecendo a outros clientes acesso a recursos hospedados. A rede pode ser enlaces LAN ou WAN, conexões de banda larga, conexões sem fio ou uma combinação de quaisquer ou todos os supracitados. As conexões podem ser estabelecidas com o uso de vários protocolos de comunicação. Em uma modalidade, o dispositivo de computação 800 se comunica com outros dispositivos de computação 800 por meio de qualquer tipo e/ou forma de gateway ou protocolo de túnel, como camada de soquete seguro (SSL - "Secure Socket Layer") ou segurança de camada de transporte (TLS - "Transport Layer Security"). A interface de rede pode incluir um adaptador de rede integrado, como uma placa de interface de rede, adequada para fazer interface do dispositivo de computação a qualquer tipo de rede capaz de comunicação e execução das operações aqui descritas. Um dispositivo de E/S pode ser uma ponte entre o barramento de sistema e um barramento de comunicação externa.

[00110] Em uma modalidade, um ambiente de rede pode ser um ambiente de rede virtual, onde os vários componentes da rede são virtualizados. Por exemplo, as várias máquinas podem ser máquinas virtuais implementadas como um computador baseado em software sendo executado em uma máquina física. As máquinas virtuais podem compartilhar o mesmo sistema operacional. Em outras modalidades, diferentes sistemas operacionais podem ser executados em cada instância de máquina virtual. Em uma modalidade, uma virtualização de tipo "hipervisor" é implementada onde múltiplas máquinas virtuais são executadas na mesma máquina física hospedeira, cada qual atuando como se tivesse seu próprio gabinete dedicado. As máquinas virtuais podem também ser executadas em diferentes máquinas físicas hospedeiras.

[00111] Outros tipos de virtualização são também contemplados como, por exemplo, a rede (por exemplo, via comunicação por rede definida por

41 / 41 software (SDN - Software Defined Networking)). As funções, como funções de controlador de borda de sessão e outros tipos de funções, podem também ser virtualizados como, por exemplo, via virtualização de funções da rede (NFV - "Network Functions Virtualization").

[00112] Em uma modalidade, o uso de LSH para descobrir automaticamente mensagens de áudio de portadora em um grande conjunto de gravações de áudio pré-conectadas pode ser aplicado no processo de suporte de serviços de mídia para um ambiente de central de contatos. Por exemplo, isso pode ajudar no processo de análise de chamada para uma central de contatos e remover a necessidade de os seres humanos ouvirem um grande conjunto de gravações de áudio para descobrir novas mensagens de áudio portadoras.

[00113] Embora a invenção tenha sido ilustrada e descrita com detalhes nos desenhos e na supracitada descrição, esta se destina a ser considerada como tendo caráter ilustrativo e não restritivo, ficando entendido que apenas a modalidade preferencial foi mostrada e descrita, e que se deseja que estejam protegidos todos os equivalentes, alterações e modificações que se enquadrem no espírito da invenção conforme descrita aqui e/ou nas reivindicações a seguir.

[00114] Portanto, o escopo adequado da presente invenção será determinado apenas pela interpretação mais ampla das reivindicações em anexo, de modo a abranger todas essas modificações, bem como todas as relações equivalentes àquelas ilustradas nos desenhos e descritas no relatório descritivo.

Claims (18)

REIVINDICAÇÕES

1. Método para prever demanda de carga de trabalho para planejamento de recursos em um ambiente central de contato, sendo que o método é caracterizado por compreender: extrair dados de histórico de uma base de dados, sendo que os dados de histórico compreendem uma pluralidade de níveis de estágio representativos do tempo que um recurso da central de contatos gasta atendendo um nível de estágio em uma jornada do cliente; pré-processar os dados de histórico, sendo que o pré- processamento compreende adicionalmente derivar gráficos de adjacência, derivar sequências zero e derivar históricos de estágios, para cada nível de estágio; determinar previsões de estágio com o uso dos dados de histórico pré-processados e construir um modelo de previsões, sendo que a previsão de estágio compreende as etapas de: executar um algoritmo de liberação que executa iterações dos dados de histórico para liberar volumes através de múltiplos estágios e períodos; reter uma porção de dados de histórico para validação, resultando em uma porção restante; usar a porção restante para construir e treinar o modelo de previsões; e calibrar o modelo de previsões; e derivar a demanda de carga de trabalho prevista usando o modelo construído.

2. Método de acordo com a reivindicação 1, caracterizado por os níveis de estágio compreenderem pontos de foco da jornada do cliente e transições de cada estágio na jornada do cliente.

3. Método de acordo com a reivindicação 1, caracterizado por a extração ser disparada por um dos seguintes: ação do usuário, trabalho programado e solicitação de fila de outro serviço.

4. Método de acordo com a reivindicação 1, caracterizado por o gráfico de adjacência fazer conexões de gráfico entre estágios.

5. Método de acordo com a reivindicação 1, caracterizado por uma sequência zero compreender um primeiro estágio de uma cadeia de uma progressão de sequências.

6. Método de acordo com a reivindicação 1, caracterizado por um histórico de estágio compreender uma propriedade para cada estágio compreendendo contagem de vetor de histórico, taxa de abandono e matriz de vetor de probabilidade.

7. Método de acordo com a reivindicação 1, caracterizado por a liberação de volumes compreender trabalhar retrocedendo a partir da data de início da previsão menos um período e repetir com cada repetição aumentando cada período em 1.

8. Método de acordo com a reivindicação 1, caracterizado por a demanda de carga de trabalho prevista compreender uma carga de trabalho gerada a partir de um volume de interações conforme um cliente progride através de estágios na jornada do cliente, incluindo abandonos previstos.

9. Método de acordo com a reivindicação 8, caracterizado por a demanda de carga de trabalho prevista compreender adicionalmente os recursos necessários para lidar com a carga de trabalho prevista para fornecer alvos de métrica de KPI à central de contatos.

10. Método para prever demanda de carga de trabalho para planejamento de recursos em um ambiente central de contato, sendo que o método é caracterizado por compreender: extrair dados de histórico de uma base de dados, sendo que os dados de histórico compreendem uma pluralidade de níveis de estágio representativos de ações que um recurso da central de contatos gasta atendendo um nível de estágio em uma jornada do cliente;

pré-processar os dados de histórico, sendo que o pré- processamento compreende adicionalmente derivar gráficos de adjacência, derivar sequências zero e derivar históricos de estágios, para cada nível de estágio; determinar previsões de estágio com o uso dos dados de histórico pré-processados e construir um modelo de previsões, sendo que a previsão de estágio compreende adicionalmente as etapas de: executar um algoritmo de liberação que executa iterações dos dados de histórico para liberar volumes através de múltiplos estágios e períodos; reter uma porção de dados de histórico para validação, resultando em uma porção restante; usar a porção restante para construir e treinar o modelo de previsões; e calibrar o modelo de previsões; e derivar a demanda de carga de trabalho prevista usando o modelo construído.

11. Método de acordo com a reivindicação 10, caracterizado por os níveis de estágio compreenderem pontos de foco da jornada do cliente e transições de cada estágio na jornada do cliente.

12. Método de acordo com a reivindicação 10, caracterizado por a extração ser disparada por um dos seguintes: ação do usuário, trabalho programado e solicitação de fila de outro serviço.

13. Método de acordo com a reivindicação 10, caracterizado por o gráfico de adjacência fazer conexões de gráfico entre estágios.

14. Método de acordo com a reivindicação 10, caracterizado por uma sequência zero compreender um primeiro estágio de uma cadeia de uma progressão de sequências.

15. Método de acordo com a reivindicação 10, caracterizado por um histórico de estágio compreender uma propriedade para cada estágio compreendendo contagem de vetor de histórico, taxa de abandono e matriz de vetor de probabilidade.

16. Método de acordo com a reivindicação 10, caracterizado por a liberação de volumes compreender trabalhar retrocedendo a partir da data de início da previsão menos um período e repetir com cada repetição aumentando cada período em 1.

17. Método de acordo com a reivindicação 10, caracterizado por a demanda de carga de trabalho prevista compreender uma carga de trabalho gerada de um volume de interações conforme um cliente progride através de estágios na jornada do cliente, incluindo abandonos previstos.

18. Método de acordo com a reivindicação 17, caracterizado por a demanda de carga de trabalho prevista compreender adicionalmente os recursos necessários para lidar com a carga de trabalho prevista para fornecer alvos de métrica de KPI à central de contatos.