Gestión de datos

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

La herramienta adecuada para el trabajo adecuado

El propósito primario de Studio es controlar la ruta de contacto. Cualquier cosa que haga en un script de Studio debe estar enfocado en el contacto. Cualquier procesamiento de datos que necesite que no esté relacionado con un contacto debe hacerse 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 trabaja con contactos y mantiene ejecutando eficientemente a los servidores.

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 no apropiada: Crear un script Studio programado que se ejecuta todos los días. El script primero hace llamadas API para desplegar la lista de agentes en el día y posteriormente mostrar el historial de estados del agente del día. Posteriormente el script revisa para ver si cualquier agente tomó una pausa por más de 30 minutos que no estaba programada. También busca las pausa claramente largas, como una pausa para ir al baño de cuatro horas. El script también determina qué agentes pasaron más tiempo en un estado no disponible, y que agentes pasaron la mayor parte del tiempo en una habilidadCerrado Se utiliza para automatizar la entrega de interacciones basadas en las habilidades, capacidades y conocimientos de los agentes 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 tiene el propósito de procesar grandes cantidades de datos, está diseñado para manejar contactos. Su abonadoCerrado Agrupación organizativa de alto nivel utilizado para administrar el soporte técnico, facturación y configuración global para su CXone entorno puede sufrir problemas de desempeño porque muchos datos de memoria suponen un mal rendimiento de los servidores.

  • 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 debiera ejecutarse durante un largo periodo de tiempo, lo cual demanda de muchos recursos.

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

  • Studio funciona mejor identificando información como un agente que pasó más tiempo en un cierto estado 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 únicamente un método potencial para resolver la tarea. Las soluciones para sus escenarios pueden demandar un enfoque diferente.

Un método de resolver esta tarea es mediante Python ejecutándose en un servidor AWS, que ofrece mayor poder de procesamiento. Desde el servidor, hacer las mismas llamadas API para mostrar la lista de agentes y el historial de estados de los agentes en el día. Colocar los datos en una tabla o quizá en un arreglo. Una tabla de una base de datos sería la preferencia para permitirle comparar más fácilmente y analizar los datos en el futuro. Los datos devueltos serían posiblemente en megabytes, lo cual no es problema en una base de datos, pero excede el límite de datos en Studio. Podría tener todo el historial de estados para cada agente en la memoria; tendría los datos completos en un lugar en vez de algunos datos en un script de Studio.

Ahora ya podría comenzar trabajando con los datos para producir las métricas deseadas, como una lista ordenada de agentes basada en el tiempo empleado en ciertos estados. Una base de datos le ayuda a presentar estos datos según vea conveniente, en vez de que esté dentro de los límites 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. Autenticar:
    1. Realizar el descubrimiento de autenticación para adquirir un enlace de token. Se puede colocar en caché el token resultante.
    2. Solicitar un token desde el punto de referencia del token que aparece en el paso anterior:
      1. Crear una solicitud POST para https://cxone.niceincontact.com/auth/token con un cuerpo x-www-formulario-conurlcodificado.
      2. Devuelve los cinco pares de valores clave, como su client_secret y client_id.
  2. Realizar un descubrimiento del punto de referencia API:
    1. Extraer la tenantId desde el token devuelto en el paso 1 anterior.
    2. Hacer una solicitud GET a https://cxone.niceincontact.com/.well-known/cxone-configuration?tenantId={SU ID DE INQUILINO}. Ejemplo de respuesta: 
      {
	"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. Extract the "area" and "domain" fields from the reply.
    4. Construct a base URI in the form of: https://api-{area}.{domain}.

  3. Crear un mapeo de lista de llamadas usando POST /listas/listas_llamadas .

    Esta API crea una lista de llamadas identificada con un {listId}. Cada llamada actualiza el mapeo de datos de los nombres de las columnas fuente para los campos CXone. En general, únicamente haría eso cuando cambien los encabezados de columna en los datos. Para esta API, debe definir valores como parámetros de consulta, luego proporcionar un cuerpo JSON con un arreglo de pares de destinationMappings, cada uno de los cuales se compone de un fieldName y un fieldValue. Estos se usan para mapear los datos cargados en el paso 4 a continuación.

    Puede encontrar definidos los nombres de campo por CXone aquí en la ayuda en línea. Los valores de los campos son los nombres de las columnas en los datos fuente para mapear al campo CXone.

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

    {
	"listId": 0
}

  4. Utilizar los datos de la lista de llamadas usando POST /lists/call-lists/{listId}/upload  con el listId que se creó en el paso 3. El listId se especifica en la ruta de la llamada API y los datos reales de la lista de llamadas se transfieren en el cuerpo de la solicitud.

    Un detalle importante es el formato del archivo. El parámetro listFile son los datos de la lista de llamadas como archivo codificado a base 64.

    También puede elegir iniciar la habilidad de marcador al concluir la carga colocando la bandera "startSkill" en "true" como parte del cuerpo de la solicitud.

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

Durante las llamadas activas, el centro de contacto Jungle quiere llamar a los datos personalizados de su CRM y mostrarlos en su La aplicación del agente. En Studio, capturan información de identificación básica desde el contacto, como un número de cuenta. Posteriormente, el script hace una solicitud GET a su CRM, revisando si la información coincide con un registro de un cliente. Si existe un registro, devuelve todos los datos del cliente. La Jungle no quiere desplegar todos los datos del cliente, y la API no les permite especificar qué devolver.

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

Push frente a llamar

En general, es mejor que use una arquitectura basada en push. Esperar que algo suceda mediante llamada naturalmente cuesta recursos, en tanto que hacer un push de datos es según demanda, no consume recursos cuando no se necesita. Hacer un push de datos normalmente le permite manejar porciones más pequeñas de datos. Hacer un push de datos se hace normalmente para necesidades en tiempo real como un contacto activo único. Las llamadas se usan normalmente en las integraciones y no se pueden desglosar o segmentar tanto.

Por ejemplo, quizá desee actualizar la IU del agente al poner en espera una llamada telefónica. Si usara la API /get-next-event en un script para escuchar (o llamar) un evento de espera desde el cliente del agente, esto bloquearía constantemente un hilo. Por el contrario, será mejor que haga un push de datos en una sola instancia para evitar el uso constante de recursos del servidor. En situaciones similares, quizá con las integraciones de los CRM, en vez de esperar que se devuelva una solicitud, hacer una llamada API que haga el push de datos y libere el hilo. Posteriormente, usar la señal con la que la API devuelve los datos al script. También podría hacer una llamada a la API para ver si ha concluido esa solicitud, y si es así, para enviar los datos.

Procesar grandes cantidades de datos

Si desea manejar datos mayores, como los datos históricos de todo su centro de contacto, use las CXone API o Intercambio de datos CXone. A gran escala, puede usar Snowflake para traer a todos los datos de su unidad de negocios; Intercambio de datos CXone le otorga una ruta directa para los datos de su centro de contactos, de manera que no se limite a hacer las llamadas a la API para traer datos. En una escala menor, la tarea ejemplo que se explica más arriba 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, podría diseñar una aplicación que envíe correos a los gerentes si tienen empleados que pasan mucho tiempo en un cierto estado.

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

Lo siguiente ejemplifica los escenarios comunes donde puede evitar usar grandes volúmenes de datos en sus scripts de Studio. También puede consultar el ejemplo más arriba, 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 capacidad de filtrar qué información se devuelve. Por ejemplo, si solicita a un CRM que devuelva información para un caso, algunas API de CRM le permiten especificar exactamente qué campos de información desea devolver. Si la API que está usando ofrece esta funcionalidad, puede evitar grandes volúmenes de datos trabajando únicamente exactamente con la información que necesita. Si la API de un proveedor no cuenta con esta funcionalidad, quizá pueda trabajar con el proveedor para agregar la opción, o puede diseñar un middleware. El middleware puede recibir los datos antes Studio, usted puede filtrar lo que no es necesario, después devolver los datos a Studio.

  • Filtrado de las respuestas de la API por tiempo:

    Si una API le permite filtrar una cantidad de tiempo, use esta funcionalidad para minimizar la cantidad de datos. Si únicamente necesita los datos de un día o una semana, asegúrese de filtrar la respuesta para que incluya únicamente los datos dentro de ese rango 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 funciones de las acciones Studio y Studio le permiten trabajar con datos enfocados principalmente en un contacto particular. Puede mantener sus datos específicos para contactos particulares con técnicas como reunir información a través de una IVR o trayendo los datos del CRM por un registro o caso a la vez.

Almacenamiento de datos

Usted tiene muchas opciones para almacenar datos. Si cuenta con una cuenta de Snowflake, puede mover sus datos del centro de contactos desde CXone a Snowflake usando Studio. NICE almacena sus datos durante 24 meses, los cuales puede llamar desde Snowflake. También puede usar los Servicios de almacenamiento en la nube para almacenar archivos como llamar grabaciones o transcripciones del chat, o moverlos a sus propios servidores. Póngase en contacto con su CXone representante de soporte para obtener más información.

Costos no esperados

En general, no incurrirá en costos adicionales basados en hacer muchas llamadas API o algo similar. Sin embargo, la manera en que 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 en los scripts y almacenarlos en un archivo de texto para cada contacto sin incluir un proceso para limpiar esos archivos.

  • Almacenar IVR presione la información de la ruta en los 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 conforme se añaden nuevos resultados. Con el tiempo y según crece el tamaño del archivo, eso genera costos de almacenamiento.

  • Almacenar archivos en CXone Almacenamiento en la nube. Si usa Almacenamiento en la nube, asegúrese de conocer cualquiera de los parámetros del almacenamiento. Puede hacer referencia al contenido de ayuda para Almacenamiento en la nube o ponerse en contacto con un representante de soporte.

Llamadas API desde Studio

Las API le ayudan a trabajar de manera eficiente y efectiva con los datos. Usted puede hacer llamadas de API desde Studio con las acciones que se listan a continuación. La siguiente lista explica las diferencias técnicas entre usar las acciones diferentes:

  • SNIPPET: Le permite agregar código personalizado a un script. Puede usar esta acción para hacer llamadas API, preparar cargas útiles, analizar datos dinámicos de datos, etc. Al hacer llamadas a la API con esta acción, cuide la velocidad de respuesta. Esta acción utiliza un hilo que está activo todo el tiempo. Si la respuesta es lenta, lo que significa que el hilo está bloqueado todo el tiempo, puede impactar negativamente sobre el desempeño del servidor. Por ejemplo, quien llama puede oír aire muerto si todos los hilos se utilizan al mismo tiempo.

  • REST API: Le deja hacer las llamadas de la API REST y utiliza menos recursos del servidor. Debería usar esta acción para hacer llamadas API cuando sea posible, aunque de manera específica acepta JSON. Si una API no devuelve JSON, quizá necesite usar la acción SNIPPET en su lugar. Dependiendo de su tarea, quizá necesite usar esta acción en conjunto con SNIPPET, porque SNIPPET puede hacer cosas como preparar cargas útiles.

  • ConnectAuth: Autentica el conector creado en Integration Hub. Integration Hub es una fuente centralizada para construir, manejar y ejecutar integraciones desde CXone a plataformas de terceros. Esta acción no bloquea los hilos.

  • ConnectRequest: Activa una solicitud Integration Hub después de haber sido autenticada. Esta acción no bloquea los hilos.

Otras Acciones Relacionadas con Datos Studio

Studio tiene varias acciones que almacenan temporalmente y obtienen pequeñas cantidades de ddatos desde una tabla de la base de datos para hacer disponibles los datos a otros scripts. Estas acciones se comportan como una lista de campos o valores. Úselos para almacenar múltiples valores, o valores necesarios más adelante en otros scripts. La lista completa de acciones son: PUTVALUE, GETVALUE, REMVALUE, GETLIST y CLEARLIST.

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

Los valores se enumeran en una tabla de la base de datos durante un período limitado, según lo configurado en la TTL hrs propiedad (tiempo de vida) de la acción PUTVALUE. El valor predeterminado es 24 horas, pero puede tener un rango de una hora a 168 horas (siete días). Puede usar la acción REMVALUE para eliminar datos antes del tiempo TTL. Esto le da un control completo sobre los datos dentro de sus scripts. La mejor práctica es eliminar los valores cuando ya no se usan y dejar el TTL en las 24 horas predeterminadas.

Notas:

  • Si varias variables necesitan ser accedidos por otros scripts o contactos, una base de datos es generalmente la mejor solución.
  • Las variables públicas no persistentes las pueden compartir otros scripts o contactos durante toda la vida del script que define dichas variables. Las variables se limpian automáticamente una vez que se liberan.
  • Estas acciones tienen un límite de 1000 artículos en la "lista". Un sólo artículo, o dato, también tiene un límite de 5KB.