Gerenciamento de dados

Centros de contato lidam com quantidades enormes de dados, desde informações de relatórios até listas de chamadas. Pode ser necessário transferir dados para ou do CXone e você pode ter que trabalhar com dados dentro do CXone. A forma como você trabalha com dados em scripts do Studio afeta o desempenho do seu sistema e a qualidade das suas interações. Esta página o(a) ajuda a gerenciar dados eficientemente.

A ferramenta correta para o trabalho correto

A principal finalidade do Studio é controlar o roteamento de contatos. Tudo que você fizer em um script do Studio deve ser focado nos contatos. Qualquer processamento de dados do qual você precise e que não seja relacionado a contatos deve ser feito fora do Studio. O Studio não foi feito para processar grandes quantidades de dados e tem um limite de 32 KB. Isto é suficiente ao se trabalhar com contatos e mantém os servidores funcionando eficientemente.

A tarefa a seguir é uma que precisa de gerenciamento de dados, com dois exemplos bem-sucedidos.

Tarefa de exemplo: analisar dados de agentes todos os dias para identificar possíveis problemas como pausas longas demais ou não programadas.

Solução inadequada: criar um script Studio agendado que é executado todos os dias. O script primeiro faz chamadas API para obter a lista do agente para o dia e em seguida obtém o histórico de estado do agente para o dia. Depois, o script verifica se algum agente fez uma pausa não programada maior que 30 minutos. Ele também busca por qualquer pausa excessivamente longa, como uma pausa de quatro horas para uso do banheiro. O script também determina quais agentes passaram a maior parte do tempo em um estado indisponível e quais agentes passaram a maior parte do tempo em uma determinada competência Usado para automatizar a entrega de interações com base nas competências, habilidades e conhecimento do agente..

Por que este método é ruim:

Esta tarefa não é focada em um contato único; Studio não é a ferramenta correta para este trabalho.
O Studio não foi feito para processar grandes quantidades de dados, e sim para atendimento de contatos. O seu locatário Alto nível de agrupamento organizacional usado para gerenciar o suporte técnico, cobrança e configurações globais para o seu ambiente CXone pode ter problemas com o desempenho, já que muitos dados na memória reduzem a performance do servidor.
O Studio tem um limite de dados de 32 KB. Este método exige que você fatie dados em pequenas quantidades para se manter dentro deste limite. Portanto, o script poderia ser executado por um longo período de tempo, o que seria bastante oneroso.
Esta tarefa seria melhor resolvida por uma engenharia que use APIs CXone em vez de um script Studio.
O Studio funciona melhor ao identificar informações como um agente que passou a maior parte do tempo em um determinado estado ou que atendeu o menor número de chamadas. Processar os dados em um servidor externo permite que você produza métricas mais valiosas.

Boa solução: este é apenas um dos métodos possíveis para se resolver a tarefa. Soluções para os seus cenários podem exigir uma abordagem diferente.

Um método para se resolver esta tarefa é com Python sendo executado em um servidor AWS, cuja potência de processamento é maior. A partir do servidor, faça as mesmas chamadas API para obter a lista do agente e o histórico de estado do agente para o dia. Coloque os dados em uma tabela ou em uma matriz. Uma tabela de banco de dados seria melhor, pois permitiria que você comparasse e analisasse dados no futuro de forma mais fácil. Os dados retornados possivelmente estariam na casa dos megabytes, o que excede o limite no Studio mas não é um problema para um banco de dados. Você pode ter o histórico completo de estado para todos os agentes dentro da memória; assim, você teria todo o conjunto de dados em um só lugar para trabalhar em vez de em pequenos pedaços de dados em um script Studio.

Agora, você poderia começar a trabalhar com os dados para criar as métricas que deseja, como uma lista ordenada de agentes com base em tempo gasto em estados específicos. Um banco de dados o(a) ajuda a apresentar esses dados do jeito que você quer, sem as limitações que você teria em um script Studio.

Aprenda um bom exemplo de criação e mapeamento de uma lista de chamada no CXone:

As instruções a seguir são um exemplo das etapas e das chamadas API que você pode fazer para criar uma nova lista de chamadas com mapeamentos de coluna definidos.

Autenticar:
1. Execute a descoberta de autenticação para obter um token de link. O token resultante pode ser armazenado em cache.
2. Solicite um token do terminal de token descoberto na etapa anterior:
  1. Crie uma solicitação POST para https://cxone.niceincontact.com/auth/token com um corpo x-www-form-urlencoded.
  2. Recupere os cinco pares de chave-valor, como client_secret e client_id.

Executar a descoberta de terminal API:

Extraia tenantId do token retornado na etapa 1 acima.

Faça uma solicitação GET para https://cxone.niceincontact.com/.well-known/cxone-configuration?tenantId={YOUR TENANT ID}. Resposta de exemplo:

{
	"private": false,
	"area": "na1",
	"cluster": "B32",
	"domain": "niceincontact.com",
	"acdDomain": "nice-incontact.com",
	"uhDomain": "nice-incontact.com",
	"ui_endpoint": "https://na1.nice-incontact.com",
	"auth_endpoint": "https://na1.nice-incontact.com",
	"api_endpoint": "https://api-na1.niceincontact.com",
	"tenantId": "11eb0358-724b-3970-97e5-0242ac110003"
}

Extract the "area" and "domain" fields from the reply.
Construct a base URI in the form of: https://api-{area}.{domain}.

Crie um mapeamento de lista de chamadas usando POST /lists/call-lists .

Esta API cria uma lista de chamadas identificada com {listId}. Cada chamada atualiza o mapeamento de dados dos nomes da coluna de fonte para campos CXone. De forma geral, você só faria isso quando cabeçalhos de coluna nos dados mudassem. Para esta API, você deve definir valores como parâmetros de consulta e, em seguida, fornecer um corpo JSON com uma matriz de pares destinationMappings, cada um deles composto por um fieldName e um fieldValue. Estes são usados para mapear os dados carregados na etapa 4 abaixo.

Você pode encontrar os nomes de campos aqui definidos pelo CXone na ajuda online. Os valores de campo são os nomes da coluna nos dados fonte para mapear o campo CXone.

Um exemplo POST seria: https://api-{area}.{domain}/incontactapi/services/v27.0/lists/call-lists?{listname}&externalIdColumn={fieldValue} com um corpo JSON. O retorno esperado seria um código 200 com um corpo de resposta:
```
{
	"listId": 0
}
```
Carregue os dados de lista de chamadas usando POST /lists/call-lists/{listId}/upload com o listId criado na etapa 3. O listId é especificado no caminho da chamada API e os dados da lista de chamadas são fornecidos no corpo da solicitação.
Um detalhe importante é o formato do arquivo. O parâmetro listFile são os dados da lista de chamadas como um arquivo codificado em base64.
Além disso, você pode escolher iniciar a competência do discador após a conclusão do carregamento definindo o sinalizador "startSkill" para "true" como parte do corpo de solicitação.
Um exemplo POST seria: https://api-{area}.{domain}/incontactapi/services/v27.0/lists/call-lists/{listId}/upload.

Durante chamadas ativas, o centro de contato Jungle quer obter dados de clientes do CRM e exibi-los no aplicativo de agente. No Studio, eles primeiro capturam informações de identificação básicas do contato, como o número de conta. Depois, o script faz uma solicitação GET para o CRM do centro, verificando se a informação corresponde ao registro do cliente. Se um registro existir, ele retorna todos os dados do cliente. O centro Jungle não quer mostrar todos os dados do cliente e a API não permite que eles especifiquem o que querem retornar.

A solução é criar um middleware entre o Studio e o CRM. A API retorna o JSON para o middleware, que analisa os detalhes desejados do cliente. Em seguida, ele passa os detalhes para o Studio. Isto também permite que o Jungle permaneça dentro do limite de 32 KB.

Push vs Poll

De forma geral, é melhor usar uma arquitetura baseada em push. Esperar por alguma coisa acontecer por poll tem um custo inato de recursos, enquanto o push de dados é sob medida; ele não consome recursos quando não é necessário. O push de dados normalmente permite que você lide com menores pedaços de dados. O push de dados é feito com frequência para necessidades em tempo real, como um único contato ativo. O poll é usado com frequência para integrações e não pode ser segmentado ou quebrado muitas vezes.

Por exemplo, talvez você tenha desejado atualizar a IU do agente ao colocar uma chamada telefônica em espera. Se tiver usado a API /get-next-event em um script para ouvir (ou poll) para o evento de espera do cliente do agente, isto bloquearia constantemente uma conversa. Em vez disso, é melhor fazer o push de dados em uma instância única para evitar o uso constante de recursos do servidor. Em circunstâncias parecidas, talvez com integrações CRM, em vez de esperar por uma solicitação ser retornada, faça uma chamada API que faz o push de dados e libera a conversa. Em seguida, use a API de sinal que envia os dados de volta ao script. Você também pode fazer uma chamada API para ver se aquela solicitação foi encerrada e, em caso afirmativo, enviar os dados.

Processamento de grandes quantidades de dados

Caso queira gerenciar grandes conjuntos de dados, como dados históricos de todo o seu centro de contatos, use APIs CXone ou Compartilhamento de Dados CXone. Em grande escala, você pode usar o Snowflake para obter todos os dados da sua unidade de negócios; o Compartilhamento de Dados CXone lhe concede um canal direto para os dados do seu centro de contatos para que você não fique limitado a fazer chamadas API para obter dados. Em escalas menores, a tarefa de exemplo ilustrada acima pode ser mais eficiente. Pequenos negócios que não possuem grandes quantidades de dados ou empresas que querem encontrar métricas específicas podem criar apps pequenos para tarefas similares. Por exemplo, você pode criar um app que envia e-mails para gerentes caso eles tenham funcionários que passam muito tempo em um determinado estado.

Exemplos de como evitar grandes conjuntos de dados em scripts

Os cenários a seguir são exemplos comuns de como você pode evitar usar grandes conjuntos de dados nos seus scripts Studio. Você também pode consultar o exemplo acima, que evita a transferência de dados excessivos de clientes de um CRM para o Studio.

Filtragem de respostas API por campo:

Algumas APIs têm a capacidade de filtrar qual informação é retornada. Por exemplo, se você solicitar um CRM a retornar informação para um caso, algumas APIs de CRM permitem que você especifique exatamente quais campos de informação você deseja retornar. Se a API que você estiver usando oferecer esta funcionalidade, é possível evitar conjuntos de dados grandes ao se trabalhar somente com a informação exata de que precisa. Se a API de um fornecedor não tiver esta funcionalidade talvez valha a pena trabalhar com o fornecedor para adicionar esta opção, ou você pode criar um middleware. O middleware pode receber os dados antes do Studio e você pode deixar de fora os dados desnecessários, retornando os dados que quer para o Studio.
Filtragem de respostas API por tempo:

Se uma API permite que você filtre por uma quantidade de tempo, use esta funcionalidade para minimizar a quantidade de dados. Se precisar de dados apenas de um dia ou semana, lembre-se de filtrar a resposta para incluir dados somente dentro deste intervalo de tempo.
Filtragem de dados por contatos individuais:

O Studio não é uma ferramenta de gerenciamento de dados, e sim uma ferramenta de gerenciamento de contatos. A capacidade do Studio e das ações Studio permite que você trabalhe com dados voltados principalmente a um contato individual. Você pode manter seus dados específicos para contatos individuais com técnicas como reunião de informações por meio de um RVI ou obtenção de dados de um CRM para um registro ou caso de cada vez.

Armazenamento de dados

Você tem várias opções para armazenar dados. Caso tenha uma conta Snowflake, você pode mover os dados do seu centro de contato do CXone para o Snowflake usando o Studio. A NICE armazena seus dados por 24 meses e estes podem ser obtidos a partir do Snowflake. Você também pode usar o Serviços de armazenamento na nuvem para armazenar arquivos como gravações de chamadas ou transcrições de chat, ou movê-los para os seus próprios servidores. Entre em contato com o seu representante de suporte CXone para mais informações.

Custos inesperados

De maneira geral, você não terá custos adicionais com base em chamadas de API excessivas ou algo do gênero. No entanto, como você armazena determinados dados pode gerar custos. Os casos a seguir são exemplos de como um armazenamento de dados inadequado criou cobranças de fatura inesperadas.

Criar muitas variáveis de script e armazená-las em um arquivo de texto para cada contato sem incluir um processo para limpeza destes arquivos.
Armazenar informações de caminho de pressionamento RVI em arquivos para uso posterior. Talvez você queira usar essas informações para fins de relatório no futuro.
Armazenar resultados de API em um arquivo que continua crescendo à medida que novos resultados são adicionados. Ao longo do tempo e à medida que o arquivo cresce em tamanho, isso gera custos de armazenamento.
Armazenar arquivos no CXone Armazenamento em Nuvem. Caso use Armazenamento em Nuvem, verifique se está ciente de quaisquer parâmetros quanto a armazenamento. Você pode consultar o conteúdo da ajuda para Armazenamento em Nuvem ou entrar em contato com um representante do suporte.

Chamadas API a partir do Studio

APIs o(a) ajudam a trabalhar com dados de forma eficiente e eficaz. Você pode fazer chamadas API a partir do Studio com as ações listadas abaixo. A lista a seguir explica as diferenças técnicas entre o uso de distintas ações:

SNIPPET: permite que você adicione código personalizado a um script. Você pode usar esta ação para fazer chamadas API, preparar cargas úteis, analisar objetos de dados dinâmicos e assim por diante. Ao fazer chamadas API com esta ação, preste atenção à velocidade de resposta. Esta ação usa uma conversa durante o tempo todo em que está ativa. Se a resposta estiver lenta, o que significa que a conversa está bloqueada o tempo inteiro, pode haver impactos negativos no desempenho do servidor. Por exemplo, um chamador pode ouvir ar parado se todas as conversas estiverem sendo usadas de uma vez.
REST API: permite que você faça chamadas REST API e usa menos recursos do servidor. Você deve usar esta ação para fazer chamadas API sempre que possível, porém ela aceita especificamente JSON. Se uma API não retorna JSON, pode ser preciso usar a ação SNIPPET em vez disso. Dependendo da sua tarefa, pode ser necessário usar esta ação juntamente com SNIPPET, já que SNIPPET pode fazer coisas como preparar cargas úteis.
ConnectAuth: autentica um conector criado no Integration Hub. Integration Hub é uma fonte centralizada para criação, gerenciamento e execução de integrações do CXone a plataformas de terceiros. Esta ação não bloqueia conversas.
ConnectRequest: aciona uma solicitação Integration Hub depois de ter sido autenticada. Esta ação não bloqueia conversas.

Outras ações Studio relacionadas a dados

O Studio possui várias ações que armazenam temporariamente e recuperam pequenas quantidades de dados de uma tabela de banco de dados para tornar os dados acessíveis a outros scripts. Estas ações se comportam como uma lista de campos ou valores. Use-as para armazenar vários valores ou valores necessários posteriormente em outros scripts. A lista completa das ações é: PUTVALUE, GETVALUE, REMVALUE, GETLIST e CLEARLIST.

Essas ações usam um tipo de dados exclusivo que só pode ser acessado usando esse conjunto de ações Studio. Os dados não são acessíveis de outra forma. Os usuários não podem acessar esse banco de dados e usá-lo, independentemente de suas permissões.

Os valores são listados em uma tabela de banco de dados por um período de tempo limitado, conforme configurado na propriedade TTL hrs (tempo de vida) da ação PUTVALUE. O padrão é 24 horas, mas pode variar de uma hora a 168 horas (sete dias). Você pode usar a ação REMVALUE para excluir dados antes do tempo de TTL. Isso lhe dá controle total sobre os dados em seus scripts. A prática recomendada é excluir valores quando eles não forem ser usados novamente e deixar a propriedade TTL como a padrão de 24 horas.

Notas:

Se várias variáveis precisarem ser acessadas por outros scripts ou contatos, um banco de dados geralmente é a melhor solução.
Variáveis públicas não persistentes podem ser compartilhadas por outros scripts ou contatos ao longo da vida do script que define essas variáveis. As variáveis são limpas automaticamente ao serem liberadas.
Estas ações têm um limite de 1000 itens na “lista”. Um único item, ou pedaço de dado, também tem um limite de 5 KB.