Data Management
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 NiCE CXone y puede necesitar trabajar con datos dentro de NiCE CXone. La forma en que trabaja con los datos en los scripts de Studio o las API afecta el rendimiento de su sistema y la calidad de sus interacciones. Esta página le ayuda a administrar 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 realizar y que no esté relacionado con contactos debe hacerse fuera de Studio. Studio no está diseñado para procesar grandes cantidades de datos, por lo que tiene un límite de datos de 32 KB. 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 todos los días para identificar potenciales problemas, como recesos demasiado largos o recesos no programados.
Solución inapropiada: Crear un script Studio programado que se ejecute todos los días. El script primero realiza Llamadas a la API para obtener la lista de agent del día y, luego, obtener el historial de estado de 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 cualquier receso excesivamente largo, como un receso 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 qué agentes pasaron más tiempo en una habilidad
Used to automate delivery of interactions based on agent skills, abilities, and knowledge. 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 abonado
High-level organizational grouping used to manage technical support, billing, and global settings for your NiCE CXone system. 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 podría ejecutarse durante un período de tiempo prolongado, lo cual consume muchos recursos.
-
Esta tarea la puede resolver mejor el equipo de ingeniería, que puede usar las API de NiCE CXone, en lugar de un script de 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étricas más 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 para resolver esta tarea es con Python ejecutándose en un servidor AWS, lo cual ofrece más potencia de procesamiento. Desde el servidor, realice las mismas Llamadas a la API para extraer la lista de agent y el historial de estado de agente del día. Coloque los datos en una tabla o quizás en una matriz. Una tabla de base de datos sería la opción preferida para permitirle comparar y analizar los datos más fácilmente 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.
- Authenticate:
- Realice el descubrimiento de autenticación
para adquirir un enlace de token. Se puede colocar en caché el token resultante. - Request a token from the token endpoint discovered in the previous step:
- Crear una solicitud POST para https://cxone.niceincontact.com/auth/token con un cuerpo x-www-form-urlencoded.
- Recuperar los cinco pares clave-valor, como su client_secret y client_id.
- Realice el descubrimiento de autenticación
- Perform API endpoint discovery:
- Extraiga el inquilinoId del token devuelto en el paso 1 anterior.
- Realice una solicitud GET a https://cxone.niceincontact.com/.well-known/cxone-configuration?tenantId={YOUR TENANT ID}. 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" } - Extraiga los campos "área" y "domain" de la respuesta.
- Construya una uri base con el siguiente formato: https://API-{area}.{domain}.
-
Cree un mapeado de lista de llamada usando POST /lists/call-lists
.Esta API crea una lista de llamada identificada con un {listId}. Cada llamada actualiza el mapeo de datos de los nombres de las columnas fuente para los campos NiCE 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 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 usan para mapear los datos cargados en el paso 4 a continuación.
Puede encontrar definidos los nombres de campo por NiCE 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 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 resultado esperado sería un código 200 con un cuerpo de respuesta:
{ "listId": 0 } - 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 corresponde a los datos de la lista de llamada como un archivo codificado en base64.
Además, puede elegir iniciar la habilidad del marcador al completarse la carga, configurando la bandera "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
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 que The Jungle se mantenga dentro del límite de datos de 32 KB.
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. La inserción de datos (push) se realiza a menudo para necesidades en tiempo real, como un único contacto activo. 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. /get-next-event
API en un script para escuchar (o consultar) el evento de espera del cliente de 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 instancias similares, tal vez con integraciones de CRM, en lugar de esperar que una solicitud regrese, realice una Llamada a la API que envíe los datos y libere el subproceso. Luego, use la API para señalar
envía los datos de vuelta al script. También podría realizar una Llamada a la API para verificar si esa solicitud ha finalizado y, si es así, enviar los datos.
Procesar Grandes cantidades de datos
Si desea administrar conjuntos DE datos grandes, como los datos históricos de todo su centro de contacto, use las NiCE CXone API
o NiCE CXone Data Share. A gran escala, puede usar Snowflake para extraer todos los datos de su unidad de negocio; Data Share le brinda una canalización directa para los datos de su centro de contacto, de modo que no esté limitado a realizar Llamadas a la API para extraer 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 crear una aplicación que envíe correos electrónicos a los supervisores si tienen empleados que pasaron demasiado tiempo en un estado determinado.
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 anterior, que evita transferir demasiados datos del cliente desde un CRM a Studio.
-
Filtro de las respuestas de la API por campo:
Algunas API ofrecen la capacidad de filtrar la información que se devuelve. Por ejemplo, si 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 que se devuelvan. 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 de Studio; puede filtrar lo que sea innecesario y, luego, devolver los datos a Studio.
-
Filtro 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 solo necesita datos de un día o una semana, asegúrese de aplicar un filtro a la respuesta para incluir solo los datos dentro de ese período de tiempo.
-
Filtro de datos para contactos individuales:
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 tiene una cuenta de Snowflake, puede mover los datos de su centro de contacto de NiCE CXone a Snowflake mediante Studio. NiCE almacena sus datos durante 24 meses, los cuales puede recuperar de Snowflake. 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, 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 almacenarlas en un archivo de texto para cada contacto sin incluir un proceso para limpiar esos archivos.
-
Almacenamiento información de ruta de pulsación de 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 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 NiCE CXone Cloud Storage. Si usa Cloud Storage, asegúrese de conocer cualquiera de los parámetros del almacenamiento. You can reference the contenido de ayuda para Cloud Storage o comuníquese con un representante de soporte.
Llamadas a la API desde Studio
Las API le ayudan a trabajar con datos de manera eficiente y efectiva. 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 subproceso está bloqueado todo el tiempo, puede afectar negativamente el rendimiento del servidor. Por ejemplo, quien llama puede oír aire muerto si todos los hilos se utilizan al mismo tiempo.
-
REST API: Le permite realizar Llamadas a 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, es posible que deba usar la acción SNIPPET en su lugar. Según su tarea, es posible que deba usar esta acción en combinación con SNIPPET, ya que SNIPPET puede hacer cosas 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 los hilos.
-
CONNECTREQUEST: Activa una solicitud de Integration Hub después de que se haya autenticado. Esta acción no bloquea los hilos.
Otras Studio acciones relacionadas con datos
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. Úselas para almacenar valores múltiples, o valores necesarios más adelante en otros Scripts. La lista completa de acciones es: 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 base de datos durante un 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 tener un rango de una hora a 168 horas (siete días). Puede usar la acción REMVALUE para eliminar datos antes de la hora de 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.
Notes:
- If several variables need to be accessed by other scripts or contacts, a database is generally the best solution.
- Non-persistent public variables can be shared by other scripts or contacts throughout the life of the script that sets those variables. The variables are automatically cleaned up once they are released.
- These actions have a limit of 1000 items in the "list". A single item, or piece of data, also has a 5 KB limit.