Data Management

Los centros de contacto manejan grandes cantidades de datos, desde los datos de reporte hasta las listas de llamadas. Es posible que deba transferir datos hacia y desde NiCE CXone, y es posible que deba trabajar con datos dentro de NiCE CXone. La forma en que trabaja con los datos en los scripts o API de Studio impacta el rendimiento de su sistema y la calidad de sus interacciones. Esta página le ayuda a gestionar los datos de manera eficiente.

La herramienta adecuada para el trabajo adecuado

El propósito principal de Studio es controlar el enrutamiento de contactos. Cualquier acción que realice en un script de Studio debe estar centrada en el contacto. Cualquier procesamiento de datos que necesite y que no esté relacionado con el contacto debe realizarse fuera de Studio. Studio no se diseña para procesar grandes cantidades de datos, por lo que tiene un límite de datos de 32KB. Esto es suficiente cuando se trabaja con contactos y mantiene los servidores funcionando de manera eficiente.

Lo siguiente es una tarea que requiere de la gestión de datos, con dos ejemplos de realización de la tarea.

Tarea de ejemplo: analizar los datos del agente diariamente para identificar problemas potenciales como pausa claramente largas o pausas sin programar.

Solución inapropiada: Crear un script programado de Studio que se ejecute todos los días. El script primero realiza Llamadas a la API para extraer la lista de agentes del día y luego extrae el historial de estado de agente del día. Luego, el script verifica si algún agente tomó un receso de más de 30 minutos que no estuviera programado. También busca cualquier receso claramente largo, como un receso de cuatro horas para ir al baño. El script también determina qué agentes pasaron la mayor cantidad de tiempo en un estado no disponible, y qué agentes pasaron la mayor cantidad de tiempo en una habilidadClosed Se usa para automatizar la entrega de interacciones según las habilidades, capacidades y conocimientos del agente. en particular.

Por qué es malo este método:

  • Esta tarea no se enfoca en un solo contacto; Studio no es la herramienta adecuada para el trabajo.

  • Studio no está pensado para procesar grandes cantidades de datos, se diseña para el manejo de contactos. Su abonadoClosed Agrupación organizativa de alto nivel utilizada para administrar el soporte técnico, la facturación y la configuración global de su sistema NiCE CXone. puede sufrir problemas de rendimiento, ya que una gran cantidad de datos en memoria produce un mal rendimiento del servidor.

  • Studio tiene un límite de datos de 32KB. Este método le pide que divida los datos en pequeñas cantidades que se mantengan debajo de dicho límite. Por lo tanto, el script podría ejecutarse durante un período prolongado, lo cual consume muchos recursos.

  • Esta tarea se soluciona mejor especificando quién puede usar las API NiCE CXone, en vez de un script Studio.

  • Studio funciona mejor al identificar información como el agente que pasó la mayor cantidad de tiempo en un estado determinado o que manejó el menor número de llamadas. Procesar los datos en un servidor externo le permite producir más métricas valiosas.


Buena solución: Este es solo un método potencial de solucionar la tarea. Las soluciones para sus escenarios pueden demandar un enfoque diferente.

Un método para solucionar esta tarea es con Python ejecutándose en un servidor AWS, lo cual ofrece más capacidad de procesamiento. Desde el servidor, realice las mismas Llamadas a la API para extraer la lista de agentes y el historial de estado de agente del día. Coloque los datos en una tabla o quizás en una matriz. Se preferiría una tabla de base de datos para permitirle comparar y analizar los datos con mayor facilidad en el futuro. Los datos devueltos posiblemente estén en megabytes, lo cual no representa un problema para una base de datos, pero excede el límite de datos en Studio. Podría tener todo el historial de estados de cada agente dentro de la memoria; tendría el conjunto de datos completo en un solo lugar para trabajar, en lugar de pequeños fragmentos de datos en un script de Studio.

Ahora podría comenzar a trabajar con los datos para producir las métricas deseadas, como una lista ordenada de agentes según el tiempo dedicado a determinados estados. Una base de datos le ayuda a presentar estos datos como lo considere conveniente, en lugar de dentro de las restricciones de un script de Studio.

Las siguientes instrucciones son un ejemplo de los pasos y llamadas API que pudiera hacer para crear una nueva lista de llamadas con los mapeos de columnas definidos.

  1. Authenticate:
    1. Realice la detección de autenticación para obtener un enlace de token. Se puede colocar en caché el token resultante.
    2. Request a token from the token endpoint discovered in the previous step:
      1. Crear una solicitud POST para https://cxone.niceincontact.com/auth/token con un cuerpo x-www-form-urlencoded.
      2. Recuperar los cinco pares de clave-valor, como su client_secret y client_id.
  2. Perform API endpoint discovery:
    1. Extraer el tenantId del token devuelto en el paso 1 anterior.
    2. Make a GET request to https://cxone.niceincontact.com/.well-known/cxone-configuration?tenantId={YOUR TENANT ID}. Example reply: 
      {

	"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"

}
    3. Extraer los campos "area" y "domain" de la respuesta.
    4. Construir una uri base con el siguiente formato: https://API-{area}.{domain}.

  3. Crear un mapeado de datos de lista de llamadas utilizando POST /lists/call-lists .

    Esta API crea una lista de llamada identificada con un {listId}. Cada llamada actualiza el mapeado de datos de los nombres de columna de origen a los campos de NiCE CXone. En general, solo debería hacer esto cuando cambian los encabezados de columna en los datos. Para esta API, debe definir los valores como parámetros de consulta y, luego, proporcionar un cuerpo JSON con una matriz de pares de destinationMappings, cada uno de los cuales está compuesto por un fieldName y un fieldValue. Estos se utilizan para mapear los datos cargados en el paso 4 a continuación.

    Puede encontrar los nombres de campo definidos por NiCE CXone aquí en la ayuda en línea. Los valores de campo son los nombres de columna en los datos de origen que se mapean al campo de NiCE CXone.

    Un ejemplo de POST sería: https://API-{area}.{domain}/incontactapi/services/v27.0/lists/call-lists?{listname}&externalIdColumn={fieldValue} con un cuerpo JSON. El retorno esperado sería un código 200 con un cuerpo de respuesta:

    {

	"listId": 0

}

  4. Upload the calling list data using POST /lists/call-lists/{listId}/upload  with the listId created in step 3. The listId is specified in the path of the API call and the actual calling list data is provided in the request body.

    Un detalle importante es el formato del archivo. El parámetro listFile es los datos de la lista de llamada como un archivo codificado en base64.

    Además, puede optar por comenzar la habilidad de marcador al completar la carga configurando el indicador "startSkill" en "true" como parte del cuerpo de la solicitud.

    Un ejemplo de POST sería: https://API-{area}.{domain}/incontactapi/services/v27.0/lists/call-lists/{listId}/upload.

Durante las llamadas activas, el centro de contacto The Jungle desea extraer datos del cliente de su CRM y mostrarlos en su aplicación de agente. En Studio, primero capturan información básica de identificación del contacto, como un número de cuenta. Luego, el script realiza una solicitud GET a su CRM, verificando si la información coincide con un registro de cliente. Si existe un registro, se devuelven todos los datos del cliente. The Jungle no desea mostrar todos los datos del cliente, y la API no les permite especificar qué devolver.

Su solución es crear un middleware que existe entre Studio y el CRM. La API devuelve el JSON al middleware, que analiza los detalles del cliente deseados. Luego, pasa los detalles a Studio. Esto también permite que The Jungle se mantenga dentro del límite de datos de 32 KB.

Push frente a llamar

En general, se recomienda usar una arquitectura basada en push. Esperar a que ocurra algo mediante sondeo (polling) consume recursos de forma inherente, mientras que enviar datos mediante push es bajo demanda; no consume recursos cuando no se necesita. El envío de datos mediante push normalmente permite manejar fragmentos de datos más pequeños. El envío de datos mediante push a menudo se realiza para necesidades en tiempo real, como un solo contacto activo. El sondeo (polling) se usa a menudo para integraciones y no puede dividirse ni segmentarse tanto.

Por ejemplo, tal vez usted quería actualizar la interfaz de usuario del agente al poner una llamada telefónica en espera. Si usted usó la API /get-next-event en un script para escuchar (o sondear) el evento de espera desde el cliente del agente, esto bloquearía constantemente un subproceso. En su lugar, usted desea enviar datos en una sola instancia para evitar el uso constante de los Recursos del servidor. En instancias similares, quizás con integraciones de CRM, en lugar de esperar a que se devuelva una solicitud, realice una Llamada a la API que envíe datos y libere el subproceso. Luego, use la API de señalización para enviar los datos de vuelta al script. También podría realizar una Llamada a la API para verificar si esa solicitud ha finalizado, y, de ser así, enviar los datos.

Procesar Grandes cantidades de datos

Si usted desea gestionar conjuntos de datos grandes, como los datos históricos de todo su centro de contacto, use las API de NiCE CXone o NiCE CXone Data Share. A gran escala, usted puede usar Snowflake para extraer todos los datos de su unidad de negocio; Data Share le proporciona un canal directo para los datos de su centro de contacto, de modo que usted no está limitado a realizar Llamadas a la API para extraer datos.

A menor escala, la tarea de ejemplo explicada anteriormente puede ser óptima. Los pequeños negocios que no tienen una gran cantidad de datos o en los negocios que se desea encontrar métricas específicas se pueden diseñar aplicaciones pequeñas para tareas similares. Por ejemplo, usted podría crear una aplicación que envíe correos electrónicos a los gerentes si tienen empleados que pasaron demasiado tiempo en un determinado estado.

Ejemplos de evitar Grandes volúmenes de datos en los scripts

Los siguientes son ejemplos de escenarios comunes en los que usted puede evitar usar conjuntos de datos grandes en sus scripts de Studio. Usted también puede consultar el ejemplo anterior, que evita transferir demasiados datos del cliente desde un CRM a Studio.

  • Filtrado de las respuestas de la API por campo:

    Algunas API ofrecen la posibilidad de filtrar qué información se devuelve. Por ejemplo, si usted solicita a un CRM que devuelva información de un caso, algunas API de CRM le permiten especificar exactamente qué campos de información desea devolver. Si la API que usted está usando ofrece esta funcionalidad, usted puede evitar los conjuntos de datos grandes trabajando únicamente con la información exacta que necesita. Si la API de un proveedor no tiene esta funcionalidad, usted puede trabajar con el proveedor para agregar la opción, o puede crear un middleware. El middleware puede recibir los datos antes de Studio, usted puede filtrar lo innecesario y luego devolver los datos a Studio.

  • Filtrado de las respuestas de la API por tiempo:

    Si una API le permite filtrar por una cantidad de tiempo, use esta funcionalidad para minimizar la cantidad de datos. Si usted solo necesita los datos de un día o una semana, asegúrese de filtrar la respuesta para incluir únicamente los datos dentro de ese período de tiempo.

  • Filtrar los datos para contactos particulares:

    Studio no es una herramienta de gestión de datos, es una herramienta de gestión de contactos. Las capacidades de Studio y las acciones de Studio le permiten trabajar con datos enfocados principalmente en un contacto individual. Usted puede mantener sus datos específicos de contactos individuales con técnicas como recopilar información a través de un IVR o extraer datos de un CRM para un registro o caso a la vez.

Almacenamiento de datos

Usted tiene muchas opciones para almacenar datos. Si usted tiene una cuenta de Snowflake, puede mover los datos de su centro de contacto de NiCE CXone a Snowflake usando Studio. NiCE almacena sus datos durante 24 meses, los cuales usted puede recuperar de Snowflake. Usted también puede usar Cloud Storage Services para almacenar archivos como grabaciones de llamadas o transcripciones del chat, o moverlos a sus propios servidores. Comuníquese con su representante de cuenta de NiCE CXone para obtener más información.

Costos no esperados

En general, usted no incurrirá en costos adicionales por realizar demasiadas Llamadas a la API o algo similar. Sin embargo, la forma en que usted almacena ciertos datos podría generar costos. Los siguientes son ejemplos donde el almacenamiento de datos inadecuados generó cargos de facturación no esperados:

  • Crear muchas variables de script y almacenarlas en un archivo de texto para cada contacto sin incluir un proceso para depurar esos archivos.

  • Almacenar información de ruta de pulsaciones del IVR en archivos para su uso posterior. Quizá usted desee usar la información con fines de informes en el futuro.

  • Almacenar los resultados de la API en un archivo que se expande continuamente a medida que se agregan nuevos resultados. A lo largo del tiempo y a medida que el archivo crece en tamaño, esto genera costos de almacenamiento.

  • Almacenar archivos en NiCE CXone Cloud Storage. Si utiliza Cloud Storage, asegúrese de estar al tanto de cualquier parámetro relacionado con el almacenamiento. Puede consultar el contenido de ayuda para Cloud Storage o comunicarse con un representante de soporte.

Llamadas a la API desde Studio

Las API le ayudan a trabajar de manera eficiente y efectiva con los datos. Puede realizar Llamadas a la API desde Studio con las acciones que se enumeran a continuación. La siguiente lista explica las diferencias técnicas entre el uso de las distintas acciones:

  • SNIPPET: Le permite agregar código personalizado a un script. Puede usar esta Acción para realizar Llamadas a la API, preparar payloads, analizar objetos de datos dinámicos, entre otros. Al realizar Llamadas a la API con esta acción, tenga cuidado con la velocidad de respuesta. Esta acción utiliza un subproceso durante todo el tiempo que está activa. Si la respuesta es lenta, es decir, si el subproceso permanece bloqueado todo el tiempo, esto puede afectar negativamente el rendimiento del servidor. Por ejemplo, es posible que la persona que llama escuche silencio en la línea si todos los subprocesos están siendo utilizados al mismo tiempo.

  • REST API: Le permite realizar Llamadas a la API REST y utiliza menos recursos del servidor. Debe usar esta Acción para realizar Llamadas a la API siempre que sea posible; sin embargo, esta acepta específicamente JSON. Si una API no devuelve JSON, es posible que deba usar la acción SNIPPET en su lugar. Según la tarea, es posible que deba usar esta acción en combinación con SNIPPET, ya que SNIPPET puede realizar tareas como preparar payloads.

  • CONNECTAUTH: Autentica un conector creado en Integration Hub. Integration Hub es una fuente centralizada para compilar, administrar y ejecutar integraciones desde NiCE CXone hacia plataformas de terceros. Esta Acción no bloquea subprocesos.

  • CONNECTREQUEST: Activa una solicitud de Integration Hub después de que se haya autenticado. Esta Acción no bloquea subprocesos.

Otras acciones de Studio relacionadas con datos

Studio tiene varias acciones que almacenan y recuperan temporalmente pequeñas cantidades de datos de una tabla de base de datos a fin de que los datos sean accesibles para otros scripts. Estas acciones se comportan como una lista de campos o valores. Utilícelas para almacenar valores múltiples o valores que se necesiten más adelante en otros scripts. La lista completa de acciones es la siguiente: PUTVALUE, GETVALUE, REMVALUE, GETLIST y CLEARLIST.

Estas acciones utilizan un tipo de datos único al que solo se puede acceder mediante este conjunto de acciones de Studio. Los datos no son accesibles de ninguna otra manera. Los usuarios no pueden acceder a esta base de datos y utilizarla, independientemente de sus permisos.

Los valores se incluyen en una tabla de base de datos durante un período de tiempo limitado, según lo configurado en la propiedad Ttl en horas (tiempo de vida) de la acción PUTVALUE. El valor predeterminado es 24 horas, pero puede variar entre una hora y 168 horas (siete días). Puede usar la acción REMVALUE para eliminar los datos antes de que transcurra el tiempo de TTL. Esto le brinda control total sobre los datos dentro de sus scripts. La práctica recomendada es eliminar los valores cuando ya no se vayan a utilizar y dejar el TTL en el valor predeterminado de 24 horas.

Notas:

  • Si otros scripts o contactos necesitan acceder a varias variables, por lo general una base de datos es la mejor solución.
  • Las variables públicas no persistentes pueden ser compartidas por otros scripts o contactos durante toda la vida del script que establece esas variables. Las variables se eliminan automáticamente una vez que se liberan.
  • Estas acciones tienen un límite de 1000 elementos en la "lista". Un solo elemento, o fragmento de datos, también tiene un límite de 5 KB.